Методическая основа технологии

Уточнение (специализация) типов.
Если при нормальном вызове операции в качестве ее аргумента может быть использовано только значение из определенного множества, для соответствующего параметра определяется специализированный тип-перечисление, значениями которого являются элементы этого множества.
• 
  Если при нормальном вызове операции в качестве ее аргумента (или объекта вызова, если эта операция является методом класса) можно использовать лишь значение, являющееся результатом другой операции, то определяется специализированный тип, который одновременно указывается как тип данного аргумента первой операции и как тип результата второй операции.
• 
  Если при нормальном вызове операции в качестве ее аргумента (или объекта вызова, если эта операция является методом класса) можно использовать лишь значение, для которого предварительно были вызваны некоторые другие операции, для соответствующего параметра определяется специализированный тип, с которым связывается программный код инициализации его значения с помощью необходимых операций.
• 
  В тех случаях, когда использование аргумента (или объекта вызова) предполагает последующее освобождение ресурсов, с его специализированным типом связывается код финализации его значения, выполняющий это освобождение.
• 
  Для описания действий по инициализации и финализации отдельных объектов данного типа иногда требуется ввести вспомогательные операции, которые должны быть один раз определены в каждом тесте, где используется такой тип. Такой код также оформляется как дополнительный атрибут специализированного типа.
• 
  При уточнении типов параметров иногда несколько параметров объединяются в один абстрактный объект, разные элементы которого используются в качестве их значений, и определяется специализированный тип такого составного объекта.
  Например, если параметрами операции являются указатель на начало строки типа char* и ее длина, можно определить специализированный тип «строка». Вместо первого параметра тогда нужно задавать указатель на первый элемент строки, а вместо второго — результат применения функции strlen() к этому указателю.
  При создании таких комплексных специализированных типов определяется код для получения значений отдельных параметров из комплексного объекта.
• 
  
  Если при нормальной работе операции ее результат всегда удовлетворяет некоторым ограничениям, например, возвращается непустой список или возвращается целое число, большее 0, для ее результата определяется специализированный тип, связанный с соответствующим ограничением.
• 
  
  При уточнении типов связи между операцией и исходным типом ее параметра или результата в базе данных дополняются аналогичными связями с соответствующим уточненным типом.
• 
  
  Каждый раз при необходимости введения специализированного типа разработчики анализируют уже имеющиеся специализированные типы, чтобы по возможности использовать повторно уже имеющееся определение типа с нужным набором ограничений.

В начало теста вставляется код инициализации для работы данной операции.
• 
  
  Затем строятся значения всех ее параметров. Для каждого типа аргумента вычисляется значение его порождающего типа (базового типа для указателей, ссылок и пр.), которое затем преобразуется в значение аргумента.
  
  
  Если значение типа определено явно, используется это значение.
  • 
    
    Если для вычисления значения нужно вызвать другую операцию, конструктор или выполнить инициализирующий код, вставляется вызов этой операции или соответствующий код. При этом значения параметров вызываемых в этом коде операций либо фиксированы, либо вычисляются по аналогичной процедуре.
    Определения вспомогательных операций, необходимых для построения значений, при этом вставляются в начало теста.
  • 
    
    Значения других типов строятся автоматически. Для примитивных типов (числа, символы, строки) используются некоторые простые генераторы значений. Значения производных типов — указателей, ссылок, массивов и пр. — строятся из значений их базовых типов. Для перечислений используется первое возможное значение. Объекты структурных типов строятся по их полям, причем поля заполняются по этой же процедуре.
  
  
  Вставляется вызов тестируемой операции с построенными аргументами.
• 
  
  Затем вставляется код финализации для всех построенных значений, для которых это необходимо.
• 
  
  В конце вставляется код финализации после работы тестируемой операции.
• 
  
  Для всех вызовов операций, использованных в коде, вставляются проверки ограничений на их результаты, указанные в соответствующих специализированных типах. Кроме того, для всех указателей, которые возникают при вызовах и используются в дальнейшем, проверяется их неравенство NULL.

Организация работ по технологии Azov

Разбиение набора операций на функциональные группы.
Интерфейс системы делится на группы операций, работающих с одними и теми же внутренними данными, и предоставляющих полный набор действий над ними. Это необходимо, прежде всего, для разбиения работ на достаточно независимые части, каждую из которых может выполнять отдельный разработчик.
• 
  Уточнение информации об интерфейсных операциях в базе данных.
  На этом этапе разработчики анализируют документацию на операции выделенных им групп, определяя условия их нормальной работы и ограничения на их результаты при такой работе. Дополнительная выявляемая при этом информация заносится в базу данных в виде специализированных типов параметров и результатов операций, возможных значений этих типов, а также в виде действий, необходимых для инициализации или уничтожения данных такого типа или же для инициализации или финализации внутренних данных системы, необходимых для нормальной работы операций.
  В ходе работы применяется методика уточнения данных, представленная ниже.
  Для заполнения базы данных используются вспомогательные инструменты, например, использующие Web-интерфейс и позволяющие осуществлять навигацию по базе данных, поиск в ней разнообразной дополнительной информации и редактирование уточняемых данных.
  Перед проведением уточнения необходимо упорядочить тестируемые операции и типы данных, связанные с ними так, чтобы операции, имеющие более сложные типы параметров, шли позже тех, которые имеют простые параметры и могут быть использованы для получения данных более сложных типов.
  При этом уточнение выполняется от простых операций к более сложным без необходимости часто переключаться на анализ других операций и может естественным образом многократно использовать на поздних этапах информацию, выявленную на ранних.

