فرار از عذاب آزمون رگرسیون (Regression testing)
یکی از عوامل بروز و ظهور Failure در سیستمهای نرمافزاری، تغییر است. در این حالت میزان احتمال بروز خطا در سیستم معمولا به قدری بالاست که نمیتوان از آن گذشت. اما مساله ناگوارتر این موضوع است، که بسیاری اوقات قسمتهایی دچار ایراد میشوند، که Developer کوچکترین کاری روی آنها انجام نداده است. اصلیترین دلیل این موضوع همان Ripple Effect یا اثر موجیست، که گاهی اوقات یک تغییر یا نقص، موجی به راه میندازد، که روی دیگر عناصر سیستم نیز تاثیر میگذارد، و این تاثیر در صورتیکه از یک اقدام اشتباه یا نقص سرچشمه گرفته باشد، میتواند سیستم را دچار Failureهای گسترده کند.
آیا متوجه نکته غمانگیز در پاراگراف قبل شدید؟
...بسیاری اوقات قسمتهایی دچار ایراد میشوند، که Developer کوچکترین کاری روی آنها انجام نداده است...
این جمله فقط یک معنی میدهد: شما نمیدانید که ممکن است Failure در کجای سیستم رخ داده باشد!
گاهی اوقات حتی قسمتی که Developer روی آن در حال کار بوده است، بدون نقص عملیات خود را انجام میدهد، اما یک یا چند قسمت دیگر سیستم Fail میشود.
این یعنی شما باید به دنبال یک سوزن در انبار کاه باشید، و البته ممکن است هیچ سوزنی هم در انبار کاه وجود نداشته باشد.
از این کار معمولا به عذابآورترین کار تیم آزمون یاد میشود.
اما آیا میتوان این کار بسیار حجیم و مهم را که پهنۀ وسیعی از هزینه آزمون نرمافزار را به خود اختصاص میدهد، بدون تکنیکهای علمی انجام داد؟
میتوان گفت انجام بدون تکنیک این کار، تقریبا با انجام ندادن آن برابر است.
اما چه روشهای کلی برای آزمون رگرسیون وجود دارد؟
در اینجا، پنج حالت محتمل است، که به فراخور سیستم حادث میشود:
- آزمون تصادفی
- اجرای مجدد تمامی آزمونهایی که نارساییهای مرتفع شده در انتشار قبلیِ نرمافزار را شناسایی کردهاند
- آزمودن تمام قسمتهای برنامه که تغییر کرده یا تصحیح شده
- آزمودن تمام قسمتها یا عناصری از برنامه که جدیدا یکپارچه(Integrate) شدهاند
- آزمودن کل سیستم
حالت 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 افزایش مییابد.
نظرات کاربران