سود:
- توانایی خواندن معیارهایی مانند پوشش خط، شاخه و شرایط به عنوان یک نقشه، نه اعتماد، و درک این موضوع که پوشش بالا می تواند اعتماد شبه ایجاد کند.
- امکان قرار دادن محدوده نیازمندی ها در کنار محدوده کد و قابل مشاهده کردن شکاف های ردیابی با هوش مصنوعی
- امکان امتیاز دهی به ویژگی ها با فرمول ریسک = احتمال × تاثیر، مستقیم تلاش محدود آزمایشی به بالاترین خطر، و مستندسازی عمدی خارج از محدوده
شما نمی توانید هر نرم افزاری را برای همیشه تست کنید. زمان و منابع محدود است. بنابراین سوال واقعی این است: تلاش محدود تست را کجا باید انجام داد؟ دو مفهوم به این سوال پاسخ می دهند. پوشش تست - معیاری که اندازهگیری میکند که چه مقدار از کد یا الزامات تحت تأثیر آزمایشها قرار گرفتهاند - نشاندهنده چیزی است که آزمایش میشود. آزمایش مبتنی بر ریسک - رویکرد تعیین اولویت آزمایش با توجه به احتمال خراب شدن یک منطقه و آسیبی که در هنگام خراب شدن ایجاد می کند - تلاش را به سمت بیشترین خطر هدایت می کند. هوش مصنوعی (AI) یک شریک تجزیه و تحلیل قدرتمند در هر دو است: شکاف های پوشش را قابل مشاهده می کند، مناطق خطر را نشان می دهد. اما نکته اصلی باقی می ماند: تعداد دامنه هایی که هوش مصنوعی می بیند می تواند گمراه کننده باشد. حتی 100٪ پوشش ردیف را می توان با آزمایش هایی که هیچ چیز را تأیید نمی کند به دست آورد. وظیفه شما این است که محدوده را به عنوان یک نقشه بخوانید، نه یک اعتماد.
خواندن صحیح معیارهای پوشش
انواع مختلفی از دامنه وجود دارد، و همه به یک اندازه معنادار نیستند:
- پوشش خط: چند خط کد حداقل یک بار اجرا شده است. رایج ترین اما ضعیف ترین معیار؛ فقط به این دلیل که یک خط کار می کند، دلیلی بر درستی رفتار آن نیست.
- پوشش شعبه: آیا هر شاخه اگر (اعم از درست و نادرست) آزمایش شده است. معنی دار تر از یک خط
- پوشش شرایط: آزمایش هر زیر شرط در شرایط پیچیده به طور جداگانه.
- پوشش مسیر: ترکیبی از مسیرهای منطقی در کد. این جامع ترین است اما در عمل رسیدن به آن به طور کامل دشوار است.
احتیاط: درصد پوشش "امتیاز کیفی" نیست. پوشش 100٪ ردیف به شما می گوید که ردیف ها کار می کنند. نه اینکه نتیجه درست را ایجاد کند (شبه پاس در واحد 1). از دامنه به عنوان پاسخی به این سوال استفاده کنید که "من هرگز به کجا نگاه نکرده ام"، نه به عنوان اطمینانی که "همه چیز آزمایش شده است".
محدوده نقاط کور
معیارهای پوشش فقط میزان اجرای کد را اندازه میگیرند. نمی تواند ببیند: (1) الزامات آزمایش نشده (کد وجود دارد اما قانون تجاری اشتباه است)، (2) کد از دست رفته (بدون دامنه برای کنترلی که هرگز نوشته نشده است)، (3) ترکیبات داده/حالت، (4) قابلیت استفاده، عملکرد، امنیت. بنابراین، پوشش نیازمندی (هر معیار پذیرش باید حداقل با یک آزمون رعایت شود) باید در کنار پوشش کد قرار گیرد. هوش مصنوعی در تولید نگاشت آزمون نیازمندی (ماتریس ردیابی) بسیار مفید است.
تست مبتنی بر ریسک: کجا تلاش کنیم؟
ریسک = احتمال (احتمال شکستگی) × ضربه (در صورت شکستن آسیب). با هوش مصنوعی میتوانید لیست ویژگیها را در این دو محور بهدست آورید و یک نقشه حرارتی ایجاد کنید. احتمال زیاد × دامنه های بالا (پرداخت، احراز هویت، یکپارچگی داده ها) سزاوار شدیدترین آزمایش هستند. مناطق کم × کم (یک صفحه نمایش ترجیحی که به ندرت استفاده می شود) آزمایش نور کافی است.
منطقه
احتمال
تاثیر
ریسک
چگالی تست
جریان پرداخت
متوسط
بسیار بالا
بالا
عمیق + اتوماسیون
احراز هویت
متوسط
بسیار بالا
بالا
عمیق + امنیت
جستجوی محصول
بالا
متوسط
متوسط-بالا
اتوماسیون + کشف
عکس پروفایل
پایین
پایین
پایین
کنترل نور
صفحه راهنما
پایین
خیلی کم
خیلی کم
بررسی کنید
تله تعقیب دامنه
هدف قرار دادن درصد پوشش (به عنوان مثال قانون "تیم باید 90٪ پوشش را بگذراند") یک عارضه جانبی خطرناک دارد: توسعه دهندگان و آزمایش کنندگان به جای پرداختن به ریسک واقعی، بر افزایش درصد تمرکز می کنند. نتیجه اغلب یک محدوده متورم بدون ادعا یا تست های بی اهمیت است - عدد خوب به نظر می رسد اما هیچ محافظتی وجود ندارد. این همان پدیده خراب شدن معیار زمانی است که خود به هدف تبدیل شود: «وقتی یک معیار هدف شد، دیگر معیار خوبی نیست». از scope به عنوان یک ابزار تشخیصی استفاده کنید، نه یک کارت گزارش عملکرد.
یک رویکرد سالم تر این است که دامنه را به صورت جهت دار بخوانید: "چرا پوشش شعبه در ماژول پرداخت بحرانی در 40٪ گیر کرده است؟" سوال این است که "آیا پوشش کلی 90٪ است؟" خیلی ارزشمندتر از سوال است. از هوش مصنوعی بخواهید گزارش محدوده را بر اساس ماژول و سطح خطر تجزیه کند. مناطق پرخطر با پوشش کم را برجسته کنید. بنابراین، محدوده به قطبنما تبدیل میشود که کار را به جای درصد کور هدایت میکند.
احتیاط: شعار "پوشش 100%" دام است. آزمایش برخی از کدها (دسترسهای ساده، قطعات تولید شده خودکار) ارزش کمی دارد. تلاشی که در آنجا صرف می شود از قوانین تجاری پرخطر به سرقت رفته است. هدف آزمایش هر رفتار و ریسک مهم است، نه هر خط.
اعلان ضعیف / اعلان قوی
ضعیف: "پوشش تست من را افزایش دهید."
قوی: "با توجه به این لیست از معیارهای پذیرش و این موارد آزمایشی موجود. (1) جدولی که معیارهای پذیرش توسط هیچ آزمایشی برآورده نشده است (شکاف پوشش الزامی). (2) به هر ویژگی امتیاز 1-5 در محورهای احتمال و تاثیر بدهید؛ رتبه بر اساس ریسک = احتمال × تاثیر. (3) برای زمان محدود خود، پیشنهاد میکنم برای زمان محدود خود، پیشنهاد میکنم کدام 5 خط نزدیک را پوشش نمیدهم. تنها معیار اولویت بندی ریسک کسب و کار: [...] تست ها: [...]
اعلان قدرتمند؛ دامنه را با ریسک تجاری ترکیب می کند و نیروی کار محدود را در اولویت قرار می دهد.
چهار قالب قابل کپی
1) شکاف دامنه مورد نیاز:
با توجه به معیارهای پذیرش زیر و این موارد آزمون. یک جدول ردیابی تولید کنید: هر معیار -> آزمون(هایی) که با آن مطابقت دارند. معیارهایی که هیچ آزمونی ندارند، «شکاف پوشش» و آزمون هایی که به هیچ معیاری متصل نمی شوند، «ضروری؟» نامیده می شوند. علامت: معیارها: [...] / تست ها: [...]
2) امتیازدهی ریسک:
این لیست از ویژگیها/ماژولها را در محورهای احتمال (احتمال شکستن) و ضربه (در صورت شکستن آسیب) از 1 تا 5 امتیاز بگیرید. ریسک = احتمال × تاثیر. در یک جدول مرتب کنید و نوع آزمایش توصیه شده (واحد/API/UI/تشخیص/امنیت) را برای هر منطقه پرخطر مشخص کنید. لیست: [...]
3) تفسیر دامنه:
گزارش پوشش زیر ارائه شد (خط ٪ ، شاخه ٪). این را به من بگویید: - این اعداد چه چیزی را ثابت نمی کنند؟ - مناطقی که علیرغم پوشش ردیف بالا ممکن است در معرض خطر باشند کدامند؟ - چه آزمایش اضافی را برای شکاف هایی که پوشش نمی بیند (نیاز، ترکیب داده ها، امنیت) توصیه می کنید؟ گزارش: [paste]
4) برنامه زمانی محدود:
[X ساعت] تا پخش باقی مانده است. رتبه بندی ریسک و شکاف های پوشش زیر آورده شده است. در این مدت طرح آزمایشی که حداکثر ریسک را کاهش دهد به ترتیب اولویت تهیه می شود. آنچه را که نباید آگاهانه آزمایش کرد و ریسک پذیرفته شده انجام آن را به وضوح بیان کنید. داده ها: [...]
سه کیف کوچک
مورد 1 - پوشش 100٪، اعتماد صفر. یک تیم از پوشش 94 درصدی خط برخوردار بود. تجزیه و تحلیل "تفسیر دامنه" نشان داد که بیشتر تست ها بدون ادعا بودند، به این معنی که آنها خطوط را اجرا کردند اما چیزی را تایید نکردند. پوشش محافظ واقعی بسیار کمتر بود. تمرکز تیم بر روی اعداد نبود، بلکه روی آزمایش جهش (واحد 10) بود. نرخ واقعی خطا دو برابر شد.
مورد 2 - نقشه خطر اولویت تصحیح شده است. یک تیم 40 درصد از تلاش آزمایشی خود را بر روی صفحه گزارشگری که به ندرت استفاده می شود صرف می کرد و از جریان پرداخت صرف نظر می کرد زیرا "فقط کار می کند". امتیازدهی ریسک هوش مصنوعی این عدم تعادل را نشان داد. نیروی کار دوباره توزیع شد. دو هفته بعد یک اشکال با تاثیر بالا در جریان پرداخت پیدا شد و قبل از زنده بسته شد.
مورد 3 - آگاهانه خارج از محدوده. 4 ساعت پس از انتشار، تیم تصمیم گرفت چه چیزی را آزمایش کند و چه چیزی را آگاهانه با الگوی "زمان بندی محدود" رد کند. دو جریان پرخطر در عمق آزمایش شدند. یک صفحه اولویت کم خطر به عنوان "ریسک پذیرفته شده" ثبت شد و از آن صرفنظر شد. تصمیم شفاف و مستدل بود. نسخه با خیال راحت منتشر شد.
اشتباهات رایج
- اشتباه درصد پوشش با کیفیت خواندن پوشش ردیف بالا به عنوان اطمینان "تست شده".
- فقط به پوشش کد نگاه می کنیم. پوشش الزامات پرش (تست هر معیار پذیرش).
- تست کردن به طور مساوی بدون در نظر گرفتن ریسک. تخصیص نیروی کار به مناطق کم خطر و بی توجهی به جریان های بحرانی.
- پنهان شدن خارج از محدوده عدم مستندسازی مواردی که در زمانی که زمان کافی وجود نداشت، آزمایش نشده بودند. سورپرایزهای پس از انتشار
- قبول امتیاز ریسک هوش مصنوعی بدون سوال هوش مصنوعی به طور کامل زمینه محصول را نمی شناسد. نمرات را با نگاه متخصص تنظیم کنید.
به طور خلاصه
پوشش تست و تست مبتنی بر ریسک دو ابزار برای هدایت تلاش محدود به مکان مناسب هستند. معیارهای پوشش (خط، شاخه، شرایط، مسیر) نشان میدهد که چه چیزی لمس شده است، اما ثابت نمیکند که درست رفتار کرده است. محدوده یک نقشه است، اعتماد نیست. پوشش نیازمندی ها را در کنار پوشش کد قرار دهید. ویژگی ها را با فرمول ریسک = احتمال × تاثیر امتیاز دهید و تلاش را به سمت بیشترین ریسک هدایت کنید. هوش مصنوعی شکاف ها را قابل مشاهده می کند، خطر را به ثمر می رساند، زمان محدودی را برنامه ریزی می کند. اما اولویت نهایی و تصمیم "انصراف آگاهانه" با متخصصی است که زمینه کسب و کار را می شناسد.
وظیفه کاربردی
یک ماژول از پروژه خود انتخاب کنید. الگوی "شکاف محدوده الزامات" را با هوش مصنوعی اجرا کنید و متوجه شوید که کدام معیارهای پذیرش آزمایش نشده اند. سپس ویژگی های فرعی ماژول را بر روی محورهای احتمال × ضربه با "امتیاز ریسک" رتبه بندی کنید. 3 ساعت (فرضی) زمان تستی که دارید را با "برنامه محدود" تقسیم کنید. آنچه را که آگاهانه آزمایش نمی کنید و ریسک پذیرفته شده را بنویسید. یک آزمایش بتن اضافه کنید که شکاف پوششی پرخطری را که پیدا میکنید ببندد.
چک لیست
- [ ] درصد پوشش را به عنوان نقشه خواندم، نه کیفیت.
- [ ] علاوه بر پوشش کد، پوشش مورد نیاز را نیز حذف کردم.
- [ ] من ویژگی ها را بر اساس احتمال × تاثیر امتیاز دادم و آنها را بر اساس ریسک رتبه بندی کردم.
- [ ] من تلاش آزمایشی را به بالاترین خطر هدایت کردم.
- [ ] من مناطقی را مستند کرده ام که آگاهانه آزمایش نشده و خطر را تایید نکرده ام.
- [ ] من امتیازهای ریسک هوش مصنوعی را بر اساس زمینه محصولم بررسی کردم.