فرض کن یه اپلیکیشن جدید نصب کردی. ظاهرش قشنگه، دکمهها سر جاشن، همهچی مرتب. ولی وقتی میخوای ثبتنام کنی، ایمیل درست وارد میکنی و باز خطا میده! یا مثلاً دکمهی «پرداخت» رو میزنی و هیچ اتفاقی نمیافته. اینجاست که میفهمیم ظاهر خوب کافی نیست، باید مطمئن بشیم پشت صحنه هم همهچی درست کار میکنه.
اینجا پای تست نرمافزار وسط میاد. تست مثل یه فیلتره که قبل از رسیدن محصول به دست کاربر، مشکلات رو میگیره. یکی از روشهای معروف تست، چیزی هست به اسم تست جعبه سیاه (Black Box Testing). اسمش شاید کمی عجیب باشه، ولی ایدهاش خیلی سادهست: ما فقط ورودی و خروجی سیستم رو بررسی میکنیم، بدون اینکه سراغ کد یا ساختار داخلیش بریم.
این مقدمه رو گذاشتم تا ذهن آماده بشه: قراره دربارهی روشی حرف بزنیم که بیشتر شبیه نگاه کاربر به نرمافزاره، نه نگاه برنامهنویس.
تعریف تست جعبه سیاه (Black Box Testing)
تست جعبه سیاه یعنی ما سیستم رو مثل یک جعبه بسته در نظر میگیریم. داخلش رو نمیبینیم و کاری به کدها یا ساختار داخلی نداریم. فقط ورودی میدیم و خروجی رو بررسی میکنیم. اگر خروجی درست بود یعنی سیستم طبق انتظار کار کرده و اگر نه، باید مشکل رو گزارش کنیم.
برای اینکه تصویر واضحتر بشه، تصور کن یک دستگاه خودپرداز جلوی ماست. ما کارت رو وارد میکنیم، رمز میزنیم و انتظار داریم پول بگیریم. هیچوقت لازم نیست بدونیم داخل دستگاه چه کدی نوشته شده یا چه قطعاتی کنار هم کار میکنن. مهم اینه که ورودیمون (کارت و رمز) به خروجی درست (پول یا پیام خطا) منجر بشه. همین نگاه کاربرمحور اساس تست جعبه سیاهه.
گاهی برای درک بهتر، تست جعبه سیاه رو با تست جعبه سفید مقایسه میکنن. در تست جعبه سفید، تستکننده به کد و ساختار داخلی دسترسی داره و میخواد مطمئن بشه همه مسیرهای منطقی درست کار میکنن. ولی در جعبه سیاه، تمرکز فقط روی رفتار بیرونی سیستم هست.
چرا به تست جعبه سیاه نیاز داریم
وقتی یک نرمافزار ساخته میشه، همیشه این احتمال وجود داره که رفتار واقعیاش با چیزی که انتظار داریم فرق کنه. تست جعبه سیاه کمک میکنه این اختلافها رو از دید کاربر پیدا کنیم. چند دلیل مهم برای استفاده از این روش:
- تمرکز روی تجربه کاربر: کاربر هیچوقت کد رو نمیبینه. چیزی که براش مهمه اینه که وقتی دکمهای رو فشار میده یا دادهای وارد میکنه، نتیجه درست بگیره. تست جعبه سیاه دقیقاً همین نگاه رو شبیهسازی میکنه.
- پیدا کردن خطاهای ورودی و خروجی: خیلی از مشکلات نرمافزار مربوط به ورودیهای اشتباه یا خروجیهای غیرمنتظره هستن. با این تست میشه مطمئن شد که سیستم در برابر دادههای مختلف درست واکنش نشون میده.
- مناسب برای تیمهایی که به کد دسترسی ندارن: گاهی تستکنندهها یا مشتریها نمیتونن یا نمیخوان وارد جزئیات فنی بشن. تست جعبه سیاه این امکان رو میده که بدون نیاز به دانش برنامهنویسی، کیفیت محصول بررسی بشه.
- صرفهجویی در زمان: چون تمرکز روی رفتار بیرونی سیستم هست، میشه سریعتر تستها رو طراحی و اجرا کرد، مخصوصا در مراحل اولیه یا زمانی که فقط میخوایم مطمئن بشیم عملکرد کلی درست کار میکنه.
روشها و تکنیکهای رایج در تست جعبه سیاه
وقتی میخوایم یک سیستم رو با نگاه کاربر بررسی کنیم، ابزارهای مختلفی داریم که کمک میکنن ورودیها و خروجیها رو بهتر بسنجیم. چند تا از مهمترین روشها:
- Equivalence Partitioning (تقسیمبندی معادل): ورودیها رو به گروههای مشابه تقسیم میکنیم. مثلاً اگر یک فیلد فقط عدد بین ۱ تا ۱۰۰ قبول میکنه، لازم نیست همه اعداد رو تست کنیم. کافیست چند نمونه از هر بخش (مثلاً یک عدد درست و یک عدد خارج از محدوده) رو امتحان کنیم.
- Boundary Value Analysis (تحلیل مقادیر مرزی): خیلی وقتها خطاها دقیقاً در مرزها رخ میدن. مثلاً اگر سیستم تا ۱۰۰ ورودی رو قبول میکنه، باید ببینیم با ۹۹، ۱۰۰ و ۱۰۱ چه رفتاری نشون میده.
- Decision Table Testing (تست با جدول تصمیم): وقتی شرایط مختلف و ترکیبهای زیادی وجود داره، جدول تصمیم کمک میکنه همه حالتها رو منظم بررسی کنیم.
- State Transition Testing (تست تغییر وضعیت): برای سیستمهایی که حالتهای مختلف دارن (مثل لاگین، لاگاوت، قفل شدن حساب)، بررسی میکنیم که تغییر وضعیتها درست انجام بشن.
انواع اصلی تست جعبه سیاه
تا اینجا گفتیم تست جعبه سیاه یعنی نگاه کردن به نرمافزار از بیرون، دقیقاً مثل کاری که کاربر انجام میدهد. اما این رویکرد فقط یک شکل ندارد. بسته به اینکه چه چیزی را میخواهیم بررسی کنیم، تست جعبه سیاه معمولا در سه دستهی اصلی قرار میگیرد.
۱. تست فانکشنال (Functional Testing)
رایجترین و آشناترین نوع تست جعبه سیاه، تست فانکشنال است. در این تست هدف این است که یک سوال پاسخ داده شود:
آیا نرمافزار همان کاری را انجام میدهد که قرار بوده انجام بدهد یا نه؟
در تست فانکشنال، ما سراغ قابلیتها و عملکردهای سیستم میرویم. مثلاً:
- آیا فرم ثبتنام با اطلاعات درست، کاربر را ثبت میکند؟
- اگر ایمیل اشتباه وارد شود، پیام خطا نمایش داده میشود؟
- دکمه پرداخت واقعاً پرداخت را انجام میدهد یا فقط ظاهرش شبیه دکمه است؟
در این نوع تست، اصلا مهم نیست پشت صحنه چه کدی نوشته شده یا منطق برنامه چطور پیادهسازی شده. فقط ورودی میدهیم و خروجی را با چیزی که انتظار داریم مقایسه میکنیم. اگر نتیجه درست بود، یعنی این بخش از سیستم کارش را درست انجام داده.
۲. تست غیر فانکشنال (Non-Functional Testing)
خیلیها فکر میکنند تست جعبه سیاه فقط برای بررسی عملکردهاست، ولی در عمل اینطور نیست. بعضی وقتها مشکل نرمافزار این نیست که «کار نمیکند»، بلکه این است که خوب کار نمیکند.
اینجاست که تستهای غیر فانکشنال وارد میشوند. در این تستها، سؤال ما این نیست که سیستم چه کاری انجام میدهد، بلکه این است که:
- آیا سریع است؟
- آیا امن است؟
- آیا کار کردن با آن راحت است؟
- آیا وقتی تعداد کاربر زیاد میشود، هنوز درست جواب میدهد؟
مثلاً:
- اگر همزمان صد نفر روی سایت باشند، هنوز صفحهها لود میشوند؟
- آیا با وارد کردن دادههای عجیب یا مخرب، سیستم از کار میافتد؟
- آیا کاربر میتواند بدون سردرگمی مسیر خودش را پیدا کند؟
در همهی این حالتها، ما باز هم کاری به کد نداریم و فقط رفتار بیرونی سیستم را بررسی میکنیم. به همین دلیل، این تستها هم جزو تست جعبه سیاه حساب میشوند.
۳. تست رگرسیون (Regression Testing)
فرض کن یک باگ را درست کردهای یا یک قابلیت جدید به سیستم اضافه شده. سؤال مهم اینجاست:
نکند این تغییر جدید، چیزی را که قبلاً درست کار میکرده خراب کرده باشد؟
تست رگرسیون دقیقا برای جواب دادن به همین سؤال است. در این نوع تست، سناریوهایی که قبلا تست شدهاند دوباره اجرا میشوند تا مطمئن شویم تغییرات جدید، دردسر تازه درست نکردهاند.
مثلاً:
- بعد از اضافه شدن یک قابلیت جدید، هنوز ثبتنام درست کار میکند؟
- بعد از تغییر در پرداخت، خریدهای قبلی بدون مشکل انجام میشوند؟
تست رگرسیون معمولاً بدون نگاه به کد انجام میشود و تمرکزش روی رفتار قابل مشاهدهی سیستم است. به همین خاطر، یکی از کاربردهای مهم تست جعبه سیاه در پروژههایی است که مدام در حال تغییر و بهروزرسانی هستند.
مزایا و معایب تست جعبه سیاه
وقتی دربارهی تست جعبه سیاه حرف میزنیم، خوبه هم نقاط قوتش رو ببینیم و هم محدودیتهاش رو بشناسیم. اینطوری میتونیم تصمیم بگیریم کجا بهترین استفاده رو ازش داشته باشیم.
مزایا
- کاربرمحور بودن: دقیقاً مثل نگاه کاربر به سیستم عمل میکنه و تجربه واقعی رو میسنجه.
- سادگی در طراحی تست: لازم نیست کد رو بشناسیم، فقط ورودی و خروجی رو بررسی میکنیم.
- مناسب برای تیمهای غیر فنی: کسانی که برنامهنویس نیستن هم میتونن تستها رو اجرا کنن.
- پوشش گستردهی عملکردها: میشه کل سیستم رو از بیرون بررسی کرد، نه فقط بخشهای داخلی.
معایب
- عدم شناسایی خطاهای داخلی: اگر مشکلی در منطق یا ساختار کد باشه، ممکنه دیده نشه.
- وابستگی به طراحی تست خوب: اگر ورودیها درست انتخاب نشن، خیلی از خطاها کشف نمیشن.
- زمانبر بودن در حالتهای پیچیده: وقتی شرایط و ورودیها زیاد باشن، طراحی همه تستها سخت میشه.
- عدم پوشش کامل مسیرهای کد: چون به کد دسترسی نداریم، نمیتونیم مطمئن بشیم همه شاخههای منطقی بررسی شدن.
مثال واقعی یا سناریو
برای اینکه تست جعبه سیاه ملموستر بشه، بیایم یک مثال ساده رو بررسی کنیم. فرض کن یک فرم ثبتنام در یک وبسایت داریم. این فرم شامل فیلدهای «نام»، «ایمیل» و «رمز عبور» هست. حالا تستکننده بدون اینکه کدی پشت این فرم رو ببینه، شروع میکنه ورودیهای مختلف رو امتحان کردن:
- وارد کردن ایمیل درست مثل
user@example.comو انتظار اینکه سیستم قبول کنه. - وارد کردن ایمیل اشتباه مثل
userexample.comو انتظار اینکه سیستم خطا بده. - گذاشتن فیلد خالی و بررسی اینکه آیا پیام هشدار نمایش داده میشه یا نه.
- وارد کردن رمز عبور خیلی کوتاه و دیدن اینکه سیستم اجازه ثبتنام میده یا خطا میده.
این تستها همه از جنس جعبه سیاه هستن چون فقط ورودی و خروجی بررسی میشن. تستکننده هیچوقت لازم نداره بدونه کد اعتبارسنجی ایمیل چطور نوشته شده یا رمز عبور چطور ذخیره میشه.
همین رویکرد رو میشه در سناریوهای دیگه هم دید. مثلاً در یک اپلیکیشن پرداخت آنلاین، تستکننده بررسی میکنه که وقتی مبلغ درست وارد میشه تراکنش موفق باشه و وقتی کارت منقضی شده وارد میشه، سیستم خطا بده.
جمعبندی
تست جعبه سیاه رو میشه مثل نگاه کاربر به یک نرمافزار در نظر گرفت. ما کاری به کد و پشت صحنه نداریم، فقط ورودیها و خروجیها رو بررسی میکنیم. این روش کمک میکنه مطمئن بشیم سیستم از دید کاربر درست کار میکنه و نیازهای اصلی رو برآورده میکنه.
دیدگاهتان را بنویسید