اتوماسیون تست (Test Automation) یعنی اجرای تستها با کد و ابزار، بهجای اجرای دستی مرحلهبهمرحله. تست خودکار وقتی درست انتخاب شود، بازخورد را سریعتر میکند و وقت تسترها را برای کارهای تحلیلی آزاد میکند. در این راهنما میبینیم اتوماسیون تست چه زمانی ارزش دارد، از کجا شروع کنیم و چطور آن را پایدار نگه داریم.
اگر با مفاهیم پایه آشنا نیستید، اول راهنمای تست نرمافزار چیست را بخوانید.
اتوماسیون تست چیست و چه چیزی نیست
در اتوماسیون، یک اسکریپت ورودیها را به سیستم میدهد، خروجی را میگیرد و با نتیجه مورد انتظار مقایسه میکند. نتیجه نهایی پاس یا شکست است و بدون دخالت انسان ثبت میشود.
تفاوت تست خودکار با تست دستی
| ویژگی | تست دستی | تست خودکار |
|---|---|---|
| هزینه شروع | پایین | بالاتر؛ نیاز به کدنویسی و زیرساخت |
| هزینه هر اجرای تکراری | ثابت و قابل توجه | پایین |
| سرعت اجرا | کند | سریع و قابل اجرای موازی |
| کشف مشکلات غیرمنتظره | خوب؛ انسان چیزهای خارج از سناریو را میبیند | محدود به بررسیهای تعریفشده |
| بررسی ظاهر و تجربه کاربری | مناسب | محدود |
| نگهداری | بهروزرسانی مستندات | بهروزرسانی کد تست |
این جدول نشان میدهد که دو روش جایگزین هم نیستند. هرکدام جای خودش را دارد.
چیزی که اتوماسیون جایگزینش نمیشود
اتوماسیون فقط چیزی را بررسی میکند که به آن گفتهاید. تست اکتشافی، قضاوت درباره تجربه کاربری و طراحی تست هنوز کار انسان است. تیمی که همه تست دستی را حذف میکند، معمولاً باگهایی را از دست میدهد که هیچ اسکریپتی دنبالشان نبود.
یک باور نادرست رایج هم این است که اتوماسیون تسترها را حذف میکند. در عمل، نقش تستر از اجرای تکراری به طراحی، تحلیل و نگهداری تستها تغییر میکند. برای آشنایی با این مسیر شغلی، نقشه راه مهندسی تست را ببینید.
چه زمانی اتوماسیون ارزش دارد
اتوماسیون سرمایهگذاری است. ارزش آن در اجرای تکراری آشکار میشود.
نشانههای آمادگی
- تستهای رگرسیون هر بار زمان بیشتری میگیرند.
- یک سناریو با دادههای زیاد باید بارها تکرار شود.
- انتشارها مرتب و پشت سر هم انجام میشوند.
- بخشهایی از محصول به ثبات نسبی رسیدهاند.
- تیم توسعه از خط لوله یکپارچهسازی مداوم استفاده میکند.
- اعضای تیم مهارت کدنویسی دارند یا فرصت یادگیری آن هست.
نشانههایی که هنوز زود است
- محصول در مرحله کشف است و رابط کاربری هر هفته عوض میشود.
- تستکیسهای دستی هنوز مستند یا پایدار نیستند.
- محیط تست قابل اعتماد و قابل تکرار وجود ندارد.
- کسی مسئولیت نگهداری تستها را نپذیرفته است.
در این وضعیتها، اول پایهها را درست کنید. خودکار کردن یک فرایند نامنظم، فقط بینظمی را سریعتر میکند.
یک محاسبه ساده برای تصمیم
برای هر تست نامزد، سه عدد را تخمین بزنید: زمان ساخت اسکریپت، زمان نگهداری در هر دوره و زمان صرفهجوییشده در هر اجرا. اگر تست در سال بارها اجرا میشود و نگهداریاش کم است، اتوماسیون منطقی است. اگر فقط چند بار اجرا میشود، احتمالاً نه.
هرم تست و انتخاب لایه مناسب
هرم تست یک مدل ساده برای توزیع تستهای خودکار است. پایه هرم تستهای سریع و ارزان است و رأس آن تستهای کند و پرهزینه.
| لایه | چه چیزی را بررسی میکند | سرعت | هزینه نگهداری | معمولاً چه کسی مینویسد |
|---|---|---|---|---|
| تست واحد (Unit) | یک تابع یا کلاس بهتنهایی | بسیار سریع | پایین | توسعهدهنده |
| تست یکپارچهسازی و API | ارتباط بین ماژولها و سرویسها | سریع | متوسط | توسعهدهنده و مهندس تست |
| تست رابط کاربری (End-to-End) | جریان کامل کاربر در مرورگر یا اپ | کند | بالا | مهندس تست |
پیام اصلی هرم این است: بیشترین تستها در لایههای پایینتر باشند. هر منطقی که بدون رابط کاربری قابل بررسی است، همانجا بررسی شود. تستهای رابط کاربری را برای جریانهای حیاتی نگه دارید.
الگوی قیف وارونه
بعضی تیمها اتوماسیون را از رابط کاربری شروع میکنند و تقریباً تست واحدی ندارند. نتیجه، مجموعهای کند و شکننده است. اگر در این وضعیت هستید، تستهای جدید را تا حد امکان در لایه API بنویسید. بهتدریج بار را از رابط کاربری به لایههای پایین منتقل کنید.
جزئیات سطوح مختلف تست را در انواع تست نرمافزار مرور کردهایم.
انتخاب تستها برای خودکارسازی
همه تستها ارزش خودکار شدن ندارند. این معیارها به انتخاب کمک میکنند:
- تکرار زیاد: تست در هر بیلد یا هر انتشار اجرا میشود.
- نتیجه قطعی: نتیجه مورد انتظار روشن و قابل مقایسه است.
- پایداری قابلیت: رفتار قابلیت بهزودی تغییر نمیکند.
- اهمیت کسبوکار: خرابی آن هزینه بالایی دارد.
- حجم داده: یک سناریو باید با ورودیهای زیاد اجرا شود.
- دشواری اجرای دستی: مثل بررسی محاسبات پیچیده یا مقایسه فایلهای بزرگ.
نامزدهای ضعیف
- تستهایی که فقط یک بار اجرا میشوند
- بررسیهای ظاهری مثل چینش و رنگ
- قابلیتهایی که طراحیشان هنوز در حال تغییر است
- سناریوهایی که به تصمیم انسانی نیاز دارند
یک پیشنهاد عملی: از تستهای دود و مسیرهای حیاتی رگرسیون شروع کنید. این تستها بیشترین تکرار را دارند و ارزششان زود دیده میشود.
انتخاب ابزار و فریمورک
انتخاب ابزار باید بعد از روشن شدن نیاز انجام شود، نه قبل از آن.
معیارهای انتخاب
- زبان برنامهنویسی تیم: ابزاری که با زبان محصول یکسان است، همکاری توسعهدهندهها را سادهتر میکند.
- نوع محصول: وب، موبایل، دسکتاپ یا API هرکدام ابزارهای خاص خود را دارند.
- جامعه کاربری و مستندات: ابزار پرکاربرد منابع آموزشی و پاسخ بیشتری دارد.
- گزارشدهی و خروجی: خروجی استاندارد مثل JUnit XML اتصال به ابزارهای دیگر را ساده میکند.
- پشتیبانی از اجرای موازی: با بزرگ شدن مجموعه، زمان اجرا مهم میشود.
دستههای رایج ابزار
- فریمورکهای تست واحد: مثل JUnit، pytest، Jest و Pest؛ معمولاً همراه زبان برنامهنویسی انتخاب میشوند.
- تست رابط کاربری وب: مثل Selenium، Playwright و Cypress.
- تست موبایل: مثل Appium و ابزارهای بومی هر پلتفرم.
- تست API: کتابخانههای HTTP در فریمورک تست، یا ابزارهایی مثل Postman.
- تست کارایی: ابزارهایی مثل JMeter و k6.
ابزار را با یک پروژه آزمایشی کوچک امتحان کنید. چند تست واقعی بنویسید، در خط لوله اجرا کنید و خروجی گزارش را ببینید. بعد تصمیم نهایی را بگیرید.
گامهای شروع اتوماسیون تست
یک مسیر مرحلهای، ریسک شروع را کم میکند:
- هدف را مشخص کنید: مثلاً «کاهش زمان رگرسیون پیش از انتشار» یا «بازخورد سریع در هر ادغام».
- تستکیسهای دستی را مرتب کنید: تست خودکار خوب از تستکیس دستی شفاف میآید. راهنمای نوشتن تستکیس در این مرحله کمک میکند.
- یک ناحیه کوچک انتخاب کنید: مثلاً ده سناریوی حیاتی.
- زیرساخت را آماده کنید: محیط تست پایدار، داده تست قابل بازسازی و دسترسی به خط لوله.
- استانداردها را تعریف کنید: نامگذاری، ساختار پوشهها، الگوی Page Object یا مشابه آن و بازبینی کد تست.
- در خط لوله اجرا کنید: تستی که فقط روی سیستم یک نفر اجرا میشود، هنوز بخشی از فرایند نیست.
- نتیجه را بسنجید و گسترش دهید: بعد از چند هفته ببینید هدف اول چقدر محقق شده است.
کد تست هم کد است
کد تست باید مثل کد محصول بازبینی، نسخهبندی و بازآرایی شود. تکرار کد، انتظارهای ثابت زمانی (Sleep) و وابستگی تستها به هم، دلیلهای رایج شکنندگی هستند. هر تست باید مستقل اجرا شود و داده خودش را بسازد یا آماده کند.
اتوماسیون در خط لوله CI/CD
ارزش واقعی تست خودکار وقتی دیده میشود که در CI/CD اجرا شود. یعنی با هر تغییر کد، بدون درخواست کسی.
چیدمان پیشنهادی
- در هر ادغام: تستهای واحد و مجموعه کوچکی از تستهای API.
- در بیلد شبانه: رگرسیون خودکار گستردهتر و تستهای رابط کاربری.
- پیش از انتشار: رگرسیون کامل خودکار همراه با تستهای دستی هدفمند.
مدیریت تستهای ناپایدار
تست ناپایدار تستی است که بدون تغییر کد، گاهی پاس و گاهی شکست میخورد. علتهای رایج اینهاست:
- انتظار ثابت بهجای انتظار برای یک شرط مشخص
- وابستگی به ترتیب اجرای تستها
- داده مشترک بین تستها
- وابستگی به سرویس بیرونی ناپایدار
- تفاوت منطقه زمانی یا تاریخ سیستم
تست ناپایدار را نادیده نگیرید. آن را از مسیر اصلی جدا کنید، علتش را پیدا کنید و بعد برگردانید. اگر تیم عادت کند شکستها را «دوباره اجرا» کند، باگهای واقعی هم نادیده گرفته میشوند.
داده و محیط تست پایدار
بسیاری از شکستهای بیدلیل از داده و محیط میآیند، نه از کد تست. هر اجرا باید با دادهای شروع شود که وضعیتش مشخص است. داده را پیش از هر تست بسازید یا از یک نسخه پایه بازیابی کنید. محیط تست خودکار را از محیطی که تسترها دستی روی آن کار میکنند جدا نگه دارید.
رویکردهای تستمحور
در توسعه تستمحور، توسعهدهنده قبل از کد اصلی، تست واحد را مینویسد. در توسعه رفتارمحور، سناریوها با زبانی نزدیک به زبان کسبوکار نوشته میشوند. هر دو رویکرد اتوماسیون را از ابتدای توسعه وارد فرایند میکنند.
اتصال نتایج اتوماسیون به مدیریت تست
وقتی تست خودکار و دستی در دو جای جدا ثبت میشوند، تصویر کلی کیفیت ناقص میماند. مدیر محصول میخواهد بداند یک نیازمندی تست شده یا نه، نه اینکه با چه روشی.
چه چیزی را ثبت کنیم
- نتیجه هر تست خودکار در هر اجرا
- نسخه یا بیلدی که تست روی آن اجرا شد
- پیوند به لاگ یا گزارش کامل خط لوله
- ارتباط تست خودکار با تستکیس و نیازمندی مربوط
سنجش پیشرفت اتوماسیون
چند شاخص ساده برای پیگیری کافی است: درصد تستهای رگرسیون خودکارشده، زمان اجرای مجموعه، تعداد تستهای ناپایدار و باگهایی که تست خودکار پیدا کرده است. تعریف دقیقتر این شاخصها را در معیارهای تست ببینید.
در TestRail میتوانید برای هر تستکیس مشخص کنید که خودکار است یا دستی و نتیجه تستهای خودکار را از طریق API در همان اجرای تست (Test Run) ثبت کنید. به این ترتیب نتیجههای دستی و خودکار با وضعیتهای Passed، Failed، Blocked و Retest کنار هم دیده میشوند و در گزارشها و مایلستونها جمع میشوند. اتصال به Jira هم پیوند نتیجهها با باگها را ساده میکند. برای دیدن گزینههای اتصال به ابزارهای CI و ردیابی باگ، صفحه یکپارچهسازیهای TestRail را ببینید.
جمعبندی
اتوماسیون تست ابزاری برای بازخورد سریعتر و رگرسیون قابل اتکاتر است، نه جایگزین قضاوت انسانی. از هدف روشن و ناحیه کوچک شروع کنید. بیشترین تستها را در لایههای پایین هرم بنویسید و تستهای رابط کاربری را برای جریانهای حیاتی نگه دارید. تستها را در خط لوله اجرا کنید، تستهای ناپایدار را جدی بگیرید و نتیجهها را کنار تستهای دستی ثبت کنید. برای مرور مفاهیم پایه، به راهنمای تست نرمافزار برگردید.