Процесс формализации требований и создания тестовых наборов

Технологический процесс создания тестов, используемый в работе Центра верификации ОС Linux, включает следующие основные стадии:

  1. декомпозиция стандарта на группы связанных функций;
  2. анализ стандарта и выделение требований для каждой группы;
  3. формализация проверяемых требований для каждой группы;
  4. разработка сценариев тестовых воздействий для каждой группы;
  5. автоматическая генерация тестов инструментами CTesK.

На этапе декомпозиции стандарта все интерфейсные элементы, описанные в стандарте, разбиваются на логически связанные группы функций. Каждая такая группа обычно состоит из операций и типов данных, связанных с определенным набором близких функций, и замкнута относительно обращения операций. Например, операции открытия и закрытия файлов, создания и удаления объектов нужно помещать в одну группу. Для 1532 функций стандарта LSB Core мы выделили 169 таких групп.

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


Рис. 1. Процесс разработки тестов на соответствие стандарту (упрощенно).

Этап анализа стандарта и выделения требований заключается в тщательном чтении текста стандарта разработчиком для идентификации атомарных требований. Обычно для каждой функции выделяется от одного до нескольких десятков требований. Каждому требованию присваивается идентификатор. В результате анализа формируется каталог требований стандарта, который представляет собой таблицу требований в виде {стандарт, идентификатор, текст требования} (пример для функции mkdir). Помимо формальной базы данных требований, в проекте формализации LSB мы нашли интересным способ представления каталога требований в виде размеченного в HTML текста стандарта.

Этап формализации требований начинается с отбора требований для проверки. Это необходимо, потому что далеко не все требования стандарта могут быть протестированы. Стандарт IEEE Std 2003.1 на методы тестирования стандартов POSIX (и основанный на нем ОСТ Минсвязи 115.009-2001) выделяет следующие причины, по которым утверждение стандарта может не проверяться:

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

Отобранные требования записываются в форме контрактных спецификаций операций и типов данных на языке SeC - спецификационном расширении языка C. Каждая операция описывается с помощью предусловия и постусловия. Предусловие операции определяет область ее определения. Постусловие определяет ограничения на результаты работы операции и итоговое состояние системы в зависимости от значений ее входных параметров и состояния системы до ее вызова. Для типов данных и элементов данных определяются ограничения целостности, называемые инвариантами. Для одной группы функций обычно создается один файл, в котором определяется спецификация модели состояния группы и все необходимые спецификации требований на ее функции (пример файла спецификации для группы math.integer). Стоит отметить, что проверки в спецификациях содержат явные ссылки на соответствующие требования в тексте стандарта - это обеспечивает прозрачность соответствия спецификации стандарту, а также позволяет генерировать отчеты о тестовом покрытии и найденных несоответствиях в терминах исходных требований.

На этапе разработки сценариев тестовых воздействий формальные спецификации требований и модели дополняются тестовыми сценариями. Тестовый сценарий задает последовательность воздействий тестов на тестируемую систему. Под воздействием понимается вызов определенной интерфейсной функции с определенными параметрами. Сценарий может задавать как простую статическую цепочку воздействий, так и определять конечный автомат, моделирующий поведение тестируемого компонента таким образом, что выполнение всех его переходов гарантирует покрытие 100% ситуаций в соответствии с выбранным критерием. Автомат задается при помощи функции вычисления состояния и набора допустимых действий в произвольном состоянии. Этот набор действий зависит от данных состояния. Использование автоматов при описании сценария позволяет малыми трудозатратами получать тщательное тестовое покрытие с контролируемой глубиной.

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

Более подробное описание архитектуры тестов, а также технических аспектов формализации требований, создания спецификаций и тестов можно найти в документе "Тестирование на основе формальных спецификаций: быстрое знакомство" PDF.


Расширенный процесс разработки тестов

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

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

Расширенный процесс разработки тестового набора представлен на рис.2:


Рис. 2. Детали процесса разработки тестов на соответствие стандарту.