Тестирование ПО систем управления имеет две взаимодополняющие цели. Первая цель — показать, что ПО удовлетворяет требованиям к нему. Вторая цель — продемонстрировать с высокой степенью доверия, что были устранены ошибки, которые могли бы привести к возникновению отказных ситуаций, определенных процессом оценки безопасности системы. Выделяют три уровня тестирования:
— тестирование интеграции ЭКПО/ЭКА, верифицирующее корректность функционирования ПО в среде объектного вычислителя;
— тестирование интеграции ЭКПО, верифицирующее взаимосвязи между требованиями и компонентами ПО и реализацию требований и компонентов в рамках архитектуры;
— тестирование нижнего уровня (модульное тестирование), верифицирующее реализацию требований нижнего уровня.
Примечание — Если разработан тестовый вариант и выполнена соответствующая процедура для тестирования интеграции ЭКПО/ЭКА или тестирования интеграции ЭКПО и удовлетворены критерии покрытия, базирующиеся на требованиях и структуре, то нет необходимости дублировать этот тестовый вариант для тестирования нижнего уровня. Замена тестов верхнего уровня номинально эквивалентными тестами нижнего уровня может быть менее эффективной из-за меньшего объема тестированных функциональных требований.
Для удовлетворения целей тестирования ПО:
— тестовые варианты должны быть основаны, прежде всего, на требованиях к ПО;
— тестовые варианты должны быть разработаны так, чтобы верифицировать корректность функционирования и сформировать условия, которые выявляют потенциальные ошибки;
— анализ покрытия требований к ПО должен определить, какие требования к ПО не были тестированы;
— анализ структурного покрытия должен определить, какие структуры ПО не были выполнены при тестировании.
8.4.1 Среда тестирования
Для достижения целей тестирования ПО может потребоваться более одной среды тестирования. Идеальная среда тестирования включает в себя ПО, загруженное в объектный вычислитель и тестируемое в среде, которая имитирует среду объектного вычислителя с высокой точностью.
Возможно сертификационное доверие для эмулятора или имитатора объектного вычислителя на инструментальном компьютере. Однако рекомендации относительно среды тестирования сводятся к следующему: некоторые тесты должны быть выполнены только в интегрированной объектной вычислительной среде, так как некоторые ошибки могут быть обнаружены только в этой среде.
8.4.2 Выбор тестовых вариантов, основанных на требованиях
Тестированию, основанному на требованиях, уделяют особое внимание, потому что эту стратегию признают наиболее эффективной в обнаружении ошибок. Рекомендации для выбора тестовых вариантов, основанных на требованиях, заключаются в следующем:
— для того чтобы выполнить задачи тестирования ПО, необходимы две категории тестовых вариантов: тесты для проверки функционирования в области допустимых значений и тесты для проверки на устойчивость к ошибкам входных данных (вне данной области);
— обеспечить особые тестовые варианты, разработанные на основе требований к ПО с учетом потенциальных источников ошибок, присущих процессам разработки ПО.
Назначение тестовых вариантов для области допустимых значений — продемонстрировать способность ПО корректно функционировать в штатных условиях и для входных данных из области допустимых значений. Тестовые варианты данной категории включают в себя следующее:
— вещественные и целые входные переменные, которые выбирают с использованием допустимых классов эквивалентности и граничных значений;
— выполнение многократных итераций кода для функций, зависящих от времени, таких как фильтры и задержки, чтобы проверить характеристики этих функций в правильном контексте;
— для проверки перехода состояний разрабатывают тестовые варианты, реализующие переходы, возможные при нормальной работе;
— тестовые наборы, которые должны проверить использование переменных и выполнение булевых операторов для требований к ПО, выраженных логическими уравнениями.
Цель тестовых вариантов проверки устойчивости к ошибкам — показать способность ПО отрабатывать недопустимые входные данные и условия. Требования к тестовым вариантам устойчивости к ошибкам следующие. Должны быть:
— выбраны вещественные и целые переменные из недопустимых классов эквивалентности;
— проверена инициализация системы для недопустимых условий;
— определены режимы с возможными ошибками для поступающих данных, особенно для сложных цифровых последовательностей данных из внешней системы;
— разработаны тестовые наборы для циклов, когда счетчик цикла — вычисляемое значение, чтобы попытаться получить значения счетчика цикла, выходящие из диапазона допустимых значений, и таким образом показать устойчивость кода, связанного с циклом;
— разработаны тестовые наборы для проверки механизмов защиты от арифметического переполнения для функций, зависящих от времени, типа фильтров и задержек;
— разработаны тестовые наборы, чтобы проверить переходы в состояния, которые невозможны в соответствии с требованиями к ПО.
8.4.3 Методы тестирования, основанные на требованиях
Тестирование, основанное на требованиях, является основным методом для тестирования любого уровня: тестирования интеграции ЭКПО/ЭКА, тестирования интеграции ЭКПО и модульного тестирования. За исключением тестирования интеграции ЭКПО/ЭКА, эти методы не требуют специальной среды тестирования или специальной стратегии. Рекомендации для выполнения тестирования, основанного на требованиях, следующие:
а) тестирование, основанное на требованиях, интеграции ЭКПО/ЭКА: данный метод тестирования должен быть сконцентрирован на источниках ошибок, связанных с выполнением ПО в среде объектного вычислителя, и на функционировании на верхнем уровне. Цель тестирования интеграции ЭКПО/ЭКА — гарантировать, что ПО в объектной среде функционирует в соответствии с требованиями верхнего уровня. Типичные ошибки, выявляемые этим методом тестирования, следующие:
1) неправильная обработка прерываний;
2) отказы, связанные с требованиями по времени выполнения;
3) некорректная реакция ПО на переходные процессы в аппаратуре или аппаратные отказы, например упорядочение начальных действий, сбой при загрузке входных данных и нестабильность питания;
4) проблемы конкуренции для шин данных и других ресурсов;
5) неспособность встроенных тестов обнаруживать некоторые виды отказов;
6) ошибки в интерфейсах аппаратных/программных средств;
7) некорректное поведение циклов обратной связи;
8) некорректная работа аппаратуры, управляющей памятью, или другой аппаратуры, работающей под управлением ПО;
9) переполнение стека;
10) неправильное функционирование механизмов, поддерживающих корректность и совместимость ПО, загружаемого в условиях эксплуатации;
11) нарушения разбиения ПО;
б) тестирование, основанное на требованиях, интеграции ЭКПО: данный метод тестирования должен быть сконцентрирован на взаимосвязях между требованиями к ПО и на реализации требований архитектурой ПО. Цель такого тестирования — гарантировать, что программные компоненты взаимодействуют друг с другом корректно и удовлетворяют требованиям к ПО и архитектуре ПО. Этот метод может быть реализован путем расширения области действия требований посредством последовательной интеграции компонентов кода с соответствующим расширением области действия тестовых вариантов. Типичные ошибки, обнаруживаемые этим методом:
1) некорректная инициализация переменных и констант;
2) ошибки передачи параметров;
3) затирание данных, особенно глобальных;
4) некорректная последовательность событий и действий;
в) модульное тестирование, основанное на требованиях: этот метод тестирования следует применять для демонстрации того, что каждый программный компонент выполняет требования нижнего уровня. Цель тестирования нижнего уровня, основанного на требованиях, — гарантировать, что программные компоненты удовлетворяют этим требованиям нижнего уровня. Типичные ошибки, выявляемые данным методом тестирования:
1) ошибка алгоритма в реализации требования к ПО;
2) некорректная работа цикла;
3) некорректные логические решения;
4) отказ при обработке правильно сформированных комбинаций входных условий;
5) некорректная реакция на отсутствующие или искаженные входные данные;
6) некорректная обработка исключительных ситуаций типа арифметических ошибок или выхода за границы массива;
7) некорректная последовательность вычислений;
8) неадекватные точность вычисления в алгоритме, точность представления данных или выполнение расчетов.
8.4.4 Анализ тестового покрытия
Анализ тестового покрытия — процесс, состоящий из двух шагов, включающий в себя анализ покрытия, основанного на требованиях, и анализ структурного покрытия. Первый шаг — анализ тестовых наборов относительно требований ПО, чтобы подтвердить, что выбранные наборы тестов удовлетворяют установленным критериям. Второй шаг — подтверждение того, что процедуры тестирования, основанные на требованиях, покрыли структуру кода. Анализ структурного покрытия может в некоторых случаях не удовлетворять заданному критерию покрытия. Например, предусмотрены дополнительные рекомендации для разрешения таких ситуаций, как мертвый код.
8.4.4.1 Анализ тестового покрытия, основанного на требованиях
Цель анализа — определить, насколько полно проверены требования к ПО во время выполнения тестирования. Анализ может выявить потребность в дополнительных тестовых наборах, основанных на требованиях. Данный анализ тестового покрытия должен показать, что:
— существуют тестовые варианты для каждого требования к ПО;
— тестовые варианты удовлетворяют критериям тестирования области определения и тестирования на устойчивость к ошибкам, как установлено в 8.4.2.
8.4.4.2 Анализ структурного покрытия.
Цель анализа — определить, существуют ли структуры кода, которые не были проверены тестовыми процедурами, основанными на требованиях. Тестовые варианты, основанные на требованиях, могут не полностью покрыть структуру кода, поэтому выполняют анализ структурного покрытия и проводят дополнительное тестирование, чтобы обеспечить полное структурное покрытие. Рекомендации для анализа структурного покрытия:
а) анализ должен подтвердить полноту структурного покрытия, соответствующую уровню ПО;
б) анализ структурного покрытия может быть выполнен для исходного кода только в том случае, когда уровень ПО не является уровнем А и компилятор генерирует объектный код, который является непосредственно трассируемым к операторам исходного кода. В противном случае должна быть выполнена дополнительная проверка объектного кода, чтобы установить корректность генерированных последовательностей кода. Объектный код, генерированный компилятором для контроля границ массива, — пример такого объектного кода, который не является непосредственно трассируемым к операторам исходного кода;
в) анализ должен подтвердить связность по данным и связность по управлению между компонентами кода.
Анализ структурного покрытия может обнаружить структуры кода, которые не были выполнены во время тестирования. В этом случае требуются дополнительные работы процесса верификации ПО. Наличие таких невыполненных структур кода может быть результатом:
— недостаточности тестовых вариантов или процедур, основанных на требованиях: следовательно, должны быть генерированы дополнительные тестовые варианты или изменены процедуры тестирования, чтобы обеспечить недостающее покрытие. Может потребоваться пересмотреть метод, используемый для выполнения анализа покрытия, основанного на требованиях;
— несоответствия в требованиях к ПО: требования к ПО должны быть модифицированы, разработаны дополнительные тестовые варианты и выполнены соответствующие процедуры тестирования;
— мертвого кода: код должен быть удален и должен быть проведен анализ, чтобы оценить эффект изменения и потребность в повторной верификации;
— отключенного кода: для отключенного кода, не предназначенного для того, чтобы быть выполненным в некоторой конфигурации при реальной эксплуатации, комбинация анализа и тестирования должна показать, что предотвращены, изолированы или устранены ситуации, при которых такой код мог бы быть случайно выполнен. Для отключенного кода, который может быть выполнен только в специальных конфигурациях среды объектного компьютера, должна быть установлена рабочая конфигурация, необходимая для нормального выполнения этого кода, и должны быть разработаны дополнительные тестовые варианты и процедуры тестирования для достижения требуемого критерия покрытия.