Дизайн теста - Test design

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

Определение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ Дизайн теста: рабочая тетрадь BBST, Джем Канер и Ребекка Л. Фидлер, июль 2016 г.
  2. ^ Практический дизайн тестов: выбор традиционных и автоматизированных методов разработки тестов., Иштван Форгач и Аттила Ковач, август 2019 г.
  3. ^ Практическое руководство по разработке тестов программного обеспечения Ли Коупленд, январь 2004 г.
  4. ^ KLEE: автоматическое создание тестов с широким охватом для сложных системных программ без посторонней помощи, Кристиан Кадар, Даниэль Данбар, Доусон Энглер из Стэндфордский Университет, 2008