Простыми словами, это алгоритм, по которому тестировщик должен пройти (смоделировать поведение пользователя), чтобы проверить работоспособность определенного куска кода. Чтобы упростить этот процесс, могут быть использованы тест-кейсы с одним сценарием выполнения, но несколькими входными параметрами и разными ожидаемыми результатами. Фактически мы получаем мини чек-листы с предварительными шагами. Мега обсуждение в нашем телеграм-канале о поиске первой работы. Четко описаны все шаги и результаты.
Чтобы структурировать тест-кейсы как логические компоненты в тест-свите, удобнее рассматривать их с точки зрения программирования, как модули, компоненты или наборы функций. Секция непосредственно тест-кейсов, и их тестовых окружений. Идентификация всех возможных рисков, влияющих на результаты, и как их будут избегать/обходить. Условия «входа и выхода» данного набора, то есть что должно быть сделано перед его выполнением, и после.
Хороший ли практикой будет делать снапшоты отдельной части компонента при тестировании?
Так я буду проходиться по каждой колонке этой таблицы, пока не заполню все 16 результатов. Создать пароль из 17-ти символов и ожидать, что регистрация не пройдет. Создать пароль из 5-ти символов и ожидать, что регистрация не пройдет. Если свит покрывает 100% кодовой базы или чуть меньше, он найдет все дефекты, созданные после изменения функции; полнота дает уверенность. Если в наборе много интеграционных тестов и мало модульных, он, очевидно, будет долго выполняться. Быстрый тест-свит даст быстрый фидбэк, разработка пойдет эффективнее.
Отличие между ними в том, что чек-листы показывают направление тестирования, а тест-кейсы подробно описывают как тестировать. Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. Отмечая пункты списка, команда или один тестировщик могут узнать о текущем состоянии выполненной работы и о качестве продукта. В рассмотренном примере все шаги приводят к одному результату. Но также есть ситуации, когда на каждый шаг будет свой ожидаемый результат.
Что проверяет тест-кейс?
Открылась страница “Создание нового жильца” с полями “Фамилия”, “Имя” и “Отчество” и кнопкой “Сохранить”.6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано “Иванов Иван Иванович”.
Чаще довольно детализированное описание «о чем этот набор». Сквозные интеграционные, набор сквозной проверки интеграции подсистем в приложении. Набор, верифицирующий обычно часть функциональности, ее отдельные аспекты.
Ожидаемый результат
Также необходимо продумать, как новый функционал будет тестироваться, после того как разработчик его реализует. Инструкцию можно писать до, во время или после тестирования. Инструкцию никогда не поздно написать. Это помогает как новичкам, так и коллегам, которые работают в одной команде.
Записав всю необходимую информацию в чеклист или тест-кейс, тестировщик упрощает себе работу — ему не нужно запоминать все требования и держать в голове другие важные детали. Приоритет тест-кейсов и чек-листов заключается в том, что они делают процесс тестирования программного обеспечения структурированным и доступным для неспециалистов. В чек-листах прописываются объекты проверки, а в тест-кейсах — пошаговый алгоритм.
Пример оформления (один ожидаемый результат)
Если развернутая последовательность ваших шагов интуитивно не очень понятна, можно с первого по четвертый шаг вынести в предусловия. Пишите в шаге только одно действие. Не надо в один шаг описывать басню о царе султане и его дочери. Если вы не хотите делать из одного шага несколько, или просто хотите значительно сократить шаги в тесте — объедините несколько повелительных предложений в одно. И зачастую по причине большой загрузки, приближающихся дедлайнов или каких-то срочных задач можно не успеть написать тест-кейс. В таком случае можно остановиться на предыдущем шаге, поскольку из названия кейса можно понять, что делать.
- Они значительно повышают качество тестирования.
- Тест-кейсы выполняются вместе (последовательно); они группируются в наборы по функциональности (предназначению), в порядке, изложенном в тест-плане.
- В зависимости от метрик и пользовательского фидбэка добавляются и удаляются функции.
- С помощью инструкции можно быстро сориентироваться в проекте.
- Тестировщик пишет специальную документацию, в которой подробно отражает, что и как должно работать.
Их пишут в процессе разработки, до старта тестирования, иногда во время и даже после тестов. Если тест-кейс нужен, чтобы выполнить другой тест-кейс, оставьте ссылку по идентификатору в столбце предварительного условия. Ожидаемые и фактические результаты работы ПО совпадают. Негативные попытаются сломать нормальную работу системы. Например, если добавляют урок, когда нет места в расписании, или не указывают его название. Положительные тест-кейсы должны демонстрировать, что, если ввести корректные данные, новый урок появится в расписании.
Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности
Такая методика применяется, исходя из того что какое значение не введи в допустимом диапазоне, это будет как бы «эквивалентно» с точки зрения тестирования; то же и с невалидными значениями. Методика позволяет сократить количество тестов, при этом ничего не теряя в покрытии. Если ввод булевый (true или false), то создаются тест-кейсы для обоих значений, и true и false. Если на ввод подается набор значений («перечисление»), то тест-кейсы делаются (тоже) с 1 валидным значением и с 2-мя невалидными.
1.ID — уникальный номер.Обычно проставляется автоматически в системах хранения тест-кейсов. В заключении, хочу сказать, что должно быть сгенерировано достаточно тест-кейсов, чтобы обеспечить функциональное покрытие в полном объеме. Шаблон тест-кейсов API для сайта Vikunja смотреть по ссылке. Шаблон тест-кейсов API данного примера предлагаю просмотреть по ссылке.