تست رگرسیون Regression چیست ؟

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