Прибуток:
- Здатність трансформувати вимоги та критерії прийнятності в комплексні тестові випадки за допомогою таких методів, як класи еквівалентності, аналіз граничних значень і таблиці рішень, за підтримки штучного інтелекту
- Можливість створювати позитивні, негативні та крайові сценарії окремо та доповнювати крайові випадки, пропущені штучним інтелектом, інформацією про продукт
- Можливість встановити відстежуваність і усунути прогалини в охопленні та непотрібне роздуття шляхом зв’язування тестових випадків із критеріями прийнятності
Робота тестувальника часто починається з чистого аркуша: у нього є вимога («користувач повинен мати можливість скинути свій пароль»), і йому потрібно перетворити це одне речення на десятки конкретних перевірок, які доведуть, що програмне забезпечення дійсно працює правильно. Це перетворення називається дизайном тесту. Ключовим є знання різниці між тестовим сценарієм — високорівневою метою, яка описує, що перевіряти, наприклад «недійсний пароль слід відхилити» — і тестовим прикладом — виконуваним модулем, який докладно описує цей сценарій із конкретними кроками, вхідними даними та очікуваним результатом. Штучний інтелект (AI) прискорює саме цей момент порожньої сторінки: перетворюючи одну вимогу на десятки проектів сценаріїв за секунди. Але пам’ятайте — ШІ відтворює ті ситуації, які ви можете придумати; Завдяки знанням про продукт ви вибираєте, які ситуації дійсно важливі.
У цьому розділі ви крок за кроком дізнаєтесь, як перетворити вимогу на повний, але безперешкодний набір тестів із підтримкою ШІ.
Крок за кроком: від вимоги до набору тестів
Крок 1 — Уточніть вимогу. Зберіть критерії прийнятності (умови, яким має відповідати робота, щоб вважатися «виконаною»), перш ніж надавати штучному інтелекту необхідну вимогу. «Пароль має бути скинутим» недостатньо; Такі правила, як «посилання для скидання дійсне протягом 30 хвилин», «той самий пароль не можна використовувати повторно» є джерелом справжнього тесту.
Крок 2 — Запровадження методів тестування. Не просто кажіть «напишіть сценарій» про ШІ; Запитайте про класичні методи розробки тестів за назвою:
- Класи еквівалентності (розподіл еквівалентності): Розподіл вхідних даних на групи, які, як очікується, вироблятимуть однакову поведінку. Наприклад, для вікового поля «дійсний діапазон», «занадто малий» і «занадто великий» є класами; Досить перевірити один приклад із кожного класу.
- Аналіз граничних значень: Тестування порогових значень на основі того факту, що помилки виникають найчастіше на межах. Це як тестувати 17, 18, 19 окремо для вікового обмеження 18 років.
- Таблиця рішень: зведення в таблицю комбінацій кількох умов і очікуваного результату кожної комбінації.
- Перехід стану: тестування переходів системи від стану до стану (наприклад, замовлення: створено → оплачено → відправлено) і недійсних переходів.
Крок 3 — Розділіть позитивні, негативні та крайові стани. Попросіть позитивний тест (очікуваний результат із правильним введенням), негативний тест (справжня помилка з недійсним введенням) і граничний випадок — межові або незвичайні випадки. AI зазвичай наголошує на позитиві; Негативні та граничні випадки є неповними, якщо ви їх явно не запросите.
Крок 4 — визначте пріоритети та обріжте. AI може генерувати 60 сценаріїв; Не всі вони мають однакову цінність. Віддайте пріоритет тим, що мають високий ризик (гроші, безпека, втрата даних), і об’єднайте ті, які є дублікатами.
Порада: надішліть окремий запит ШІ зі словами «згенеруйте 5 немислимих граничних випадків на основі цієї вимоги». Найцінніший внесок ШІ полягає в тому, що він часто нагадує вам про надзвичайні ситуації, які ви не помітили.
Слабка підказка / Сильна підказка
Слабко: «Напишіть тестові випадки для скидання пароля».
Сильно: «Створіть тестові випадки для функції «скидання пароля» з такими критеріями прийнятності: посилання дійсне протягом 30 хвилин, одноразове використання, останні 3 паролі не можна використовувати повторно, обліковий запис заблоковано на 15 хвилин після 5 невдалих спроб. Застосуйте класи еквівалентності та аналіз граничних значень. Наведіть позитивні, негативні та крайові випадки в окремих заголовках. Для кожного випадку: ідентифікатор, передумова, кроки, дані тестування, очікуваний результат, пов’язаний результат. критерії прийняття. Виділіть сценарії безпеки/блокування.
Потужна підказка; Він містить правила, методи, формат виводу та порядок пріоритетів. Таким чином, AI створює виконувані та відстежувані тестові випадки, а не декоративні.
Формат виводу тестового випадку
Попросіть структурований формат, який можна імпортувати безпосередньо в інструмент керування тестами вашої команди (наприклад, TestRail, Zephyr, Xray). У наступній таблиці показано компоненти хорошого тесту:
область
опис
приклад
ID
унікальний ідентифікатор
TC-PWD-014
Назва
коротка мета
Прострочене посилання буде відхилено
передумова
Необхідні умови перед тестуванням
Посилання для скидання було створено 31 хвилину тому
кроки
Послідовні дії
1. Натисніть на посилання 2. Введіть новий пароль
тестові дані
Використані конкретні значення
старе посилання, новий пароль "Abc!2345"
очікуваний результат
Поведінка підлягає перевірці
Помилка «Термін дії посилання закінчився», пароль не змінюється
Критерії прийняття
посилання на відстежуваність
АК-3: посилання дійсне 30 хвилин
пріоритет
Рівень ризику
висока
Чотири шаблони, які можна копіювати
1) Створення сценарію на технічній основі:
Ваша роль: старший розробник тестів. Створюйте тестові випадки для функції: [функції та критерії прийняття]. Застосовуйте: класи еквівалентності, аналіз точок зупину, таблицю рішень. Надайте результати в 3 групах: позитивний / негативний / крайній випадок. Кожен випадок: ідентифікатор, передумова, кроки, дані тестування, очікуваний результат, пов’язані критерії прийнятності, пріоритет (високий/середній/низький).
2) Edge case hunter:
Перелічіть 10 граничних випадків, якими зазвичай не користуються для такої функції: [функція]. Напишіть одним реченням, чому це ризиковано для кожного. Подумайте про такі осі, як пусте/нульове значення, надто довге введення, паралелізм, тайм-аут, помилки формату, Юнікод/емодзі, мінус/нуль, збій мережі.
3) Виготовлення таблиці рішень:
Створіть таблицю рішень для такого бізнес-правила: [правила]. Стовпці: комбінації умов; рядки: кожна умова та очікувана дія. Позначати недосяжні або суперечливі комбінації. Потім запропонуйте тестовий приклад для кожної комбінації.
4) Контроль простежуваності:
Враховуючи наведений нижче список критеріїв прийнятності та такі тестові випадки: [критерії] / [випадки]. Покажіть у формі таблиці, яким критеріям прийнятності відповідають ЖОДНІ тестові випадки (розрив у охопленні), а яким випадкам не відповідають жодні критерії (зайвий випадок).
три міні-чохла
Випадок 1 — Значення крайових станів. Експерт з команди фінтехів написав 18 скриптів для функції переказу грошей. Він застосував шаблон «edge case hunter» до ШІ; ШІ нагадав про ситуацію «одночасної передачі одного балансу з двох пристроїв» (конкурентність). Під час тестування цього сценарію було виявлено та закрито вразливість подвійних витрат перед запуском. Одна неприємна ситуація запобігла потенційному шестизначному збитку.
Випадок 2 — Обрізка опуклості. Команда змусила штучний інтелект створити сценарій для форми членства, і було розглянуто 74 випадки. Запуск шаблону відстеження виявив, що 74 випадки відповідали лише 9 критеріям прийнятності, причому багато хто повторно тестував той самий клас еквівалентності. Набір скорочено з 74 до 23 значущих випадків; час роботи зменшився на 68%, покриття не зменшилося.
Випадок 3 — Невірне припущення. ШІ запропонував перевірити недійсні дати, як-от «31 лютого», для поля дати, але не знав, що компонент календаря, який використовувала команда, уже заблокував це. Експерт виключив 4 з 6 сценаріїв дат, створених ШІ, як непотрібні в контексті продукту. можливості, створені ШІ; зробив вибір інформації про товар.
Поширені помилки
- Запит сценарію без надання критеріїв прийняття. Не знаючи, що правда, штучний інтелект створює поверхневі сценарії, які часто пропускають реальний ризик.
- Просто задовольняйтеся позитивними тестами. Явно не бажаю негативних і крайніх випадків. Саме тут часто криються помилки.
- Прийняття створеного таким, яким воно є. Забуваючи, що штучний інтелект не знає контексту продукту, і залишаючи непотрібні або неможливі сценарії на знімальному майданчику.
- Обхід відстежуваності. Не пов’язувати справи з критеріями прийняття; як наслідок, не видно, який критерій не перевірено (розрив охоплення).
- Помилка кількості. Радіти тому, що «вийшло 60 сценаріїв». Цінність не в кількості, а в масштабі, який покриває ризик.
Підсумовуючи
Розробка тесту полягає в перекладі вимоги з одного речення в конкретні виконувані випадки, які підтверджують правильність програмного забезпечення. Штучний інтелект значно прискорює цю трансформацію: він створює всеосяжні креслення, коли ви надаєте йому критерії прийнятності, класичні методи тестування (класи еквівалентності, точка зупину, таблиця рішень, перехід станів) і чіткий вихідний формат. Але штучний інтелект упереджений до позитиву, не знає контексту продукту та може створити непотрібне роздуття. Ваше завдання полягає в тому, щоб явно запитувати негативні та крайні випадки, налагоджувати відстеження, розставляти пріоритети за ризиком і обрізати.
Аплікаційне завдання
Виберіть функцію зі свого проекту та запишіть критерії прийнятності. Попросіть штучний інтелект створити тестові випадки за допомогою шаблону «генерація сценарію на основі техніки». Потім застосуйте шаблони «edge case hunter» і «traceability check». У результаті: (1) додайте принаймні 3 граничні випадки, які штучний інтелект пропускає, (2) видаліть випадки, які не підключаються до жодних критеріїв прийняття, (3) напишіть нові випадки, якщо є якісь критерії прийняття, які залишилися неперевіреними. Залийте остаточний набір в електронну таблицю.
контрольний список
- [ ] Перш ніж запитувати сценарій, я уточнив критерії прийняття.
- [] Я запитав YZ про класи еквівалентності та аналіз граничних значень за назвою.
- [ ] Я генерував позитивні, негативні та крайові стани окремо.
- [] Я пов’язав кожен тест із критерієм прийнятності (відстежуваність).
- [ ] Я перевірив прогалини та непотрібні випадки за допомогою таблиці.
- [ ] Я визначив пріоритет ризику та обрізав роздутий набір.