برای پیدا کردن باگ لازم نیست همیشه کد را ببینیم. وقتی Rule تخفیف، پاسخ API یا مسیر لغو سفارش را از روی ورودی و خروجی بررسی میکنیم، از دیدگاه تست جعبه سیاه (Black-box Testing) استفاده کردهایم. چالش اصلی، انتخاب چند تست هدفمند از میان ورودیها و مسیرهای تقریباً بینهایت است.
در این راهنمای جامع، تفاوت جعبهسیاه با جعبهسفید و خاکستری، چهار تکنیک اصلی طراحی تست مبتنی بر Specification، روشهای مکمل، مثالهای عملی و یک ماتریس انتخاب را بررسی میکنیم. برای آموزش عمیق EP و BVA، مقاله جداگانه تقسیمبندی همارزی و تحلیل مقدار مرزی مرجع تخصصی این خوشه است.
فهرست مطالب
تست جعبه سیاه (Black-box Testing) چیست؟
تست جعبه سیاه رویکردی است که تست را بر اساس رفتار قابلمشاهده، نیازمندی، قرارداد و Specification طراحی میکند، نه ساختار داخلی کد. تستر ورودی، اقدام، خروجی، State و اثر جانبی را میسنجد و میپرسد سیستم از بیرون چه رفتاری باید داشته باشد.
جعبهسیاه به معنی «تستر هیچ دانش فنی ندارد» نیست. تستر ممکن است معماری و API را بشناسد، اما مبنای پوشش این تست، Rule و رفتار بیرونی است. همچنین فقط UI نیست: Unit از دید Contract، API، Integration، System و Acceptance هم میتوانند با تکنیک Black-box طراحی شوند.
نمونههای Black-box Test
- فیلد سن فقط بازه مجاز را میپذیرد؛
- کاربر بدون نقش مدیر پاسخ ۴۰۳ میگیرد؛
- تخفیف بر اساس نوع کاربر و مبلغ درست اعمال میشود؛
- سفارش فقط از Stateهای مجاز عبور میکند؛
- Callback تکراری نتیجه را دوباره اعمال نمیکند؛
- جریان ثبتنام از دید کاربر کامل میشود.
مزایا
- تمرکز مستقیم بر نیاز کاربر و کسبوکار؛
- امکان طراحی پیش از تکمیل کد؛
- استقلال نسبی از جزئیات پیادهسازی؛
- کاربرد در سطحها و فناوریهای مختلف؛
- مناسب برای کشف Rule اشتباه، رابط ناسازگار و رفتار ناقص؛
- مکمل دید توسعهدهنده و تست ساختاری.
محدودیتها
- پوشش کد، شاخه و مسیر داخلی را نشان نمیدهد؛
- اگر Specification ناقص باشد، تست نیز ممکن است ناقص شود؛
- ترکیب پارامترها و Stateها سریع بزرگ میشود؛
- علت ریشهای شکست همیشه از خروجی بیرونی روشن نیست؛
- رفتار پنهان یا کد مرده بدون روش دیگر دیده نمیشود.
تفاوت تست جعبه سیاه، سفید و خاکستری
| رویکرد | مبنای طراحی | نمونه تمرکز | ریسک پوششدادهشده |
|---|---|---|---|
| Black-box | Requirement، Rule، ورودی/خروجی | تخفیف و State سفارش | رفتار اشتباه یا ناقص |
| White-box | کد، Branch، Condition، Path، Data Flow | شاخه اجرا نشده یا Loop | منطق و ساختار داخلی |
| Gray-box | ترکیب رفتار بیرونی و دانش محدود داخل | API با شناخت DB/Cache | یکپارچگی و نقاط پنهانتر |
این رویکردها رقیب نیستند. برای پوشش ساختار، راهنمای تکنیکهای تست جعبه سفید و برای ترکیب دیدها، مقاله تست جعبه خاکستری را بخوانید.
چهار تکنیک اصلی Black-box در ISTQB
سرفصل رسمی ISTQB Foundation Level چهار تکنیک Black-box را پوشش میدهد: Equivalence Partitioning، Boundary Value Analysis، Decision Table Testing و State Transition Testing.
۱. تقسیمبندی همارزی (Equivalence Partitioning)
فضای داده را به پارتیشنهایی تقسیم میکنیم که انتظار داریم اعضای هرکدام رفتار مشابهی داشته باشند. سپس از هر پارتیشن دستکم یک نماینده انتخاب میکنیم.
مثال سن ۱۸ تا ۶۵
- کمتر از ۱۸: نامعتبر؛
- ۱۸ تا ۶۵: معتبر؛
- بیشتر از ۶۵: نامعتبر؛
- اعشاری: نامعتبر اگر فقط Integer مجاز است؛
- متن یا خالی: طبق Rule جدا.
نماینده میانی بهتنهایی مرز را پوشش نمیدهد. پارتیشنها باید بدون همپوشانی و غیرخالی باشند. برای ورودی پیچیده و Edge Case، راهنمای تقسیمبندی همارزی پیشرفته را ببینید.
چه زمانی مناسب است؟
- دامنه ورودی یا خروجی بزرگ است؛
- Rule گروههای معتبر/نامعتبر دارد؛
- نوع کاربر، روش پرداخت یا تنظیمات Behavior متفاوت دارند؛
- میخواهیم تعداد دادهها را بدون حذف گروه مهم کم کنیم.
۲. تحلیل مقدار مرزی (Boundary Value Analysis)
BVA روی مرز پارتیشنهای مرتب تمرکز میکند، چون خطاهای <، <=، > و >= معمولاً در لبه آشکار میشوند.
برای بازه ۱۸ تا ۶۵:
- روش دو نقطهای: ۱۷، ۱۸، ۶۵، ۶۶؛
- روش سه نقطهای: ۱۷، ۱۸، ۱۹ و ۶۴، ۶۵، ۶۶.
مرز فقط عدد نیست: طول رمز، تعداد فایل، تاریخ انقضا، اندازه Upload و تعداد تلاش ورود نیز مرز دارند. راهنمای تحلیل مقدار مرزی پیشرفته Robustness و Error Guessing را توضیح میدهد.
نکته مهم درباره کوچکترین گام
همسایه مرز به دقت داده وابسته است. برای مبلغ با دو رقم اعشار، مقدار بعدی ممکن است ۰٫۰۱ باشد؛ برای Timestamp شاید یک میلیثانیه. آن را از Requirement و Precision سیستم بگیرید.
۳. تست جدول تصمیم (Decision Table Testing)
وقتی خروجی به ترکیب چند شرط وابسته است، جدول تصمیم Ruleها را به ستونهای قابلبررسی تبدیل میکند. مثال:
- کاربر VIP است؟
- مبلغ بالای آستانه است؟
- کد تخفیف معتبر است؟
- اقدام: درصد تخفیف یا پیام رد.
| شرط/Rule | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| VIP؟ | بله | بله | خیر | خیر |
| کد معتبر؟ | بله | خیر | بله | خیر |
| اعمال تخفیف؟ | ویژه | پایه VIP | عمومی | خیر |
جدول نشان میدهد ترکیبها کامل، متناقض یا دارای اولویت نامشخصاند. راهنمای تست جدول تصمیم مراحل ساخت را پوشش میدهد.
۴. تست انتقال حالت (State Transition Testing)
وقتی پاسخ سیستم به State قبلی و Event وابسته است، فقط ورودی فعلی کافی نیست. مدل شامل State، Event، Guard، Action و State بعدی میشود.
مثال سفارش
- Draft → پرداخت موفق → Paid؛
- Paid → ارسال → Shipped؛
- Paid → لغو پیش از ارسال → Cancelled؛
- Shipped → لغو مستقیم → ممنوع یا فرایند مرجوعی؛
- Callback موفق تکراری در Paid → بدون تغییر دوم.
هم انتقالهای مجاز و هم نامعتبر را تست کنید. مقاله State Transition Testing جدول و نمودار عملی دارد.
روشهای مکمل طراحی جعبه سیاه
Use Case Testing
مسیر اصلی، Alternate و Exception را از هدف Actor تا Outcome پوشش میدهد. برای End-to-End و Acceptance مناسب است.
Pairwise / Combinatorial Testing
وقتی Browser × OS × Role × Locale ترکیب زیادی میسازد، Pairwise مجموعهای انتخاب میکند که تعامل هر جفت مقدار را پوشش دهد. ریسکهای بحرانی باید جدا و صریح پوشش بگیرند.
Cause–Effect Graphing
علتها و اثرهای منطقی را مدل و سپس به جدول تصمیم تبدیل میکند؛ برای Ruleهای پیچیده مفید اما نیازمند زمان و دقت است.
Error Guessing
یک تکنیک تجربهمحور است، نه Black-box رسمی مبتنی بر Specification؛ اما مکمل بسیار مؤثری است. تستر از باگهای قبلی و دانش دامنه برای مواردی مانند Double-click، Null، Back/Refresh، Race، Timezone و ارقام فارسی استفاده میکند.
Checklist-based Testing
لیست ریسکهای تکرارشونده مانند دسترسی، خطا، Log، RTL و Recovery را مرور میکند. چکلیست باید از داده واقعی محصول بهروز شود.
ماتریس انتخاب تکنیک تست
| مسئله | تکنیک اصلی | مثال |
|---|---|---|
| دامنه بزرگ با رفتار گروهی | Equivalence Partitioning | سن، نوع فایل، نقش کاربر |
| لبه بازه یا ظرفیت | Boundary Value Analysis | حداقل مبلغ، طول، تاریخ |
| ترکیب شرط و Rule | Decision Table | تخفیف، مجوز، کارمزد |
| رفتار وابسته به وضعیت | State Transition | سفارش، حساب، تیکت |
| هدف و جریان کاربر | Use Case | ثبتنام، خرید، مرجوعی |
| پیکربندیهای زیاد | Pairwise | Browser/OS/Locale |
| باگهای شناختهشده دامنه | Error Guessing | دابلکلیک، تومان/ریال |
یک قابلیت معمولاً بیش از یک تکنیک میخواهد. EP/BVA داده را پوشش میدهند، Decision Table ترکیب Rule را و State Transition توالی را. آنها را بر اساس Risk کنار هم قرار دهید.
مثال عملی: تست جعبه سیاه Checkout
فرض کنید Checkout فروشگاه ایرانی شامل آدرس، روش ارسال، کد تخفیف و پرداخت است.
تقسیمبندی همارزی
- کد تخفیف معتبر، منقضی، مصرفشده و متعلق به کاربر دیگر؛
- آدرس داخل محدوده ارسال و خارج آن؛
- کاربر مهمان، عادی و VIP؛
- پرداخت موفق، ناموفق و نامشخص.
مقدار مرزی
- مبلغ درست قبل، روی و بعد از آستانه ارسال رایگان؛
- حداقل و حداکثر طول آدرس و کد پستی؛
- آخرین لحظه اعتبار کد و بلافاصله پس از انقضا؛
- حداکثر تعداد کالا در سبد و یک مورد بیشتر.
جدول تصمیم
نوع کاربر × مبلغ × کد × کمپین را به Rule تبدیل کنید تا اولویت تخفیف و امکان تجمیع مشخص شود.
انتقال حالت
Cart → Pending Payment → Paid/Failed/Unknown. Callback تکراری، Retry و بازگشت با Back نباید سفارش دوباره بسازند.
Use Case و Error Guessing
- Main: خرید موفق؛
- Alternate: تغییر آدرس یا روش ارسال؛
- Exception: موجودی تمام، Timeout و کد منقضی؛
- Error Guessing: Double-click پرداخت، ارقام فارسی، چند Tab، Refresh و اختلاف ریال/تومان.
پوشش در تست جعبه سیاه
Coverage را با معیار تکنیک بسنجید، نه فقط تعداد Test Case:
- EP Coverage: چند پارتیشن شناساییشده نماینده دارند؟
- BVA Coverage: چند مرز/شرط مرزی تست شده است؟
- Decision Table: چند Rule معتبر پوشش دارد؟
- State Transition: چند State و Transition مجاز/نامعتبر بررسی شدهاند؟
- Requirement/Risk: کدام نیاز و ریسک Test Condition دارد؟
صددرصد یک معیار تضمین بیعیبی نیست؛ فقط محدوده همان مدل را نشان میدهد. Specification ناقص یا Risk ناشناخته میتواند بیرون بماند.
تست جعبه سیاه دستی یا خودکار؟
تکنیک طراحی از روش اجرا جداست. تست Black-box میتواند دستی یا خودکار باشد:
- EP/BVA را Data-driven در Unit/API اجرا کنید؛
- Decision Table را به Parameterized Test تبدیل کنید؛
- State Transition را با Model/State Coverage پوشش دهید؛
- چند Use Case حیاتی را UI خودکار کنید؛
- Error Guessing و Exploratory را با انسان ادامه دهید.
اتوماسیون نباید تعداد زیاد Test Case مشابه در UI بسازد. Rule را در پایینترین سطح مؤثر تست کنید.
اشتباهات رایج
- برابر دانستن Black-box با «فقط UI»؛
- فرض اینکه تستر نباید هیچ دانش فنی داشته باشد؛
- نوشتن فقط Happy Path؛
- یکیکردن همه دادههای نامعتبر در یک Partition؛
- فراموشکردن مرز باز/بسته و Precision؛
- استفاده از EP/BVA برای Rule چندشرطی بدون Decision Table؛
- نادیدهگرفتن State و توالی رویداد؛
- انفجار ترکیبها بدون Pairwise/Risk؛
- تکیه کامل به Specification ناقص؛
- عدم ترکیب با White-box، Static و Exploratory.
چکلیست طراحی Black-box Test
- Actor، هدف و رفتار قابلمشاهده روشن است.
- Specification، Rule و Acceptance Criterion بازبینی شدهاند.
- ورودی، خروجی، State و اثر جانبی فهرست شدهاند.
- پارتیشنهای معتبر/نامعتبر جدا و بدون همپوشانیاند.
- مرز و کوچکترین گام داده مرتب مشخص است.
- ترکیب شرطها در جدول تصمیم آمده است.
- State و Transition مجاز/ممنوع مدل شدهاند.
- Main، Alternate و Exception Flow پوشش دارند.
- ترکیب زیاد با Risk/Pairwise کنترل شده است.
- تاریخچه باگ برای Error Guessing استفاده شده است.
- سطح تست مناسب انتخاب شده است.
- Coverage به Requirement/Risk قابلردیابی است.
سوالات متداول
آیا تست جعبه سیاه فقط توسط QA انجام میشود؟
خیر. Developer، QA، Product و Business میتوانند تست مبتنی بر رفتار و Specification طراحی یا اجرا کنند. نقشها به سطح و زمینه بستگی دارند.
آیا برای Black-box Testing برنامهنویسی لازم است؟
برای طراحی دستی الزام نیست، اما دانش API، داده، SQL و کدنویسی توان تحلیل و اتوماسیون را بیشتر میکند. مبنای طراحی رفتار بیرونی است، نه میزان دانش فنی فرد.
آیا Black-box همان Functional Testing است؟
خیر. Black-box رویکرد طراحی بر اساس رفتار است؛ Functional هدف بررسی کارکرد است. بسیاری از Functional Testها Black-box هستند، اما Non-functional Requirement نیز میتواند از بیرون تست شود.
بهترین تکنیک جعبه سیاه کدام است؟
به مدل مسئله بستگی دارد: گروه داده → EP، مرز → BVA، شرطها → Decision Table، State → Transition، جریان کاربر → Use Case. معمولاً ترکیب چند تکنیک لازم است.
آیا تست جعبه سیاه بهتنهایی کافی است؟
معمولاً نه. با تست استاتیک، White-box، Gray-box، تحلیل امنیت، Non-functional و Exploratory ترکیب شود تا هم Specification و هم ساختار و ریسک ناشناخته دیده شوند.
جمعبندی
تست جعبه سیاه فضای بزرگ رفتار را به مدلهای قابلمدیریت تبدیل میکند. EP گروهها، BVA لبهها، Decision Table ترکیب Rule و State Transition توالی رفتار را پوشش میدهند. تکنیک را از روی شکل مسئله انتخاب، با روشهای مکمل و ریسک ترکیب و پوشش را با مدل مربوط اندازهگیری کنید—نه با تعداد خام تستکیس.
