‏تکنیک‌های حرفه‌ای برای تست نرم‌افزار بهتر

تست نرم‌افزار خوب فقط به نوشتن یه سری unit test و integration test ختم نمی‌شه. تست‌های مبتنی بر مثال (example-based) فقط سناریوهایی رو پوشش می‌دن که از قبل بهشون فکر کردی — یعنی هر باگی که ذهنت بهش نرسیده، همچنان توی کد پنهانه. این مقاله یه مجموعه از تکنیک‌های قوی‌تره که می‌تونی روی هر نوع تستی لایه‌بندی کنی.

تصادفی‌سازی (Randomness) یکی از ساده‌ترین و مؤثرترین کارها اینه که ورودی‌های تستت رو تصادفی کنی. این کار طیف وسیع‌تری از حالت‌ها رو پوشش می‌ده و باگ‌هایی رو آشکار می‌کنه که هیچ‌وقت پیش‌بینیشون نمی‌کردی. تصادفی‌سازی می‌تونه روی ورودی توابع، ترتیب اجرای توابع، پیکربندی سیستم، و حتی زمان‌بندی اعتبارسنجی‌ها اعمال بشه. ابزارهای محبوبی مثل Hypothesis برای پایتون، libFuzzer برای C/C++، و AFL++ این کار رو خیلی راحت می‌کنن.

تنظیم دقیق تصادفی‌سازی صرفاً تصادفی بودن کافی نیست — باید اون رو تنظیم کنی. مثلاً اگه فکر می‌کنی صدا زدن تابع a() دو بار پشت‌سرهم احتمال بیشتری برای پیدا کردن باگ داره، می‌تونی وزن این حالت رو بالاتر ببری. اما مراقب باش: اگه خیلی زیاد تنظیم کنی، ترکیب‌های دیگه‌ای مثل a() -> b() -> a() هرگز تست نمی‌شن و باگ‌های پنهان در اون مسیرها کشف نمی‌شن. رویکردهایی مثل Adaptive Random Testing و coverage-guided fuzzing مثل AFL++ کمک می‌کنن این تعادل بهتر برقرار بشه.

Swarm Testing این تکنیک جالبه: بعضی وقت‌ها می‌تونی باگ‌های بیشتری پیدا کنی اگه بخشی از سیستمت رو موقتاً غیرفعال کنی. فرض کن یه برنامه داری با توابع increment() و decrement(). اگه هر دو با احتمال مساوی صدا زده بشن، شمارنده هرگز به اندازه کافی بزرگ یا کوچک نمی‌شه تا باگ رو فعال کنه. اما اگه گاهی فقط increment() رو فعال کنی، شانس رسیدن به اون باگ خیلی بالاتر می‌ره. Swarm testing این کار رو به‌صورت تصادفی و چرخشی انجام می‌ده تا هیچ بخشی از کد همیشه نادیده نمونه.

پوشش کل سطح سیستم یه اشتباه رایج اینه که بخش‌هایی مثل APIهای پیکربندی یا مدیریت سیستم از تست جا می‌مونن. دقیقاً همین جاهاست که باگ‌ها جمع می‌شن. تست‌هات باید سیستم رو از صفر راه‌اندازی کنه و فاز راه‌اندازی و عملیات‌های مدیریتی رو هم جدی بگیره.

تست کرش‌های «درست» یه تله رایج اینه که سعی می‌کنیم از خاموش شدن یا کرش کردن سیستم توی تست جلوگیری کنیم. اما اگه سیستم قرار باشه در شرایط خاصی خاموش بشه، باید مطمئن بشیم این اتفاق توی تست می‌افته. فرایندهای بازیابی (recovery) معمولاً باگ‌های زیادی پنهان می‌کنن و تست نکردنشون یعنی یه دسته کامل از مشکلات نادیده گرفته می‌شن.

Buggification: رویدادهای نادر رو رایج کن بعضی مسیرهای کد — مثل error handling یا retry logic — به‌ندرت در حالت عادی اجرا می‌شن. «Buggification» یعنی توی محیط تست، عمداً با احتمال کم خطا تزریق کنیم تا این مسیرها بیشتر تست بشن. مثلاً این کد نشون می‌ده چطور می‌شه با یه شرط ساده خطای مصنوعی ایجاد کرد:

void my_function(Data data) {
  try {
    if (running_under_test() && random() <= 0.01) {
      throw new Error("Artificial error introduced by buggification in my_function()");
    }
    int result = process_data(data);
    send(result);
  } catch (Exception e) {
    send("Unable to process data. Exception was: " + e);
  }
}

این ۱٪ احتمال خطا باعث می‌شه کد error handling که شاید ماه‌ها تست نشده بود، حالا به‌طور منظم زیر فشار قرار بگیره و مشکلاتش سر بزنه.

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

نکات کلیدی:

• تست‌های مبتنی بر مثال فقط باگ‌هایی رو پیدا می‌کنن که از قبل بهشون فکر کردی — تصادفی‌سازی این محدودیت رو می‌شکنه
• تنظیم بیش از حد تصادفی‌سازی می‌تونه ترکیب‌های مهمی از حالت‌ها رو از تست حذف کنه
• Swarm testing با غیرفعال کردن موقت بخش‌هایی از سیستم، باگ‌هایی رو آشکار می‌کنه که در تست کامل هرگز ظاهر نمی‌شن
• APIهای پیکربندی و مدیریتی جاهایی هستن که باگ جمع می‌شه و اغلب نادیده گرفته می‌شن
• کرش‌ها و خاموش شدن‌های برنامه‌ریزی‌شده باید حتماً در تست اتفاق بیفتن
• Buggification با تزریق خطاهای مصنوعی با احتمال کم، مسیرهای کد نادر رو به بخش‌های پرتکرار تست تبدیل می‌کنه