2.5. Инструментальная поддержка

Работа по описываемой технологии поддерживается с помощью следующих инструментов.

• База данных с уточненной информацией о тестируемых операциях.

• Инструмент для редактирования информации в базе.

• Компоновщик тестов, строящий тесты работоспособности по этой информации.

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

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

Для автоматической генерации тестов используется компоновщик тестов, реализующий процедуру построения теста, описанную в разделе 2.3. Методическая основа технологии.

Схема основных таблиц базы данных, используемой для хранения как исходной, так и уточненной информации о тестируемых операциях, приведена на Рис. 3.

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

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

• Для каждой тестируемой операции:

  • ее имя;

  • ссылка на тип результата (если этот тип не равен void);

  • ссылка на класс, если эта операция — метод класса;

  • для методов классов — флаги, указывающие, что это статический, чисто виртуальный, конструктор, деструктор или обычный метод, а также доступность метода (public, protected).

• Для каждого параметра одной из тестируемых операций:

  • ссылка на операцию;

  • номер параметра;

  • ссылка на тип параметра.

• Для каждого типа:

  • его имя;

  • разновидность типа — примитивный ли это тип, перечисление, класс, структура, объединение, шаблон, экземпляр шаблона, указатель, алиас (определенный с помощью typedef), константный тип (тип const T для некоторого другого T), тип ссылки, функциональный указатель и др.;

  • ссылка на базовый тип для указателей, ссылочных типов, константных типов и других аналогичных производных типов.

Рисунок 3. Основные таблицы базы данных с информацией о тестируемых операциях.

Дополнительные таблицы базы данных содержат следующую информацию.

• В ходе уточнения создается набор специализированных типов, данные которых должны удовлетворять дополнительным ограничениям. Такие типы описываются в таблице TGSpecType. Для каждого специализированного типа указывается следующее.

  • Имя — оно не используется в каком-либо коде и нужно только для удобства ссылок на данный тип, в частности, для поддержки возможности использовать один и тот же специализированный тип для параметров и результатов нескольких операций.

  • Ссылка на исходный тип, который уточняется данным типом. Например, если для параметра, обозначающего интервал времени в секундах в тестируемой системе используется тип int, можно определить специализированный тип «временной интервал, измеряемый в секундах», для которого исходным типом будет int.

  • Ссылка на базовый специализированный тип для указателей, ссылочных типов, константных типов и других аналогичных производных типов.

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

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

• InitCode — набор действий, которые нужно выполнить над объектом или значением исходного, не специализированного типа, чтобы получить объект или значение специализированного типа.

• FinalCode — набор действий, которые нужно выполнить, чтобы освободить ресурсы, занятые при создании объекта или значения специализированного типа.

• NormalResult — код, который нужно выполнить, чтобы проверить корректность возвращенного какой-либо операцией значения данного специализированного типа.

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

• При уточнении типов может быть уточнен тип результата операции или тип объекта, в котором эта операция вызывается как метод. Для указания этих данных об операциях используется таблица TGInterface и ее поля TGIspecreturn и TGIspecobjecttype.
  Кроме того использование операции в нормальном режиме может потребовать некоторых действий по инициализации внутренних данных системы и захвату ресурсов до вызова, а также действий по освобождению этих ресурсов после вызова. Код этих действий заносится в поля TGISpreamble и TGISfinalization дополнительной таблицы TGInterfaceSupplement, вместе с ссылкой на уточняемую операцию.

• Для поддержки комплексных специализированных типов связь параметра с его специализированным типом опосредуется двумя промежуточными таблицами — таблицей TGParameter, содержащей ссылки на исходные параметры и на получаемые таким образом комплексы, и таблицей комплексов TGParameterProxy. Для каждого комплекса указывается набор параметров, из которых он состоит, ссылка на специализированный тип комплекса и код для получения значений отдельных параметров.

3. Использование предложенной технологии на практике

Технология Azov была применена для построения тестов работоспособности библиотеки Qt версии 3 [9], предназначенной для разработки переносимых приложений с графическим интерфейсом пользователя и входящей в состав стандарта Linux Standard Base (LSB, [3]).

Стандарт LSB включает 10873 доступных для проверки (public или protected) методов, конструкторов и деструкторов классов Qt 3. Информация о них в структурированном виде представлена в базе данных стандарта, находящейся в открытом доступе [10], как и информация обо всех операциях, входящих в этот стандарт.

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

Операции были разбиты на группы по классам, методами которых они являются. Поскольку классов Qt тоже довольно много (около 400), они также были разделены на несколько групп в соответствии с их основной функциональностью.

В ходе уточнения было определено 1665 специализированных типов, и для 36 операций были добавлены описания действий по инициализации и финализации. Ряд показателей использования специализированных типов приведен в Табл. 1. Около половины специализированных типов используются повторно, а некоторые — очень много раз. Из таблицы видно также, что примерно в 50% случаев параметры и объекты вызова генерируются автоматически, без использования явно указанных значений специализированных типов.

Разработка тестов для Qt вместе с разработкой инструментов, поддерживающих технологию Azov, силами 3-х человек заняла около 4-х месяцев. При этом в начале проекта значительная часть усилий тратилась на разработку и отладку инструментов. На конечной фазе проекта, когда инструменты были уже отлажены, каждый разработчик в день создавал тесты для 80-100 функций, с учетом затрат времени на анализ документации, уточнение данных, генерацию, компиляцию и отладку получаемых тестов. Это существенно больше, чем 3-8 функций в день, обрабатываемых при традиционной ручной разработке тестовых вариантов. Причиной такого повышения производительности являются, прежде всего, широкое и многократное использование специализированных типов и его инструментальная поддержка при проведении уточнения данных о тестируемых операциях.

		Количество	Исходные типы
Максимальное количество использований специализированного типа		513	bool (специализированный тип — тип параметров, принимающих значение true)
Количество специализированных типов, использованных	400 и более раз	3	bool, int
	200-399 раз	5	bool, int, char*, QWidget*
	100-199 раз	16	—
	10-99 раз	225	—
	2-9 раз	556	—
Общее количество специализированных типов		1665	—
Количество использований специализированных типов как типов параметров или объектов вызова		11503	—
Количество использований всех типов как типов параметров или объектов вызова		22757	—

Таблица 1. Показатели использования специализированных типов.

В результате были получены тесты для 10803 функций и методов из 10873. 70 методов (0.6%) не было протестировано по одной из следующих причин.

• Методы класса QSessionManager не могут быть вызваны обычным образом, поскольку библиотека Qt 3 не позволяет как-либо создать объект этого класса. Такой объект может использоваться только в рамках переопределяемого метода финализации приложения, который вызывается средой Qt3 автоматически в конце работы приложения.

• Некоторые конструкторы и деструкторы, предназначенные для вызовов только для объектов самого этого класса, а не его наследников, определены для абстрактных классов. Выполнить вызов такого конструктора или деструктора средствами языка C++ не удается.

• Несколько методов классов Qt 3 попали в стандарт LSB, хотя не предназначены для использования извне библиотеки.

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

При выполнении полученных тестов на одной из реализаций Qt 3 было выявлено около 10 различных ошибок в самой реализации библиотеки, несмотря на то, что все тесты представляют собой простейшие сценарии работы с методами ее классов.

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