فرار از عذاب آزمون رگرسیون (Regression testing)

1395/4/1 ابوالفضل دیزجی 1123

یکی از عوامل بروز و ظهور Failure در سیستم­های نرم­افزاری، تغییر است. در این حالت میزان احتمال بروز خطا در سیستم معمولا به قدری بالاست که نمی­توان از آن گذشت. اما مساله ناگوارتر این موضوع است، که بسیاری اوقات قسمت­هایی دچار ایراد می­شوند، که Developer کوچکترین کاری روی آنها انجام نداده است. اصلی‌ترین دلیل این موضوع همان Ripple Effect یا اثر موجیست، که گاهی اوقات یک تغییر یا نقص، موجی به راه میندازد، که روی دیگر عناصر سیستم نیز تاثیر می­گذارد، و این تاثیر در صورتیکه از یک اقدام اشتباه یا نقص سرچشمه گرفته باشد، می­تواند سیستم را دچار Failureهای گسترده کند.    

آیا متوجه نکته غم­انگیز در پاراگراف قبل شدید؟

...بسیاری اوقات قسمت­هایی دچار ایراد می­شوند، که Developer کوچکترین کاری روی آنها انجام نداده است...

این جمله فقط یک معنی می­دهد: شما نمی­دانید که ممکن است Failure در کجای سیستم رخ داده باشد!

گاهی اوقات حتی قسمتی که Developer روی آن در حال کار بوده است، بدون نقص عملیات خود را انجام می­دهد، اما یک یا چند قسمت دیگر سیستم Fail می­شود.

این یعنی شما باید به دنبال یک سوزن در انبار کاه باشید، و البته ممکن است هیچ سوزنی هم در انبار کاه وجود نداشته باشد.

از این کار معمولا به عذاب‌آورترین کار تیم آزمون یاد می­شود.

اما آیا می­توان این کار بسیار حجیم و مهم را که پهنۀ وسیعی از هزینه آزمون نرم­افزار را به خود اختصاص می­دهد، بدون تکنیک­های علمی انجام داد؟

می­توان گفت انجام بدون تکنیک این کار، تقریبا با انجام ندادن آن برابر است.

اما چه روش­های کلی برای آزمون رگرسیون وجود دارد؟

در اینجا، پنج حالت محتمل است، که به فراخور سیستم حادث می­شود:

  1. آزمون تصادفی
  2. اجرای مجدد تمامی آزمون­هایی که نارسایی­های مرتفع شده در انتشار قبلیِ نرم­افزار را شناسایی کرده­اند
  3. آزمودن تمام قسمت­های برنامه که تغییر کرده یا تصحیح شده
  4. آزمودن تمام قسمت­ها یا عناصری از برنامه که جدیدا یکپارچه(Integrate) شده­اند
  5. آزمودن کل سیستم

حالت 1، به هیچ وجه روش قابل اطمینانی نیست، و معمولا تیم­هایی که مشکلات شدید مهندسی یا کمبود زمان دارند از این روش استفاده می­کنند. حالات 2 تا 4 راندمان نسبتا خوبی دارند، چون به احتمال زیاد تعداد زیادی از مشکلات محتمل در این روش کشف می­شوند. روش پنجم از همه مطمئنتر است، اما تقریبا غیرممکن می­باشد. چون بر اساس قواعد ریاضی، آزمون کامل کاری غیرممکن است، که مجال بحث آن در اینجا نیست.

البته منظور از آزمون کامل در اینجا آزمون تعداد زیادی از Test Caseها بر اساس قواعد علمی آزمون است.

اما متدهایی وجود دارد، که بتوان میزان راندمان آزمون رگرسیون را افزایش داد، و تقریبا آنرا به سمت کمال سوق داد. یعنی پیروی از روشی که با کمترین تعداد آزمون بیشترین تعداد نقص را در سیستم کشف کرد. در این متدها صرفا بر اولویت بندی Test Caseها در Test Suit و حذف برخی از آنها بر اساس میزان اهمیت­شان تمرکز می­کنند. این میزان اهمیت خود بر اساس متریک­هایی استخراج می­شود، که خود از قواعد علمی و فنی پیروی می­کنند.

Test Suit در حقیقت مجموعه­ای زنجیروار از Test Caseهای متوالیست که اجرای آنها به یکدیگر وابسته است.

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

سه متد برای اولویت­بندی Test Caseها در Test Suitها وجود دارد: OTCP، APFD و FTCP.

در تحقیقات انجام شده در سال 2015 که در ژورنال بین­المللی مهندسی نرم­افزار منتشر شد، مشخص گردید که متد FTCP برای اولویت­بندی Test Caseها مفیدتر است. توضیح روش FTCP از حوصله این مقاله خارج است، اما مهمترین اصلی که در روش FTCP بدان توجه می­شود، این است که بر اساس این الگوریتم، نقصی که حداقل زمان برای تشخیص آن در Test Suite اختصاص داده شده، در ابتدای امر قرار می­گیرد.

در تحقیقاتی مقایسه­ای که در این راستا انجام گردید مشخص شد، با این روش، راندمان آزمون رگرسیون به نسبت دو روش APFD و OTCP افزایش می­یابد.