Тест характеристики - Characterization test

В компьютерное программирование, а характеристический тест (также известный как Золотой Мастер Тестирование[1]) является средством описания (характеристики) действительный поведение существующего программного обеспечения, и, следовательно, защитить существующее поведение устаревший код от непреднамеренных изменений через автоматизированное тестирование. Этот термин был придуман Майклом Фезерсом.[2]

Обзор

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

В Джеймс Бахс и классификация тестовых оракулов Майкла Болтона,[3] такая проверка соответствует историческому оракулу. В отличие от обычного подхода утверждения -основан тестирование программного обеспечения результат теста определяется не отдельными значениями или свойствами (которые проверяются с помощью утверждений), а путем сравнения сложного результата тестируемого программного процесса в целом с результатом того же процесса в предыдущем версия программного обеспечения. В некотором смысле тестирование характеристик инвертирует традиционное тестирование: традиционные тесты проверяют отдельные свойства (белые списки их), где тестирование характеристик проверяет все свойства, которые не были удалены (занесенный в черный список ).

При создании характеризационного теста необходимо наблюдать, какие выходы имеют место для данного набора входов. Учитывая наблюдение, что унаследованный код дает определенный вывод на основе заданных входных данных, можно написать тест, который утверждает, что выходные данные унаследованного кода соответствуют наблюдаемому результату для заданных входных данных. Например, если кто-то видит, что f (3.14) == 42, то это можно создать как характеристический тест. Затем, после модификаций системы, тест может определить, вызвали ли модификации изменения результатов при одинаковых входных данных.

К сожалению, как и в случае с любым другим тестированием, обычно невозможно создать характеристический тест для всех возможных входных и выходных данных. Таким образом, многие люди выбирают либо заявление, либо покрытие ветки. Однако даже это может быть сложно. Составители тестов должны использовать свое суждение, чтобы решить, какой объем тестирования подходит. Часто бывает достаточно написать тесты характеристик, которые охватывают только определенные входы и выходы, которые, как известно, происходят, с уделением особого внимания крайним случаям.

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

Одним из интересных аспектов характеризационных тестов является то, что, поскольку они основаны на существующем коде, можно автоматически генерировать некоторые характеризационные тесты. Инструмент автоматизированного тестирования характеристик будет проверять существующий код с широким диапазоном соответствующих и / или случайных входных значений, записывать выходные значения (или изменения состояния) и генерировать набор тестов характеризации. Когда сгенерированные тесты выполняются для новой версии кода, они генерируют один или несколько сбоев / предупреждений, если эта версия кода была изменена таким образом, чтобы изменить ранее установленное поведение.

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

Преимущества

Тестирование Golden Master имеет следующие преимущества перед традиционным тестированием программного обеспечения на основе утверждений:

  • Это относительно легко реализовать для сложных унаследованные системы.
  • Таким образом, возможен рефакторинг.
  • Обычно это разумный подход для сложных результатов, таких как PDF-файлы, XML, изображения и т. д., где проверка всех соответствующих атрибутов с утверждениями будет неощутимой из-за количества атрибутов и приведет к нечитаемым /неподдерживаемый тестовый код.

Недостатки

Тестирование Golden Master имеет следующие недостатки по сравнению с традиционным тестированием программного обеспечения на основе утверждений:

  • Это зависит от повторяемость. Неустойчивые и недетерминированные значения должны быть замаскированный / удален, как из Золотого Мастера, так и из результата процесса. Если необходимо удалить слишком много элементов или удалить их слишком сложно, это может сделать тестирование Golden Master непрактичным.
  • Это зависит не только от повторяемости программного обеспечения, но и от стабильности среды и входных значений.
  • Тестирование Golden Master не предполагает правильности результатов. Он просто помогает обнаруживать нежелательные последствия изменений программного обеспечения.

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

  1. ^ "Дж. Б. Рейнсбергер - Кодекс выживания с Золотым Мастером и Сэмплингом". Получено 2017-05-30.
  2. ^ Перья, Майкл С. Эффективная работа с устаревшим кодом (ISBN  0-13-117705-2).
  3. ^ Болтон, Майкл (январь 2005 г.). «Тестирование без карты» (PDF). Лучшее программное обеспечение. Sticky Minds / TechWell. Получено 2017-05-30.

внешняя ссылка