В программной инженерии тестовый случай — это спецификация входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов, которые определяют один тест, который должен быть выполнен для достижения определенной цели тестирования программного обеспечения , например, для проверки определенного пути программы или для проверки соответствия определенному требованию. [1] Тестовые случаи лежат в основе тестирования, которое является методичным, а не бессистемным. Можно создать ряд тестовых случаев для получения желаемого покрытия тестируемого программного обеспечения. Формально определенные тестовые случаи позволяют многократно запускать одни и те же тесты для последовательных версий программного обеспечения, что позволяет проводить эффективное и последовательное регрессионное тестирование . [2]
Для того чтобы полностью проверить, что все требования приложения выполнены, должно быть не менее двух тестовых случаев для каждого требования: один положительный тест и один отрицательный тест. [3] Если требование имеет подтребования, каждое подтребование должно иметь не менее двух тестовых случаев. Отслеживание связи между требованием и тестом часто осуществляется с помощью матрицы прослеживаемости . Письменные тестовые случаи должны включать описание функциональности, которую нужно протестировать, и подготовку, необходимую для обеспечения возможности проведения теста.
Формальный письменный тестовый случай характеризуется известными входными данными и ожидаемыми выходными данными, которые разрабатываются до выполнения теста. [4] Известные входные данные должны проверять предварительное условие , а ожидаемые выходные данные должны проверять постусловие .
Для приложений или систем без формальных требований тестовые случаи могут быть написаны на основе принятой нормальной работы программ аналогичного класса. В некоторых школах тестирования тестовые случаи вообще не пишутся, но действия и результаты сообщаются после выполнения тестов.
В тестировании сценариев гипотетические истории используются для того, чтобы помочь тестировщику продумать сложную проблему или систему. Эти сценарии обычно не записываются подробно. Они могут быть такими же простыми, как схема для среды тестирования, или они могут быть описанием, написанным прозой. Идеальный тест сценария — это история, которая мотивирует, вызывает доверие, сложна и проста для оценки. Они обычно отличаются от тестовых случаев тем, что тестовые случаи представляют собой отдельные шаги, в то время как сценарии охватывают ряд шагов ключа. [5] [6]
Тестовый случай обычно содержит один шаг или последовательность шагов для проверки правильного поведения/функциональности и особенностей приложения. Обычно указывается ожидаемый результат или ожидаемый исход.
Дополнительная информация, которая может быть включена: [7]
Более крупные тестовые случаи могут также содержать предварительные состояния или шаги, а также описания. [7]
Письменный тестовый пример также должен содержать место для фактического результата.
Эти шаги можно сохранить в документе текстового процессора, электронной таблице, базе данных или другом общедоступном хранилище.
В системе базы данных вы также можете увидеть прошлые результаты тестов, кто сгенерировал результаты и конфигурацию системы, использованную для генерации этих результатов. Эти прошлые результаты обычно хранятся в отдельной таблице.
Тестовые наборы часто также содержат [8]
Помимо описания тестируемой функциональности и подготовки, необходимой для обеспечения возможности проведения теста, наиболее трудоемкой частью тестового случая является создание тестов и их изменение при изменении системы.
При особых обстоятельствах может возникнуть необходимость провести тест, получить результаты, а затем группа экспертов оценит, можно ли считать результаты пройденными. Это часто происходит при определении показателей производительности новых продуктов. Первый тест принимается в качестве базовой линии для последующих циклов тестирования и выпуска продукта.
Приемочные тесты , которые используют вариацию письменного тестового случая, обычно выполняются группой конечных пользователей или клиентов системы, чтобы убедиться, что разработанная система соответствует указанным требованиям или контракту. [9] [10] Пользовательские приемочные тесты различаются включением счастливого пути или положительных тестовых случаев до почти полного исключения отрицательных тестовых случаев. [11]