در این مقاله با مفهوم و concept تست رگرسیون regression آشنا می‌شوید. ما سعی کردیم بصورت تجربی و با نگاهی ساده، تست رگرسیون را شرح دهیم. تعاریف و دسته بندی های مختلفی از انواع تست وجود دارد که این امر میتواند موجب سردرگمی خصوصا برای افراد تازه وارد شود. قبل از ورود به این مطلب، شما باید در نظر بگیرید که این تعاریف و دسته بندی ها ، بسته به نوع نگاه و scope ، اولویت یا priority در سازمان ، نوع محصول و در کل هدف ما بستگی دارد. در مقاله ای دیگر به طور دقیق تری به این موضوع پرداخته خواهد شد.
تست Regression برای اطمینان از اینکه هر تغییری در سورس کد مانند اصلاح خطا، اضافه کردن فیچر و… تاثیری مخربی بر روی عملکرد سیستم نگذاشته باشد، اجرا میشود. این تست معمولا بصورت جعبه سیاه – black box انجام میشود.
یک محصول نرم افزاری در حال توسعه را درنظر بگیرید. تیم توسعه‌ی نرم‌افزار، با توجه به نیازمندی‌ها، شروع به پیاده‌سازی ماژول ها و فیچرها میکند. درکنارش، تیم تست باتوجه به این نیازمندی‌ها، برای مثال ۲۰۰ تست کیس برای تست functional طراحی میکند. در مزحله ی بعد، یک نسخه از نرم افزار در اختیار تیم تست قرار گرفته، و تست اجرا میشود. بعد از این فرایند، احتمالا نرم افزار آماده‌ی اجرای تست پذیرش و سپس تحویل به کارفرما میشود .بعد از مدتی کارفرما، یک نیازمندی جدید تعریف کرده و تیم توسعه فرایند کد زنی را شروع کرده و بعد از اتمام، یک نسخه در اختیار تیم تست قرار می‌دهند.
تیم تست هم با توجه به فیچر جدید، ۵۰ تست کیس طراحی میکند. و برای اطمینان از اینکه تغییرات جدید، تاثیری مخربی بر عملکرد قبلی سیستم ( ۲۰۰ تست کیس قبلی که اجرا شدند) نداشته باشد، علاوه بر اجرای ۵۰ تست جدید، تست کیس قبلی را هم اضافه می‌کنند (با اینکه ممکن است هیچ تغییری در کامپوننت ها و ماژول های نسخه ی قبلی صورت نگرفته باشد). این فرایند به همین شکل ادامه پیدا میکند، و هربار تست های قبلی هم مجددا اجرا میشوند. این مثال به طور کامل تعریف تست رگرسیون را نشان می‌دهد.
همونطور که گفته شد در حالت کلی این تست زمانی اجرا میشود که یک تغییر در نرم افزار شکل بگیرد. این تست تضمین میکند که با تغییرات صورت گرفته در کد، برنامه همچنان به درستی کار میکند.
نکات:
ما اینجا به دو مورد از approach یا رویکرد های مطرح تست regression اشاره میکنیم
در این رویکرد قسمتی که دچار تغییر شده و قسمت هایی که ممکن است تحت تاثیر این تغییر باشند، بررسی میشود . از این متود معمولا در متودولوژی های agile بهره گرفته میشود، جایی که زمان و بهینه بودن اهمیت فراوانی پیدا میکند. به این صورت که تیم QA ، با توجه به تغییرات، تست کیس های منتخب و مربوطه را انتخاب و اجرا می‌کنند.
این رویکرد علاوه بر بررسی نواحی مورد تغییر و مناطق تحت تاثیر (impact areas) ، ماژول ها و فیچر های قدیمی را هم بررسی میکند. به عبارتی کل محصول را پوشش داده میشود. از این روش معمولا در مراحل پایانی و همچین بعد از تعییرات وسیع که ممکن است حوزه های functional و non-functional را تحت تاثیر قرار دهد استفاده میشود.
انتخاب هر کدام از این رویکرد ها به scale پروژه و همچنین رویکرد توسعه‌ی نرم افزار ( اجایل یا واترفال ) ، نوع زمان بندی و … بستگی دارد.
در این تکنیک، همه‌‌ي تست کیس ها اجرا میشوند. تا تضمین دهد هیج تاثیر مخربی روی عملکرد قبلی نرم افزار ایجاد نشده است.
توحه: دو تکنیک زیر، گاهی به عنوان تکنیک تست کیس نویسی برای تست رگرسیون هم درنظر گرفته میشود.
در این تکنیک به جای اجرای مجدد همه ی تست کیس ها، بخشی از آن را انتخاب و اجرا میکنیم. تست کیس ها به دو دسته ی
تقسیم میشوند.
Reusable ها دوباره در چرخه رگریشتن بعدی استفاده میشوند، منسوخ شده ها هم کنار گذاشته میشوند. به این ترتیب در زمان و هزینه صرفه جویی میشود.
در این تکنیک، test case ها اولویت بندی میشوند. به بیان ساده، تست کیس های مهم و حیاتی که فیچرها و functionality های اصلی نرم افزار را در برمی‌گیرند، انتخاب میشوند.
نکته: تفاوت تکنیک و رویکرد در این است که رویکرد، scope و ناحیه ی ما را مشخص میکند، که ما در این scope می‌توانیم از بعضی تکنیک ها استفاده کنیم.
بهتر است در انتخاب تست کیس ها به موارد زیر توجه کنیم:
سوالی که مطرح میشود این است که این تست را اتوماتیک اجرا کنیم یا بصورت دستی؟
اگر در مراحل ابتدایی پروژه هستید و نرم افزار هنوز به پایداری نرسیده است ( یعنی ممکن است تغییرات وسیعی صورت بگیرد و یا اینکه هنوز بصورت کامل فیچرهای اصلی اون پیاده سازی نشدند) و یا ابعاد و مقیاس پروژه کوچک می‌باشد، بهتر است بصورت دستی انجام شود. همچنین ممکن است در برخی مواقع نوشتن اسکریپت برای اجرای یک action، پیجیده و یا نشدنی باشد که در این صورت باید بصورت manual تست شود.
تست اتوماتیک هم بیشتر برای پروژه ها بزرگ تر و یا معمولی درنظر گرفته میشود. این کار بشدت در زمان صرفه جویی میکند، در agile development هم ممکن است بهره ی زیادی از آن گرفته شود. جایی که تیم ها باید در بازه های مشخص release داشته باشند که اجرای اتوماتیک باعث میشود زمانشان را روی انواع تست دیگر بگذارند. تست اتوماتیک رگرسیون، گاهی برخی از خطا ها و باگ هایی را که در تست دستی امکان شناسایی آن نیست، کشف می‌کنند. خصوصا خطاهایی که ممکن است بصورت تصادفی ایجاد شوند که این امر با تکرار پیاپی تست ها، قابل شناسایی ست.
انتخاب ابزار هم وابسته به نوع تست ماست، برای مثال اگر رگرسیون فقط بصورت فانکشنال و در لایه ی ui است، ابزار هایی مانند selenium و cypress کمک بسیاری برای اجرای تست های end to end می‌کنند.
از مشکلات تست رگرسیون می‌توان به موارد زیر اشاره کرد:
در بعضی از رفرنس ها و منابع تست، یک type از تست در کنار functional و non-functional، به نام change-related test در نظر گرفته شده است. این دسته از تست زمانی که هر تغییری در سیستم مانند اصلاح خطا یا اضافه کردن امکانات جدید و… صورت می‌گیرد، بررسی میکند که تغییرات انجام شده مطابق انتظار عمل می‌کنند و مشکلی وجود ندارد. change-related همانطور که از نامش مشخص است، وابسته به تغییر است.
این تست، دو عضو دارد:
تست رگرسیون را قبلا بررسی کردیم. Confirmation testing یا Re-testing و یا تست مجدد، تستی است که بعد از fix شدن یک باگ انجام میشود. زمانی که یک تست خطا می‌خورد، گزارش این باگ در اختیار تیم توسعه قرار گرفته میشود و آنها بعد از بررسی، این مشکل را در نسخه ی جدید رفع می کنند. حال برای اینکه مطمین شوند که این خطا رفع شده، مجدد تستی را که مربوط به همین خطا است احرا می‌کنند تا مطمئن شوند خطا اصلاح شده است. این تست ترمرکزش بر روی فیکس شدن باگ است، که تفاوتش با regression هم در این نکته است! ابتدا Retest انجام میشود، سپس تست رگرسیون.
