После составления требований их нужно преобразовать в конкретные тесты. Ключевая проблема при создании тестов - это определить их количество, которое покажет, что конкретное требование выполняется в системе
Как правило, одно требование может включать множество аспектов (например, авторизация пользователя, ограничение на ввод)
Для этого из каждого требования нужно извлечь тестовые условия - конкретные аспекты (свойства, правила, состояния, результаты) компонента или системы, который должен быть проверен в ходе тестирования. Например, у требования:
Авторизованный пользователь может добавить в корзину от 1 до 10 единиц доступного товара
есть 4 тестовых условия, которые нужно проверить:
Декомпозиция требования на условия осуществляется буквально вычленяя словосочетания из требования. Так как тестовое условие - это описание свойства функции, важно, чтобы уровень детализации не был настолько избыточным, что тестовое условие превращается в тест-кейс
Далее из тестовых условий формируются тестовые сценарии - описания ситуации или условий функционирования тестируемого объекта, используемое в качестве основы для определения и разработки соответствующих тест-кейсов
Если тестовое условие отвечает на вопрос “что проверяется?”, то тестовый сценарий отвечает на вопрос “в какой именно ситуации это проверяется?”. Тестовые сценарии описывают варианты поведения, в которых нужно проверять одно конкретное тестовое условие
Разные тестовые сценарии появляются из-за вариативности, которая создается благодаря:
Далее тестовые сценарии превращаются в тест-кейс (от англ. Test Case) - набор предусловий, входных данных, действий и ожидаемых результатов, определяющий конкретную проверку тестируемого объекта и предназначенный для достижения установленной цели тестирования
Тест-кейс состоит из 6 элементов:
Название или идентификатор тест-кейса
Название должно кратко и конкретно описывать проверяемое правило в этом тесте (например, условие + ожидаемое поведение)
Тестовые данные, на которых будет проверяться тест
Тестовые данные - данные, созданные или выбранные для использования в качестве входных данных при выполнении одного или нескольких тест-кейсов в соответствии с целями и условиями тестирования
Тестовые данные могут описывать значения, пользователей, объекты, состояния, связи или историю
Чтобы проверка была воспроизводимой, важно после тестирования вернуть систему в исходное состояние
Шаги взаимодействия с системой в ходе теста
Разделение между предусловиями и шагами взаимодействия зависит от того, что проверяется в тесте. Например, при проверки авторизации вход пользователя в систему является шагом, а при проверки работоспособности корзина авторизация является предусловием
Одна из проблем, которая появляется при создании тест-кейса, - это перегруженность, при которой проверяется множество условий одновременно, каждое из которых зависит от предыдущего
На основе сравнения ожидаемого и реального результатов образуется вердикт проверки:
Вместо тест-кейсов можно создать чек-лист - структурированный перечень тестовых условий, характеристик или аспектов тестируемого объекта, каждый из которых подлежит отдельной проверке в процессе тестирования
Чек-лист хорошо подходит вместо тест-кейсов, если:
Обычно для одного продукта чек-листы и тест-кейсы комбинируются для проверки разного функционала
Тестирование можно разделить на два вида:
Негативное тестирование - тестирование компонента или системы в условиях или способом, не предусмотренными их штатным использованием, с целью проверки корректности поведения при некорректных, недопустимых или неожиданных воздействиях
Негативное тестирование может включать проверку:
Негативные тесты не должны быть хаотичными, поэтому они также должны быть основаны на тестовых условиях и на рисках, которые появляются
Обычно позитивные и негативные проверки связаны, так как они проверяют то, что правило разрешает, и то, что оно запрещает. При этом нельзя пренебрегать позитивными проверками - нет смысла проверять, работает ли функция неправильно, если она вообще не работает правильно
Важно соблюдать трассируемость тестов: если изменилось требование, то нужно соответствующе изменить тестовые условия, сценарии и тест-кейсы. Такой подход также позволяет проверять, какие требования еще не были покрыты тест-кейсами