1. Постановка задачи

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

Входными данными для процесса проектирования тестов являются документ с требованиями к бортовым системам. Этот документ хранится в системе управления требованями DOORS в виде дерева (списка) отдельных требований. Каждое такое требование содержит:

• уникальный идентификатор;

• текст требования;

• уровень гарантии проектирования;

• метод проверки: демонстрация или тестирование;

• другие атрибуты.

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

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

Пример тестовой ситуации.

Состояние самолета (режим полета, фаза, значение важных атрибутов)

Действия/события

Что надо проверить?

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

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

Помимо основной задачи инструменты должны поддерживать решение дополнительных задач:

• верификация результатов проектирования тестов;

• оценка необходимых свойств интегрированного тестового стенда;

• валидация исходных требований;

• генерация документов, необходимых для сертификации бортовых систем, таких как:

  • матрица верификации;

  • описание процедур верификации.

Дополнительные требования.

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

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

Генерация отчетов об изменениях в проектировании тестов за определенный период. Как следствие – необходимость хранения изменений в разметке и тестовых ситуациях.

От нас: для наиболее эффективной работы для рабочего места потребуется большой монитор (возможно широкоформатный или два монитора).

1. Предлагаемое решение

В качестве решения поставленной задачи предлагается использовать следующий подход.

В исходном документе с требованиями выделяются элементарные требования, каждому из них присваивается:

• уникальный идентификатор,

• привязка к одному или нескольким кускам текста (или картинки!!!);

• произвольный набор атрибутов.

Выделенные элементарные требования образуют дерево, в котором связь “ребенок-родитель” означает, что дочернее требование является уточнением родительского.

Затем для каждого элементарного требования из шаблона создается параметризованная тестовая ситуация. Одна тестовая ситуация может быть привязана к нескольким элементарным требованиям, которые она проверяет. Слово “параметризованная” в данном контексте означает, что в теле описания ситуации могут использоваться параметры (такие как, “высота”, “фаза полета” и т.д.). Возможные значения параметров и принципы их комбинирования описываются также в параметризованной тестовой ситуации. При подстановке конкретного набора параметров в параметризованную тестовую ситуацию получается тестовая ситуация в классическом понимании.

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

Библиотека типовых тестовых ситуаций, именованные множества типовых тестовых ситуаций, (их параметризация???), различные представления для удобной навигации (дерево, теги, ...).

Вся информация об исходных требованиях, элементарных требованиях, параметризованных и типовых тестовых ситуациях хранится на сервере в нашем собственном формате и при необходимости экспортируется в DOORS.

Список возможностей