Верификация программного обеспечения. Планирование верификации и аттестации
Верификацией и аттестацией называют процессы проверки и анализа, в ходе которых проверяется соответствие программного обеспечения своей спецификации и требованиям заказчиков. Верификация и аттестация охватывают полный жизненный цикл ПО – они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования готовой программной системы.
Верификация и аттестация не одно и то же, хотя их легко перепутать. Кратко различие между ними можно определить следующим образом:
Верификация отвечает на вопрос, правильно ли создана система;
Аттестация отвечает на вопрос, правильно ли работает система.
Согласно этим определениям, верификация проверяет соответствие ПО системной спецификации, в частности функциональным и нефункциональным требованиям. Аттестация– более общий процесс. Во время аттестации необходимо убедиться, что программный продукт соответствует ожиданиям заказчика. Аттестация проводится после верификации, для того чтобы определить, насколько система соответствует не только спецификации, но и ожиданиям заказчика.
Как уже отмечалось ранее, на ранних этапах разработки ПО очень важна аттестация системных требований. В требованиях часто встречаются ошибки и упущения; в таких случаях конечный продукт, вероятно, не будет соответствовать ожиданиям заказчика. Но, конечно, аттестация требований не может выявить все проблемы в спецификации требований. Иногда недоработки и ошибки в требованиях обнаруживаются только после завершения реализации системы.
В процессах верификации и аттестации используются две основные методики проверки и анализа систем.
1. Инспектирование ПО. Анализ и проверка различных представлений системы, например документации спецификации требований, архитектурных схем или исходного кода программ. Инспектирование выполняется на всех этапах процесса разработки программной системы. Параллельно с инспектированием может выполняться автоматический анализ исходного кода программ и соответствующих документов. Инспектирование и автоматический анализ – это статические методы верификации и аттестации, поскольку им не требуется исполняемая система.
2. Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы. Тестирование – это динамический метод верификации и аттестации, так как применяется к исполняемой системе.
На рис. 20.1 показано место инспектирования и тестирования в процессе разработки ПО. Стрелки указывают на те этапы процесса разработки, на которых можно применять данные методы. Согласно этой схеме, инспектирование можно выполнять на всех этапах процесса разработки системы, а тестирование – в тех случаях, когда создан прототип или исполняемая программа.
К методам инспектирования относятся: инспектирование программ, автоматический анализ исходного кода и формальная верификация. Но статические методы могут проверить только соответствие программ спецификации, с их помощью невозможно проверить правильность функционирования системы. Кроме того, статическими методами нельзя проверить такие нефункциональные характеристики, как производительность и надежность. Поэтому для оценивания нефункциональных характеристик проводится тестирование системы.
Рис. 20.1. Статическая и динамическая верификация и аттестация
Несмотря на широкое применение инспектирования ПО, преобладающим методом верификации и аттестации все еще остается тестирование. Тестирование – это проверка работы программ с данными, подобными реальным, которые будут обрабатываться в процессе эксплуатации системы. Наличие в программе дефектов и несоответствий требованиям обнаруживается путем исследования выходных данных и выявления среди них аномальных. Тестирование выполняется на этапе реализации системы (для проверки соответствия системы ожиданиям разработчиков) и после завершения ее реализации.
На разных этапах процесса разработки ПО применяют различные виды тестирования.
1. Тестирование дефектов проводится для обнаружения несоответствий между программой и ее спецификацией, которые обусловлены ошибками или дефектами в программах. Такие тесты разрабатываются для выявления ошибок в системе, а не для имитации ее работы.
2. Статистическое тестирование оценивает производительность и надежность программ, а также работу системы в различных режимах эксплуатации. Тесты разрабатываются так, чтобы имитировать реальную работу системы с реальными входными данными. Надежность функционирования системы оценивается по количеству сбоев, отмеченных в работе программ. Производительность оценивается по результатам измерения полного времени выполнения операций и времени отклика системы при обработке тестовых данных.
Главная цель верификации и аттестации – удостовериться в том, что система "соответствует своему назначению". Соответствие программной системы своему назначению отнюдь не предполагает, что в ней совершенно не должно быть ошибок. Скорее, система должна достаточно хорошо соответствовать тем целям, для которых планировалась. Уровень необходимой достоверности соответствия зависит от назначения системы, ожиданий пользователей и условий на рынке программных продуктов.
1. Назначение ПО. Уровень достоверности соответствия зависит от того, насколько критическим является разрабатываемое программное обеспечение по тем или иным критериям. Например, уровень достоверности для систем, критическим по обеспечению безопасности, должен быть значительно выше аналогичного уровня достоверности для опытных образцов программных систем, разрабатываемых для демонстрации некоторых новых идей.
2. Ожидания пользователей. Следует с грустью отметить, что в настоящее время у большинства пользователей невысокие требования к программному обеспечению. Пользователи настолько привыкли к отказам, происходящим во время работы программ, что не удивляются этому. Они согласны терпеть сбои в работе системы, если преимущества ее использования компенсируют недостатки. Вместе с тем с начала 1990-х годов терпимость пользователей к отказам в работе программных систем постепенно снижается. В последнее время создание ненадежных систем стало практически неприемлемым, поэтому компаниям, занимающимся разработкой программных продуктов, необходимо все больше внимания уделять верификации и аттестации программного обеспечения.
3. Условия рынка программных продуктов. При оценке программной системы продавец должен знать конкурирующие системы, цену, которую покупатель согласен заплатить за систему, и назначенный срок выхода этой системы на рынок. Если у компании-разработчика несколько конкурентов, необходимо определить дату выхода системы на рынок до окончания полного тестирования и отладки, иначе первыми на рынке могут оказаться конкуренты. Если покупатели не желают приобретать ПО по высокой цене, возможно, они согласны терпеть большее количество отказов в работе системы. При определении расходов на процесс верификации и аттестации необходимо учитывать все эти факторы.
Как правило, в ходе верификации и аттестации в системе обнаруживаются ошибки. Для исправления ошибок в систему вносятся изменения. Этот процесс отладки обычно интегрирован с другими процессами верификации и аттестации. Вместе с тем тестирование (или более обобщенно – верификация и аттестация) и отладка являются разными процессами, которые имеют различные цели.
1. Верификация и аттестация – процесс обнаружения дефектов в программной системе.
2. Отладка – процесс локализации дефектов (ошибок) и их исправления (рис. 20.2).
Рис. 20.2. Процесс отладки
Простых методов отладки программ не существует. Опытные отладчики обнаруживают ошибки путем сравнения шаблонов тестовых выходных данных с выходными данными тестируемых систем. Чтобы определить местоположение ошибки, необходимы знания о типах ошибок, шаблонах выходных данных, языке программирования и процессе программирования. Очень важны знания о процессе разработке ПО. Отладчикам известны наиболее распространенные ошибки программистов (например, связанные с пошаговым увеличением значения счетчика). Также учитываются ошибки, типичные для определенных языков программирования, например связанные с использованием указателей в языке С.
Определение местонахождения ошибок в программном коде не всегда простой процесс, поскольку ошибка необязательно находится возле того места в коде программы, где произошел сбой. Чтобы локализовать ошибки, программист-отладчик разрабатывает дополнительные программные тесты, которые помогают выявить источник ошибки в программе. Может возникнуть необходимость в ручной трассировке выполнения программы.
Интерактивные средства отладки являются частью набора средств поддержки языка, интегрированных с системой компиляции программного кода. Они обеспечивают специальную среду выполнения программ, посредством которой можно получить доступ к таблице идентификаторов, а оттуда к значениям переменных. Пользователи часто контролируют выполнение программы пошаговым способом, последовательно переходя от оператора к оператору. После выполнения каждого оператора проверяются значения переменных и выявляются возможные ошибки.
Обнаруженная в программе ошибка исправляется, после чего необходимо снова проверить программу. Для этого можно еще раз выполнить инспектирование программы или повторить предыдущее тестирование. Повторное тестирование используется для того, чтобы убедиться, что сделанные в программе изменения не внесли в систему новых ошибок, поскольку на практике высокий процент "исправления ошибок" либо не завершается полностью, либо вносит новые ошибки в программу.
В принципе во время повторного тестирования после каждого исправления необходимо еще раз запускать все тесты, однако на практике такой подход оказывается слишком дорогостоящим. Поэтому при планировании процесса тестирования определяются зависимости между частями системы и назначаются тесты для каждой части. Тогда можно трассировать программные элементы с помощью специальных контрольных примеров (контрольных данных), подобранных для этих элементов. Если результаты трассировки задокументированы, то для проверки измененного программного элемента и зависимых от него компонентов можно использовать только некоторое подмножество всего множества тестовых данных.
Планирование верификации и аттестации
Верификация и аттестация – дорогостоящий процесс. Для больших систем, например систем реального времени со сложными нефункциональными ограничениями, половина бюджета, выделенного на разработку системы, тратится на процесс верификации и аттестации. Поэтому очевидна необходимость тщательного планирования данного процесса.
Планирование верификации и аттестации, как один из этапов разработки программных систем, должно начинаться как можно раньше. На рис. 20.3 показана модель разработки ПО, учитывающая процесс планирования испытаний. Здесь планирование начинается еще на этапах создания спецификации и проектирования системы. Данную модель иногда называют V-моделью (чтобы увидеть букву V, необходимо повернуть рис. 20.3 на 90°). На этой схеме также показано разделение процесса верификации и аттестации на несколько этапов, причем на каждом этапе выполняются соответствующие тесты.
Рис. 20.3. Планирование испытаний в процессе разработки и тестирования
В процессе планирования верификации и аттестации необходимо определить соотношение между статическими и динамическими методами проверки системы, определить стандарты и процедуры инспектирования и тестирования ПО, утвердить технологическую карту проверок программ (см. раздел 19.2) и составить план тестирования программ. Чему уделить больше внимания – инспектированию или тестированию, зависит от типа разрабатываемой системы и опыта организации. Чем более критична система, тем больше внимания необходимо уделить статическим методам верификации.
В плане верификации и аттестации основное внимание уделяется стандартам процесса тестирования, а не описанию конкретных тестов. Этот план предназначен не только для руководства, он в основном предназначен специалистам, занимающимся разработкой и тестированием систем. План дает возможность техническому персоналу получить полную картину испытаний системы и в этом контексте спланировать свою работу. Кроме того, план предоставляет информацию менеджерам, отвечающим за то, чтобы у группы тестирования были все необходимые аппаратные и программные средства.
План испытаний не является неизменным документом. Его следует регулярно пересматривать, так как тестирование зависит от процесса реализации системы. Например, если реализация какой-либо части системы не завершена, то невозможно провести тестирование сборки системы. Поэтому план необходимо периодически пересматривать, чтобы сотрудников, занятых тестированием, можно было использовать на других работах.
Верификация и валидация (verification and validation - V& V) предназначены для анализа, проверки правильности выполнения и соответствия ПО спецификациям и требованиям заказчика. Данные методы проверки правильности программ и систем соответственно означают:
- верификация - это проверка правильности создания системы в соответствии с ее спецификацией;
- валидация - это проверка правильности выполнения заданных требований к системе.
Верификация помогает сделать заключение о корректности созданной системы после завершения ее проектирования и разработки. Валидация позволяет установить выполнимость заданных требований и включает в себя ряд действий для получения правильных программ и систем, а именно:
- планирование процедур проверки и контроля проектных решений и требований;
- обеспечение уровня автоматизации проектирования программ CASE- средствами;
- проверка правильности функционирования программ методами тестирования на наборах целевых тестов;
- адаптация продукта к операционной среде и др.
Валидация выполняет эти действия путем просмотра и инспекции спецификаций и результатов проектирования на этапах ЖЦ для подтверждения того, что имеется корректная реализация начальных требований и выполнены заданные условия и ограничения. В задачи верификации и валидации входят проверки полноты, непротиворечивости и однозначности спецификации требований и правильности выполнения функций системы.
Верификации и валидации подвергаются:
- основные компоненты системы;
- интерфейсы компонентов (программные, технические и информационные) и взаимодействия объектов (протоколы и сообщения), обеспечивающие выполнение системы в распределенных средах;
- средства доступа к БД и файлам (транзакции и сообщения) и проверка средств защиты от несанкционированного доступа к данным разных пользователей;
- документация к ПО и к системе в целом;
- тесты, тестовые процедуры и входные данные.
Иными словами, основными систематическими методами правильности программ являются:
- верификация компонентов ПС и валидация спецификации требований;
- инспектирование ПС для установления соответствия программы заданным спецификациями;
- тестирование выходного кода ПС на тестовых данных в конкретной операционной среде для выявления ошибок и дефектов, вызванных разными недоработками, аномальными ситуациями, сбоями оборудования или аварийным прекращением работы системы (см. гл. 9).
Стандарты ISO/IEC 3918-99 и 12207 включают в себя процессы верификации и валидации. Для них определены цели, задачи и действия по проверке правильности создаваемого продукта (включая рабочие, промежуточные продукты) на этапах ЖЦ и соответствия его требованиям.
Основная задача процессов верификации и валидации состоит в том, чтобы проверить и подтвердить , что конечный ПП отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы позволяют выявить ошибки в рабочих продуктах этапов ЖЦ, без выяснения причин их появления, а также установить правильность ПП относительно его спецификации.
Эти процессы взаимосвязанные и определяются одним термином - «верификация и валидация» (V&V 7).
При верификации осуществляется:
- проверка правильности перевода отдельных компонентов в выходной код, а также описаний интерфейсов путем трассировки взаимосвязей компонентов в соответствии с заданными требованиями заказчика;
- анализ правильности доступа к файлам или БД с учетом принятых в используемых системных средствах процедур манипулирования данными и передачи результатов;
- проверка средств защиты компонентов на соответствие требованиям заказчика и проведение их трассировки.
После проверки отдельных компонентов системы проводятся их интеграция, а также верификация и валидация интегрированной системы. Систему тестируют на множестве наборов тестов для определения адекватности и достаточности этих наборов для завершения тестирования и установления правильности системы.
Идея создания международного проекта по формальной верификации была предложена Т. Хоаром, она обсуждалась на симпозиуме по верифицированному ПО в феврале 2005 г. в Калифорнии. Затем в октябре этого же года на конференции IFIP в Цюрихе был принят международный проект сроком на 15 лег но разработке «целостного автоматизированного набора инструментов для проверки корректности ПС».
В нем сформулированы следующие основные задачи:
- разработка единой теории построения и анализа программ;
- построение всеобъемлющего интегрированного набора инструментов верификации для всех производственных этапов, включая разработку спецификаций и их проверку, генерацию тестовых примеров, уточнение, анализ и верификацию программ;
- создание репозитария формальных спецификаций и верифицированных программных объектов разных видов и типов.
В данном проекте предполагается, что верификация будет охватывать все аспекты создания и проверки правильности ПО и станет панацеей от всех бед, связанных с постоянным возникновением ошибок в создаваемых программах.
Многие формальные методы доказательства и верификации специфицированных программ прошли практическую апробацию. Проделана большая работа международного комитета ISO/IEC в рамках стандарта ISO/ IEC 12207:2002 по стандартизации процессов верификации и валидации ПО. Проверка корректности формальными методами разных объектов программирования является перспективной.
Репозитарий является хранилищем программ, спецификаций и инструментов, применяемых при разработках и испытаниях, оценках готовых компонентов, инструментов и заготовок методов. На него возлагаются следующие общие задачи:
- накопление верифицированных спецификаций, методов доказательства, программных объектов и реализаций кодов для сложных применений;
- накопление всевозможных методов верификации, их оформление в виде, пригодном для поиска и выбора реализованной теоретической идеи для дальнейшего применения;
- разработка стандартных форм для задания и обмена формальными спецификациями разных объектов программирования, а также инструментов и готовых систем;
- разработка механизмов интероперабельности и взаимодействия для переноса готовых верифицированных продуктов из репозитария в новые распределенные и сетевые среды для создания новых ПС.
Данный проект предполагается развивать в течение 50 лет. Более ранние проекты ставили подобные цели: улучшение качества ПО, формализация сервисных моделей, снижение сложности за счет использования ПИК, создание отладочного инструментария для визуальной диагностики ошибок и их устранения и др. Однако коренного изменения в программировании не произошло ни в смысле визуальной отладки, ни в достижении высокого качества ПО. Процесс развития продолжается.
Новый международный проект по верификации ПО требует от его участников не только знаний теоретических аспектов спецификации программ, но и высокой квалификации программистов для его реализации в ближайшие годы.
Термины «верификация» и «валидация» очень часто используются в технической литературе и связаны с анализом качества любого программного обеспечения. В научной литературе можно встретить различные трактовки данных понятий. Итак, попробуем разобраться в этом вопросе.
Наиболее правильным, с нашей точки зрения, является следующее определение. Валидация и верификация - это виды деятельности, которые направлены на проведение контроля качества с целью обнаружения на ранних стадиях ошибок в нем. Казалось бы, они имеют общую цель. Но все-таки эти виды обладают различиями в источниках проверяемых свойств, ограничений и правил, несоблюдение которых может считаться ошибкой.
Верификация - это проверка соответствия программного обеспечения представленной техзаданием, архитектурой или В «обязанности» данного термина включается и сопоставление процедуры расчетов с процессом их разработки, правилами и стандартами.
Верификация данных может выполняться для установки соответствия функционирования программы установленным нормам, требованиям, проектным решениям и пользовательской документации. При этом обязательной предварительной проверке подлежат те документы, с которыми проводится сравнение на соответствие их стандартам и нормативам, установленным в той стране, где эксплуатируется программное обеспечение. Необходимо принимать во внимание и соблюдение всех последовательностей выполняемых операций.
В случае обнаружения ошибки или дефекта в работе программы либо же обнаружения противоречия между указанными выше документами и действующим функционированием программы принятие решения о выборе документа для исправления должно быть решением отдельной задачи.
В отличие от верификации валидация отвечает за проверку соответствия разрабатываемых или сопровождаемых программных продуктов потребностям либо нуждам заказчиков или пользователей. Указанные нужды зачастую не фиксируются ни в какой документации. Именно поэтому валидация менее формализована, чем верификация. Это процесс, в котором участвует представитель заказчика, пользователя, а также может присутствовать аналитик или эксперт в Другими словами, те, которые могут выразить конкретные потребности и реальные нужды заинтересованных лиц.
Верификация - это ответ на вопрос «Выполнено ли программное обеспечение правильно?», а валидация - «Сделано ли правильное программное обеспечение?».
При поиске ответа на поставленные вопросы можно обнаружить, что валидация (или аттестация) по содержанию имеет значение несколько шире, чем проверка (верификация). Однако верификация достаточно тесно связана с обеспечением контроля за качеством программного продукта.
Например, верификация компьютерной программы предусматривает процесс, в котором за основу ставится цель по обеспечению удовлетворения требований данных, полученных в определенном жизненном цикле продукта, тем, которые были получены на предыдущей стадии.
Если же вести речь о верификации модели, то здесь речь пойдет о проверке правильности отображения данной вычислительной модели необходимой концептуальной либо
При верификации системного кода проводится анализ кодировки источника и проверка соответствия его документальному описанию.
В процессе верификации могут включаться операции, содержащие альтернативные расчеты. Проводится сравнение технической и научной документаций нового проекта с соответствующей документацией уже существующего проекта, обязательное тестирование, апробация нового программного продукта и демонстрация результатов.
Верификация ПО Верификация является одной из форм тестирования. Она была разработана в 80-х гг. Кларком и Эмерсоном в США, а также независимо Квайлом и Сифакисом во Франции. Тестирование ПО – процесс выявления ошибок в ПО. Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно установить корректность функционирования анализируемой программы. Верификация (от лат. verus – истинный, facere - делать) – проверка, проверяемость, способ обоснования (подтверждения) каких-либо теоретических положений путем их сопоставления с опытными данными. Верификация – это подтверждение на основе предоставления объективных свидетельств того, что установленные требования были выполнены (по ГОСТ ИСО).
Формальная верификация Формальная верификацияКак правило, большинством разработчиков программных систем для проверки правильности проекта практикуются методы имитационного моделирования и тестирования. Они довольно эффективны на самых ранних стадиях отладки, когда проектируемая система всё ещё изобилует ошибками, но результативность этих методов быстро снижается, как только система становится чище. Достойной альтернативой имитационному моделированию и тестированию являются методы формальной верификации. При имитационном моделировании и тестировании исследуются только некоторые из возможных сценариев поведения проектируемой системы, поэтому остаётся открытым вопрос о том, не содержится ли фатальная ошибка в незадействованных траекториях. Формальная верификация же обеспечивает исчерпывающий анализ всех возможных вариантов поведения системы.
Методы формальной верификации Автоматическое доказательство теорем – доказательство теорем, реализуемое программно. В основе лежит аппарат математической логики. Также использует идеи теории искусственного интеллекта. Процесс доказательства основывается на логике высказываний и предикатов. Проверка моделей. Метод автоматической верификации параллельных систем с конечным числом состояний. Символьное выполнение (графы). Абстрактная интерпретация.
Этапы формальной верификации на модели Этапы формальной верификации на модели Моделирование. Для проектируемой системы необходимо построить её абстрактную модель (например, конечную систему переходов), приемлемую для инструментальных средств верификации моделей программы. Спецификация. Эта задача состоит в формулировании свойств, которыми должна обладать проектируемая система. Определить, охватывает ли заданная спецификация все свойства, которыми должна обладать система, невозможно. Для аппаратуры и программного обеспечения, как правило, применяют динамические логики, временные логики и их варианты с неподвижными точками. Вычисления алгоритмов. Результатом вычислений алгоритма глобальной проверки на модели является множество состояний модели, в которых спецификация выполняется, а алгоритм локальной проверки на модели строит в качестве контрпримера некоторое вычисление (ошибочную трассу), которое показывает, почему формула не выполняется. Контрпример особенно важен для поиска тонких ошибок в сложных системах переходов.
Метод проверки на модели По сравнению с другими подходами в формальной верификации программ, метод проверки на модели обладает двумя замечательными преимуществами: Он полностью автоматический, и его применение не требует от пользователя никаких особых знаний в таких математических дисциплинах, как логика и теория доказательства теорем. Всякий, кто может провести моделирование проектируемой системы, вполне способен осуществить и проверку этой системы. Если проектируемая система не обладает желаемым свойством, то результатом проверки на модели будет контрпример, который демонстрирует поведение системы, опровергающее это свойство. Эта ошибочная трасса даёт бесценную информацию для понимания причины ошибки, равно как и важный ключ к решению возникшей проблемы. Основной недостаток метода проверки на модели это "комбинаторный взрыв", который возникает, когда в системе переходы в некоторых компонентах выполняются параллельно. В 1987 г. К.МакМиллан показал, что, используя, символьное представление графа переходов, можно верифицировать очень сложные системы. Новое символьное представление было основано на упорядоченных двоичных разрешающих диаграммах (OBDD) Бриана.
Понятие верификации ПО БКУ В РКК «Энергия» нельзя использовать понятие верификация в полном объеме, так как при создании очень сложных систем невозможна реализация полной проверки, так как существуют временные и стоимостные ограничения. Показатель качества отработки и испытаний ПО БКУ КА
Отработка и испытания ПО БКУ. На предприятии РКК «Энергия» для отработки ПО БКУ используются НКО, работающие в реальном масштабе времени. Комплексная отработка и испытания ПО осуществляются группой интеграции и тестирования по специально разработанным программам и методикам испытаний (ПМИ) (тестовым сценариям). НКО-1 НКО-2 (реальная машина БЦВС) Используется для интеграции и последующей отладки ПО БКУ в объеме: выборочные проверки магистральных путей наиболее вероятных нештатных ситуаций; контроль интерфейса,т.е. проверка ПО в рамках: обмен массивами и словами данных; передача командных массивов; передача ТМ-данных; проверка распределения ресурсов (памяти, процессорного времени, каналов I/O). Используется для испытаний, по- другому верификации, ПО БКУ в объеме: отработка ПО БКУ в соответствии с планом полета (ПП) и режимами КА; проверка на соответствие ПО спецификации.
Программа методика испытаний Для проведения проверки ПО разрабатываются программы методики испытаний (ПМИ). ПМИ для каждого сценария должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.
Тестовый сценарий Тестовый сценарий комплексной отладки строится на основе логической схемы процессов отладки. Сценарий должен отражать во времени возникновение событий и взаимосвязей между ними. Выбор дискретных моментов времени, в которые проводится оценка и принимаются управляющие воздействия, осуществляется в зависимости от специфики ПО и хода процесса реализации отладки. Тестовые сценарии пишут на языках, разработанных на предприятии. К таким языкам относятся: Д Диполь (использовался при создании СМ, ТГК и КА спутниковой системы связи «Ямал», также используется в КИС- контрольный испытательный стенд); L Lua (используется сейчас для МИМ1- малый исследовательский модуль); в внутренние тестовые языки.
Матрица прослеживаемости требований (НКО2) В матрице прослеживаемости требований представлен перечень всех требований, идентификатор программной единицы, наименование программной единицы, номер требований вышестоящего ТЗ и идентификатор теста, подтверждающего данные требования.
Протокол испытаний Протокол испытаний – это текстовый файл, содержащий в хронологическом порядке отклики системы на входные воздействия в ходе проведения испытаний. Протокол содержит московское время события, время относительно начала теста, значения устанавливаемых параметров и примечания, содержащие комментарии о событиях.
ТМ-архив Архив телеметрии – это файл, содержащий в закодированном виде набор телеметрических сообщений, полученных от системы в ходе проведения испытаний. Архив содержит бортовое время событий и значения телеметрических параметров. Программа Telemet2 позволяет представить архив телеметрии в виде текстового файла с комментариями и значениями параметров в десятичном и шестнадцатеричном виде.
Критерии приемки ПМИ для каждого теста должна содержать требования, определяющие критерий приемки. Объем и глубина проверок считаются достаточными, при условии выполнения следующих требований полноты тестирования: ПО БКУ должно функционировать во всех возможных полетных конфигурациях; проверены все функциональные альтернативы в соответствии с внешней спецификацией; отработаны основные нештатные ситуации; проверены граничные значения. ПМИ для каждого теста в разделе "Критерий оценки" должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.
Заказчик (заявитель) . Эта роль принадлежит представителю организации, заказавшей разрабатываемую систему. Обычно заявитель ограничен в своем взаимодействии и общается только с менеджерами проекта и специалистом по сертификации или внедрению. Обычно заказчик имеет право изменять требования к продукту (только во взаимодействии с менеджерами), читать проектную и сертификационную документацию, затрагивающую нетехнические особенности разрабатываемой системы.
Менеджер проекта . Эта роль обеспечивает коммуникационный канал между заказчиком и проектной группой. Менеджер продукта управляет ожиданиями заказчика, разрабатывает и поддерживает бизнес- контекст проекта. Его работа не связана напрямую с продажей, он сфокусирован на продукте, его задача - определить и обеспечить требования заказчика . Менеджер проекта имеет право изменять требования к продукту и финальную документацию на продукт.
Менеджер программы . Эта роль управляет коммуникациями и взаимоотношениями в проектной группе, является в некотором роде координатором, разрабатывает функциональные спецификации и управляет ими, ведет график проекта и отчитывается по состоянию проекта, инициирует принятие критичных для хода проекта решений.
Тестирование - процесс выполнения программы с целью обнаружения ошибки.
Тестовые данные - входы, которые используются для проверки системы.
Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.
Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.
Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.
Ошибка - действие программиста на этапе разработки, приводящее к тому, что в программном обеспечении содержится внутренний дефект, который в процессе работы программы может привести к неправильному результату.
Отказ - непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней.
Таким образом, в процессе тестирования программного обеспечения, как правило, проверяют следующее.
