Печалби:
- Възможност за четене на показатели като линия, разклонение и покритие на условия като карта, а не доверие, и разбиране, че високото покритие може да даде псевдо доверие
- Възможност за поставяне на обхвата на изискванията до обхвата на кода и пропуските в проследимостта да бъдат видими с помощта на изкуствен интелект
- Възможност за оценяване на характеристики с формулата риск = вероятност × въздействие, насочване на ограничени усилия за тестване към най-високия риск и документиране на умишлено излизане извън обхвата
Не можете да тествате всеки софтуер завинаги; Времето и ресурсите са ограничени. Така че истинският въпрос е: къде да положим ограничените усилия за тестване? Две концепции отговарят на този въпрос. Тестово покритие – показател, който измерва каква част от кода или изискванията са засегнати от тестовете – представлява това, което се тества. Тестване, базирано на риска - подходът за определяне на приоритета на теста според вероятността за влошаване на дадена област и щетите, които ще причини, когато се влоши - насочва усилията към най-големия риск. Изкуственият интелект (AI) е мощен партньор за анализ и в двете: той прави пропуските в покритието видими, предлага рискови области. Но основното предупреждение остава: броят на обхватите, които AI вижда, може да бъде подвеждащ; Дори 100% покритие на редове може да се постигне с тестове, които не проверяват нищо. Вашата работа е да прочетете обхвата като карта, а не доверие.
Правилно четене на показателите за покритие
Има няколко вида обхват и не всички са еднакво значими:
- Покритие на реда: Колко реда код са били изпълнени поне веднъж. Най-често срещаният, но най-слабият критерий; Само защото една линия работи не е доказателство, че се държи правилно.
- Покритие на клонове: дали всеки клон if (истинен и неверен) е бил тестван. По-смислен от ред.
- Покритие на условията: Тестване на всяко подусловие в сложни условия отделно.
- Покритие на пътя: Комбинации от логически пътища в кода. Той е най-изчерпателният, но трудно достъпен напълно на практика.
Внимание: Процентът на покритие не е „качествен рейтинг“. 100% покритие на редове ви казва, че редовете работят; не че дава правилния резултат (псевдо-проходът в единица 1). Използвайте обхвата като отговор на въпроса "къде никога не съм търсил", а не като уверение, че "всичко е тествано".
Обхват на слепи петна
Показателите за покритие измерват само каква част от кода е била изпълнена; не може да види: (1) непроверени изисквания (кодът съществува, но бизнес правилото е грешно), (2) липсващ код (няма обхват за контрола, която никога не е била написана), (3) комбинации данни/състояние, (4) използваемост, производителност, сигурност. Следователно покритието на изискванията (всеки критерий за приемане трябва да бъде изпълнен от поне един тест) трябва да бъде поставено до покритието на кода. AI е много полезен при създаването на картографирането на изискване-тест (матрица за проследяване).
Тестване, базирано на риска: къде да полагаме усилия?
Риск = вероятност (възможност за счупване) × въздействие (вреда при счупване). С AI можете да направите списък с функции по тези две оси и да създадете топлинна карта. Висока вероятност × високи домейни (плащане, удостоверяване, цялост на данните) заслужават най-интензивното тестване; ниски × ниски области (рядко използван екран с предпочитания) тестването на светлина е достатъчно.
площ
вероятност
Въздействие
Риск
Плътност на теста
Поток на плащане
среден
много високо
високо
Дълбоко + автоматизация
удостоверяване
среден
много високо
високо
Дълбоко + сигурност
Търсене на продукти
високо
среден
Средно-високо
Автоматизация + откриване
Профилна снимка
ниско
ниско
ниско
управление на светлината
Помощна страница
ниско
твърде ниско
твърде ниско
преглед
Капанът на преследването на обхвата
Превръщането на процента на покритие в цел (напр. правилото „екипът трябва да премине 90% покритие“) има опасен страничен ефект: разработчиците и тестерите се фокусират върху увеличаването на процента, вместо да се справят с действителния риск. Резултатът често е раздут обхват без твърдения или тривиални тестове - числото изглежда добре, но няма защита. Това е феноменът на покварения критерий, когато самият той се превърне в цел: „когато една мярка стане цел, тя престава да бъде добра мярка“. Използвайте обхвата като инструмент за диагностика, а не карта за отчет на ефективността.
По-здравословният подход е да се чете обхватът насочено: „Защо покритието на клона е останало на 40% в критичния модул за плащане?“ Въпросът е "общото покритие 90% ли е?" Той е много по-ценен от въпроса. Накарайте AI да разбие доклада за обхвата по модул и ниво на риск; Маркирайте зоните с висок риск с ниско покритие. Така обхватът се превръща в компас, който насочва труда, а не в сляп процент.
Внимание: Лозунгът "100% покритие" е капан. Тестването на някакъв код (прости инструменти за достъп, автоматично генерирани части) е с ниска стойност; усилията, изразходвани там, са крадено от високорискови бизнес правила. Целта е да се тества всяко важно поведение и риск, а не всеки ред.
Слаба подкана / Силна подкана
Слаб: „Увеличете обхвата ми на тестване.“
Силно: „Като се има предвид този списък с критерии за приемане и тези съществуващи тестови случаи. (1) Таблично кои критерии за приемане не са изпълнени от нито един тест (пропуск в покритието на изискването). (2) Оценка на всяка характеристика 1-5 по осите на вероятността и въздействието; класиране по риск = вероятност × въздействие. (3) За моето ограничено време предложете кои 5 пропуска трябва да запълня първо, като започнете с най-високия риск. Не приемайте покритието на кодовата линия като единствено критерий; приоритизиране на бизнес риска: [...] Тестове: [...]"
Мощна подсказка; съчетава обхват с бизнес риск и дава приоритет на ограничен труд.
Четири копируеми шаблона
1) Пропуск в обхвата на изискването:
Предвид следните критерии за приемане и тези тестови случаи. Създайте таблица за проследимост: всеки критерий -> тест(ове), който отговаря на него. Критериите, които нямат никакви тестове, се наричат "COVERAGE GAP", а тестовете, които не се свързват с никакви критерии, се наричат "НЕОБХОДИМИ?" Оценка: Критерии: [...] / Тестове: [...]
2) Оценка на риска:
Оценете този списък с функции/модули 1-5 по осите на вероятността (вероятност от счупване) и въздействие (повреда при счупване). Риск = вероятност × въздействие. Сортирайте в таблица и посочете препоръчания тип тестване (устройство/API/UI/разузнаване/сигурност) за всяка зона с висок риск. Списък: [...]
3) Тълкуване на обхвата:
Беше даден следният отчет за покритие (линия %, клон %). Кажете ми следното: - Какво НЕ доказват тези числа? - Кои са областите, които могат да бъдат изложени на риск въпреки високото покритие на редовете? - Какво допълнително тестване бихте препоръчали за пропуски, които покритието не вижда (изискване, комбинация от данни, сигурност)? Доклад: [поставяне]
4) План с ограничено време:
[X часа] остават до излъчване. Дадени са следните пропуски в класирането на риска и покритието. През този период се изготвя тестовият план, който ще намали максималния риск по приоритет. Ясно посочете какво НЕ трябва съзнателно да тествате и приетия риск от това. Данни: [...]
три мини калъфа
Случай 1 — 100% покритие, нулево доверие. Един отбор се похвали с 94% покритие на линията. Анализът на „интерпретация на обхвата“ показа, че повечето от тестовете са без твърдения, което означава, че изпълняват линии, но не проверяват нищо. Действителното защитно покритие беше много по-ниско. Екипът се фокусира не върху числата, а върху тестването на мутациите (единица 10); действителният процент на улавяне на грешки се е удвоил.
Случай 2 — Коригиран приоритет на картата на риска. Един екип прекарваше 40% от усилията си за тестване на рядко използван екран за отчитане, пропускайки потока на плащане, защото „просто работи“. Оценяването на риска от AI показа този дисбаланс. Трудът беше преразпределен; Две седмици по-късно в потока на плащанията беше открит бъг със силно въздействие и беше затворен преди активиране.
Случай 3 — В съзнание извън обсега. 4 часа след издаването екипът реши какво да тества и какво съзнателно да пропусне с шаблона „ограничен график“. Два високорискови потока бяха тествани дълбоко; екран с предпочитания с нисък риск беше документиран като „приет риск“ и пропуснат. Решението беше прозрачно и мотивирано; Версията излезе благополучно.
Често срещани грешки
- Грешка в процента на покритие за качество. Четене на високо покритие на реда като "тествана" гаранция.
- Просто гледам покритието на кода. Прескачане на покритие на изискванията (тестване на всеки критерий за приемане).
- Тестване еднакво без отчитане на риска. Разпределяне на работна ръка в зони с нисък риск и пренебрегване на критичните потоци.
- Скриване извън обхвата. Недокументиране на това, което не е тествано, когато не е имало достатъчно време; Изненади след издаването.
- Приемане на рисковия резултат на AI без съмнение. AI не познава напълно контекста на продукта; Коригирайте резултатите с експертно око.
В обобщение
Тестовото покритие и базираното на риска тестване са два инструмента за насочване на ограничените усилия към правилното място. Показателите за покритие (линия, клон, състояние, път) показват какво е било докоснато, но не доказват, че се е държало правилно; Обхватът е карта, доверието не е. Поставете покритието на изискванията до покритието на кода. Оценете характеристиките с формулата риск = вероятност × въздействие и насочете усилията към най-големия риск. AI прави пропуските видими, оценява риска, планира ограничено време; но крайният приоритет и решението за „съзнателно отказване“ е на експерта, който познава бизнес контекста.
Задача за приложение
Изберете модул от вашия собствен проект. Стартирайте шаблона „requirements scope gap“ с AI и разберете кои критерии за приемане не са тествани. След това класирайте подхарактеристиките на модула по осите на вероятност × въздействие с „оценка на риска“. Разпределете (хипотетични) 3 часа време за тестване, което имате, с „ограничения график“; Запишете какво съзнателно няма да тествате и поетия риск. Добавете конкретен тест, който ще запълни празнината в покритието с най-висок риск, която откриете.
контролен списък
- [ ] Разчитам процента на покритие като карта, а не като качество.
- [ ] Освен покритието на кода премахнах и покритието на изискванията.
- [ ] Оцених функциите по вероятност × въздействие и ги класирах по риск.
- [ ] Пренасочих усилията за тестване към най-високия риск.
- [ ] Документирал съм области, които не са съзнателно тествани и признават риск.
- [ ] Прегледах рисковите резултати на AI въз основа на моя продуктов контекст.