سطوح تست نرم‌افزار چیست؟ Unit تا Acceptance با مثال

یک تابع تخفیف می‌تواند تمام تست‌های واحد را Pass کند، اما هنگام اتصال به سبد مبلغ را با واحد ریال بفرستد؛ کل فروشگاه می‌تواند در تست سیستم سالم باشد، اما درگاه پرداخت واقعی Callback را با ترتیبی متفاوت تحویل دهد؛ محصول از نظر فنی کار کند، اما واحد مالی آن را نپذیرد. این شکست‌ها شبیه هم نیستند و با یک لایه تست کشف نمی‌شوند. سطوح تست نرم‌افزار کمک می‌کنند هر نوع رابطه و هدف را در جای مناسب بررسی کنیم.

پاسخ کوتاه: مدل رایج آموزشی چهار سطح را معرفی می‌کند: تست واحد، یکپارچه‌سازی، سیستم و پذیرش. در مدل فعلی ISTQB CTFL v4.۰.۱، یکپارچه‌سازی به دو سطح Component Integration و System Integration تفکیک شده و در نتیجه پنج سطح داریم: Component، Component Integration، System، System Integration و Acceptance. هر سطح Test Object، هدف، مبنا، محیط، مسئول و نقص‌های هدف متفاوتی دارد.

سطح تست (Test Level) چیست؟

سطح تست گروهی از فعالیت‌های تست است که بر Test Object و هدف مشخصی در یک سامانه تمرکز دارد. سطح‌ها را می‌توان با این ویژگی‌ها از هم تشخیص داد:

• چه چیزی تست می‌شود؟ تابع، مؤلفه، کل سیستم یا تعامل با سامانه بیرونی؟
• هدف چیست؟ منطق داخلی، رابط، انطباق سیستم یا پذیرش کسب‌وکار؟
• Test Basis کدام است؟ کد، طراحی API، نیازمندی سیستم یا فرآیند کسب‌وکار؟
• چه نقص‌هایی هدف‌اند؟ محاسبه، قرارداد، پیکربندی، workflow یا آمادگی عملیاتی؟
• چه کسی و در کدام محیط اجرا می‌کند؟

سیلابس رسمی ISTQB CTFL v4.۰.۱ پنج سطح را توصیف می‌کند و تاکید دارد اهداف متفاوت سطوح به جامعیت تست و کاهش تکرار بی‌هدف کمک می‌کنند.

بالاخره چهار سطح تست داریم یا پنج سطح؟

هر دو عبارت را در منابع می‌بینید. مدل سنتی، همه تعاملات را زیر عنوان Integration Testing قرار می‌دهد. مدل ISTQB فعلی آن را برای شفافیت به دو سطح تقسیم می‌کند:

مدل چهارسطحی رایج	مدل پنج‌سطحی ISTQB ۴.۰.۱	توضیح
Unit Testing	Component Testing	تست جزء در انزوا؛ این دو نام معمولاً معادل‌اند
Integration Testing	Component Integration Testing	تعامل اجزای داخل سیستم
	System Integration Testing	تعامل سیستم با سیستم‌ها و سرویس‌های بیرونی
System Testing	System Testing	رفتار کل سیستم یکپارچه
Acceptance Testing	Acceptance Testing	اعتبارسنجی نیاز کسب‌وکار و آمادگی استقرار

در گفتگو با تیم، نام مدل را روشن کنید. گفتن «تست Integration انجام شد» بدون مشخص‌کردن Component یا System Integration ممکن است باعث شود قرارداد درگاه، پیامک یا سرویس شریک اصلاً آزموده نشود.

تفاوت سطح تست با نوع، تکنیک و فاز تست

