Наборы тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 151/301
•
На основе разбиения приложения на
модули и подмодули
{125}
. Для каждого
модуля (или его отдельных подмодулей) можно составить свой набор тест-
кейсов.
•
По принципу проверки самых важных, менее важных и всех остальных функ-
ций приложения (именно по этому принципу мы составляли примеры чек-ли-
стов
{116}
).
•
По принципу группировки тест-кейсов для проверки некоего уровня требова-
ний или типа требований
{39}
, группы требований или отдельного требования.
•
По принципу частоты обнаружения тест-кейсами
дефектов в приложении
(например, мы видим, что некоторые тест-кейсы раз за разом завершаются
неудачей, значит, мы можем объединить их в набор,
условно названный
«проблемные места в приложении»).
•
По архитектурному принципу (см. «многоуровневая архитектура»
150
самосто-
ятельно): наборы для проверки пользовательского интерфейса и всего
уровня
представления, для проверки уровня бизнес-логики,
для проверки
уровня данных.
•
По области внутренней работы приложения, например: «тест-кейсы, затра-
гивающие работу с базой данных», «тест-кейсы, затрагивающие работу с
файловой системой», «тест-кейсы, затрагивающие работу с сетью», и т.д.
•
По видам тестирования (см. главу «Подробная
классификация тестирова-
ния»
{69}
).
Не нужно заучивать этот список. Это всего лишь примеры — грубо говоря,
«первое, что приходит в голову». Важен принцип: если вы видите, что выполнение
некоторых тест-кейсов в виде набора принесёт вам пользу, создавайте такой набор.
Примечание: без хороших инструментальных средств управления тест-кей-
сами работать с наборами тест-кейсов крайне тяжело, т.к.
приходится самостоя-
тельно следить за приготовлениями, «недостающими шагами», изолированностью
или обобщённостью, свободностью или последовательностью и т.д.
Логика создания эффективных проверок
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Достарыңызбен бөлісу: