 | Эта статья требует дополнительных ссылок для проверки . ( ноябрь 2019 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон ) |
В программной инженерии , тест дизайн является деятельностью извлечения и определения тестовых случаев от условий испытаний для тестового ПО .
Определение [ править ]
Условие тестирования - это утверждение об объекте тестирования. Условия тестирования могут быть указаны для любой части компонента или системы, которая может быть проверена: функций, транзакций, функций, атрибутов качества или структурных элементов.
Основная проблема разработки тестов состоит в том, что существует бесконечное множество различных тестов, которые вы можете запустить, но не хватает времени, чтобы запустить их все. Необходимо выбрать подмножество тестов; достаточно мал для запуска, но достаточно хорошо выбран, чтобы тесты находили ошибку и предоставляли другую информацию, связанную с качеством. [1]
Дизайн тестов - одна из важнейших предпосылок качества программного обеспечения. Хороший дизайн теста поддерживает:
- определение и улучшение процессов и процедур, связанных с качеством ( обеспечение качества );
- оценка качества продукта в соответствии с ожиданиями и потребностями клиентов ( контроль качества );
- поиск дефектов в продукте (тестирование программного обеспечения).
Существенными предпосылками разработки теста являются: [2]
- Соответствующая спецификация (тестовые базы).
- Анализ рисков и сложности.
- Исторические данные ваших предыдущих разработок (если есть).
Базы тестирования, такие как требования или пользовательские истории, определяют, что следует тестировать (тестовые объекты и условия тестирования). Базы тестирования включают в себя некоторые методы проектирования тестов, которые следует использовать или не использовать.
Анализ рисков неизбежно определяет тщательность тестирования. Чем выше риск использования функции / объекта, тем более тщательное тестирование необходимо. То же самое можно сказать и о сложности. Анализ рисков и сложности определяет методы проектирования тестов, которые будут применяться для данной спецификации.
Исторические данные о ваших предыдущих разработках помогают установить лучший набор методов проектирования тестов для достижения оптимальной стоимости и высокого качества вместе. В отсутствие исторических данных можно сделать некоторые предположения, которые следует уточнить для последующих проектов.
На основе этих предпосылок может быть реализована оптимальная стратегия разработки тестов.
Результатом разработки теста является набор тестовых примеров, основанный на спецификации. Эти тестовые примеры могут быть разработаны до начала реализации и должны быть независимыми от реализации. Первый способ тестирования очень важен, так как эффективно поддерживает предотвращение дефектов. На основе приложения и текущего тестового покрытия могут быть созданы дополнительные тестовые примеры (но это не дизайн теста).
На практике для сложных спецификаций следует применять больше методов проектирования тестов.
В целом, дизайн теста не зависит от экстраординарных (почти магических) навыков человека, создавшего тест, а основан на хорошо понятых принципах. [3]
Автоматический тестовый дизайн [ править ]
Целые наборы тестов или тестовые примеры, выявляющие реальные ошибки, могут быть автоматически сгенерированы программным обеспечением с использованием проверки модели или символьного выполнения . [4] Проверка модели может гарантировать выполнение всех путей простой программы, в то время как символьное выполнение может обнаруживать ошибки и генерировать тестовый пример, который выявит ошибку при запуске программного обеспечения с использованием этого тестового примера.
Однако, каким бы хорошим ни был автоматический дизайн тестов, он подходит не для всех обстоятельств. Если сложность становится слишком высокой, тогда в игру должен вступить человеческий тест, поскольку он гораздо более гибкий и может сконцентрироваться на создании наборов тестов более высокого уровня.
Ссылки [ править ]
- ^ Дизайн теста: рабочая тетрадь BBST , Джем Канер и Ребекка Л. Фидлер, июль 2016 г.
- ^ Практический дизайн тестов: Выбор традиционных и автоматизированных методов проектирования тестов , Иштван Форгач и Аттила Ковач, август 2019 г.
- ↑ Практическое руководство по разработке тестов программного обеспечения , Ли Коупленд, январь 2004 г.
- ^ KLEE: Автоматическая генерация тестов с высоким уровнем охвата для сложных системных программ , Кристиан Кадар, Дэниел Данбар, Доусон Энглер из Стэнфордского университета , 2008 г.