مفهوم	به چه سؤال پاسخ می‌دهد؟	مثال
Test Level	چه Test Object و رابطه‌ای را می‌آزماییم؟	Component، System، Acceptance
Test Type	کدام ویژگی کیفیت را می‌سنجیم؟	Functional، Performance، Security
Test Technique	چگونه تست‌ها را طراحی می‌کنیم؟	BVA، Decision Table، Branch Coverage
Test Phase/Activity	در فرایند چه کاری انجام می‌دهیم؟	تحلیل، طراحی، اجرا، Closure

بنابراین «Functional Testing» سطح نیست؛ نوع تستی است که می‌تواند در Component، Integration، System و Acceptance انجام شود. همین موضوع برای تست غیرکارکردی نیز صدق می‌کند. مثلاً benchmark یک تابع در سطح Component و آزمون بار کل سامانه در سطح System هر دو Performance Test هستند.

سطح ۱: تست مؤلفه یا واحد (Component/Unit Testing)

Component Testing کوچک‌ترین جزء قابل تست را در انزوا بررسی می‌کند: تابع، کلاس، ماژول، کتابخانه یا سرویس کوچک، بسته به معماری. Test Basis معمولاً کد، طراحی جزء و قرارداد آن است و توسعه‌دهنده اغلب در محیط توسعه با Unit Test Framework آن را اجرا می‌کند.

هدف‌ها و نقص‌های رایج تست واحد

• منطق و محاسبه اشتباه
• شرط و مسیر خطای پوشش‌نداده
• رفتار مرزی، null و ورودی نامعتبر
• تغییر state یا side effect ناخواسته
• مدیریت استثنا و بازگشت مقدار نادرست
• کد مرده یا شاخه دست‌نیافتنی

برای تابع سقف تخفیف فروشگاه، تست‌های واحد می‌توانند مبلغ درست زیر، روی و بالای سقف را با داده سریع و مستقل بررسی کنند. تکنیک‌های تست جعبه سفید و Code Coverage در این سطح پرکاربردند، ولی تست جعبه سیاه مرزی هم برای قرارداد تابع ارزش دارد.

ایزوله‌سازی، Stub و Mock

وابستگی کند یا غیرقابل‌کنترل مانند شبکه و زمان را می‌توان با Test Double جایگزین کرد؛ اما Mock کردن بیش‌ازحد، تستی می‌سازد که فقط فرضیات نویسنده را تایید می‌کند. مرز واحد را بر رفتار قابل‌مشاهده تعریف کنید و هرجا قرارداد واقعی حیاتی است، سطح Integration را جایگزین نکنید.

نمونه ورودی و خروجی سطح Unit

• ورودی: کد قابل‌ساخت، قرارداد تابع، داده و Test Double
• خروجی: تست‌های سریع و تکرارپذیر، گزارش شکست و پوشش ساختاری منتخب
• معیار مناسب: رفتارهای پرریسک پوشش دارند و مجموعه در CI پایدار است؛ صرفاً درصد پوشش کافی نیست

سطح ۲: تست یکپارچه‌سازی مؤلفه‌ها

Component Integration Testing رابط و تعامل میان اجزای داخل یک سیستم را می‌سنجد. مثال‌ها:

• Checkout Service با Pricing و Inventory
• Repository با پایگاه داده
• Publisher با صف پیام داخلی
• Frontend Module با API داخلی
• دو پکیج یا کتابخانه با مدل داده مشترک

نقص‌های رایج شامل mapping اشتباه، قرارداد ناسازگار، ترتیب فراخوانی، تراکنش ناقص، timeout، serialization، مدیریت خطای وابستگی و race condition هستند. این سطح معمولاً از Unit کندتر ولی از تست End-to-End سریع‌تر و قابل‌تشخیص‌تر است.

استراتژی‌های یکپارچه‌سازی

