Единици
1. Вовед во вештачката интелигенција при тестирање на софтвер и ОК: улоги, граници, ризик од фалсификување и валидација 2. Тест-сценарио и генерирање тест-случај: од барање до сеопфатна контрола 3. Истражувачко тестирање и генерирање на идеи за тестирање: Креативно ловење бубачки со вештачка интелигенција 4. Автоматизација за тестирање на интерфејсот: генерирање на код за селен, драматург и кипарис со вештачка интелигенција 5. Автоматизација на API тест: договор, шема и валидација од крај до крај со вештачка интелигенција 6. Генерирање на единица тест и способност за тестирање: робусно тестирање со вештачка интелигенција 7. Пишување и одредување приоритети на извештај за грешка: јасни, репродуктивни записи со вештачка интелигенција 8. Анализа на покриеност со тест и тестирање засновано на ризик: насочување правилно со вештачка интелигенција 9. Регресивно тестирање, одржување на тестот и борба против кревки тестови 10. Ризик од лажна доверба, тест за квалитет и мутации: тестови за тестирање 11. Работен тек од крај до крај, интеграција на CI/CD, етика и безбедност: Одговорно користење вештачка интелигенција
Единица 8 / 11

Анализа на покриеност со тест и тестирање засновано на ризик: насочување правилно со вештачка интелигенција

Добивки:

  • Способност да се читаат метрика како покриеност на линии, гранки и услови како мапа, а не како доверба, и разбирање дека високата покриеност може да даде псевдодоверба
  • Способност да се стави опсегот на барања веднаш до опсегот на кодот и да се направат празнините во следливост видливи со вештачката интелигенција
  • Способност да се бодуваат карактеристики со формулата ризик = веројатност × влијание, да се насочат ограничените напори за тестирање до највисокиот ризик и да се документира намерно надвор од опсегот

Не можете да го тестирате секој софтвер засекогаш; Времето и ресурсите се ограничени. Значи, вистинското прашање е: каде да се вложат ограничените напори за тестирање? Два концепти одговараат на ова прашање. Покриеноста на тестот - метрика која мери колку од кодот или барањата се допрени од тестовите - го претставува она што се тестира. Тестирање засновано на ризик - пристапот на одредување на приоритетот на тестот според веројатноста за влошување на областа и штетата што ќе ја предизвика кога ќе се влоши - го насочува напорот кон најголем ризик. Вештачката интелигенција (ВИ) е моќен партнер за анализа и во двете: ги прави видливи празнините во покриеноста, сугерира ризични области. Но, централната забелешка останува: бројот на опфати што вештачката интелигенција ги гледа може да биде погрешен; Дури и 100% покриеност на редови може да се постигне со тестови кои не потврдуваат ништо. Ваша задача е да го читате опсегот како мапа, а не како доверба.

Правилно читање на метрика на покриеност

Постојат неколку видови на опсег, и не сите се подеднакво значајни:

  • Покриеност на линијата: Колку линии код биле извршени барем еднаш. Најчест, но најслаб критериум; Само затоа што линијата работи не е доказ дека таа се однесува правилно.
  • Покриеност на гранка: дали секоја гранка ако (и вистинита и неточна) е тестирана. Позначајно од линија.
  • Покриеност на состојбата: Тестирање на секоја под-услови во сложени услови посебно.
  • Покривање на патека: Комбинации на логички патеки во кодот. Тој е најсеопфатен, но тешко е да се постигне целосно во пракса.
Внимание: процентот на покриеност не е „оценка за квалитет“. 100% покриеност на редови ви кажува дека редовите работат; не дека го дава точниот резултат (псевдопродавањето во единицата 1). Користете го опсегот како одговор на прашањето „каде никогаш не сум погледнал“, а не како уверување дека „сè е тестирано“.

Опсег слепи точки

Метриката на покриеност мери само колку од кодот е извршен; не може да ги види: (1) непроверени барања (кодот постои, но деловното правило е погрешно), (2) недостасува код (нема простор за контрола што никогаш не била напишана), (3) комбинации на податоци/состојби, (4) употребливост, перформанси, безбедност. Затоа, покриеноста на барањата (секој критериум за прифаќање мора да биде исполнет со најмалку еден тест) треба да се стави веднаш до покриеноста со код. Вештачката интелигенција е многу корисна во производството на мапирање на барања-тест (матрица за следливост).

