Верификация ПО обеспечивает техническую оценку всех средств разработки ПО, в том числе и результатов верификации ПО. Верификацию ПО выполняют в соответствии с Планом верификации ПО (12.3) и Планом квалификационного тестирования ПО (12.4), которые разрабатывают в процессе планирования ПО.
Таблицы А.З — А.7 содержат резюме целей и результатов верификации в зависимости от уровня ПО.
Примечание — Чем ниже уровень ПО, тем меньше внимания уделяют:
— верификации требований нижнего уровня;
— верификации архитектуры ПО;
— полноте покрытия тестами;
— контролю процедур верификации;
— независимости работ процесса верификации ПО;
— перекрытию работ процесса верификации ПО, т. е. выполнению различных верификационных работ, каждая из которых обнаруживает ошибки одного и того же класса;
— тестированию отказоустойчивости;
— верификационным работам, обнаруживающим ошибки, которые оказывают лишь косвенное влияние на результаты разработки, например отклонение от стандартов разработки ПО.
Назначение верификации ПО состоит в том, чтобы обнаружить и зарегистрировать ошибки, которые могли быть внесены в ПО во время его разработки (устранение ошибок является задачей разработки ПО). Основное назначение верификации ПО — проверить что:
— системные требования, предназначенные для программной реализации, были должным образом переработаны в требования верхнего уровня к ПО, которые удовлетворяют этим системным требованиям;
— требования верхнего уровня были переработаны в архитектуру ПО и требования нижнего уровня, которые удовлетворяют требованиям верхнего уровня; если разработано несколько уровней требований к ПО между требованиями верхнего уровня и требованиями нижнего уровня, то каждый последующий уровень требований разработан так, чтобы удовлетворять требованиям более высокого уровня;
— архитектура ПО и требования нижнего уровня должным образом преобразованы в исходный код, удовлетворяющий им;
— исполняемый объектный код удовлетворяет требованиям к ПО;
— инструментальные средства, используемые для выполнения указанных работ, являются технически корректными и полными для заданного уровня ПО.
Цели верификации ПО должны быть достигнуты посредством выполнения комбинации просмотров, анализов, разработки тестовых наборов и процедур и последующего выполнения этих тестовых процедур. Просмотры и анализы обеспечивают оценку точности, полноты и верифицируем ости требований к ПО, архитектуры ПО и исходного кода. Разработка тестовых наборов должна обеспечивать дальнейшую оценку внутренней непротиворечивости и полноты требований. Выполнение тестовых процедур обеспечивает демонстрацию соответствия требованиям.
Входная информация для процесса верификации ПО включает в себя системные требования, требования к ПО, описание архитектуры, данные о трассируемости, исходный код, исполняемый объектный код, План верификации ПО, План квалификационного тестирования ПО.
Выходные результаты верификации ПО должны быть включены в документы «Процедуры верификации ПО» (12.21), «Результаты верификации ПО» (12.23), «Описание квалификационного тестирования ПО» (12.22), «Отчет о квалификационном тестировании ПО» (12.24).
Просмотры и анализы ПО применяют к результатам процессов разработки и верификации ПО. Различия между просмотрами и анализами заключаются в том, что анализ дает воспроизводимое доказательство, а просмотр предоставляет качественную (экспертную) оценку. Просмотр может включать в себя инспекцию выходных результатов указанных процессов, использующую контрольные листы или другие подобные средства. Анализ может заключаться в детальном исследовании функциональности, эффективности и безопасности компонентов ПО, а также их связи с другими компонентами системы или с оборудованием.
Цель этих просмотров и анализов — обнаружить и зарегистрировать ошибки, которые могли быть внесены в процессе разработки требований к ПО. Данные просмотры и анализы должны подтвердить, что требования верхнего уровня удовлетворяют следующим целям:
а) согласованность с системными требованиями: гарантировать, что функции системы, которые должно выполнять ПО, определены, что требования по функциональности, эффективности и требования, связанные с безопасностью системы, удовлетворены в требованиях верхнего уровня к ПО и что правильно определены производные требования и обоснована их необходимость;
б) точность и непротиворечивость: гарантировать, что каждое требование верхнего уровня является точным, однозначным и достаточно детализированным и что требования не противоречат друг другу;
в) совместимость с объектным компьютером: гарантировать, что не существует никаких противоречий между требованиями верхнего уровня и возможностями аппаратных/программных средств объектного вычислителя, особенно такими, как время реакции системы и аппаратура ввода/вывода;
г) верифицируемость: гарантировать, что каждое требование верхнего уровня может быть верифицировано;
д) соответствие стандартам: гарантировать, что процесс разработки требований к ПО полностью соответствует стандартам на разработку требований и обоснованы любые отклонения от данных стандартов;
е) трассируемость: гарантировать, что функциональные системные требования, требования по эффективности и требования к безопасности системы, предназначенные для программной реализации, были включены в требования верхнего уровня;
ж) алгоритмические аспекты: гарантировать точность и корректность поведения предложенных алгоритмов, особенно в областях отсутствия непрерывности.
Цель этих просмотров и анализов — обнаружить и зарегистрировать ошибки, которые могли быть внесены во время разработки архитектуры ПО. Данные просмотры и анализы должны подтвердить, что архитектура ПО соответствует следующим требованиям:
а) согласованность с требованиями верхнего уровня: гарантировать, что архитектура ПО не находится в противоречии с требованиями верхнего уровня, особенно те функции, которые гарантируют целостность системы, например схемы разбиения;
б) непротиворечивость: гарантировать, что существует корректная связь между компонентами архитектуры ПО, осуществляемая через потоки данных и поток управления;
в) совместимость с объектным компьютером: гарантировать, что не существует никаких противоречий между архитектурой ПО и программно-аппаратными возможностями объектного компьютера, особенно такими, как инициализация, асинхронные операции, синхронизация и прерывания;
г) верифицируемость: гарантировать, что архитектура ПО может быть верифицирована, например не существует неограниченных рекурсивных алгоритмов;
д) соответствие стандартам: гарантировать, что процесс проектирования ПО полностью соответствовал стандартам на процесс проектирования ПО и отклонения от этих стандартов обоснованы, особенно ограничения сложности и использования конструкций проекта, которые не согласуются с задачами безопасности системы;
е) целостность разбиения: гарантировать, что будут предотвращены или изолированы любые нарушения в декомпозиции.
Цель этих просмотров и анализов — обнаружить и зарегистрировать ошибки, которые могли быть внесены в процессе проектирования ПО. Эти просмотры и анализы должны подтвердить, что требования нижнего уровня удовлетворяют следующим целям:
а) согласованность с требованиями верхнего уровня: гарантировать, что требования нижнего уровня к ПО удовлетворяют требованиям верхнего уровня к ПО, что формируемые требования правильно определены и обоснована их необходимость;
б) точность и непротиворечивость: гарантировать, что каждое требование нижнего уровня является точным, однозначным и достаточно детализированным и что требования нижнего уровня не противоречат друг другу;
в) совместимость с объектным компьютером: гарантировать, что не существует никаких противоречий между требованиями к ПО и возможностями аппаратных и программных средств объектного компьютера, особенно по использованию ресурсов (таких, как загрузка шины, время реакции системы и аппаратуры ввода/вывода);
г) верифицируемость: гарантировать, что каждое требование нижнего уровня может быть верифицировано;
д) соответствие стандартам: гарантировать, что процесс проектирования ПО полностью соответствует стандартам на процесс проектирования ПО и что отклонения от этих стандартов обоснованы;
е) трассируемость: гарантировать, что требования верхнего уровня и производные требования были реализованы в требованиях нижнего уровня;
ж) алгоритмические аспекты: гарантировать точность и корректность поведения предложенных алгоритмов, особенно в областях отсутствия непрерывности.
Цель этих просмотров и анализов — выявление и регистрация ошибок, которые могли быть внесены в процессе кодирования ПО. Эти просмотры и анализы подтверждают, что выходные результаты кодирования являются точными, полными и могут быть верифицированы. Прежде всего проверяют корректность кода по отношению к требованиям к ПО и архитектуре ПО и соответствие стандартам на кодирование. Эти просмотры и анализы обычно ограничиваются исходным кодом. На данном этапе необходимо показать:
а) согласованность с требованиями нижнего уровня: гарантировать, что исходный код является корректным, полным и соответствует требованиям нижнего уровня, а также то, что исходный код не содержит неописанных функций;
б) согласованность с архитектурой ПО: гарантировать, что исходный код соответствует потоку данных и потоку управления, которые определены архитектурой ПО;
в) верифицируемость: гарантировать, что исходный код не содержит операторов и структур, которые не могут быть верифицированы, и что код не подвергался изменениям в целях тестирования;
г) соответствие стандартам: гарантировать, что процесс разработки кода ПО полностью соответствует стандартам кодирования ПО и отклонения от этих стандартов обоснованы, особенно в случаях ограничения сложности и использования конструкций кода, предназначенных для удовлетворения целей безопасности системы (сложность в данном контексте — степень связности программных компонентов, уровень вложенности управляющих структур и сложность логических или числовых выражений); этот анализ также должен гарантировать, что отклонения от стандартов оправданы;
д) трассируемость: гарантировать, что требования нижнего уровня к ПО были воплощены в исходный код;
е) точность и непротиворечивость: гарантировать правильность и непротиворечивость исходного кода, включая реализацию стеков, переполнение и разрешающую способность для арифметики с фиксированной точкой, конкуренцию ресурсов, синхронизацию выполнения самых сложных случаев, обработку особых ситуаций, использование неинициализированных переменных или констант, неиспользуемые переменные или константы и нарушения целостности данных из-за конфликтов прерываний или задач.
Цель этих просмотров и анализов — гарантировать, что результаты процесса интеграции ЭКПО являются полными и корректными. Это может быть выполнено путем детального исследования информации о редактировании связей, загрузке и картах памяти. Должны быть проконтролированы и исключены:
— неправильные аппаратные адреса;
— перекрытия памяти;
— отсутствующие компоненты ПО.
Цель этих просмотров и анализов — гарантировать, что тестирование кода было разработано и выполнено точно и полностью. Должны быть рассмотрены следующие вопросы:
а) тестовые варианты: верификация тестовых вариантов представлена в 8.4.4;
б) тестовые процедуры: проверить, что тестовые варианты правильно представлены в процедурах тестирования и ожидаемых результатах;
в) результаты тестирования: гарантировать, что результаты тестирования корректны и что расхождения между фактическими и ожидаемыми результатами объяснимы.
Тестирование ПО систем управления имеет две взаимодополняющие цели. Первая цель — показать, что ПО удовлетворяет требованиям к нему. Вторая цель — продемонстрировать с высокой степенью доверия, что были устранены ошибки, которые могли бы привести к возникновению отказных ситуаций, определенных процессом оценки безопасности системы. Выделяют три уровня тестирования:
— тестирование интеграции ЭКПО/ЭКА, верифицирующее корректность функционирования ПО в среде объектного вычислителя;
— тестирование интеграции ЭКПО, верифицирующее взаимосвязи между требованиями и компонентами ПО и реализацию требований и компонентов в рамках архитектуры;
— тестирование нижнего уровня (модульное тестирование), верифицирующее реализацию требований нижнего уровня.
Примечание — Если разработан тестовый вариант и выполнена соответствующая процедура для тестирования интеграции ЭКПО/ЭКА или тестирования интеграции ЭКПО и удовлетворены критерии покрытия, базирующиеся на требованиях и структуре, то нет необходимости дублировать этот тестовый вариант для тестирования нижнего уровня. Замена тестов верхнего уровня номинально эквивалентными тестами нижнего уровня может быть менее эффективной из-за меньшего объема тестированных функциональных требований.
Для удовлетворения целей тестирования ПО:
— тестовые варианты должны быть основаны, прежде всего, на требованиях к ПО;
— тестовые варианты должны быть разработаны так, чтобы верифицировать корректность функционирования и сформировать условия, которые выявляют потенциальные ошибки;
— анализ покрытия требований к ПО должен определить, какие требования к ПО не были тестированы;
— анализ структурного покрытия должен определить, какие структуры ПО не были выполнены при тестировании.
Для достижения целей тестирования ПО может потребоваться более одной среды тестирования. Идеальная среда тестирования включает в себя ПО, загруженное в объектный вычислитель и тестируемое в среде, которая имитирует среду объектного вычислителя с высокой точностью.
Возможно сертификационное доверие для эмулятора или имитатора объектного вычислителя на инструментальном компьютере. Однако рекомендации относительно среды тестирования сводятся к следующему: некоторые тесты должны быть выполнены только в интегрированной объектной вычислительной среде, так как некоторые ошибки могут быть обнаружены только в этой среде.
Тестированию, основанному на требованиях, уделяют особое внимание, потому что эту стратегию признают наиболее эффективной в обнаружении ошибок. Рекомендации для выбора тестовых вариантов, основанных на требованиях, заключаются в следующем:
— для того чтобы выполнить задачи тестирования ПО, необходимы две категории тестовых вариантов: тесты для проверки функционирования в области допустимых значений и тесты для проверки на устойчивость к ошибкам входных данных (вне данной области);
— обеспечить особые тестовые варианты, разработанные на основе требований к ПО с учетом потенциальных источников ошибок, присущих процессам разработки ПО.
Назначение тестовых вариантов для области допустимых значений — продемонстрировать способность ПО корректно функционировать в штатных условиях и для входных данных из области допустимых значений. Тестовые варианты данной категории включают в себя следующее:
— вещественные и целые входные переменные, которые выбирают с использованием допустимых классов эквивалентности и граничных значений;
— выполнение многократных итераций кода для функций, зависящих от времени, таких как фильтры и задержки, чтобы проверить характеристики этих функций в правильном контексте;
— для проверки перехода состояний разрабатывают тестовые варианты, реализующие переходы, возможные при нормальной работе;
— тестовые наборы, которые должны проверить использование переменных и выполнение булевых операторов для требований к ПО, выраженных логическими уравнениями.
Цель тестовых вариантов проверки устойчивости к ошибкам — показать способность ПО отрабатывать недопустимые входные данные и условия. Требования к тестовым вариантам устойчивости к ошибкам следующие. Должны быть:
— выбраны вещественные и целые переменные из недопустимых классов эквивалентности;
— проверена инициализация системы для недопустимых условий;
— определены режимы с возможными ошибками для поступающих данных, особенно для сложных цифровых последовательностей данных из внешней системы;
— разработаны тестовые наборы для циклов, когда счетчик цикла — вычисляемое значение, чтобы попытаться получить значения счетчика цикла, выходящие из диапазона допустимых значений, и таким образом показать устойчивость кода, связанного с циклом;
— разработаны тестовые наборы для проверки механизмов защиты от арифметического переполнения для функций, зависящих от времени, типа фильтров и задержек;
— разработаны тестовые наборы, чтобы проверить переходы в состояния, которые невозможны в соответствии с требованиями к ПО.
Тестирование, основанное на требованиях, является основным методом для тестирования любого уровня: тестирования интеграции ЭКПО/ЭКА, тестирования интеграции ЭКПО и модульного тестирования. За исключением тестирования интеграции ЭКПО/ЭКА, эти методы не требуют специальной среды тестирования или специальной стратегии. Рекомендации для выполнения тестирования, основанного на требованиях, следующие:
а) тестирование, основанное на требованиях, интеграции ЭКПО/ЭКА: данный метод тестирования должен быть сконцентрирован на источниках ошибок, связанных с выполнением ПО в среде объектного вычислителя, и на функционировании на верхнем уровне. Цель тестирования интеграции ЭКПО/ЭКА — гарантировать, что ПО в объектной среде функционирует в соответствии с требованиями верхнего уровня. Типичные ошибки, выявляемые этим методом тестирования, следующие:
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.2.
Цель анализа — определить, существуют ли структуры кода, которые не были проверены тестовыми процедурами, основанными на требованиях. Тестовые варианты, основанные на требованиях, могут не полностью покрыть структуру кода, поэтому выполняют анализ структурного покрытия и проводят дополнительное тестирование, чтобы обеспечить полное структурное покрытие. Рекомендации для анализа структурного покрытия:
а) анализ должен подтвердить полноту структурного покрытия, соответствующую уровню ПО;
б) анализ структурного покрытия может быть выполнен для исходного кода только в том случае, когда уровень ПО не является уровнем А и компилятор генерирует объектный код, который является непосредственно трассируемым к операторам исходного кода. В противном случае должна быть выполнена дополнительная проверка объектного кода, чтобы установить корректность генерированных последовательностей кода. Объектный код, генерированный компилятором для контроля границ массива, — пример такого объектного кода, который не является непосредственно трассируемым к операторам исходного кода;
в) анализ должен подтвердить связность по данным и связность по управлению между компонентами кода.
Анализ структурного покрытия может обнаружить структуры кода, которые не были выполнены во время тестирования. В этом случае требуются дополнительные работы процесса верификации ПО. Наличие таких невыполненных структур кода может быть результатом:
— недостаточности тестовых вариантов или процедур, основанных на требованиях: следовательно, должны быть генерированы дополнительные тестовые варианты или изменены процедуры тестирования, чтобы обеспечить недостающее покрытие. Может потребоваться пересмотреть метод, используемый для выполнения анализа покрытия, основанного на требованиях;
— несоответствия в требованиях к ПО: требования к ПО должны быть модифицированы, разработаны дополнительные тестовые варианты и выполнены соответствующие процедуры тестирования;
— мертвого кода: код должен быть удален и должен быть проведен анализ, чтобы оценить эффект изменения и потребность в повторной верификации;
— отключенного кода: для отключенного кода, не предназначенного для того, чтобы быть выполненным в некоторой конфигурации при реальной эксплуатации, комбинация анализа и тестирования должна показать, что предотвращены, изолированы или устранены ситуации, при которых такой код мог бы быть случайно выполнен. Для отключенного кода, который может быть выполнен только в специальных конфигурациях среды объектного компьютера, должна быть установлена рабочая конфигурация, необходимая для нормального выполнения этого кода, и должны быть разработаны дополнительные тестовые варианты и процедуры тестирования для достижения требуемого критерия покрытия.
Подготовка к тестированию модулей. Разработчик должен определить тестовые варианты (в терминах входных данных, ожидаемых результатов и критериев оценки) и тестовые процедуры для тестирования каждого модуля ПО. Тестовые варианты должны покрывать все аспекты проекта для данного модуля. Разработчик должен зарегистрировать эту информацию в соответствующих файлах разработки ПО.
Выполнение модульного тестирования. Разработчик должен выполнить тестирование программного кода, соответствующего каждому модулю. Тестирование должно быть выполнено в соответствии с заранее определенными тестовыми вариантами и тестовыми процедурами.
Изменение и повторное тестирование. Разработчик должен выполнить изменения ПО, связанные с коррекцией дефектов, выявленных в процессе верификации, выполнить повторное тестирование в необходимом объеме и модифицировать файлы разработки ПО и другие программные средства, основываясь на результатах модульного тестирования.
Анализ и регистрация результатов модульного тестирования. Разработчик должен проанализировать результаты модульного тестирования и зарегистрировать результаты тестирования и анализа в соответствующих файлах разработки ПО.
Интеграция и тестирование модулей означают объединение программного кода, соответствующего двум или более программным модулям, тестирование полученного в результате кода, чтобы гарантировать, что вместе они работают так, как предполагалось, и продолжение этого процесса до полной интеграции и тестирования кода каждого ЭКПО. Последняя стадия этого тестирования — внутреннее тестирование ЭКПО разработчиком.
Если ЭКПО разрабатывают для нескольких различных построений, то до завершения разработки всех построений не могут быть выполнены полностью интеграция и тестирование модулей данного ЭКПО. Интеграцию и тестирование модулей для каждого построения следует интерпретировать как интеграцию ПО, разработанного для текущего построения, с другим ПО, разработанным для данного и предыдущих построений, и тестирование результата интеграции.
Подготовка к интеграционному тестированию. Разработчик должен определить тестовые варианты (в терминах входных данных, ожидаемых результатов и критериев оценки) и тестовые процедуры для выполнения интеграционного тестирования. Тестовые варианты должны покрывать все аспекты проекта уровня ЭКПО и эскизного проекта ЭКПО. Разработчик должен зарегистрировать эту информацию в соответствующих файлах разработки ПО.
Выполнение интеграционного тестирования. Тестирование следует выполнять в соответствии с тестовыми вариантами и тестовыми процедурами интеграционного тестирования.
Изменение и повторное тестирование. Разработчик должен выполнить изменения ПО, связанные с коррекцией дефектов, выявленных в процессе верификации, выполнить повторное тестирование в необходимом объеме и модифицировать файлы разработки ПО и другие программные средства, основываясь на результатах интеграционного тестирования.
Анализ и регистрация результатов интеграционного тестирования. Разработчик должен проанализировать результаты интеграционного тестирования и зарегистрировать результаты тестирования и анализа в соответствующих файлах разработки ПО.
Интеграция и тестирование ЭКПО/ЭКА означают объединение ЭКПО с взаимодействующими ЭКА и ЭКПО, тестирование полученного объединения с целью определить, работают ли они вместе, как предполагалось, и продолжение этого процесса до тех пор, пока интеграция и тестирование не будут выполнены для всех ЭКПО и ЭКА в системе. Последняя стадия этого тестирования — внутреннее тестирование системы разработчиком.
Если систему или ЭКПО разрабатывают для нескольких различных построений, интеграция и тестирование ЭКПО/ЭКА не могут быть выполнены полностью до завершения последнего построения. Интеграцию и тестирование для каждого построения следует интерпретировать как интеграцию текущего построения каждого ЭКПО с текущим построением других ЭКПО и ЭКА и тестирование результатов интеграции с целью показать, что системные требования, которые должны быть реализованы в данном построении, были удовлетворены.
Подготовка к интеграции и тестированию ЭКПО/ЭКА.
Разработчик должен разработать и зарегистрировать тестовые варианты (в терминах входных данных, ожидаемых результатов и критериев оценки) и тестовые процедуры для проведения интеграционного тестирования ЭКПО/ЭКА. Тестовые варианты должны покрывать все аспекты системного уровня проектирования. Разработчик должен зарегистрировать связанную с тестированием информацию в соответствующих файлах разработки ПО.
Выполнение интеграции и тестирования ЭКПО/ЭКА.
Разработчик должен выполнить интеграционное тестирование ЭКПО/ЭКА. Тестирование должно быть выполнено в соответствии с тестовыми вариантами и процедурами интеграционного тестирования ЭКПО/ЭКА.
Изменение и повторное тестирование.
Разработчик должен выполнить все необходимые изменения в ПО, принять участие в повторном тестировании в необходимом объеме и модифицировать файлы разработки ПО и другие программные средства, основываясь на результатах интеграционного тестирования ЭКПО/ЭКА.
Анализ и регистрация результатов интеграции и тестирования ЭКПО/ЭКА.
Разработчик должен участвовать в выполнении анализа результатов интеграции и тестирования ЭКПО/ЭКА. Результаты анализа и тестирования должны быть зарегистрированы в соответствующих файлах разработки ПО.
Разработчик должен принимать участие в квалификационном тестировании системы.
Квалификационное тестирование системы выполняют для демонстрирования заказчику, что были удовлетворены системные требования. Квалификационное тестирование системы должно покрывать системные требования в Спецификации системы/подсистемы и в соответствующих Спецификациях требований к интерфейсу. Это тестирование противопоставляется внутреннему тестированию системы, выполненному разработчиком, как заключительная стадия интеграции и тестирования ЭКПО/ЭКА.
Если систему разрабатывают для нескольких различных построений, квалификационное тестирование системы в целом не может быть выполнено до завершения последнего построения. Квалификационное тестирование системы для каждого построения следует интерпретировать как планирование и выполнение тестирования для текущего построения системы с целью показать выполнение системных требований, которые должны быть реализованы в данной конфигурации.
Лицом, ответственным за выполнение требований 8.5.4, не должно быть лицо, принимавшее участие в выполнении проектирования или кодировании ПО системы. Это не исключает возможность оказания помощи в проведении квалификационного тестирования со стороны лиц, выполнявших проектирование или кодирование, например путем предоставления тестовых вариантов, основанных на знании внутренней реализации системы.
Квалификационное тестирование системы, выполняемое разработчиком, должно включать в себя тестирование в объектной или альтернативной среде, одобренной заказчиком.
Разработчик должен участвовать в разработке и регистрации процесса подготовки к тестированию, тестовых вариантов и тестовых процедур, которые нужно использовать для квалификационного тестирования системы, и прослеживании соответствия между тестовыми вариантами и требованиями к системе. Для систем ПО все полученные результаты должны быть включены в документ «Описание тестирования ПО». Разработчик должен предварительно уведомить заказчика о времени и месте проведения квалификационного тестирования системы.
Если квалификационное тестирование системы должно быть засвидетельствовано заказчиком, то до его проведения разработчик должен проверить тестовые варианты и тестовые процедуры, чтобы гарантировать, что они полны и точны и что ПО готово для проведения тестирования в присутствии заказчика. Разработчик должен зарегистрировать результаты этой работы в соответствующих файлах разработки ПО и должен модифицировать тестовые варианты и тестовые процедуры соответствующим образом.
Разработчик должен участвовать в квалификационном тестировании системы. Тестирование должно быть выполнено в соответствии с тестовыми вариантами и тестовыми процедурами системного тестирования.
Разработчик должен реализовать все необходимые изменения в ПО и участвовать в проведении повторного тестирования в требуемом объеме, заранее уведомляя заказчика о повторном тестировании. Разработчик обязан вносить необходимые изменения в файлы разработки ПО и другие программные средства в соответствии с результатами квалификационного тестирования системы.
Разработчик должен участвовать в анализе и регистрации результатов квалификационного тестирования системы. Все полученные результаты должны быть включены в соответствующий документ «Отчет о тестировании ПО».