Тестовый дизайн

В обеспечения разработке программного проектирование тестов — это деятельность по созданию и определению тестовых примеров от условий тестирования до тестируемого программного обеспечения .

Определение

Условие тестирования — это утверждение о тестируемом объекте. Условия тестирования могут быть установлены для любой части компонента или системы, которая может быть проверена: функций, транзакций, свойств, атрибутов качества или структурных элементов.

Фундаментальная проблема проектирования тестов заключается в том, что существует бесконечное множество различных тестов, которые можно запустить, но времени на их все не хватает. Необходимо выбрать подмножество тестов; достаточно маленький для запуска, но достаточно хорошо выбранный, чтобы тесты находили ошибки и предоставляли другую информацию, связанную с качеством. ^[1]

Проектирование тестов является одной из важнейших предпосылок качества программного обеспечения. Хороший дизайн тестов поддерживает:

определение и улучшение процессов и процедур, связанных с качеством ( обеспечение качества );
оценка качества продукта с учетом ожиданий и потребностей клиентов ( контроль качества );
поиск дефектов в продукте (тестирование программного обеспечения).

Существенными предпосылками тест-дизайна являются: ^[2]

Соответствующая спецификация (тестовые базы).
Анализ рисков и сложности.
Исторические данные ваших предыдущих разработок (если существуют).

Базы тестирования, такие как требования или пользовательские истории, определяют, что следует тестировать (объекты тестирования и условия тестирования). Базы тестирования включают в себя некоторые методы проектирования тестов, которые следует использовать или не использовать.

Анализ рисков неизбежен для принятия решения о тщательности тестирования. Чем больше риска связано с использованием функции/объекта, тем более тщательное тестирование необходимо. То же самое можно сказать и о сложности. Анализ рисков и сложности определяет методы проектирования тестов, которые следует применять для данной спецификации.

Исторические данные о ваших предыдущих разработках помогают выбрать лучший набор методов проектирования тестов для одновременного достижения оптимальных затрат и высокого качества. При отсутствии исторических данных можно сделать некоторые предположения, которые необходимо уточнить для последующих проектов.

На основе этих предварительных условий может быть реализована оптимальная стратегия проектирования тестов.

Результатом проектирования тестов является набор тестовых случаев, основанных на спецификации. Эти тестовые примеры могут быть разработаны до начала реализации и должны быть независимыми от реализации. Первый способ проектирования тестов очень важен, поскольку эффективно способствует предотвращению дефектов. На основе приложения и текущего тестового покрытия могут быть созданы дополнительные тестовые сценарии (но это не проектирование тестов).

На практике для сложных спецификаций следует применять больше методов проектирования тестов.

В целом, разработка теста не зависит от исключительных (почти магических) навыков человека, создающего тест, а основана на хорошо понятных принципах. ^[3]

ISO/IEC/IEEE 29119-4:2015, часть 4, подробно описывает стандартные определения методов проектирования тестов. Сайт разработчиков тестов предлагает методологию LEA (Learn-Exercision-Apply) для поддержки эффективного обучения, отработки и применения методов. ^[4]

Автоматический дизайн теста

Целые наборы тестов или тестовые примеры, выявляющие реальные ошибки, могут автоматически генерироваться программным обеспечением с использованием проверки модели или символьного выполнения . Проверка модели может гарантировать выполнение всех путей простой программы, в то время как символическое выполнение может обнаружить ошибки и создать тестовый пример, который выявит ошибку при запуске программного обеспечения с использованием этого тестового примера.

Однако каким бы хорошим ни был автоматический дизайн тестов, он не подходит для всех обстоятельств. Если сложность становится слишком высокой, то в игру должен вступить человек, поскольку он гораздо более гибок и может сосредоточиться на создании наборов тестов более высокого уровня.

Ссылки

^ Проектирование тестов: Рабочая тетрадь BBST , авторы: Сем Канер и Ребекка Л. Фидлер, июль 2016 г.
^ Практический дизайн тестов: выбор традиционных и автоматизированных методов проектирования тестов , Иштван Форгач и Аттила Ковач, август 2019 г.
^ Руководство для практикующего специалиста по проектированию тестов программного обеспечения , Ли Коупленд, январь 2004 г.
^ Иштван, Форгач; Ковач, Аттила (2021). Смена парадигмы в тестировании программного обеспечения . Измерьте IT. ISBN 978-615-01-2781-1 .

[1] Проектирование тестов: Рабочая тетрадь BBST , авторы: Сем Канер и Ребекка Л. Фидлер, июль 2016 г.

[2] Практический дизайн тестов: выбор традиционных и автоматизированных методов проектирования тестов , Иштван Форгач и Аттила Ковач, август 2019 г.

[3] Руководство для практикующего специалиста по проектированию тестов программного обеспечения , Ли Коупленд, январь 2004 г.

[4] Иштван, Форгач; Ковач, Аттила (2021). Смена парадигмы в тестировании программного обеспечения . Измерьте IT. ISBN 978-615-01-2781-1 .

[1]

[2]

[3]

[4]