سود:
- هدف از تست رگرسیون را درک کنید و قادر به انتخاب تست ها و تولید موارد رگرسیون با توجه به تغییرات با هوش مصنوعی باشید.
- توانایی تشخیص علل ریشه ای تست های شکننده (زمان، وابستگی سفارش، حالت مشترک، وابستگی خارجی) و اعمال راه حل های دائمی بدون سرکوب علامت
- امکان حفظ نظم اجرای پیش انتشار بسته کامل در حالی که مجموعه رگرسیون سریع، مستقل و قابل اعتماد با حذف تست های تکراری حفظ می شود.
نرم افزار به طور مداوم تغییر می کند. هر ویژگی جدید، هر اصلاح، می تواند چیزی را که قبلاً کار می کرد، خراب کند. اختلال متعاقب یک تابع کار قبلی، رگرسیون نامیده می شود. تست رگرسیون در حال آزمایش مجدد عملکرد موجود با هر تغییر است تا این تخریب ها را شناسایی کند. با گذشت زمان، این مجموعههای آزمایشی بزرگتر میشوند - هزاران تست - و دو مشکل بزرگ ایجاد میشود: مجموعه کاهش مییابد و تستهای ورقهای - تستهای غیرقابل اعتمادی که گاهی اوقات در همان کد قبول میشوند و گاهی اوقات با شکست مواجه میشوند - اعتماد تیم را به نتایج آزمایش از بین میبرند. هوش مصنوعی (AI) کمکی قدرتمند در نگهداری مجموعه رگرسیون به خوبی، سریع و قابل اعتماد است. اما اخطار اصلی همچنان باقی است: در حالی که هوش مصنوعی ممکن است پیشنهاد کند که یک آزمایش شکننده را "گذرانده" کند، اغلب میتواند یک وصله ایجاد کند که یک باگ واقعی را پوشش دهد. وظیفه شما این است که علت اصلی بی ثباتی را بیابید، نه سرکوب علائم.
علل ریشه ای تست های شکننده
تست شکننده موذیترین مشکل تست است: چه موفق شود چه شکست، غیرقابل اعتماد است و تیم را به این عادت سوق میدهد که "باید دوباره گیر کرده باشد، دوباره آن را اجرا کنید" - و این عادت روزی یک باگ واقعی را به عنوان "پوستهپوست" نادیده میگیرد. علل اصلی اصلی:
- شرایط زمانبندی/مسابقه: تست بدون انتظار برای پایان عملیات، نتیجه را بررسی میکند. شایع ترین دلیل.
- وابستگی سفارش: تست ها به داده های باقی مانده از یکدیگر بستگی دارند. وقتی ترتیب تغییر می کند خراب می شود.
- مورد مشترک: چندین آزمایش از داده/کاربر آزمایش یکسان استفاده میکنند، متناقض.
- وابستگی خارجی: شبکه واقعی، سرویس شخص ثالث، زمان سیستم، مقدار تصادفی.
- تفاوت محیطی: به محلی تغییر می کند، در CI (محیط یکپارچه سازی مداوم) می ماند.
احتیاط: گذراندن یک تست شکننده با "چند بار تلاش مجدد" اغلب یک خطای همزمان واقعی را پنهان می کند. تلاش مجدد یک ابزار تشخیصی است نه یک درمان. ابتدا علت اصلی را پیدا کنید. فقط از تلاش مجدد به عنوان آخرین راه حل برای بی ثباتی مستند و واقعا خارجی استفاده کنید.
نگهداری تست: سالم نگه داشتن بسته
مجموعه رگرسیون مانند یک باغ است. در صورت عدم مراقبت، علف های هرز کنترل می شوند. هوش مصنوعی در سه وظیفه تعمیر و نگهداری کمک می کند:
1. تمیز کردن آزمایشی تکراری/غیر ضروری. با گذشت زمان تعداد زیادی از موارد آزمایش یک چیز جمع می شوند. هوش مصنوعی گروه بندی و ادغام تست های مشابه را پیشنهاد می کند.
2. تشخیص تست شکننده. کد تست و الگوی ناپایداری را به هوش مصنوعی می دهید. علل ریشه ای احتمالی و راه حل دائمی را پیشنهاد می کند.
3. انتخاب / اولویت بندی آزمون. اجرای کل بسته با هر تغییر گران است. با تجزیه و تحلیل تاثیر تست (فقط تست های مربوطه را بر اساس کد تغییر یافته انتخاب کنید)، هوش مصنوعی توصیه می کند که کدام آزمایش باید ابتدا اجرا شود. با این حال، بسته کامل قبل از انتشار ضروری است.
قرنطینه: مدیریت درست تست های شکننده
متوجه شده اید که یک آزمایش شکننده است، اما زمانی برای رفع فوری علت اصلی آن ندارید. چه باید کرد؟ دو راه اشتباه وجود دارد: حذف کامل تست (این رفتار دیگر اصلا حفظ نمیشود) یا خاموش کردن آن با تلاش مجدد (پوشاندن اشکال واقعی). راه صحیح قرنطینه کردن است (تفاوت موقت تست شکننده از بسته اصلی و ردیابی آن در یک لیست جداگانه). تست قرنطینه از ادغام نسخه جلوگیری نمی کند، اما یک بدهی قابل مشاهده باقی می ماند و به طور منظم مورد رسیدگی قرار می گیرد. نکته مهم این است: قرنطینه یک اتاق انتظار است نه سطل زباله. اگر لیست قرنطینه در حال افزایش است، این زنگ خطری است که سلامت آزمایش تیم رو به وخامت است. هوش مصنوعی می تواند لیست قرنطینه شما را به صورت دوره ای بررسی کند و آن را بر اساس الگوهای علت اصلی گروه بندی کند. راهحلهای جمعی را با آشکار کردن دلایل مشترک، مانند "همه 6 تست به یک کاربر آزمایش مشترک متصل هستند" ممکن میسازد.
نکته: به هر رکورد قرنطینه یک «مالک» و «آخرین تاریخ بازبینی» اضافه کنید. قرنطینه متروکه تبدیل به زباله ای دائمی می شود. آزمایش های شکننده برای همیشه در آنجا زندگی می کنند زیرا هیچ کس اهمیتی نمی دهد.
جدول استراتژی رگرسیون
وضعیت
استراتژی
نقش هوش مصنوعی
اصلاح جزئی
منطقه آسیب دیده + تست دود
تست های مربوطه را انتخاب کنید
ویژگی جدید
ماژول مرتبط + یکپارچه سازی
یک مورد رگرسیون جدید پیشنهاد کنید
فاکتور بزرگ
بسته رگرسیون کامل
تجزیه و تحلیل شکاف پوشش
پیش از انتشار
بسته کامل + اکتشاف
برآورد اولویت و مدت
تعمیر زنده فوری
متمرکز + مسیر بحرانی
حداقل مجموعه تست ایمن
اعلان ضعیف / اعلان قوی
ضعیف: "این تست گاهی اوقات با شکست مواجه می شود، آن را برطرف کنید."
قوی: "این تست در 3 مورد از 10 اجرا ناموفق بود، کد بدون تغییر. تشخیص علت اصلی بیثباتی: میتواند زمانبندی/مسابقه، وابستگی به ترتیب، حالت مشترک، وابستگی خارجی یا تفاوت محیطی باشد. نشان دهید کدام خط در تست به هر علت احتمالی اشاره میکند. راهحل دائمی پیشنهاد کنید؛ "اگر راهحلهایی را که نشانهها قابل سرکوب کردن هستند" پیشنهاد نکنید. [کد] دنباله خطا: [ورود].
اعلان قدرتمند؛ تشخیص را به علت اصلی هدایت می کند و صراحتاً سرکوب علائم را ممنوع می کند.
چهار قالب قابل کپی
1) تشخیص تست شکننده:
این کد تست گاهی اوقات بدون تغییر می گذرد و گاهی با شکست مواجه می شود. نامزدهای علت اصلی (نژاد، وابستگی به ترتیب، حالت مشترک، وابستگی خارجی، ساعت/تصادفی، تفاوت محیط) را فهرست کنید و خط شواهد موجود در آزمون را برای هر کدام نشان دهید. پیشنهاد راه حل دائمی؛ راه حل سرکوب کننده مانند تلاش مجدد را به عنوان آخرین راه حل و با توجیه علامت گذاری کنید. تست: [کد] / الگوی ناپایداری: [چند بار در چند اجرا]
2) پیشنهاد یک مورد رگرسیون:
تغییر زیر ایجاد شد: [تغییر/خلاصه روابط عمومی]. رفتارهای فعلی را که این تغییر میتواند شکسته شود فهرست کنید و برای هر کدام یک مورد آزمون رگرسیون پیشنهاد دهید. به ویژه مناطقی از عوارض جانبی و وابستگی های مشترک را برجسته کنید.
3) پاکسازی آزمایشی تکراری:
مجموعه تست زیر را بررسی کنید. موارد تکراری یا همپوشانی را گروهبندی کنید که رفتار یکسانی را آزمایش میکنند. پیشنهاد دهید که کدام یک را باید نگه دارم و کدام یک را برای هر گروه ترکیب کنم. در صورت وجود خطر از بین رفتن پوشش هشدار دهید. تست ها: [لیست/کد]
4) انتخاب اثر تست:
فایل ها/عملکردهای زیر تغییر کرده اند: [list]. از مجموعه آزمایشی موجود، تست هایی را که باید ابتدا اجرا کنم (آنهایی که به طور مستقیم/غیر مستقیم به کد تغییر یافته مرتبط هستند) انتخاب و توجیه کنید. توجه: به من یادآوری کنید که من همچنان مجموعه کامل پیش از انتشار را اجرا خواهم کرد.
سه کیف کوچک
مورد 1 - اشتباه واقعی با تلاش مجدد پوشانده شد. یک تیم 3 بار تکرار را به آزمون پرداخت باقیمانده گاه به گاه اضافه کرد. اکنون آزمون همیشه "گذر" بود. استفاده از "تشخیص تست شکننده" نشان داد که بی ثباتی ناشی از شرایط مسابقه واقعی است: در بار بالا، تایید پرداخت گاهی اوقات دوبار پردازش می شود. برای ماهها، Retry یک اشکال را که میتوانست منجر به از دست دادن واقعی پول شود، پنهان کرد. علت اصلی رفع شد، سعی کنید دوباره حذف شود.
مورد 2 - بسته کوچک شد، سرعت افزایش یافت. مجموعه رگرسیون 1400 تستی 55 دقیقه طول کشید. با "تمیز کردن تست تکراری"، 380 تست تکراری یا پوشیده شد. ادغام شد. بسته به 900 تست کاهش یافت، زمان به 34 دقیقه کاهش یافت، پوشش به طور قابل اندازه گیری کاهش پیدا نکرد. بازخورد سریعتر تیم را تشویق کرد که بیشتر آزمایش کنند.
مورد 3 - وابستگی به ترتیب. یک آزمون همیشه به صورت محلی انجام می شود، اما به طور تصادفی در CI شکست می خورد. تشخیص هوش مصنوعی نشان داد که آزمایش به کاربر ایجاد شده توسط آزمایش دیگری بستگی دارد، در CI شکسته شد زیرا آزمایشها به ترتیب موازی/متفاوت انجام شدند. هر آزمون برای ایجاد داده های خود ساخته شده است. بلاتکلیفی تمام شده است.
اشتباهات رایج
- خاموش کردن آزمون شکننده با تلاش مجدد. تلاش مجدد بدون جستجوی علت اصلی؛ پوشاندن اشتباه واقعی
- فرهنگ "دوباره گیر کرده". نادیده گرفتن معمول نتایج قرمز؛ یک روز، نادیده گرفتن اشتباه واقعی.
- بسته را اصلا هرس نمی کنند. اجازه دادن به تست های تکراری برای انباشته شدن و کاهش سرعت بسته.
- وابستگی بین آزمون ها آزمایشها بر اساس شرایط/توالی رایج هستند. منبع عدم قطعیت
- تست فقط قسمت تغییر یافته و پرش از بسته کامل. میانبر پیش از انتشار؛ فرار عوارض جانبی پنهان
- تکیه بر وابستگی خارجی تستهای مبتنی بر شبکه/ساعت/مقدار تصادفی واقعی؛ به طور طبیعی ناپایدار
به طور خلاصه
تست رگرسیون تغییراتی را که عملکردهای قبلی کار می کردند را می گیرد. اما با رشد بستهها، کندی و آزمایش شکننده اعتماد را از بین میبرد. علل اصلی آزمایش شکننده معمولاً زمانبندی، وابستگی به سفارش، وضعیت مشترک و وابستگیهای خارجی است. هوش مصنوعی یک کمک قدرتمند در تشخیص، تمیز کردن و انتخاب تست است. اما سرکوب عدم تصمیم با تلاش مجدد، اشتباهات واقعی را می پوشاند. علت اصلی را پیدا کنید، آزمایش ها را مستقل و قطعی کنید، بسته را به طور منظم هرس کنید، بسته کامل را قبل از انتشار اجرا کنید.
وظیفه کاربردی
تستی را از پروژه خود انتخاب کنید که می دانید شکننده است (یا ناپایدار به نظر می رسد). کاندیدهای علت اصلی را استخراج کنید و خطوط شواهد را در آزمون با الگوی "تشخیص تست شکننده" تأیید کنید. علت اصلی را شناسایی کنید و یک راه حل دائمی را بدون تلاش مجدد اجرا کنید. سپس 10 تست را از بسته خود انتخاب کنید و آنهایی را بیابید که می توانند با "پاکسازی تست تکراری" ترکیب شوند. گزارش دهید که چه تعداد از بی ثباتی های آزمایشی را به دلیل ریشه ای حل کرده اید و چه تعداد موارد غیرضروری را از مجموعه حذف کرده اید.
چک لیست
- [ ] من علت اصلی آزمایش شکننده را تشخیص داده ام. من علائم را سرکوب نکردم.
- [ ] من تلاش مجدد را به عنوان آخرین راه حل موجه در نظر گرفتم، نه یک درمان.
- [ ] من تست ها را مستقل و قطعی کردم (منزوی از وابستگی های خارجی).
- [ ] من تست های تکراری/غیر ضروری را از مجموعه رگرسیون هرس کردم.
- [ ] من آزمایش را بر اساس تغییر انتخاب کردم، اما پیش انتشار بسته کامل را اجرا کردم.
- [ ] من هر قرمزی را جدی گرفتم، برخلاف فرهنگ «باز هم گیر کرد، پاس».