4. Сопоставление с другими подходами к автоматизации создания тестов

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

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

Можно выделить следующие источники для построения тестовых данных, тестовых воздействий и их последовательностей.

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

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

Источник данных для проверки	Нет проверок	Требование отсутствия исключений и серьезных сбоев	Ограничения типов данных		Ограничения на одну операцию	Совместные ограничения для нескольких операций
Источник тестовых воздействий
Синтаксис сигнатур и/или разбиение входных данных	Методы и инструменты генерации тестов на основе покрывающих наборов [11]
Структура типов	OTK/Pinery [12,13]	Инструменты Parasoft (Jtest, C++test, .TEST [14]) Ограничения в виде утверждений, постусловий и инвариантов
		JCrasher [15]
		Azov
Связи по типам
	Методы генерации структурных тестов на основе генетических алгоритмов [16-18]
Структура потока управления		CodeScroll API Tester, Suresoft Technologies [19]
	Методы генерации структурных тестов с использованием разрешения ограничений (constraint solving) [20,21]
Ограничения типов данных	Pinery [13]	Azov Ограничения в виде инвариантов данных типа и действий по корректному построению этих данных		T-VEC Test Vector Generation System [22] Ограничения в виде постусловий и инвариантов
Ограничения на одну операцию
					Lurette [23]
Совместные ограничения для нескольких операций
			Методы и инструменты генерации тестов на основе автоматных моделей, включая Stateflow, Statecharts, SDL, LOTOS, Lustre или специализированные нотации [24,25]
			UniTESK [26]

Таблица 2. Классификация подходов к автоматическому построению тестов.

Классификация имеющихся на рынке инструментов, а также ряда исследовательских методов, использующих автоматическую генерацию тестов, на основе выполняемых проверок и видов данных, используемых для построения тестов, показана в Табл. 2. Технология Azov в этой таблице попадает сразу в несколько клеток, поскольку сочетает при генерации тестов использование структуры типов, связей по типам, действий по инициализации данных типа и (иногда) специфических действий по инициализации системы перед использованием определенной операции. Для проверок используются ограничения типов результатов и фактор отсутствия сбоев при вызове тестируемой операции.

Заметим, что кроме технологии Azov связи по типам используются при генерации тестов только рядом методов построения структурных тестов на основе генетических алгоритмов [19-21].

5. Дальнейшее развитие технологии

Дальнейшее развитие технологии Azov возможно по нескольким направлениям.

• Расширение возможностей повторного использования.
  В данный момент специализированные типы представляют собой практически единственный вид элементов технологии, которые можно использовать многократно. Для расширения таких возможностей можно определить механизмы, позволяющие повторно использовать ограничения типов, позволив таким образом создавать типы, уточняющие другие специализированные типы и наследующие все их ограничения.
• Увеличение качества и полноты тестов.
  Тестирование работоспособности предполагает однократный вызов каждой из тестируемых операций и проверку только некоторых базовых ограничений. Однако предложенную технологию достаточно просто расширить так, чтобы создаваемые тесты обладали большей полнотой и более аккуратно проверяли тестируемую систему.
  • Добавление дополнительных ограничений.
    В настоящий момент проверяются ограничения, применимые только при одном из простейших сценариев использования. Можно ввести более сложные проверки за счет введения дополнительных ограничений и условий на входные параметры, при которых эти ограничения должны проверяться.
  • Использование нескольких наборов параметров.
    Для более тщательного тестирования можно использовать не по одному значению каждого параметра, а строить различные их наборы, перебирая некоторое множество значений для каждого параметра. Множества значений типов можно указывать как простым перечислением этих значений в базе, так и определением некоторых шаблонов построения таких значений, в свою очередь имеющих некоторые параметры. Во втором случае для построения конкретного значения по шаблону с параметрами можно использовать процедуру выбора значений параметров, реализуемую компоновщиком тестов.
  • Добавление различных сценариев использования.
    При тестировании работоспособности операции вызываются в наиболее простых сценариях их использования. Однако даже часто возникающих сценариев использования операции бывает несколько, иногда для граничных значений параметров операция должна демонстрировать специфическое поведение. Кроме того, большинство операций должно правильно реагировать на некорректно заданные параметры.
    Для добавления поддержки различных сценариев использования необходимо уметь задавать набор сценариев или режимов работы операции и для каждого режима определять соответствующие специализированные типы параметров и специфические ограничения на результаты работы.
  • Построение тестовых последовательностей.
    Для операций, поведение которых зависит от внутреннего состояния системы, можно увеличить качество и количество создаваемых тестов за счет автоматического добавления перед вызовом операции обращений к другим операциям, изменяющих те внутренние данные, от которых зависит работа этой операции.
• Создание тестов совместимости.
  Описанная технология может использоваться для создания тестов совместимости нескольких библиотек, если объекты вызова и аргументы вызова тестируемых операций из одной библиотеки в тестах получать как результаты вызовов операций из других библиотек.
• Использование представленной методики уточнения при быстрой разработке программного обеспечения.
  Методику уточнения информации об операциях можно использовать при разработке программного обеспечения не только для создания тестов. Поскольку база данных с исходной информацией об операциях системы может быть достаточно просто получена как побочный результат компиляции, эта методика может быть основой контроля качества, анализа и уточнения проектных решений, создания проектной документации при быстрой разработке программных систем.
  Работа может быть построена на основе ежедневных сборок: база данных с информацией о системе, собранной в предыдущий вечер наутро поступает для уточнения и анализа. Выявленная при таком анализе за день информация о дополнительных ограничениях на типы параметров и результатов далее согласовывается с проектировщиками и может использоваться для уточнения и исправления ошибок проектирования и для создания проектной документации.
  При этом, однако, важно иметь специальные механизмы распознавания и интеграции изменений базы по сравнению с предыдущей версией.

6. Заключение

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

В данной статье представлена технология Azov автоматизации разработки тестов работоспособности, созданная в Институт системного программирования РАН. Для ее применимости достаточно иметь базу данных, где информация об операциях системы представлена в хорошо структурированном виде, и документацию с описанием базовой функциональности этих операций. Можно заметить, что любой компилятор в принципе способен выдать такую базу данных в качестве побочного результата своей работы.

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

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