Пример построения тестов по технологии Azov

int XSetScreenSaver(Display*, int, int, int, int) — устанавливает режим работы хранителя экрана для заданного дисплея.
• 
  int XGetScreenSaver(Display*, int*, int*, int*, int*) — возвращает текущие параметры работы хранителя экрана для данного дисплея, значения возвращаются по параметрам-указателям, соответствующим параметрам предыдущей функции.
• 
  int XForceScreenSaver(Display*, int) — активирует или дезактивирует хранитель экрана для заданного дисплея в зависимости от указанного второго параметра.
• 
  int XActivateScreenSaver(Display*) — активирует хранитель экрана для заданного дисплея.
• 
  int XResetScreenSaver(Display*) — дезактивирует хранитель экрана для заданного дисплея.

Второй и третий параметры функции XSetScreenSaver() являются интервалами времени в секундах, определяющими режим работы хранителя экрана. Можно ввести для них тип TimeIntervalInSeconds, определив для него возможное корректное значение 1. Второй и третий параметры XGetScreenSaver() являются указателями на этот же тип.
• 
  Четвертый и пятый параметры XSetScreenSaver(), а также второй параметр XForceScreenSaver() имеют на самом деле перечислимые типы, определяющие возможные режимы работы или активации/дезактивации хранителя экрана. Для них можно ввести типы, соответственно, BlankingMode, ExposuresMode
  и ForceMode. Корректные значения для них четко определены в тексте стандарта — это, соответственно, {DontPreferBlanking, PreferBlanking, DefaultBlanking}, {DontAllowExposures, AllowExposures, DefaultExposures} и {Active, Reset}. Четвертый и пятый параметры XGetScreenSaver() являются указателями на типы BlankingMode
  
  В качестве значений интервала времени в секундах используется 1.
• 
  В качестве значений специализированных типов BlankingMode, ExposuresMode
  и ForceMode
  используются, соответственно, значения DontPreferBlanking, DontAllowExposures и Active.
• 
  Результаты работы всех функций проверяются на равенство BadValue, если результат оказывается равен этому значению, выдается сообщение об ошибке.
• 
  Кроме того, корректность результатов, возвращаемых по указателям функцией XGetScreenSaver() через ее 4-й и 5-й параметры, можно проверять сравнением их с возможными значениями специализированных перечислимых типов BlankingMode
  и ExposuresMode.

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

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

  Источник данных для проверки	Нет проверок	Требование отсутствия исключений и серьезных сбоев	Ограничения типов данных	Ограничения на одну операцию	Совместные ограничения для нескольких операций
  Источник тестовых воздействий
  Синтаксис сигнатур и/или разбиение входных данных	Методы и инструменты генерации тестов на основе покрывающих наборов[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].
  
  
  

  Технология автоматизации создания тестов работоспособности

  
  Для тех случаев, когда интерфейс системы очень велик (состоит из тысяч различных операций) и большая часть информации об элементах этого интерфейса хранится в хорошо структурированном, подходящем для автоматической обработки виде, можно предложить достаточно эффективную технологию автоматизации построения тестов работоспособности, позволяющую создавать их массово, в большом количестве. Такая технология, названная Azov, была разработана в 2007 году в Институте системного программирования РАН.
  Эта технология существенно использует базу данных с информацией об операциях тестируемой системы и предполагает некоторое уточнение этой информации, в основном сводящееся к уточнению (специализации) типов параметров операций и их результатов. Такое уточнение выполняется вручную и позволяет в дальнейшем полностью автоматически построить корректные входные данные для каждой операции и проверить некоторые свойства ее результата.
  Технология Azov включает следующие элементы.
  
  Методика уточнения данных об интерфейсных операциях.
  • 
    База данных с расширенной информацией о тестируемых операциях.
  • 
    Инструменты, использующиеся для внесения дополнительной информации в базу данных операций.
  • 
    Компоновщик тестов работоспособности, автоматически генерирующий набор тестов для выделенного множества операций по имеющейся в базе информации.
  
  Основная идея технологии следующая: информация о типах параметров и результатов тестируемых операций уточняется таким образом, чтобы позволить сгенерировать значения параметров для простейших сценариев нормального использования этих операций и выполнить некоторые (далеко не полные) проверки корректности их результатов. Поскольку одни и те же типы данных в больших системах используются многократно, массовая генерация тестов может привести к существенному снижению трудозатрат на каждый тест.
  
  
  

  Автоматизация создания тестов обычно основана

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

  ---