Тестирање засновано на ризик: каде ги вложуваме напорите?

Ризик = веројатност (шанса за кршење) × влијание (штета ако се скрши). Со вештачката интелигенција, можете да постигнете список со карактеристики на овие две оски и да креирате топлинска карта. Голема веројатност × високи домени (плаќање, автентикација, интегритет на податоци) заслужуваат најинтензивно тестирање; ниски × ниски области (ретко користен екран со приоритети) тестирање на светлина е доволно.

област

веројатност

Влијание

Ризик

Густина на тестот

Тек на плаќање

средно

многу високо

високо

Длабока + автоматизација

автентикација

средно

многу високо

високо

Длабока + безбедност

Пребарување производ

високо

средно

Средно-Висок

Автоматизација + откривање

Фотографија на профилот

низок

низок

низок

контрола на светлината

Страница за помош

низок

премногу ниско

премногу ниско

преглед

Стапица на бркање опсег

Ставањето на процентот на покриеност цел (на пр. правилото „тимот мора да помине 90% покриеност“) има опасен несакан ефект: програмерите и тестерите се фокусираат на зголемување на процентот наместо на решавање на вистинскиот ризик. Резултатот е често надуен опсег без тврдења или тривијални тестови - бројот изгледа убаво, но нема заштита. Ова е феноменот на расипување на критериумот кога тој самиот станува цел: „кога мерката станува цел, таа престанува да биде добра мерка“. Користете го опсегот како дијагностичка алатка, а не картичка за извештај за перформансите.

Поздрав пристап е да се чита опсегот насоки: „Зошто покриеноста на филијалата е заглавена на 40% во критичниот модул за плаќање?“ Прашањето е "дали целокупната покриеност е 90%?" Тоа е многу повредно од прашањето. Вештачката интелигенција нека го разложи извештајот за опфатот по модул и ниво на ризик; Истакнете области со висок ризик со мала покриеност. Така, опсегот станува компас што го насочува трудот наместо слеп процент.

Внимание: Слоганот „100% покриеност“ е замка. Тестирањето на некои кодови (едноставни додатоци, авто-генерирани делови) има мала вредност; напорот потрошен таму е украден од деловните правила со висок ризик. Целта е да се тестира секое важно однесување и ризик, а не секоја линија.

Слаб промпт / Силен промпт

Слабо: „Зголемете ја мојата покриеност за тестирање“.
Силно: „Со оглед на оваа листа на критериуми за прифаќање и овие постојни тест случаи. (1) Табеларно кои критериуми за прифаќање не се исполнети со ниту еден тест (јаз на покриеност на барањата). (2) Оценете ја секоја карактеристика 1-5 на оските на веројатност и влијание; единствениот критериум да се даде приоритет на деловниот ризик Критериуми: [...] Тестови: [...]“

Моќен потсетник; го комбинира опсегот со деловниот ризик и дава приоритет на ограничената работна сила.

Четири шаблони за копирање

1) Јаз во опсегот на барањата:

Со оглед на следните критериуми за прифаќање и овие тест случаи. Направете табела за следливост: секој критериум -> тест(и) што го исполнуваат. Критериумите кои немаат никакви тестови се нарекуваат „ПОКРИВАЊЕ ЈАЗ“, а тестовите што не се поврзуваат со ниту еден критериум се нарекуваат „НЕОПХОДНИ?“ Ознака: Критериуми: [...] / Тестови: [...]

2) Оценување за ризик:

Оценете ја оваа листа на карактеристики/модули 1-5 за оските на веројатноста (веројатноста за кршење) и ударот (оштетувањето ако е скршено). Ризик = веројатност × влијание. Подредете во табела и наведете го препорачаниот тип на тестирање (единица/API/UI/извидување/безбедност) за секоја област со висок ризик. Список: [...]

3) Толкување на опсегот:

Даден е следниот извештај за покриеност (линија %, гранка %). Кажи ми го ова:- Што НЕ докажуваат овие бројки?- Кои се областите што би можеле да бидат изложени на ризик и покрај високата покриеност на редови?- Кое дополнително тестирање би препорачале за празнините што покриеноста не ги гледа (барање, комбинација на податоци, безбедност)? Извештај: [залепи]

