ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию

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

Цель анализа — определить, насколько полно проверены требования к ПО во время выполнения тестирования. Анализ может выявить потребность в дополнительных тестовых наборах, основанных на требованиях. Данный анализ тестового покрытия должен показать, что:

— существуют тестовые варианты для каждого требования к ПО;

— тестовые варианты удовлетворяют критериям тестирования области определения и тестирования на устойчивость к ошибкам, как установлено в 8.4.2.

Цель анализа — определить, существуют ли структуры кода, которые не были проверены тестовыми процедурами, основанными на требованиях. Тестовые варианты, основанные на требованиях, могут не полностью покрыть структуру кода, поэтому выполняют анализ структурного покрытия и проводят дополнительное тестирование, чтобы обеспечить полное структурное покрытие. Рекомендации для анализа структурного покрытия:

а) анализ должен подтвердить полноту структурного покрытия, соответствующую уровню ПО;

б) анализ структурного покрытия может быть выполнен для исходного кода только в том случае, когда уровень ПО не является уровнем А и компилятор генерирует объектный код, который является непосредственно трассируемым к операторам исходного кода. В противном случае должна быть выполнена дополнительная проверка объектного кода, чтобы установить корректность генерированных последовательностей кода. Объектный код, генерированный компилятором для контроля границ массива, — пример такого объектного кода, который не является непосредственно трассируемым к операторам исходного кода;

в) анализ должен подтвердить связность по данным и связность по управлению между компонентами кода.

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

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

— несоответствия в требованиях к ПО: требования к ПО должны быть модифицированы, разработаны дополнительные тестовые варианты и выполнены соответствующие процедуры тестирования;

— мертвого кода: код должен быть удален и должен быть проведен анализ, чтобы оценить эффект изменения и потребность в повторной верификации;

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

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

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

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

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

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

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

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