Прибыль:
- Способность преобразовать требования и критерии приемки в комплексные тестовые примеры с использованием таких методов, как классы эквивалентности, анализ граничных значений и таблицы решений, при поддержке искусственного интеллекта.
- Возможность отдельно создавать положительные, отрицательные и крайние сценарии и дополнять крайние случаи, пропущенные искусственным интеллектом, информацией о продукте.
- Возможность установить прослеживаемость и устранить пробелы в покрытии и ненужное раздувание, связывая тестовые примеры с критериями приемки.
Работа тестировщика часто начинается с чистого листа: у него есть требование («пользователь должен иметь возможность сбросить свой пароль»), и ему нужно превратить это единственное предложение в десятки конкретных проверок, которые докажут, что программное обеспечение действительно работает правильно. Это преобразование называется тест-дизайном. Знание разницы между сценарием тестирования (целью высокого уровня, описывающей, что тестировать, например «неверный пароль должен быть отклонен»), и тестовым примером (исполняемым модулем, подробно описывающим этот сценарий с конкретными шагами, входными данными и ожидаемым результатом) является ключевым моментом. Искусственный интеллект (ИИ) ускоряет именно этот момент «чистой страницы», превращая одно требование в десятки черновых сценариев за секунды. Но помните: ИИ воспроизводит те ситуации, о которых вы можете подумать; Благодаря своему знанию продукта вы сами выбираете, какие ситуации действительно важны.
В этом модуле вы шаг за шагом узнаете, как превратить требование в комплексный, но простой набор тестов с поддержкой искусственного интеллекта.
Шаг за шагом: от требования к набору тестов
Шаг 1 — Уточните требование. Соберите критерии приемки (условия, которым должна соответствовать работа, чтобы считаться «выполненной»), прежде чем передавать ИИ необработанные требования. «Пароль должен быть сбрасываемым» недостаточно; Такие правила, как «ссылка для сброса действительна в течение 30 минут», «один и тот же пароль не может быть использован повторно» являются источником настоящего теста.
Шаг 2 — Внедрить методы тестирования. Не говорите просто «напишите сценарий» об ИИ; Спросите по названию классические методы проектирования тестов:
- Классы эквивалентности (разделение эквивалентности): разделение входных данных на группы, которые, как ожидается, будут обеспечивать одинаковое поведение. Например, для поля возраста «допустимый диапазон», «слишком маленький» и «слишком большой» являются классами; Достаточно протестировать по одному примеру из каждого класса.
- Анализ граничных значений: проверка пороговых значений на основе того факта, что ошибки чаще всего возникают на границах. Это как тестировать 17, 18, 19 отдельно на возрастное ограничение 18 лет.
- Таблица решений: таблица комбинаций нескольких условий и ожидаемого результата каждой комбинации.
- Переход между состояниями: тестирование переходов системы из состояния в состояние (например, заказ: создан → оплачен → отправлен) и недопустимых переходов.
Шаг 3 — Разделите положительные, отрицательные и краевые состояния. Попросите положительный тест (ожидаемый результат при правильном вводе), отрицательный тест (правильная ошибка при недопустимом вводе) и крайний случай — пограничные или необычные случаи. ИИ обычно подчеркивает позитив; Отрицательные и крайние случаи являются неполными, если вы явно не запросите их.
Шаг 4. Расставьте приоритеты и сократите их. ИИ может генерировать 60 сценариев; Не все они имеют одинаковую ценность. Расставьте приоритеты с высоким риском (деньги, безопасность, потеря данных) и объедините те, которые являются дубликатами.
Совет: отправьте ИИ отдельный запрос с текстом «сгенерируйте 5 немыслимых крайних случаев на основе этого требования». Самый ценный вклад ИИ заключается в том, что он часто напоминает вам об чрезвычайных ситуациях, которые вы упустили из виду.
Слабая подсказка / Сильная подсказка
Слабое: «Напишите тестовые примеры для сброса пароля».
Сильный: «Создать тестовые сценарии для функции «сброса пароля» со следующими критериями приемлемости: ссылка действительна в течение 30 минут, одноразовое использование, последние 3 пароля не могут быть использованы повторно, учетная запись заблокирована на 15 минут после 5 неверных попыток. Примените классы эквивалентности и анализ граничных значений. Укажите положительные, отрицательные и крайние случаи в отдельных заголовках. Для каждого случая: идентификатор, необходимые условия, шаги, тестовые данные, ожидаемый результат, соответствующие критерии приемлемости. Выделите сценарии безопасности/блокировки.
Мощная подсказка; Он дает правила, методы, формат вывода и порядок приоритетов. Таким образом, ИИ создает исполняемые и отслеживаемые тестовые примеры, а не декоративные.
Формат вывода тестового примера
Попросите структурированный формат, который можно импортировать непосредственно в инструмент управления тестированием вашей команды (например, TestRail, Zephyr, Xray). В следующей таблице показаны компоненты хорошего тестового примера:
площадь
Описание
пример
идентификатор
уникальный идентификатор
TC-PWD-014
Название
краткая цель
Ссылка с истекшим сроком действия будет отклонена.
предпосылка
Условия, необходимые перед тестированием
Ссылка для сброса была создана 31 минуту назад
шаги
Последовательные действия
1. Нажмите на ссылку 2. Введите новый пароль.
данные испытаний
Используемые конкретные значения
старая ссылка, новый пароль "Abc!2345"
ожидаемый результат
Поведение, требующее проверки
Ошибка «Срок действия ссылки истек», пароль не меняется
Критерии приемки
ссылка для отслеживания
АК-3: ссылка действительна 30 минут
приоритет
Уровень риска
высокий
Четыре копируемых шаблона
1) Производство сценариев на технической основе:
Ваша роль: старший дизайнер тестов. Создайте тестовые сценарии для функции: [функция и критерии приемки]. Примените: классы эквивалентности, анализ точек останова, таблицу решений. Обеспечьте выходные данные в 3 группах: положительный / отрицательный / крайний случай. Каждый случай: идентификатор, предварительное условие, шаги, тестовые данные, ожидаемый результат, соответствующие критерии приемки, приоритет (высокий/средний/низкий).
2) Охотник за крайними случаями:
Перечислите 10 обычно игнорируемых крайних случаев для следующей функции: [функция]. Напишите одним предложением, почему это рискованно для каждого. Подумайте о таких осях, как пусто/нулевой, слишком длинный ввод, параллелизм, тайм-аут, ошибки формата, Unicode/emoji, отрицательный/нулевой, сбой в сети.
3) Производство таблицы решений:
Создайте таблицу решений для следующего бизнес-правила: [правила]. Столбцы: комбинации условий; строки: каждое условие и ожидаемое действие. Отмечайте недостижимые или противоречивые комбинации. Затем предложите тестовый пример для каждой комбинации.
4) Контроль прослеживаемости:
Учитывая следующий список критериев приемки и следующие тестовые примеры: [критерии] / [случаи]. Покажите в табличной форме, каким критериям приемки соответствуют НЕТ тестовых случаев (пробел в охвате), а каким случаям не соответствует ни один критерий (избыточный случай).
три мини-кейса
Случай 1 — Значение краевых состояний. Эксперт из финтех-команды написал 18 скриптов для функции денежных переводов. Он применил к ИИ шаблон «охотника за крайними случаями»; ИИ напомнил ситуацию «переноса одного и того же баланса с двух устройств одновременно» (concurrency). При тестировании этого сценария была обнаружена уязвимость двойной траты, которая была закрыта перед запуском в эксплуатацию. Единственная дополнительная ситуация предотвратила потенциальный шестизначный убыток.
Случай 2 — Устранение выпуклости. Команда попросила ИИ создать сценарий для формы членства, и было обработано 74 случая. Запуск шаблона прослеживаемости показал, что 74 случая соответствовали только 9 критериям приемлемости, причем многие из них повторно тестировали один и тот же класс эквивалентности. Набор сокращен с 74 до 23 значимых случаев; время выполнения сократилось на 68%, охват не уменьшился.
Случай 3 — Неверное предположение. ИИ предложил протестировать недопустимые даты, такие как «31 февраля», для поля даты, но не знал, что компонент календаря, который использовала команда, уже заблокировал это. Эксперт исключил 4 из 6 сценариев свиданий, выдаваемых ИИ, как ненужные в контексте продукта. Возможности, созданные ИИ; сделал выбор информации о продукте.
Распространенные ошибки
- Запрос сценария без указания критериев приемки. Не зная, что является правдой, ИИ создает поверхностные сценарии, которые часто упускают из виду реальный риск.
- Просто довольствуюсь положительными тестами. Явно не желаю отрицательных и крайних случаев. Именно здесь часто кроются ошибки.
- Принятие того, что произведено, таким, какое оно есть. Забывая, что ИИ не знает контекста продукта, и оставляя на съемочной площадке ненужные или невозможные сценарии.
- Обход отслеживания. Не привязывать дела к критериям приемлемости; в результате не видно, какой критерий не проверяется (разрыв в охвате).
- Количественная ошибка. Радуюсь, потому что «выпущено 60 сценариев». Ценность не в количестве, а в объеме, который покрывает риск.
В итоге
Проектирование тестов — это преобразование требования, состоящего из одного предложения, в конкретные, выполнимые случаи, которые доказывают правильность программного обеспечения. ИИ значительно ускоряет эту трансформацию: он создает комплексные чертежи, когда вы задаете ему критерии приемки, классические методы тестирования (классы эквивалентности, точки останова, таблицу решений, переход состояний) и понятный формат вывода. Но ИИ склонен к позитиву, не знает контекста продукта и может привести к ненужному раздуванию. Ваша задача — явно запрашивать отрицательные и крайние случаи, обеспечивать отслеживаемость, расставлять приоритеты по рискам и сокращать риски.
Задача приложения
Выберите функцию из своего проекта и запишите критерии приемки. Попросите ИИ сгенерировать тестовые примеры с помощью шаблона «генерация сценария на основе технологий». Затем примените шаблоны «Охотник за крайними случаями» и «Проверка прослеживаемости». В результате: (1) добавьте как минимум 3 крайних случая, которые ИИ пропускает, (2) сократите случаи, которые не связаны ни с какими критериями приемки, (3) напишите новые случаи, если какие-либо критерии приемки остались непроверенными. Залейте окончательный набор в электронную таблицу.
контрольный список
- [ ] Прежде чем запросить сценарий, я уточнил критерии приёмки.
- [ ] Я попросил у YZ классы эквивалентности и анализ граничных значений по имени.
- [ ] Я генерировал положительные, отрицательные и краевые состояния отдельно.
- [ ] Я связал каждый тестовый пример с критерием приемки (отслеживаемостью).
- [ ] Я проверил пробелы в объеме и ненужные случаи с помощью таблицы.
- [ ] Я расставил приоритеты по рискам и подрезал раздутый набор.