انواع تست نرمافزار هر کدام بخش مشخصی از کیفیت محصول را میسنجند. شناخت این انواع به تیم کمک میکند تست درست را در زمان درست اجرا کند. این مقاله انواع تست را از تست واحد تا تست پذیرش، همراه با کاربرد هر کدام، دستهبندی میکند.
دستهبندی انواع تست نرمافزار
تستها را میتوان از چند زاویه دستهبندی کرد. یک تست ممکن است همزمان در چند دسته قرار بگیرد. مثلاً یک تست رگرسیون میتواند خودکار، عملکردی و در سطح سیستم باشد. چهار زاویه اصلی اینها هستند:
| زاویه دستهبندی | پرسش اصلی | نمونهها |
|---|---|---|
| سطح تست | کدام بخش از سیستم تست میشود | واحد، یکپارچگی، سیستم، پذیرش |
| هدف تست | چه ویژگیای سنجیده میشود | عملکردی، غیرعملکردی |
| دانش از کد | تستر چقدر از ساختار داخلی خبر دارد | جعبه سیاه، جعبه سفید، جعبه خاکستری |
| روش اجرا | تست چطور اجرا میشود | دستی، خودکار، اکتشافی |
تست ایستا و تست پویا
یک دستهبندی کلیتر هم وجود دارد. تست ایستا بدون اجرای کد انجام میشود؛ مثل بازبینی نیازمندی، بازبینی کد و تحلیل ایستای کد با ابزار. تست پویا با اجرای نرمافزار انجام میشود و همه انواعی که در ادامه میآیند در این دسته هستند. تست ایستا ارزانترین راه پیدا کردن خطاست، چون پیش از نوشتن یا اجرای کد انجام میشود.
اگر تازه با مفاهیم تست آشنا میشوید، ابتدا راهنمای جامع تست نرمافزار را بخوانید.
سطوح تست: از تست واحد تا تست پذیرش
سطوح تست به ترتیب از کوچکترین بخش کد تا کل سیستم پیش میروند. هر سطح باگهای خاص خودش را پیدا میکند.
تست واحد
تست واحد (Unit Testing) کوچکترین بخش قابل تست کد، مثل یک تابع یا کلاس، را بهصورت مستقل بررسی میکند. وابستگیها معمولاً با نمونههای جعلی جایگزین میشوند. این تستها را معمولاً توسعهدهنده مینویسد. تست واحد سریع است و در هر بیلد اجرا میشود. روش TDD هم بر نوشتن تست واحد پیش از کد تکیه دارد.
تست یکپارچگی
تست یکپارچگی (Integration Testing) تعامل بین ماژولها، سرویسها یا سیستمهای بیرونی را بررسی میکند. مثلاً آیا سرویس سفارش داده را درست به سرویس انبار میفرستد. باگهای رایج این سطح، ناسازگاری قالب داده، خطای قرارداد API و مشکلات زمانبندی هستند.
تست سیستم
تست سیستم (System Testing) کل سیستم یکپارچه را در برابر نیازمندیها میسنجد. این تست در محیطی نزدیک به محیط عملیاتی انجام میشود. معمولاً تیم QA آن را اجرا میکند و هم تست عملکردی و هم غیرعملکردی را پوشش میدهد.
تست پذیرش
تست پذیرش (Acceptance Testing) تأیید میکند که محصول برای استفاده آماده است. انواع رایج آن:
- تست پذیرش کاربر: کاربران یا نمایندگان کسبوکار سناریوهای واقعی را اجرا میکنند.
- تست آلفا: در محیط سازنده و توسط کاربران داخلی انجام میشود.
- تست بتا: نسخه محدود در اختیار گروهی از کاربران واقعی قرار میگیرد.
- تست پذیرش قراردادی و قانونی: انطباق با قرارداد یا الزامات قانونی بررسی میشود.
تست عملکردی و انواع آن
تست عملکردی بررسی میکند که سیستم «چه کاری» انجام میدهد. مرجع آن نیازمندیها و معیارهای پذیرش است. چند نوع پرکاربرد تست عملکردی:
تست دود
تست دود (Smoke Testing) بررسی سریع قابلیتهای حیاتی روی یک بیلد جدید است. اگر تست دود رد شود، بیلد برای تست عمیقتر پذیرفته نمیشود. این تست معمولاً کوتاه است و اغلب خودکار میشود.
تست سلامت
تست سلامت (Sanity Testing) پس از یک اصلاح یا تغییر کوچک انجام میشود. تمرکز آن محدود به همان بخش تغییریافته است. هدف این است که مطمئن شویم اصلاح کار میکند و بخش مرتبط آسیب ندیده است.
تست رگرسیون
تست رگرسیون اطمینان میدهد که تغییرات جدید قابلیتهای قبلی را خراب نکرده است. با رشد محصول، این مجموعه بزرگ میشود و بهترین کاندیدای اتوماسیون است. جزئیات انتخاب و اولویتبندی این تستها در مقاله تست رگرسیون آمده است.
تست تأییدی
تست تأییدی (Confirmation Testing) پس از رفع یک باگ انجام میشود. همان تستکیسی که باگ را پیدا کرده بود، دوباره اجرا میشود. اگر قبول شود، باگ بسته میشود. این تست معمولاً با یک دور کوتاه رگرسیون روی بخشهای مرتبط همراه است. مسیر کامل یک باگ از ثبت تا بسته شدن را در مقاله چرخه عمر باگ و گزارش باگ ببینید.
تست API
در تست API، درخواستها مستقیم به سرویس فرستاده و پاسخها بررسی میشوند. این تست بدون رابط کاربری انجام میشود، پس سریعتر و پایدارتر است. کدهای وضعیت، ساختار پاسخ، اعتبارسنجی ورودی و پیامهای خطا از موارد اصلی آن هستند. تست API بخش مهمی از لایه میانی هرم تست است.
تست سرتاسری
تست سرتاسری (End-to-End) یک جریان کامل کاربر را از ابتدا تا انتها بررسی میکند. مثلاً جستوجوی کالا، افزودن به سبد، پرداخت و دریافت پیامک تأیید. این تستها ارزشمند اما کند و شکنندهاند، پس تعدادشان باید محدود باشد.
تست غیرعملکردی
تست غیرعملکردی بررسی میکند سیستم «چطور» کار میکند. کاربر ممکن است یک قابلیت را درست ببیند، اما اگر کند یا ناامن باشد، تجربه خوبی ندارد.
| نوع تست | هدف | نمونه پرسش |
|---|---|---|
| تست کارایی | سنجش سرعت و پاسخگویی | زمان پاسخ صفحه جستوجو چقدر است |
| تست بار | رفتار در بار مورد انتظار | آیا سیستم با تعداد کاربر همزمان پیشبینیشده پایدار است |
| تست استرس | رفتار فراتر از ظرفیت | سیستم در چه نقطهای از کار میافتد و چطور بازیابی میشود |
| تست امنیت | یافتن آسیبپذیریها | آیا کاربر میتواند به داده کاربر دیگر دسترسی پیدا کند |
| تست کاربردپذیری | سنجش سهولت استفاده | آیا کاربر تازهوارد بدون راهنما خرید را کامل میکند |
| تست سازگاری | رفتار در محیطهای مختلف | آیا صفحه در مرورگرها و دستگاههای رایج درست نمایش داده میشود |
| تست دسترسپذیری | امکان استفاده برای همه کاربران | آیا فرم با صفحهخوان و صفحهکلید قابل استفاده است |
برای محصولات فارسیزبان، تست راستبهچپ، نمایش اعداد فارسی و تقویم شمسی هم بخش مهمی از تست سازگاری و کاربردپذیری است.
تست بر اساس دانش از کد
تست جعبه سیاه
در تست جعبه سیاه، تستر فقط ورودی و خروجی را میبیند. طراحی تست بر اساس نیازمندیها انجام میشود. افراز همارزی، تحلیل مقادیر مرزی و جدول تصمیم تکنیکهای رایج این رویکرد هستند.
تست جعبه سفید
در تست جعبه سفید، تست بر اساس ساختار داخلی کد طراحی میشود. هدف، پوشش مسیرها، شرطها و شاخههای کد است. پوشش کد معیار رایج سنجش این رویکرد است. البته پوشش بالا بهتنهایی کیفیت را تضمین نمیکند.
تست جعبه خاکستری
در تست جعبه خاکستری، تستر دانش محدودی از ساختار داخلی دارد. مثلاً ساختار پایگاه داده یا معماری سرویسها را میداند. این دانش به طراحی تستهای دقیقتر یکپارچگی و API کمک میکند.
تست دستی، خودکار و اکتشافی
تست دستی
در تست دستی، تستر مراحل را خودش اجرا میکند. این روش برای قابلیتهای تازه، تست کاربردپذیری و موقعیتهایی که قضاوت انسانی لازم است مناسب است. کیفیت تست دستی به کیفیت تستکیسها بستگی دارد. روش نوشتن تستکیس خوب را در مقاله نوشتن تستکیس حرفهای با نمونه ببینید.
تست خودکار
در اتوماسیون تست، اسکریپتها تست را اجرا و نتیجه را بررسی میکنند. تستهای واحد، تستهای API و مجموعه رگرسیون بهترین کاندیداها هستند. هرم تست کمک میکند بیشتر تستهای خودکار در لایههای پایینتر و سریعتر باشند. برای شروع، مقاله اتوماسیون تست را بخوانید.
تست اکتشافی
تست اکتشافی یادگیری، طراحی و اجرای همزمان تست است. تستر با یک هدف مشخص و زمان محدود، سیستم را کاوش میکند. این روش باگهایی را پیدا میکند که تستهای اسکریپتی از آنها غافل میمانند. نتایج هر جلسه باید ثبت شود تا به تستکیسهای جدید تبدیل شود.
انتخاب انواع تست مناسب و مدیریت آنها در TestRail
هیچ پروژهای همه انواع تست را با یک عمق اجرا نمیکند. انتخاب باید بر اساس ریسک، نوع محصول و مرحله ریلیز باشد. چند راهنمای عملی:
- تست واحد و تست دود را در هر بیلد اجرا کنید.
- تست یکپارچگی را برای مرزهای بین سرویسها در اولویت قرار دهید.
- تست رگرسیون را پیش از هر ریلیز، ترجیحاً بهصورت خودکار، اجرا کنید.
- تست بار و امنیت را برای بخشهای حساس، مثل پرداخت و ورود، برنامهریزی کنید.
- برای قابلیتهای تازه، جلسههای تست اکتشافی در نظر بگیرید.
جایگاه انواع تست در پایپلاین CI/CD
در یک پایپلاین CI/CD، تستها معمولاً از سریع به کند چیده میشوند. ابتدا تحلیل ایستا و تست واحد اجرا میشود. سپس تست یکپارچگی و API میآید. پس از استقرار روی محیط تست، تست دود و بخشی از رگرسیون سرتاسری اجرا میشود. این ترتیب باعث میشود خطا در زودترین و ارزانترین مرحله متوقف شود و توسعهدهنده بازخورد را در چند دقیقه ببیند.
این تصمیمها باید در طرح تست هر ریلیز ثبت شوند. در TestRail، میتوانید با یک فیلد سفارشی نوع تست را برای هر تستکیس مشخص کنید. سپس برای هر نوع، یک Test Run جدا بسازید و همه را در یک Test Plan کنار هم نگه دارید؛ مثلاً یک اجرا برای تست دود، یک اجرا برای رگرسیون و یک اجرا برای تست سیستم. نتایج تستهای خودکار هم از طریق API در همان اجرا ثبت میشوند. برای آشنایی با امکانات این ابزار، صفحه امکانات TestRail را ببینید. برای سنجش نتایج هر نوع تست هم مقاله معیارهای تست و گزارش کیفیت مفید است.
جمعبندی
انواع تست نرمافزار را میتوان بر اساس سطح، هدف، دانش از کد و روش اجرا دستهبندی کرد. سطوح تست از تست واحد تا تست پذیرش پیش میروند. تست عملکردی درستی رفتار را میسنجد و تست غیرعملکردی کیفیت اجرای آن را. ترکیب درست تست دستی، خودکار و اکتشافی، پوشش کاملتری میدهد. انتخاب آگاهانه این انواع، زنجیره نیازمندی ← تستکیس ← اجرای تست ← باگ ← ریلیز را قابل اعتمادتر میکند.