• Incremental: اجزا مرحله‌ای اضافه می‌شوند و محل شکست محدودتر می‌ماند.
• Top-Down: از مؤلفه‌های سطح بالا شروع و وابستگی پایین با Stub جایگزین می‌شود.
• Bottom-Up: از اجزای پایه شروع و فراخواننده موقت با Driver شبیه‌سازی می‌شود.
• Big Bang: اجزای متعدد یک‌باره متصل می‌شوند؛ آماده‌سازی ساده‌تر به نظر می‌رسد ولی مکان‌یابی علت در سیستم بزرگ دشوار است.

Contract Test، تست Repository واقعی و اجرای ephemeral dependency در container از رویکردهای عملی این سطح‌اند. مقاله راهنمای عمیق تست یکپارچه‌سازی طراحی محیط، Stub/Driver و استراتژی‌ها را جداگانه بررسی می‌کند.

سطح ۳: تست سیستم (System Testing)

در System Testing، کل سیستم یکپارچه به‌عنوان Test Object ارزیابی می‌شود. تمرکز بر انطباق با نیازمندی‌های سیستم و رفتار end-to-end داخل مرز محصول است. تیم تست یا ترکیبی از نقش‌ها آن را در محیطی نماینده اجرا می‌کنند.

چه چیزهایی در تست سیستم بررسی می‌شوند؟

• سفرهای کامل کاربر و قواعد کسب‌وکار
• نقش‌ها و دسترسی‌ها در سراسر محصول
• ذخیره، بازیابی و سازگاری state
• خطا، بازیابی و پیام قابل‌فهم
• کارایی، امنیت، کاربردپذیری، سازگاری و دسترس‌پذیری
• پیکربندی، نصب، مهاجرت و Feature Flagهای سیستم

در فروشگاه، «از جست‌وجوی کالا تا ثبت سفارش» یک سناریوی System Test است، اگر سرویس‌های بیرونی با sandbox یا شبیه‌ساز کنترل شده‌اند. جزئیات دامنه و رویکرد در مقاله تست سیستم و استراتژی‌های آن آمده است.

آیا محیط باید دقیقاً Production باشد؟

هرچه تفاوت محیط بیشتر باشد، دامنه ادعای نتیجه محدودتر می‌شود. نسخه سرویس‌ها، حجم داده، تنظیمات امنیتی، topology، شبکه و observability را نزدیک کنید یا اختلاف را مستند سازید. کپی داده واقعی بدون مجوز و ماسک‌سازی راه‌حل شباهت محیط نیست.

سطح ۴: تست یکپارچه‌سازی سیستم‌ها

System Integration Testing رابط میان سیستم تحت تست و سامانه‌ها/سرویس‌های بیرونی را هدف می‌گیرد. برای محصول ایرانی، نمونه‌های مهم عبارت‌اند از:

• درگاه پرداخت و Callback
• سرویس پیامک و رمز یک‌بارمصرف
• شرکت حمل‌ونقل و رهگیری مرسوله
• سرویس احراز هویت یا امضای دیجیتال
• سامانه حسابداری، CRM یا شریک تجاری

Test Basis معمولاً قرارداد API، پروتکل، schema، SLA و فرایند عملیاتی مشترک است. نقص‌های هدف شامل تفاوت format و timezone، retry تکراری، idempotency، rate limit، certificate، خطای partial، ترتیب event و ناسازگاری نسخه‌اند.

Sandbox، شبیه‌ساز یا سرویس واقعی؟

هیچ‌کدام به‌تنهایی کافی نیست:

• Service Virtualization: سناریوهای خطا و پاسخ کمیاب را سریع و کنترل‌شده می‌سازد، اما رفتار واقعی شریک را تضمین نمی‌کند.
• Sandbox رسمی: قرارداد و جریان نزدیک‌تری دارد، ولی ممکن است محدود یا با Production متفاوت باشد.
• تست محدود end-to-end: بالاترین اطمینان عملی را می‌دهد، اما کند، حساس و نیازمند مجوز/داده امن است.

برای سناریوی مالی، مبلغ، شناسه تراکنش، Callback تکراری، timeout، بازگشت دیرهنگام و تطبیق سفارش را در لایه مناسب آزمایش کنید. راهنمای تست درگاه پرداخت و Sandbox مثال‌های این مرز را پوشش می‌دهد.

سطح ۵: تست پذیرش (Acceptance Testing)

Acceptance Testing بر Validation و نشان دادن آمادگی استقرار تمرکز دارد: آیا سیستم نیاز کسب‌وکار کاربر را برآورده و برای استفاده قابل‌پذیرش است؟ Ideally کاربران هدف یا نمایندگان معتبر کسب‌وکار در آن مشارکت دارند.

انواع تست پذیرش

• UAT: کاربر یا نماینده کسب‌وکار workflowها و معیارهای پذیرش را تایید می‌کند.
• OAT: آمادگی عملیات مانند backup/restore، monitoring، runbook، دسترسی و پشتیبانی بررسی می‌شود. راهنمای تست آمادگی عملیاتی این شاخه را باز می‌کند.
• Contractual Acceptance: تعهدهای قرارداد و خروجی تحویل بررسی می‌شوند.
• Regulatory Acceptance: الزامات مقرراتی یا حوزه‌ای با شاهد لازم ارزیابی می‌شوند.
• Alpha/Beta: محصول در جامعه محدود داخلی یا کاربران بیرونی برای بازخورد و پذیرش عملی ارائه می‌شود.

UAT نباید به «یک دور تست دوباره توسط QA» یا نمایش نمایشی قابلیت تبدیل شود. سناریو باید از کار واقعی، داده نماینده و اختیار تصمیم کاربر کسب‌وکار بیاید. همچنین پذیرش لزوماً کاملاً دستی یا فقط در انتهای پروژه نیست؛ معیارهای پذیرش می‌توانند از refinement تعریف و بخشی از آن‌ها خودکار شوند.

مقایسه پنج سطح تست نرم‌افزار

سطح	Test Object	هدف اصلی	مجری رایج	نمونه نقص
Component/Unit	تابع، کلاس، ماژول	صحت جزء در انزوا	توسعه‌دهنده	شرط یا محاسبه اشتباه
Component Integration	رابط اجزای داخلی	همکاری داخل سیستم	توسعه/QA فنی	mapping یا تراکنش ناقص
System	کل محصول	انطباق با نیازمندی سیستم	تیم چندتخصصی/QA	شکست سفر یا ویژگی کیفیت
System Integration	مرز سیستم‌های بیرونی	سازگاری قرارداد و عملیات	QA، توسعه، عملیات/شریک	Callback، schema یا retry نادرست
Acceptance	سیستم در زمینه استفاده	نیاز کسب‌وکار و آمادگی	کاربر/محصول/عملیات	workflow نامناسب یا نبود آمادگی

مثال لایه‌ای: پرداخت فروشگاه اینترنتی

سطح	سناریوی نمونه	شاهد
Unit	تابع سقف تخفیف برای زیر/روی/بالای مرز	assertion سریع روی خروجی تابع
Component Integration	Pricing نتیجه را با واحد درست به Checkout می‌دهد	قرارداد و داده پایگاه داده تست
System	کاربر از سبد تا سفارش با درگاه شبیه‌سازی‌شده پیش می‌رود	وضعیت سفارش، مبلغ و رویدادهای داخلی
System Integration	Sandbox درگاه Callback موفق، تکراری و دیرهنگام می‌فرستد	Request ID، idempotency و تطبیق تراکنش
Acceptance	مالی و پشتیبانی مغایرت‌گیری، مرجوعی و runbook را تایید می‌کنند	معیار پذیرش و sign-off نقش‌های مجاز

یک سناریو می‌تواند در چند سطح حضور داشته باشد، اما با هدف و oracle متفاوت. کپی یکسان تست end-to-end در همه لایه‌ها فقط هزینه و Fail تکراری تولید می‌کند.

نوع‌های تست در کدام سطح اجرا می‌شوند؟

اغلب Test Typeها محدود به یک سطح نیستند:

نوع تست	Component	Integration	System	Acceptance
Functional	قانون تابع	قرارداد تعامل	سفر کامل	فرایند کسب‌وکار
Performance	benchmark جزء	latency وابستگی	بار و ظرفیت کل	پذیرش SLA/تجربه
Security	validation و مسیر مجوز	اعتماد بین سرویس‌ها	آزمون کل سامانه	ریسک/انطباق قابل‌پذیرش
Reliability	خطا و retry جزء	خرابی وابستگی	تاب‌آوری سیستم	آمادگی عملیات

مقاله تست کارکردی و انواع آن این تمایز را از دید Test Type توضیح می‌دهد.

آیا سطح‌ها حتماً پشت‌سرهم اجرا می‌شوند؟

مدل‌های آموزشی آن‌ها را به‌ترتیب نشان می‌دهند، اما در Agile و DevOps فعالیت‌ها هم‌پوشانی دارند:

• Unit با هر commit اجرا می‌شود.
• Component Integration در CI با پایگاه داده یا service container بالا می‌آید.
• Contract Test پیش از آماده بودن شریک، ناسازگاری را زود هشدار می‌دهد.
• System Test روی محیط موقت یا Staging اجرا می‌شود.
• پذیرش از refinement معیار می‌سازد و در پایان فقط تایید نهایی نمی‌کند.
• تست پس از استقرار با canary و monitoring ادامه می‌یابد.

سطح‌ها «مرحله زمانی سخت» نیستند؛ مرز هدف و Test Object هستند. آماده شدن یک سطح می‌تواند ورودی سطح دیگر باشد، ولی تیم نباید منتظر پایان کامل همه Unit Testها بماند تا طراحی System Test را آغاز کند.

چگونه استراتژی چندسطحی بسازیم؟

1. معماری و سفرهای بحرانی را ترسیم کنید. اجزای داخلی و سیستم‌های بیرونی را جدا نشان دهید.
2. ریسک را به ارزان‌ترین سطح معتبر ببرید. قانون محاسبه را در Unit و قرارداد در Integration بسنجید؛ همه‌چیز را به UI موکول نکنید.
3. هدف هر سطح را بنویسید. Test Object، Basis، محیط، مالک و خروجی روشن باشد.
4. هم‌پوشانی ارزشمند را نگه دارید. یک قانون مالی می‌تواند در Unit و System بررسی شود، اما هرکدام دلیل متفاوت دارند.
5. شکاف را با traceability پیدا کنید. هر ریسک بحرانی حداقل در یک سطح شاهد مناسب داشته باشد.
6. بازخورد را متناسب کنید. تست‌های سریع زود و مکرر؛ تست‌های کند و شکننده انتخابی‌تر.
7. داده و محیط را طراحی کنید. isolation، قرارداد و واقع‌نمایی را آگاهانه متعادل کنید.
8. نتیجه سطح‌ها را در Release جمع کنید. Pass یک سطح جای دیگری را نمی‌گیرد؛ محدودیت و Blocked شفاف بماند.

اشتباهات رایج درباره سطوح تست

• یکی گرفتن سطح با نوع: «تست کارکردی» را کنار Unit/System به‌عنوان سطح پنجم می‌گذارند.
• اتکا به UI End-to-End: مجموعه کند، Flaky و سخت‌تشخیص می‌شود.
• حذف Integration چون Unitها سبزند: قرارداد و پیکربندی واقعی آزموده نمی‌شوند.
• Mock کردن سیستم بیرونی در همه‌جا: ناسازگاری واقعی درگاه یا پیامک تا تولید پنهان می‌ماند.
• یکی گرفتن System و System Integration: مرز شریک بیرونی بدون مالک می‌ماند.
• UAT به‌عنوان تست دوباره QA: Validation نیاز کاربر و اختیار پذیرش حذف می‌شود.
• اجرای ترتیبی سخت: طراحی تست دیر شروع و بازخورد کند می‌شود.
• تکرار همان سناریو در همه سطح‌ها: هزینه بالا بدون افزایش متناسب اطمینان.
• اعلام «حذف یک سطح» بدون تحلیل ریسک: ممکن است فقط نام حذف شود و شکاف واقعی پنهان بماند.

