در تست نرمافزار، همیشه قرار نیست کل سیستم را یکجا بررسی کنیم. گاهی لازم است یک بخش کوچک از نرمافزار را بهصورت مستقل تست کنیم، گاهی تعامل بین چند بخش را بررسی کنیم و در مراحل بعدی، عملکرد کل سیستم یا ارتباط آن با سیستمهای دیگر را مورد آزمایش قرار دهیم.
در نهایت نیز باید مشخص شود که آیا محصول ساختهشده واقعاً نیازهای مورد انتظار کاربران، مشتریان و کسبوکار را برآورده میکند یا خیر.
این تفاوت در دامنه و هدف تست باعث میشود تست نرمافزار در سطوح مختلف انجام شود. به این سطوح، Test Levels یا سطوح تست گفته میشود.
در این مقاله، سطوح تست نرم افزار را بر اساس چارچوب ISTQB بررسی میکنیم و در کنار اصطلاحات استاندارد، از نامهایی استفاده میکنیم که برای تسترهای نرمافزار رایجتر و آشناتر هستند.
Test Level یا سطح تست چیست؟
Test Level مشخص میکند تست در چه سطحی از نرمافزار انجام میشود و تمرکز اصلی تست روی چه چیزی قرار دارد.
برای مثال، زمانی که یک Component را بهصورت مستقل بررسی میکنیم، با سطح متفاوتی از تست نسبت به زمانی روبهرو هستیم که کل سیستم را بررسی میکنیم.
در نگاه کلی میتوان دامنه تست را از یک جزء کوچکتر به سمت سیستم کامل و سپس پذیرش سیستم در نظر گرفت:
Component
↓
Component Integration
↓
System
↓
Acceptanceالبته این نمودار به این معنی نیست که همه پروژهها باید تستها را دقیقاً به همین ترتیب و بهصورت کاملاً خطی اجرا کنند. نحوه اجرای Test Levelها به عواملی مانند چرخه توسعه نرمافزار، معماری سیستم، ریسکها، نوع محصول و شرایط پروژه بستگی دارد.
در چارچوب ISTQB، Test Levelها از یکدیگر متمایز هستند و هرکدام Test Object، اهداف تست، Test Basis، انواع خطاهای قابل شناسایی و مسئولیتهای متفاوتی دارند.
Unit Testing چیست؟
Unit Testing یا تست واحد، یکی از شناختهشدهترین اصطلاحات در صنعت نرمافزار است. در این سطح، بخش کوچکی از نرمافزار بهصورت مستقل بررسی میشود تا مشخص شود آیا مطابق انتظار عمل میکند یا خیر.
در terminology رسمی ISTQB، اصطلاح Component Testing برای این سطح استفاده میشود. بااینحال، در بسیاری از پروژهها و منابع فنی، عبارت Unit Testing رایجتر است.
Unit Testing چه چیزی را بررسی میکند؟
در Unit Testing معمولاً یک بخش مشخص و نسبتاً مستقل از نرمافزار بررسی میشود؛ برای مثال:
- یک Function
- یک Method
- یک Class
- یک Component
فرض کنیم در یک فروشگاه اینترنتی، بخشی از نرمافزار وظیفه محاسبه تخفیف را بر عهده دارد.
قیمت کالا: 1,000,000 تومان
درصد تخفیف: 20٪
قیمت نهایی: 800,000 توماندر Unit Testing میتوان منطق محاسبه تخفیف را بهصورت مستقل بررسی کرد، بدون اینکه لازم باشد کل فروشگاه اینترنتی اجرا شود.
هدف Unit Testing چیست؟
هدف اصلی این سطح، بررسی رفتار Component موردنظر و شناسایی خطاها در همان بخش است.
یکی از مزیتهای مهم این سطح آن است که خطاها میتوانند نسبتاً زود و قبل از اینکه به بخشهای دیگر سیستم منتقل شوند، شناسایی شوند.
برای مثال، اگر منطق محاسبه تخفیف اشتباه باشد، بهتر است این خطا زمانی پیدا شود که هنوز همان Component را بررسی میکنیم، نه زمانی که کاربر در مرحله پرداخت با مبلغ اشتباه مواجه شده است.
Unit Testing را چه کسی انجام میدهد؟
Component Testing معمولاً توسط توسعهدهندگان انجام میشود، هرچند مسئولیتها و شیوه اجرای آن به تیم و پروژه بستگی دارد.
بااینحال، نباید Unit Testing را صرفاً با «تست توسط برنامهنویس» تعریف کنیم. ویژگی اصلی این Test Level، سطحی است که تست روی آن انجام میشود، نه صرفاً شخصی که تست را اجرا میکند.
Unit Testing و Component Testing چه تفاوتی دارند؟
این دو اصطلاح در بسیاری از پروژهها بهجای یکدیگر استفاده میشوند، اما از نظر terminology استاندارد بهتر است تفاوت آنها را بدانیم.
Unit Testing اصطلاح رایج صنعت است، درحالیکه Component Testing اصطلاحی است که ISTQB برای این Test Level به کار میبرد.
بنابراین در این مقاله از Unit Testing بهعنوان اصطلاح آشناتر استفاده میکنیم، اما اصطلاح استاندارد Component Testing را نیز در نظر میگیریم.
وقتی چند Component باید با یکدیگر ارتباط برقرار کنند، دیگر فقط عملکرد مستقل یک Component مطرح نیست و وارد Integration Testing میشویم.
Integration Testing چیست؟
ممکن است هر Component بهتنهایی درست کار کند، اما زمانی که Componentها با یکدیگر ارتباط برقرار میکنند، خطاهایی به وجود بیاید.
برای مثال، یک Component ممکن است داده را بهدرستی تولید کند، اما Component دیگر آن داده را با فرمت اشتباه دریافت کند.
Integration Testing یا تست یکپارچهسازی، به بررسی این تعاملها و ارتباطها مربوط میشود.
در این سطح، تمرکز اصلی روی Interfaceها، تبادل داده و تعامل بین بخشهای مختلف قرار میگیرد.
یک مثال ساده از Integration Testing
فرض کنیم در یک فروشگاه اینترنتی دو Component داریم:
Component سفارش
↓
Component پرداختممکن است هر دو Component بهصورت مستقل درست کار کنند، اما هنگام ارتباط با یکدیگر مشکلی وجود داشته باشد؛ مثلاً مبلغ سفارش بهدرستی به بخش پرداخت ارسال نشود.
در این حالت، مشکل لزوماً در عملکرد مستقل هیچکدام از Componentها نیست، بلکه ممکن است در تعامل بین آنها باشد.
Integration Testing در ISTQB چگونه تقسیم میشود؟
در چارچوب ISTQB، بسته به اینکه چه اجزایی با یکدیگر یکپارچه میشوند، دو سطح مهم مطرح است:
- Component Integration Testing: بررسی تعامل و Interface بین Componentها
- System Integration Testing: بررسی تعامل سیستم مورد آزمایش با سایر سیستمها یا سرویسهای خارجی
بنابراین وقتی در پروژهها بهصورت کلی از Integration Testing صحبت میکنیم، باید مشخص کنیم منظورمان کدام سطح از یکپارچهسازی است.
Component Integration Testing چیست؟
در Component Integration Testing، Componentهای مختلف یک نرمافزار با یکدیگر یکپارچه میشوند و تعامل بین آنها بررسی میشود.
برای مثال:
Component A
↓
Component B
↓
Component Cتمرکز میتواند روی مواردی مانند:
- Interfaceها
- انتقال داده
- فرمت داده
- فراخوانی Componentها
- نحوه تعامل بین Componentها
باشد.
برای مثال، در یک فروشگاه اینترنتی:
سبد خرید
↓
محاسبه مبلغ
↓
ثبت سفارشممکن است هر بخش بهتنهایی درست کار کند، اما اطلاعات سبد خرید هنگام ایجاد سفارش بهدرستی منتقل نشود.
System Integration Testing چیست؟
در System Integration Testing، دامنه یکپارچهسازی گستردهتر میشود.
در این سطح بررسی میکنیم سیستم مورد آزمایش چگونه با سایر سیستمها یا سرویسهای خارجی ارتباط برقرار میکند.
برای مثال:
فروشگاه اینترنتی
↓
درگاه پرداخت
↓
سامانه بانکییا:
Application
↓
External API
↓
Third-party Serviceدر اینجا تمرکز روی ارتباط بین Componentهای داخل یک نرمافزار نیست؛ بلکه تعامل سیستم با سایر سیستمها یا سرویسها بررسی میشود.
تفاوت Component Integration و System Integration چیست؟
به زبان ساده:
Component Integration Testing:
آیا Componentهای مختلف نرمافزار بهدرستی با یکدیگر تعامل میکنند؟
System Integration Testing:
آیا سیستم ما بهدرستی با سایر سیستمها و سرویسها تعامل میکند؟
این تفاوت در سیستمهایی که از APIهای متعدد، Microservices و سرویسهای شخص ثالث استفاده میکنند اهمیت بیشتری پیدا میکند.
System Testing چیست؟
در System Testing، نرمافزار بهعنوان یک سیستم یکپارچه بررسی میشود.
در این سطح، تمرکز دیگر روی یک Function یا صرفاً ارتباط بین دو Component نیست؛ بلکه میخواهیم ببینیم کل سیستم در شرایط مورد انتظار چگونه عمل میکند.
System Testing چه چیزی را بررسی میکند؟
برای مثال، در یک فروشگاه اینترنتی میتوان یک فرایند کامل خرید را بررسی کرد:
ورود به حساب کاربری
↓
جستجوی محصول
↓
افزودن به سبد خرید
↓
ثبت سفارش
↓
پرداخت
↓
دریافت تأیید سفارشممکن است هر یک از این بخشها قبلاً بهصورت جداگانه تست شده باشند، اما در System Testing سؤال اصلی این است:
آیا کل سیستم و فرایند موردنظر، بهصورت یکپارچه و مطابق انتظار عمل میکند؟
هدف System Testing چیست؟
هدف System Testing شناسایی مشکلاتی است که ممکن است فقط زمانی قابل مشاهده باشند که سیستم بهصورت کامل مورد بررسی قرار گیرد.
برای مثال:
- ورود کاربر بهدرستی کار میکند.
- سبد خرید بهدرستی کار میکند.
- پرداخت بهدرستی کار میکند.
اما ممکن است زمانی که کاربر کل فرایند خرید را از ابتدا تا انتها طی میکند، سفارش بهدرستی ثبت نشود.
چنین مشکلی ممکن است در تستهای سطح پایینتر دیده نشده باشد، اما در System Testing قابل شناسایی باشد.
آیا System Testing فقط شامل تست Functional است؟
خیر.
در System Testing میتوان جنبههای مختلف سیستم را بررسی کرد. برای مثال:
- Functional Testing
- Performance Testing
- Security Testing
- Usability Testing
بنابراین میتوان این رابطه را بهصورت ساده چنین نشان داد:
System Testing
├── Functional Testing
├── Performance Testing
├── Security Testing
└── Usability Testingاین مثال یک نکته مهم را نشان میدهد:
System Testing یک Test Level است، درحالیکه Functional، Performance و Security به جنبه یا نوع تست مربوط میشوند.
System Testing بر چه اساسی انجام میشود؟
برای طراحی تستهای این سطح، میتوان از مواردی مانند نیازمندیهای سیستم، مشخصات محصول و سایر Test Basisهای مرتبط استفاده کرد.
بنابراین تستر فقط بررسی نمیکند که «سیستم کار میکند یا نه»، بلکه بررسی میکند:
آیا سیستم همان رفتاری را دارد که بر اساس نیازمندیها و انتظارات تعریفشده باید داشته باشد؟
تفاوت Integration Testing و System Testing چیست؟
این دو Test Level گاهی با یکدیگر اشتباه گرفته میشوند.
در Integration Testing تمرکز روی تعامل و ارتباط بین اجزا یا سیستمها است.
اما در System Testing تمرکز روی رفتار و قابلیتهای کل سیستم قرار دارد.
Integration Testing: آیا بخشها و سیستمهای مرتبط، درست با یکدیگر تعامل میکنند؟
System Testing: آیا کل سیستم، بهعنوان یک محصول یکپارچه، مطابق انتظار عمل میکند؟
Acceptance Testing چیست؟
تا اینجا از بررسی یک Component کوچک به سمت بررسی کل سیستم حرکت کردیم. اما هنوز یک سؤال مهم باقی میماند:
آیا نرمافزار ساختهشده واقعاً نیازهای مورد انتظار کاربران، مشتریان و کسبوکار را برآورده میکند؟
برای پاسخ به این سؤال، Acceptance Testing یا تست پذیرش انجام میشود.
در Acceptance Testing بررسی میشود که آیا سیستم برای استفاده یا استقرار موردنظر مناسب است و نیازهای مورد انتظار ذینفعان را برآورده میکند یا خیر.
هدف Acceptance Testing چیست؟
در این سطح، سؤال اصلی فقط این نیست که:
«آیا سیستم از نظر فنی درست کار میکند؟»
بلکه سؤال مهمتر این است:
«آیا سیستم برای هدفی که به خاطر آن ساخته شده، قابل قبول و مناسب است؟»
برای مثال، فرض کنیم یک شرکت یک سامانه فروش آنلاین سفارش داده است. یکی از نیازهای اصلی این است که مشتری بتواند محصول را انتخاب کند، سفارش خود را ثبت کند و پرداخت را انجام دهد.
در Acceptance Testing بررسی میشود که آیا سیستم ساختهشده واقعاً این نیاز را از دید کاربر و کسبوکار برآورده میکند یا خیر.
چه کسی Acceptance Testing را انجام میدهد؟
بسته به نوع پروژه و نوع Acceptance Testing، افراد مختلفی میتوانند در این سطح نقش داشته باشند؛ از جمله:
- مشتری
- کاربران موردنظر
- نمایندگان کسبوکار
- سایر ذینفعان
- یا اعضای تیمی که مسئول پذیرش محصول هستند
بنابراین Acceptance Testing لزوماً به این معنی نیست که همیشه خود «کاربر نهایی» تمام تستها را انجام میدهد.
UAT چه ارتباطی با Acceptance Testing دارد؟
UAT یا User Acceptance Testing یکی از شناختهشدهترین شکلهای Acceptance Testing است، اما این دو اصطلاح کاملاً مترادف نیستند.
در UAT، تمرکز بیشتر روی این است که آیا سیستم از دید کاربران و نیازهای کسبوکار قابل قبول است یا خیر.
در کنار UAT، شکلهای دیگری از Acceptance Testing نیز وجود دارند، از جمله:
- Operational Acceptance Testing
- Contractual Acceptance Testing
- Regulatory Acceptance Testing
- Alpha Testing
- Beta Testing
بنابراین بهتر است Acceptance Testing را یک مفهوم گستردهتر در نظر بگیریم که UAT یکی از شکلهای آن است.
تفاوت Acceptance Testing و System Testing چیست؟
در System Testing تمرکز اصلی روی این است که آیا سیستم بهعنوان یک محصول کامل، رفتار و قابلیتهای مورد انتظار را دارد.
اما در Acceptance Testing سؤال اصلی این است که آیا سیستم برای نیازها و هدف موردنظر مشتری، کاربر یا کسبوکار قابل قبول است.
System Testing: آیا سیستم مطابق مشخصات و رفتار مورد انتظار عمل میکند؟
Acceptance Testing: آیا سیستم برای هدف و نیاز موردنظر قابل قبول است؟
این دو مفهوم به مباحث Verification و Validation نیز مرتبط هستند که بهتر است بهصورت جداگانه و با جزئیات بررسی شوند.
سطوح تست نرم افزار در یک نگاه
اکنون میتوان Test Levelهای اصلی را در کنار یکدیگر مقایسه کرد:
| Test Level | اصطلاح رایج | تمرکز اصلی |
|---|---|---|
| Component Testing | Unit Testing | بررسی یک Component بهصورت مستقل |
| Component Integration Testing | بخشی از Integration Testing | بررسی تعامل بین Componentها |
| System Testing | System Testing | بررسی رفتار و قابلیتهای کل سیستم |
| System Integration Testing | بخشی از Integration Testing | بررسی ارتباط سیستم با سایر سیستمها و سرویسها |
| Acceptance Testing | Acceptance Testing / UAT | بررسی پذیرش و مناسب بودن سیستم برای هدف موردنظر |
برای درک بهتر، همان فروشگاه اینترنتی را در نظر بگیریم:
Component Testing
↓
محاسبه قیمت
Component Integration Testing
↓
ارتباط سبد خرید و سفارش
System Testing
↓
فرایند کامل خرید
System Integration Testing
↓
ارتباط با درگاه پرداخت
Acceptance Testing
↓
آیا محصول نیاز موردنظر کاربر و کسبوکار را برآورده میکند؟نکته مهم این است که Integration Testing در terminology دقیق ISTQB را نباید صرفاً یک سطح واحد در کنار System Testing در نظر گرفت. در این چارچوب، بسته به محل یکپارچهسازی، با Component Integration Testing یا System Integration Testing مواجه میشویم.
تفاوت Test Levels و Test Types چیست؟
یکی از نکات مهم در یادگیری تست نرمافزار، تشخیص تفاوت سطوح تست (Test Levels) و انواع تست (Test Types)
است.
این دو مفهوم به هم مرتبطاند، اما یکسان نیستند.
Test Level به چه سؤالی پاسخ میدهد؟
Test Level مشخص میکند:
چه سطحی از نرمافزار را تست میکنیم؟
برای مثال:
- Component Testing
- Component Integration Testing
- System Testing
- System Integration Testing
- Acceptance Testing
Test Type به چه سؤالی پاسخ میدهد؟
Test Type مشخص میکند:
چه جنبهای از نرمافزار را بررسی میکنیم؟
برای مثال:
- Functional Testing
- Performance Testing
- Security Testing
- Usability Testing
بنابراین میتوان یک Test Type را در Test Levelهای مختلف به کار برد.
برای مثال:
System Testing
↓
Performance Testingیا:
System Testing
↓
Security Testingدر این مثالها، System Testing سطح تست است و Performance یا Security مشخص میکند چه جنبهای از سیستم بررسی میشود.
Regression Testing در کدام دسته قرار میگیرد؟
Regression Testing یک Test Level نیست.
Regression Testing میتواند در سطوح مختلف انجام شود. برای مثال، بعد از ایجاد یک تغییر ممکن است لازم باشد:
- یک Component را دوباره تست کنیم،
- Integrationها را بررسی کنیم،
- یا کل سیستم را Regression کنیم.
بنابراین بهتر است این مفاهیم را از یکدیگر جدا نگه داریم:
Test Level: کدام سطح از نرمافزار را تست میکنیم؟
Test Type: چه جنبهای از نرمافزار را بررسی میکنیم؟
Regression Testing: آیا تغییرات جدید باعث ایجاد مشکل در بخشهایی شدهاند که قبلاً درست کار میکردند؟
آیا سطوح تست همیشه به یک ترتیب اجرا میشوند؟
خیر.
اگرچه Test Levelها معمولاً از Component Testing تا Acceptance Testing معرفی میشوند، این به معنی آن نیست که همه پروژهها باید آنها را دقیقاً به همین ترتیب و بهصورت کاملاً خطی اجرا کنند.
نحوه اجرای سطوح تست به عواملی مانند:
- چرخه توسعه نرمافزار (SDLC)
- معماری سیستم
- نوع محصول
- ریسکهای پروژه
- روش توسعه
- نیازمندیها
بستگی دارد.
در برخی پروژهها ممکن است تستها تا حد زیادی به شکل زیر پیش بروند:
Component Testing
↓
Integration Testing
↓
System Testing
↓
Acceptance Testingاما در رویکردهای تکرارشونده مانند Agile، تستها میتوانند در طول Iterationها و Sprintهای مختلف تکرار شوند و چند Test Level در یک چرخه توسعه درگیر باشند.
برای مثال:
Sprint
├── Component Testing
├── Integration Testing
├── System Testing
└── Acceptance Testingهمچنین با ایجاد یک تغییر در نرمافزار، ممکن است تستهای قبلی دوباره اجرا شوند. به همین دلیل Regression Testing میتواند در چند Test Level مختلف اتفاق بیفتد.
آیا هر پروژهای به تمام Test Levelها نیاز دارد؟
لزوماً نه.
برای مثال، یک نرمافزار ساده ممکن است ارتباطی با سیستم خارجی نداشته باشد و در نتیجه System Integration Testing به شکل معمول آن موضوعیت نداشته باشد.
در مقابل، در یک سیستم بزرگ با Microservices، APIهای متعدد و سرویسهای شخص ثالث، بررسی Integrationها میتواند اهمیت بسیار زیادی داشته باشد.
بنابراین Test Levelها را بهتر است بهعنوان چارچوبی برای سازماندهی و درک تستها در نظر بگیریم، نه یک دستورالعمل ثابت که همه پروژهها باید دقیقاً از آن پیروی کنند.
جمعبندی سطوح تست نرم افزار
Test Level یا سطح تست مشخص میکند تست در چه سطحی از نرمافزار انجام میشود و تمرکز اصلی تست روی چه چیزی قرار دارد.
در چارچوب ISTQB، Test Levelهای اصلی عبارتاند از:
- Component Testing که در صنعت نرمافزار معمولاً با اصطلاح Unit Testing شناخته میشود.
- Component Integration Testing برای بررسی تعامل بین Componentها.
- System Testing برای بررسی رفتار و قابلیتهای کل سیستم.
- System Integration Testing برای بررسی ارتباط سیستم با سایر سیستمها و سرویسها.
- Acceptance Testing برای بررسی پذیرش و مناسب بودن سیستم برای هدف موردنظر.
درک این سطوح به تستر کمک میکند مشخص کند چه چیزی را در چه سطحی باید بررسی کند.
در عین حال، نباید Test Level را با Test Type اشتباه گرفت. Test Level درباره سطحی از نرمافزار که تست میشود صحبت میکند، در حالی که Test Type به جنبهای از نرمافزار که مورد بررسی قرار میگیرد مربوط است.
همچنین Test Levelها الزاماً یک ترتیب اجرایی ثابت و خطی ندارند و نحوه استفاده از آنها باید با توجه به ریسک، معماری، نیازمندیها و SDLC پروژه تعیین شود.
در نهایت، یک تستر نرمافزار با شناخت Test Levelها بهتر میتواند تشخیص دهد که در حال بررسی یک Component، تعامل بین Componentها، کل سیستم، ارتباط سیستم با سیستمهای دیگر یا پذیرش محصول است.