4) Ограничен временски план:

Уште [X часа] до емитувањето. Следното рангирање на ризикот и празнините во покриеноста се дадени. Во овој период по приоритет се подготвува планот за тестирање кој ќе го намали максималниот ризик. Јасно наведете што НЕ треба свесно да се тестира и прифатениот ризик од тоа. Податоци: [...]

три мини футроли

Случај 1 — 100% покриеност, нула доверба. Еден тим се пофали со 94% покриеност на линијата. Анализата на „толкување на опсегот“ покажа дека повеќето од тестовите биле без тврдење, што значи дека истрчале линии, но не потврдиле ништо. Вистинската заштитна покриеност беше многу помала. Тимот не се фокусираше на бројки, туку на тестирање на мутации (единица 10); вистинската стапка на фаќање на грешка се удвои.

Случај 2 - Поправен приоритет на картата на ризик. Еден тим трошеше 40% од напорите за тестирање на ретко користен екран за известување, прескокнувајќи го протокот на плаќање затоа што „само функционира“. Оценувањето на ризикот за вештачка интелигенција ја покажа оваа нерамнотежа. Трудот беше прераспределен; Две недели подоцна беше пронајдена грешка со големо влијание во протокот на плаќања и беше затворена пред почетокот.

Случај 3 - Свесен надвор од опсегот. 4 часа по објавувањето, тимот одлучи што да тестира и што свесно да прескокне со шаблонот „ограничен распоред“. Два високоризични струи беа тестирани длабоко; екранот со преференци со низок ризик беше документиран како „прифатен ризик“ и беше прескокнат. Одлуката беше транспарентна и образложена; Верзијата излезе безбедно.

Вообичаени грешки

  • Погрешен процент на покриеност со квалитет. Читање покриеност со високи редови како „тестирано“ уверување.
  • Само гледајќи ја покриеноста на кодот. Покривање на барањата за прескокнување (тестирање на секој критериум за прифаќање).
  • Тестирање подеднакво без да се земе предвид ризикот. Распределба на работна сила во области со низок ризик и занемарување на критичните текови.
  • Се крие надвор од опсегот. Недокументирање на она што не било тестирано кога немало доволно време; Изненадувања по објавувањето.
  • Прифаќање на резултатот за ризик на ВИ без прашање. ВИ не го познава целосно контекстот на производот; Прилагодете ги резултатите со стручно око.

Сумирано

Покриеноста на тестот и тестирањето базирано на ризик се две алатки за насочување на ограничениот напор на вистинското место. Метриката на покриеност (линија, гранка, состојба, патека) покажува што е допрено, но не докажува дека се однесувало правилно; Опсегот е мапа, довербата не е. Ставете ја покриеноста на барањата до покриеноста со кодот. Оценете ги карактеристиките со формулата ризик = веројатност × влијание и насочете го напорот до најголем ризик. Вештачката интелигенција прави видливи празнини, постигнува ризик, планира ограничено време; но конечниот приоритет и одлуката за „свесно откажување“ лежи кај експертот кој го знае деловниот контекст.

Задача за апликација

Изберете модул од вашиот сопствен проект. Извршете го шаблонот „јаз во опсегот на барања“ со вештачка интелигенција и дознајте кои критериуми за прифаќање не се тестирани. Потоа рангирајте ги под-карактеристиките на модулот на оските на веројатност × удари со „оценка за ризик“. Дистрибуирајте ги (хипотетичките) 3 часа време за тестирање што го имате со „ограничениот распоред“; Запишете го она што свесно нема да го тестирате и прифатениот ризик. Додајте конкретен тест кој ќе го затвори најризичниот јаз во покриеност што ќе го најдете.

листа за проверка

  • [ ] Процентот на покриеност го читам како карта, а не како квалитет.
  • [ ] Покрај покриеноста со кодот, ја отстранив и покриеноста на барањата.
  • [ ] Ги оценив карактеристиките по веројатност × влијание и ги рангираше по ризик.
  • [ ] Ги пренасочив напорите за тестирање на највисок ризик.
  • [ ] Имам документирано области кои не се свесно тестирани и не го признав ризикот.
  • [ ] Ги прегледав оценките за ризик на вештачката интелигенција врз основа на мојот контекст на производот.