چک‌لیست سطوح تست نرم‌افزار

• مدل چهارسطحی یا پنج‌سطحی مورد استفاده تیم مشخص است.
• Component Integration از System Integration تفکیک شده است.
• برای هر سطح، Test Object و هدف روشن داریم.
• Functional/Non-Functional به‌عنوان Type و نه Level مدیریت می‌شوند.
• ریسک‌ها به پایین‌ترین سطح معتبر نگاشت شده‌اند.
• Unit Testها سریع، مستقل و دارای assertion معنادارند.
• قراردادها و پایگاه داده واقعی در سطح مناسب آزموده می‌شوند.
• کل سیستم در محیط نماینده بررسی می‌شود.
• سرویس‌های بیرونی با شبیه‌ساز، Sandbox و تست محدود واقعی پوشش دارند.
• کاربر/کسب‌وکار و عملیات در Acceptance نقش واقعی دارند.
• تکرار و شکاف بین سطح‌ها دوره‌ای بازبینی می‌شود.

سؤالات متداول سطوح تست

چهار سطح اصلی تست نرم‌افزار کدام‌اند؟

در مدل رایج: Unit، Integration، System و Acceptance. ISTQB فعلی Integration را به Component Integration و System Integration تفکیک می‌کند و پنج سطح می‌سازد.

تفاوت Integration Testing و System Testing چیست؟

Integration روی رابط و تعامل اجزا یا سیستم‌ها تمرکز دارد؛ System کل محصول یکپارچه را در برابر نیازمندی‌های سیستم ارزیابی می‌کند. شکست قرارداد داخلی ممکن است در Integration، و شکست سفر کامل کاربر در System کشف شود.

آیا تست سیستم همان End-to-End Testing است؟

نه دقیقاً. System Testing کل سیستم را می‌سنجد و ممکن است وابستگی بیرونی شبیه‌سازی شود. End-to-End معمولاً یک فرایند را از ابتدا تا انتها میان چند مؤلفه یا سیستم دنبال می‌کند و می‌تواند بخشی از System/System Integration باشد.

کدام سطح مهم‌تر است؟

هیچ پاسخ عمومی ندارد. هر سطح دسته متفاوتی از ریسک را پوشش می‌دهد. هدف این است که با کمترین تکرار، ریسک در مناسب‌ترین سطح شاهد داشته باشد؛ نه اینکه تعداد تست‌های یک سطح حداکثر شود.

آیا Acceptance Testing حتماً دستی است؟

خیر. بخشی از معیارهای پذیرش و قراردادها می‌توانند خودکار باشند، اما قضاوت درباره تناسب workflow، آمادگی عملیات و پذیرش کسب‌وکار معمولاً به مشارکت انسانی و صاحب اختیار نیاز دارد.

جمع‌بندی

سطوح تست نقشه‌ای برای تقسیم مسئولیت کیفیت‌اند: جزء، اتصال داخلی، کل سیستم، اتصال بیرونی و پذیرش. مدل پنج‌سطحی امروز کمک می‌کند «Integration» مبهم نماند؛ مدل چهارسطحی نیز برای آموزش خلاصه هنوز کاربرد دارد. مهم‌تر از نام‌ها این است که Test Object، هدف و ریسک هر سطح روشن باشد. قانون را نزدیک کد، قرارداد را روی مرز، سفر را در سیستم و ارزش/آمادگی را با ذی‌نفع معتبر بیازمایید.