Цели и методы тестирования ПО

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

- тестирование интеграции ЭКПО/ЭКА, верифицирующее корректность функционирования ПО в среде объектного вычислителя;

- тестирование интеграции ЭКПО, верифицирующее взаимосвязи между требованиями и компонентами ПО и реализацию требований и компонентов в рамках архитектуры;

- тестирование нижнего уровня (модульное тестирование), верифицирующее реализацию требований нижнего уровня.

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

Д ля удовлетворения целей тестирования ПО:

- тестовые варианты должны быть основаны, прежде всего, на требованиях к ПО;

- анализ покрытия требований к ПО должен определить, какие требования к ПО не были тестированы;

- анализ структурного покрытия должен определить, какие структуры ПО не были выполнены при тестировании.

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 Анализ структурного покрытия.

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

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

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

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

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

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

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

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

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: