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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

منبع خبر