Печалби:
- Възможност за трансформиране на изискване и критерии за приемане в изчерпателни тестови случаи с техники като класове за еквивалентност, анализ на гранични стойности и таблици за решения, с подкрепата на изкуствен интелект
- Възможност за създаване на положителни, отрицателни и крайни сценарии поотделно и допълване на крайните случаи, пропуснати от изкуствения интелект с информация за продукта
- Възможност за установяване на проследимост и премахване на пропуски в покритието и ненужно раздуване чрез свързване на тестови случаи с критерии за приемане
Работата на тестера често започва с този празен лист: той има изискване („потребителят трябва да може да нулира паролата си“) и трябва да превърне това едно изречение в десетки конкретни проверки, които ще докажат, че софтуерът действително работи правилно. Тази трансформация се нарича тестов дизайн. Познаването на разликата между тестов сценарий — цел от високо ниво, която описва какво да се тества, като например „невалидна парола трябва да бъде отхвърлена“ — и тестов случай — изпълнима единица, която описва подробно този сценарий с конкретни стъпки, вход и очакван резултат, е от ключово значение. Изкуственият интелект (AI) ускорява точно този момент на празна страница: превръща едно изискване в десетки чернови на сценарии за секунди. Но помнете – AI възпроизвежда ситуациите, за които можете да се сетите; Вие избирате с познанията си за продукта кои ситуации са наистина важни.
В този модул ще научите стъпка по стъпка как да превърнете дадено изискване в цялостен, но без излишни тестове с поддръжка на AI.
Стъпка по стъпка: от изискване до набор от тестове
Стъпка 1 — Изяснете изискването. Съберете критерии за приемане (условия, на които една работа трябва да отговаря, за да се счита за „свършена“), преди да дадете на AI суровото изискване. „Паролата трябва да може да се нулира“ не е достатъчно; Правила като „връзката за нулиране е валидна за 30 минути“, „същата парола не може да се използва повторно“ са източникът на истинския тест.
Стъпка 2 — Прилагане на техники за тестване. Не казвайте просто „напишете скрипт“ за AI; Поискайте класически техники за проектиране на тестове по име:
- Класове на еквивалентност (разделяне на еквивалентност): Разделяне на входове на групи, които се очаква да произведат същото поведение. Например за полето за възраст "валиден диапазон", "твърде малък" и "твърде голям" са класове; Тестването на един пример от всеки клас е достатъчно.
- Анализ на граничните стойности: Тестване на праговите стойности въз основа на факта, че грешките възникват най-много на границите. Това е като да тествате 17, 18, 19 отделно за възрастовата граница 18.
- Таблица с решения: Табулиране на комбинации от множество условия и очаквания резултат от всяка комбинация.
- Преход на състояние: Тестване на преходите на системата от състояние в състояние (например поръчка: създадено → платено → изпратено) и невалидни преходи.
Стъпка 3 — Разделете положителните, отрицателните и крайните състояния. Поискайте положителен тест (очакван резултат с правилен вход), отрицателен тест (правилна грешка с невалиден вход) и краен случай — гранични или необичайни случаи. AI обикновено набляга на положителното; Отрицателните и крайните случаи са непълни, освен ако изрично не ги поискате.
Стъпка 4 — Приоритизиране и подрязване. AI може да генерира 60 сценария; Не всички са с еднаква стойност. Дайте приоритет на тези с висок риск (пари, сигурност, загуба на данни) и комбинирайте тези, които са дубликати.
Съвет: Изпратете отделна заявка до AI, като казвате „генерирайте 5 немислими крайни случая от това изискване“. Най-ценният принос на AI е, че често ви напомня за необикновени ситуации, които сте пренебрегнали.
Слаба подкана / Силна подкана
Слаб: „Напишете тестови случаи за повторно задаване на парола.“
Силно: „Генерирайте тестови случаи за функцията „нулиране на парола“ със следните критерии за приемане: връзка, валидна за 30 минути, еднократна употреба, последните 3 пароли не могат да се използват повторно, акаунтът е заключен за 15 минути след 5 неправилни опита. Приложете класове за еквивалентност и анализ на гранични стойности. Дайте положителни, отрицателни и крайни случаи в отделни заглавия. За всеки случай: ID, предпоставка, стъпки, тестови данни, очакван резултат, свързан критерии за приемане. Маркирайте сценарии за сигурност/заключване, вземете го."
Мощна подсказка; Той дава правила, техники, изходен формат и приоритетен ред. По този начин AI произвежда изпълними и проследими тестови случаи, а не декоративни.
Изходен формат на тестов случай
Поискайте структуриран формат, който може да бъде импортиран директно в инструмента за управление на тестове на вашия екип (напр. TestRail, Zephyr, Xray). Следната таблица показва компонентите на един добър тестов случай:
площ
Описание
пример
ID
уникален идентификатор
TC-PWD-014
Заглавие
кратка цел
Изтеклата връзка ще бъде отхвърлена
предпоставка
Необходимо условие преди тестване
Връзката за нулиране е генерирана преди 31 минути
стъпки
Последователни действия
1. Кликнете върху връзката 2. Въведете новата парола
тестови данни
Използвани конкретни стойности
стара връзка, нова парола "Abc!2345"
очакван резултат
Поведението трябва да бъде проверено
Грешка „Връзката е изтекла“, паролата не се променя
Критерии за приемане
връзка за проследяване
AK-3: връзката е валидна 30 минути
приоритет
Ниво на риск
високо
Четири копируеми шаблона
1) Създаване на технически сценарий:
Вашата роля: старши дизайнер на тестове. Генериране на тестови случаи за функция: [характеристика и критерии за приемане]. Прилагане: класове на еквивалентност, анализ на точки на прекъсване, таблица на решения. Осигурете изход в 3 групи: Положителен / Отрицателен / Краен случай. Всеки случай: ID, предварително условие, стъпки, тестови данни, очакван резултат, свързани критерии за приемане, приоритет (висок/среден/нисък).
2) Ловец на ръбове:
Избройте 10 обикновено пренебрегвани крайни случая за следната функция: [характеристика]. Напишете с едно изречение защо е рисковано за всеки. Помислете за оси като празно/нулево, въвеждане твърде дълго, паралелност, изчакване, грешки при форматиране, Unicode/емоджи, отрицателно/нула, прекъсване на мрежата.
3) Производство на таблица за решения:
Създайте таблица с решения за следното бизнес правило: [правила]. Колони: комбинации от условия; редове: всяко условие и очаквано действие. Маркирайте непостижими или противоречиви комбинации. След това предложете тестов случай за всяка комбинация.
4) Контрол на проследимостта:
Предвид следния списък с критерии за приемане и следните тестови случаи: [критерии] / [случаи]. Покажете в таблична форма кои критерии за приемане са изпълнени от НЯМА тестови случаи (пропуск в покритието) и кои случаи не са изпълнени от никакви критерии (излишен случай).
три мини калъфа
Случай 1 — Стойност на крайните състояния. Експерт от финтех екип е написал 18 скрипта за функцията за парични преводи. Той приложи шаблона „edge case hunter“ към AI; AI напомни ситуацията на „прехвърляне на същия баланс от две устройства едновременно“ (едновременност). Когато този сценарий беше тестван, уязвимостта на двойното харчене беше открита и затворена, преди да се активира. Една единствена периферна ситуация предотврати потенциална шестцифрена загуба.
Случай 2 — Изрязване на издутината. Един екип накара AI да създаде скрипт за формуляра за членство и бяха получени 74 случая. Изпълнението на шаблона за проследяване установи, че 74 случая отговарят само на 9 критерия за приемане, като много от тях са тествали повторно същия клас на еквивалентност. Наборът беше намален от 74 на 23 значими случая; времето за изпълнение намаля с 68%, покритието не намаля.
Случай 3 — Погрешно предположение. AI предложи тестване на невалидни дати като „31 февруари“ за поле за дата, но не знаеше, че компонентът на календара, който екипът използва, вече е блокирал това. Експертът елиминира 4 от 6-те сценария за дата, произведени от AI като ненужни в контекста на продукта. Възможности, генерирани от AI; направи избор на информация за продукта.
Често срещани грешки
- Искане на скрипт без посочване на критерии за приемане. Без да знае какво е вярно, AI създава повърхностни сценарии, които често пропускат реалния риск.
- Просто се задоволявайте с положителни тестове. Изрично не желая негативни и крайни случаи. Това е мястото, където често се крият грешките.
- Приемане на произведеното такова, каквото е. Забравяйки, че AI не познава контекста на продукта и оставя ненужни или невъзможни сценарии на снимачната площадка.
- Заобикаляне на проследимостта. Несвързване на случаи с критерии за приемане; в резултат на това не се вижда кой критерий не е тестван (разлика в покритието).
- Количествена грешка. Щастлив, защото "излязоха 60 сценария". Стойността не е в броя, а в обхвата, който покрива риска.
В обобщение
Дизайнът на теста е за превеждане на изискване от едно изречение в конкретни, изпълними случаи, които доказват коректността на софтуера. AI значително ускорява тази трансформация: той създава изчерпателни чертежи, когато му дадете критерии за приемане, класически техники за тестване (класове на еквивалентност, точка на прекъсване, таблица на решения, преход на състояние) и ясен изходен формат. Но AI е предубеден към положителното, не познава контекста на продукта и може да доведе до ненужно раздуване. Вашата работа е изрично да поискате отрицателни и крайни случаи, да установите проследимост, да приоритизирате според риска и да отстраните.
Задача за приложение
Изберете функция от вашия собствен проект и запишете критериите за приемане. Накарайте AI да генерира тестови случаи с шаблона „генериране на сценарий, базиран на техника“. След това приложете шаблоните „edge case hunter“ и „traceability check“. В резултат на това: (1) добавете поне 3 крайни случая, които AI прескача, (2) изрежете случаи, които не се свързват с никакви критерии за приемане, (3) напишете нови случаи, ако има критерии за приемане, останали нетествани. Изсипете крайния комплект в електронна таблица.
контролен списък
- [ ] Преди да поискам скрипт, изясних критериите за приемане.
- [ ] Попитах YZ за класове на еквивалентност и анализ на гранични стойности по име.
- [ ] Генерирах отделно положителни, отрицателни и крайни състояния.
- [ ] Свързах всеки тестов случай с критерий за приемане (проследимост).
- [ ] Проверих празнината в обхвата и ненужните случаи с таблицата.
- [ ] Приоритизирах според риска и подрязах набъбналия набор.