Особенности индустриального тестирования

Подходы к разработке тестов

Рассмотрим разные подходы к разработке тестов, два к выбору тестовых данных и два к реализации тестового кода.

Тестирование спецификации

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

Пример использования спецификации требований для разработки тестов.

Пусть задан следующий фрагмент набора требований для модели обмена транзакциями:

1. Функция DoTransaction должна принимать адрес и данные в соответствии с параметрами, создавать в очереди новый элемент, заполнять его адресную часть и часть полей данных переданной информацией и инициировать транзакцию
2. Функция DoAddressTenure должна принимать адрес в соответствии с параметрами, создавать в очереди новый элемент и заполнять его адресную часть
3. Функция DoDataTenure должна принимать данные в соответствии с параметрами, находить в очереди первый элемент с частично незаполненными полями данных, дополнять его переданной информацией и инициировать транзакцию

Концептуальное описание набора тестов, проверяющего спецификацию, может выглядеть следующим образом:

1. Вызвать DoTransaction с адресом и данными. Проверить появление в очереди еще одного элемента. Проверить появление на шине транзакции с правильными адресом и данными.
2. Вызвать DoAddressTenure с адресом. Проверить появление в очереди еще одного элемента. Проверить отсутствие новой транзакции на шине.
3. Вызвать DoDataTenure с данными. Проверить заполнение полей данных. Проверить появление на шине транзакции с правильными адресом и данными

Тестирование сценариев

Разработка тестов, основанных на использовании сценариев, осуществляется по следующей методике:

1. Определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.

Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.

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

Пример использования спецификации требований для разработки тестов.

Так, для рассмотренного выше примера возможно создание следующего сценария и тестов.

1. Сценарий: пользователь имеет две независимые нити управления, одна из которых отвечает за генерацию полных транзакций посредством DoTransaction, а другая – за сбор транзакций из адресной части и части данных, когда эта информация приходит из разных источников. Таким образом, вторая нитка использует вызовы к DoAddressTenure и DoDataTenure.
2. Описание тестов: Вызвать DoAddressTenure c адресом А1, вызвать DoTransaction с адресом А2 и данными D2, вызвать DoDataTenure с данными D1. Проверить последовательное появление на шине двух транзакций: {А1, D1} и {А2, D2}

При выполнении этого теста было, в частности, обнаружено, что функция DoTransaction была реализована через вызовы к DoAddressTenure и DoDataTenure, что приводило к появлению на шине транзакций вида {А1, D2} и {А2, D1}. Подобный дефект может быть обнаружен с большим трудом, если разрабатывать тесты, основываясь только на спецификации требований.

Ручная разработка тестов

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

Генерация тестов

В настоящее время некоторые языки спецификаций, используемые для описания алгоритмов тестирования, могут быть использованы для генерации тестового кода. Рассмотрим генерацию кода из языка MSC. Тест, описанный выше, формализован на языке MSC (Рис. 9.3). Здесь каждая стрелка с пометкой DoTransaction, DoAddressTenure или DoDataTenure представлет собой вызов соответствующей функции продукта с передачей параметров. Стрелка checkTr соответствует проверке прохождения по шине транзакции с соответствующими параметрами. Каждая из стрелок диаграммы генератором тестов преобразуется в исполнимый код, при этом стрелкам, представляющим собой вызовы функций может соответствовать достаточно простой и маленький участок кода, вызывающий соответствующую функцию и проверяющий ее выходное значение на наличие ошибок.

Рис. 9.3. Формальная запись сценарного теста на MSC

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

В результате в рассматриваемом примере выигрыш от применения генерационного подхода достигается в основном за счет использования наглядного визуального представления тестов, что может быть нивелировано затратами на создание генерационного сценария на MSC.

Возможна куда более эффективная формализация MSC сценария для генерации тестов. Рис. 9.4 представляет другой способ формализации для теста, выполняющего те же самые проверки.

Рис. 9.4. Формальная запись сценарного теста на MSC с использованием параллелизма.

В MSC на Рис. 9.4 проверки транзакций сгруппированы с порождающими их вызовами в отдельные фрагменты, а параллелизм, используемый при исполнении фрагментов, задан через Par – формальную конструкцию, применяемую для изображения параллелизма в языке MSC. При генерации тестов по диаграмме Рис. 9.4 тестовый генератор перебирает все возможные и неповторяющиеся варианты вызова тестируемых функций, сохраняя при этом корректность порядка проверок, что в данном примере дает три сгенерированных теста. Несложно видеть, что затраты на создание диаграммы Рис. 9.4 не сильно отличаются от затрат на диаграмму Рис. 9.3, в то время как количество тестов увеличивается в три раза.

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