Верификация Программного обеспечения. Испытание БКУ и его ПО на НКО

  • 10.01.2024
команда включает более двух человек неизбежно встает вопрос о распределении ролей, прав и ответственности в команде. Конкретный набор ролей определяется многими факторами - количеством участников разработки и их личными предпочтениями, принятой методологией разработки, особенностями проекта и другими факторами. Практически в любом коллективе разработчиков можно выделить перечисленные ниже роли. Некоторые из них могут вовсе отсутствовать, при этом отдельные люди могут выполнять сразу несколько ролей, однако общий состав меняется мало.

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

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

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

Тестирование - процесс выполнения программы с целью обнаружения ошибки.

Тестовые данные - входы, которые используются для проверки системы.

Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.

Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.

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

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

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

Верификация ПО Верификация является одной из форм тестирования. Она была разработана в 80-х гг. Кларком и Эмерсоном в США, а также независимо Квайлом и Сифакисом во Франции. Тестирование ПО – процесс выявления ошибок в ПО. Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно установить корректность функционирования анализируемой программы. Верификация (от лат. verus – истинный, facere - делать) – проверка, проверяемость, способ обоснования (подтверждения) каких-либо теоретических положений путем их сопоставления с опытными данными. Верификация – это подтверждение на основе предоставления объективных свидетельств того, что установленные требования были выполнены (по ГОСТ ИСО).


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


Методы формальной верификации Автоматическое доказательство теорем – доказательство теорем, реализуемое программно. В основе лежит аппарат математической логики. Также использует идеи теории искусственного интеллекта. Процесс доказательства основывается на логике высказываний и предикатов. Проверка моделей. Метод автоматической верификации параллельных систем с конечным числом состояний. Символьное выполнение (графы). Абстрактная интерпретация.


Этапы формальной верификации на модели Этапы формальной верификации на модели Моделирование. Для проектируемой системы необходимо построить её абстрактную модель (например, конечную систему переходов), приемлемую для инструментальных средств верификации моделей программы. Спецификация. Эта задача состоит в формулировании свойств, которыми должна обладать проектируемая система. Определить, охватывает ли заданная спецификация все свойства, которыми должна обладать система, невозможно. Для аппаратуры и программного обеспечения, как правило, применяют динамические логики, временные логики и их варианты с неподвижными точками. Вычисления алгоритмов. Результатом вычислений алгоритма глобальной проверки на модели является множество состояний модели, в которых спецификация выполняется, а алгоритм локальной проверки на модели строит в качестве контрпримера некоторое вычисление (ошибочную трассу), которое показывает, почему формула не выполняется. Контрпример особенно важен для поиска тонких ошибок в сложных системах переходов.


Метод проверки на модели По сравнению с другими подходами в формальной верификации программ, метод проверки на модели обладает двумя замечательными преимуществами: Он полностью автоматический, и его применение не требует от пользователя никаких особых знаний в таких математических дисциплинах, как логика и теория доказательства теорем. Всякий, кто может провести моделирование проектируемой системы, вполне способен осуществить и проверку этой системы. Если проектируемая система не обладает желаемым свойством, то результатом проверки на модели будет контрпример, который демонстрирует поведение системы, опровергающее это свойство. Эта ошибочная трасса даёт бесценную информацию для понимания причины ошибки, равно как и важный ключ к решению возникшей проблемы. Основной недостаток метода проверки на модели это "комбинаторный взрыв", который возникает, когда в системе переходы в некоторых компонентах выполняются параллельно. В 1987 г. К.МакМиллан показал, что, используя, символьное представление графа переходов, можно верифицировать очень сложные системы. Новое символьное представление было основано на упорядоченных двоичных разрешающих диаграммах (OBDD) Бриана.


Понятие верификации ПО БКУ В РКК «Энергия» нельзя использовать понятие верификация в полном объеме, так как при создании очень сложных систем невозможна реализация полной проверки, так как существуют временные и стоимостные ограничения. Показатель качества отработки и испытаний ПО БКУ КА


Отработка и испытания ПО БКУ. На предприятии РКК «Энергия» для отработки ПО БКУ используются НКО, работающие в реальном масштабе времени. Комплексная отработка и испытания ПО осуществляются группой интеграции и тестирования по специально разработанным программам и методикам испытаний (ПМИ) (тестовым сценариям). НКО-1 НКО-2 (реальная машина БЦВС) Используется для интеграции и последующей отладки ПО БКУ в объеме: выборочные проверки магистральных путей наиболее вероятных нештатных ситуаций; контроль интерфейса,т.е. проверка ПО в рамках: обмен массивами и словами данных; передача командных массивов; передача ТМ-данных; проверка распределения ресурсов (памяти, процессорного времени, каналов I/O). Используется для испытаний, по- другому верификации, ПО БКУ в объеме: отработка ПО БКУ в соответствии с планом полета (ПП) и режимами КА; проверка на соответствие ПО спецификации.






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


Тестовый сценарий Тестовый сценарий комплексной отладки строится на основе логической схемы процессов отладки. Сценарий должен отражать во времени возникновение событий и взаимосвязей между ними. Выбор дискретных моментов времени, в которые проводится оценка и принимаются управляющие воздействия, осуществляется в зависимости от специфики ПО и хода процесса реализации отладки. Тестовые сценарии пишут на языках, разработанных на предприятии. К таким языкам относятся: Д Диполь (использовался при создании СМ, ТГК и КА спутниковой системы связи «Ямал», также используется в КИС- контрольный испытательный стенд); L Lua (используется сейчас для МИМ1- малый исследовательский модуль); в внутренние тестовые языки.


Матрица прослеживаемости требований (НКО2) В матрице прослеживаемости требований представлен перечень всех требований, идентификатор программной единицы, наименование программной единицы, номер требований вышестоящего ТЗ и идентификатор теста, подтверждающего данные требования.


Протокол испытаний Протокол испытаний – это текстовый файл, содержащий в хронологическом порядке отклики системы на входные воздействия в ходе проведения испытаний. Протокол содержит московское время события, время относительно начала теста, значения устанавливаемых параметров и примечания, содержащие комментарии о событиях.


ТМ-архив Архив телеметрии – это файл, содержащий в закодированном виде набор телеметрических сообщений, полученных от системы в ходе проведения испытаний. Архив содержит бортовое время событий и значения телеметрических параметров. Программа Telemet2 позволяет представить архив телеметрии в виде текстового файла с комментариями и значениями параметров в десятичном и шестнадцатеричном виде.


Критерии приемки ПМИ для каждого теста должна содержать требования, определяющие критерий приемки. Объем и глубина проверок считаются достаточными, при условии выполнения следующих требований полноты тестирования: ПО БКУ должно функционировать во всех возможных полетных конфигурациях; проверены все функциональные альтернативы в соответствии с внешней спецификацией; отработаны основные нештатные ситуации; проверены граничные значения. ПМИ для каждого теста в разделе "Критерий оценки" должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.

Целью данного курса является изложение комплексного взгляда на процесс верификации программного обеспечения. Предметом обсуждения являются различные подходы и методы, применяемые в области верификации и, в частности, тестирования программного обеспечения. Предполагается, что разрабатываемое программное обеспечение является частью более общей системы. Подобная система включает аппаратные, информационные и организационные (человек-пользователь, человек-оператор и т.п.) компоненты, разрабатываемые, возможно, разными коллективами. Поэтому необходимы документы разработки, определяющие требования к различным компонентам системы и правила их взаимодействия. Кроме того, предполагается, что отказы системы могут приводить к последствиям той или иной тяжести, поэтому при разработке программного обеспечения необходимы и оправданы усилия, потраченные на выявление скрытых дефектов. В первую очередь, это касается средств и процедур верификации программного обеспечения. В состав курса входит ряд практических занятий, иллюстрирующих на примере простой системы приемы и методы верификации программного обеспечения в среде Microsoft Visual Studio 2005 Team Edition for Software Testers. Данная публикация входит в состав "Библиотеки учебных курсов", формирование которой ведется в рамках программы академического сотрудничества MSDN Academic Alliance (MSDN AA).

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.

Рис. 7 Тестирование, верификация и валидация Верификация программного обеспечения – более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам. Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации, такое же допущение сделано и в данном учебном курсе. Валидация программной системы – процесс, целью которого является доказательство того, что в результате разработки системы мы достигли тех целей, которые планировали достичь благодаря ее использованию. Иными словами, валидация – это проверка соответствия системы ожиданиям заказчика. Вопросы, связанные с валидацией выходят за рамки данного учебного курса и представляют собой отдельную интересную тему для изучения. Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос «Как это сделано?» или «Соответсвует ли поведение разработанной программы требованиям?», верификация – «Что сделано?» или «Соответствует ли разработанная система требованиям?», а валидация – «Сделано ли то, что нужно?» или «Соответствует ли разработанная система ожиданиям заказчика?». 1.7. Документация, создаваемая на различных этапах жизненного цикла Синхронизация всех этапов разработки происходит при помощи документов, которые создаются на каждом из этапов. Документация при этом создается и на прямой отрезке жизненного цикла – при разработке программной системы, и на обратном – при ее верификации. Попробуем на примере V-образного жизненного цикла проследить за тем, какие типы документов создаются на каждом из отрезков, и какие взаимосвязи между ними существуют (Рис. 8). Результатом этапа разработки требований к системе являются сформулированные требования к системе – документ, описывающие общие принципы работы системы, ее взаимодействие с «окружающей средой» - пользователями системы, а также, программными и аппаратными средствами, обеспечивающими ее работу. Обычно параллельно с требованиями к системе создается план верификации и определяется стратегия верификации. Эти документы определяют общий подход к тому, как будет выполняться тестирование, какие методики будут применяться, какие аспекты будущей системы должны быть подвергнуты тщательной проверке. Еще одна задача, решаемая при помощи определения стратегии верификации – определение места различных верификационных процессов и их связей с процессами разработки. 20 Верификационный процесс, работающий с системными требованиями – это процесс валидации требований, сопоставления их реальным ожиданиям заказчика. Забегая вперед, скажем, что процесс валидации отличается от приемо-сдаточных испытаний, выполняемых при передаче готовой системы заказчику, хотя может считаться частью таких испытаний. Валидация является средством доказать не только корректность реализации системы с точки зрения заказчика, но и корректность принципов, положенных в основу ее разработки. Рис. 8 Процессы и документы при разработке программных систем Требования к системе являются основой для процесса разработки функциональных требований и архитектуры проекта. В ходе этого процесса разрабатываются общие требования к программному обеспечению системы, к функциям которые она должна выполнять. Функциональные требования часто включают в себя определение моделей поведения системы в штатных и нештатных ситуациях, правила обработки данных и определения интерфейса с пользователем. Текст требования, как правило, включает в себя слова «должна, должен» и имеет структуру вида «В случае, если значение температуры на датчике ABC достигает 30 и выше градусов Цельсия, система должна прекращать выдачу звукового сигнала». Функциональные требования являются основой для разработки архитектуры системы – описания ее структуры в терминах подсистем и структурных единиц языка, на котором производится реализация – областей, классов, модулей, функций и т.п. На базе функциональных требований пишутся тест-требования – документы, содержащие определение ключевых точек, которые должны быть проверены для того, чтобы убедиться в корректности реализации функциональных требований. Часто тест- требования начинаются словами «Проверить, что» и содержат ссылки на соответствующие им функциональные требования. Примером тест-требований для приведенного выше функционального требования могут служить «Проверить, что в случае падения температуры на датчике ABC ниже 30 градусов Цельсия система выдает предупреждающий звуковой сигнал» и «Проверить, что в случае, когда значение температуры на датчике ABC выше 30 градусов Цельсия, система не выдает звуковой сигнал». 21 Одна из проблем, возникающих при написании тест-требований – принципиальная нетестируемость некоторых требований, например требование «Интерфейс пользователя должен быть интуитивно понятным» невозможно проверить без четкого определения того, что является интуитивно понятным интерфейсом. Такие неконкретные функциональные требования обычно впоследствии видоизменяют. Архитектурные особенности системы также могут служить источником для создания тест-требований, учитывающих особенности программной реализации системы. Примером такого требования является, например, «Проверить, что значение температуры на датчике ABC не выходит за 255». На основе функциональных требований и архитектуры пишется программный код системы, для его проверки на основе тест-требований готовится тест-план – описание последовательности тестовых примеров, выполняющих проверку соответствия реализации системы требованиям. Каждый тестовый пример содержит конкретное описание значений, подаваемых на вход системы, значений, которые ожидаются на выходе и описание сценария выполнения теста. В зависимости от объекта тестирования тест-план может готовиться либо в виде программы на каком-либо языке программирования, либо в виде входного файла данных для инструментария, выполняющего тестируемую систему и передающего ей значения, указанные в тест-плане, либо в виде инструкций для пользователя системы, описывающей необходимые действия, которые нужно выполнить для проверки различных функций системы. В результате выполнения всех тестовых примеров собирается статистика об успешности прохождения тестирования – процент тестовых примеров, для которых реальные выходные значения совпали с ожидаемыми, так называемых пройденных тестов. Не пройденные тесты являются исходными данными для анализа причин ошибок и последующего их исправления. На этапе интеграции осуществляется сборка отдельных модулей системы в единое целое и выполнение тестовых примеров, проверяющих всю функциональность системы. На последнем этапе осуществляется поставка готовой системы заказчику. Перед внедрением специалисты заказчика совместно с разработчиками проводят приемо- сдаточные испытания – выполняют проверку критичных для пользователя функций согласно заранее утвержденной программе испытаний. При успешном прохождении испытаний система передается заказчику, в противном случае отправляется на доработку. 1.8. Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла 1.8.1. Модульное тестирование Модульному тестированию подвергаются небольшие модули (процедуры, классы и т.п.). При тестировании относительного небольшого модуля размером 100-1000 строк есть возможность проверить, если не все, то, по крайней мере, многие логические ветви в реализации, разные пути в графе зависимости данных, граничные значения параметров. В соответствии с этим строятся критерии тестового покрытия (покрыты все операторы, все логические ветви, все граничные точки и т.п.). . Модульное тестирование обычно выполняется для каждого независимого программного модуля и является, пожалуй, наиболее распространенным видом тестирования, особенно для систем малых и средних размеров. 1.8.2. Интеграционное тестирование Проверка корректности всех модулей, к сожалению, не гарантирует корректности функционирования системы модулей. В литературе иногда рассматривается 22 «классическая» модель неправильной организации тестирования системы модулей, часто называемая методом «большого скачка». Суть метода состоит в том, чтобы сначала оттестировать каждый модуль в отдельности, потом объединить их в систему и протестировать систему целиком. Для крупных систем это нереально. При таком подходе будет потрачено очень много времени на локализацию ошибок, а качество тестирования останется невысоким. Альтернатива «большому скачку» - интеграционное тестирование, когда система строится поэтапно, группы модулей добавляются постепенно. 1.8.3. Системное тестирование Полностью реализованный программный продукт подвергается системному тестированию. На данном этапе тестировщика интересует не корректность реализации отдельных процедур и методов, а вся программа в целом, как ее видит конечный пользователь. Основой для тестов служат общие требования к программе, включая не только корректность реализации функций, но и производительность, время отклика, устойчивость к сбоям, атакам, ошибкам пользователя и т.д. Для системного и компонентного тестирования используются специфические виды критериев тестового покрытия (например, покрыты ли все типовые сценарии работы, все сценарии с нештатными ситуациями, попарные композиции сценариев и проч.). 1.8.4. Нагрузочное тестирование Нагрузочное тестирование позволяет не только получать прогнозируемые данные о производительности системы под нагрузкой, которая ориентирована на принятие архитектурных решений, но и предоставляет рабочую информацию службам технической поддержки, а также менеджерам проектов и конфигурационным менеджерам, которые отвечают за создания наиболее продуктивных конфигураций оборудования и ПО. Нагрузочное тестирование позволяет команде разработки, принимать более обоснованные решения, направленные на выработку оптимальных архитектурных композиций. Заказчик со своей стороны, получает возможность проводить приёмо-сдаточные испытания в условиях приближенных к реальным. 1.8.5. Формальные инспекции Формальная инспекция является одним из способов верификации документов и программного кода, создаваемых в процессе разработки программного обеспечения. В ходе формальной инспекции группой специалистов осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что она осуществляется инспекторами, не участвовавшими в разработке инспектируемого документа. 1.9. Верификация сертифицируемого программного обеспечения Дадим несколько определений, определяющих общую структуру процесса сертификации программного обеспечения: Сертификация ПО – процесс установления и официального признания того, что разработка ПО проводилась в соответствии с определенными требованиями. В процессе сертификации происходит взаимодействие Заявителя, Сертифицирующего органа и Наблюдательного органа Заявитель - организация, подающая заявку в соответствующий Сертифицирующий орган на получения сертификата (соответствия, качества, годности и т.п.) изделия. Сертифицирующий орган – организация, рассматривающая заявку Заявителя о проведении Сертификации ПО и либо самостоятельно, либо путем формирования специальной комиссии производящая набор процедур направленных на проведение процесса Сертификации ПО Заявителя. 23 Наблюдательный орган – комиссия специалистов, наблюдающих за процессами разработки Заявителем сертифицируемой информационной системы и дающих заключение, о соответствии данного процесса определенным требованиям, которое передается на рассмотрение в Сертифицирующий орган. Сертификация может быть направлена на получение сертификата соответствия, либо сертификата качества. В первом случае результатом сертификации является признание соответствия процессов разработки определенным критериям, а функциональности системы определенным требованиям. Примером таких требований могут служить руководящие документы Федеральной службы по техническому и экспортному контролю в области безопасности программных систем . Во втором случае результатом является признание соответствия процессов разработки определенным критериям, гарантирующим соответствующий уровень качества выпускаемой продукции и его пригодности для эксплуатации в определенных условиях. Примером таких стандартов может служить серия международных стандартов качества ISO 9000:2000 (ГОСТ Р ИСО 9000-2001) или авиационные стандарты DO- 178B , AS9100 , AS9006 . Тестирование сертифицируемого программного обеспечения имеет две взаимодополняющие цели: Первая цель - продемонстрировать, что программное обеспечение удовлетворяет требованиям на него. Вторая цель - продемонстрировать с высоким уровнем доверительности, что ошибки, которые могут привести к неприемлемым отказным ситуациям, как они определены процессом, оценки отказобезопасности системы, выявлены в процессе тестирования. Например, согласно требованиям стандарта DO-178B, для того, чтобы удовлетворить целям тестирования программного обеспечения, необходимо следующее: Тесты, в первую очередь, должны основываться на требованиях к программному обеспечению; Тесты должны разрабатываться для проверки правильности функционирования и создания условий для выявления потенциальных ошибок. Анализ полноты тестов, основанных на требованиях на программное обеспечение, должен определить, какие требования не протестированы. Анализ полноты тестов, основанных на структуре программного кода, должен определить, какие структуры не исполнялись при тестировании. Также в этом стандарте говорится о тестировании, основанном на требованиях. Установлено, что эта стратегия наиболее эффективна при выявлении ошибок. Руководящие указания для выбора тестовых примеров, основанных на требованиях, включают следующее: Для достижения целей тестирования программного обеспечения должны быть проведены две категории тестов: тесты для нормальных ситуаций и тесты для ненормальных (не отраженных в требованиях, робастных) ситуаций. Должны быть разработаны специальные тестовые примеры для требований на программное обеспечение и источников ошибок, присущих процессу разработки программного обеспечения. Целью тестов для нормальных ситуаций является демонстрация способности программного обеспечения давать отклик на нормальные входы и условия в соответствии с требованиями. 24 Целью тестов для ненормальных ситуаций является демонстрация способности программного обеспечения адекватно реагировать на ненормальные входы и условия, иными словами, это не должно вызывать отказ системы. Категории отказных ситуаций для системы устанавливаются путем определения опасности отказной ситуации для самолета и тех, кто в нем находится. Любая ошибка в программном обеспечении может вызвать отказ, который внесет свой вклад в отказную ситуацию. Таким образом, уровень целостности программного обеспечения, необходимый для безопасной эксплуатации, связан с отказными ситуациями для системы. Существует 5 уровней отказных ситуаций от несущественной до критически опасной. Согласно этим уровням вводится понятие уровня критичности программного обеспечения. От уровня критичности зависит состав документации, предоставляемой в сертифицирующий орган, а значит и глубина процессов разработки и верификации системы. Например, количество типов документов и объем работ по разработке системы, необходимых для сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-два порядка от количества и объемов, необходимых для сертификации по самому высокому уровню. Конкретные требования определяет стандарт, по которому планируется вести сертификацию. 25 ТЕМА 2. Тестирование программного кода (лекции 2-5) 2.1. Задачи и цели тестирования программного кода Тестирование программного кода – процесс выполнения программного кода, направленный на выявление существующих в нем дефектов. Под дефектом здесь понимается участок программного кода, выполнение которого при определенных условиях приводит к неожиданному поведению системы (т.е. поведению, не соответствующему требованиям). Неожиданное поведение системы может приводить к сбоям в ее работе и отказам, в этом случае говорят о существенных дефектах программного кода. Некоторые дефекты вызывают незначительные проблемы, не нарушающие процесс функционирования системы, но несколько затрудняющие работу с ней. В этом случае говорят о средних или малозначительных дефектах. Задача тестирования при таком подходе – определение условий, при которых проявляются дефекты системы и протоколирование этих условий. В задачи тестирования обычно не входит выявление конкретных дефектных участков программного кода и никогда не входит исправление дефектов – это задача отладки, которая выполняется по результатам тестирования системы. Цель применения процедуры тестирования программного кода – минимизация количества дефектов, в особенности существенных, в конечном продукте. Тестирование само по себе не может гарантировать полного отсутствия дефектов в программном коде системы. Однако, в сочетании с процессами верификации и валидации, направленными на устранение противоречивости и неполноты проектной документации (в частности – требований на систему), грамотно организованное тестирование дает гарантию того, что система удовлетворяет требованиям и ведет себя в соответствии с ними во всех предусмотренных ситуациях. При разработке систем повышенной надежности, например, авиационных, гарантии надежности достигаются при помощи четкой организации процесса тестирования, определения его связи с остальными процессами жизненного цикла, введения количественных характеристик, позволяющих оценивать успешность тестирования. При этом, чем выше требования к надежности системы (ее уровень критичности), тем более жесткие требования предъявляются. Таким образом, в первую очередь мы рассматриваем не конкретные результаты тестирования конкретной системы, а общую организацию процесса тестирования, используя подход «хорошо организованный процесс дает качественный результат». Такой подход является общим для многих международных и отраслевых стандартах качества, о которых более подробно будет рассказано в конце данного курса. Качество разрабатываемой системы при таком подходе является следствием организованного процесса разработки и тестирования, а не самостоятельным неуправляемым результатом. Поскольку современные программные системы имеют весьма значительные размеры, при тестировании их программного кода используется метод функциональной декомпозиции. Система разбивается на отдельные модули (классы, пространства имен и т.п.), имеющие определенную требованиями функциональность и интерфейсы. После этого по отдельности тестируется каждый модуль – выполняется модульное тестирование. Затем выполняется сборка отдельных модулей в более крупные конфигурации – выполняется интеграционное тестирование, и наконец, тестируется система в целом – выполняется системное тестирование. С точки зрения программного кода, модульное, интеграционное и системное тестирование имеют много общего, поэтому в данной теме основное внимание будет уделено модульному тестированию, особенности интеграционного и системного тестирования будут рассмотрены позднее. 26 В ходе модульного тестирования каждый модуль тестируется как на соответствие требованиям, так и на отсутствие проблемных участков программного кода, могущих вызвать отказы и сбои в работе системы. Как правило, модули не работают вне системы – они принимают данные от других модулей, перерабатывают их и передают дальше. Для того, чтобы с одной стороны, изолировать модуль от системы и исключить влияние потенциальных ошибок системы, а с другой стороны – обеспечить модуль всеми необходимыми данными, используется тестовое окружение. Задача тестового окружения – создать среду выполнения для модуля, эмулировать все внешние интерфейсы, к которым обращается модуль. Об особенностях организации тестового окружения пойдет речь в данной теме. Типичная процедура тестирования состоит в подготовке и выполнении тестовых примеров (также называемых просто тестами). Каждый тестовый пример проверяет одну «ситуацию» в поведении модуля и состоит из списка значений, передаваемых на вход модуля, описания запуска и выполнения переработки данных – тестового сценария, и списка значений, которые ожидаются на выходе модуля в случае его корректного поведения. Тестовые сценарии составляются таким образом, чтобы исключить обращения к внутренним данным модуля, все взаимодействие должно происходить только через его внешние интерфейсы. Выполнение тестового примера поддерживается тестовым окружением, которое включает в себя программную реализацию тестового сценария. Выполнение начинается с передачи модулю входных данных и запуска сценария. Реальные выходные данные, полученные от модуля в результате выполнения сценария сохраняются и сравниваются с ожидаемыми. В случае их совпадения тест считается пройденным, в противном случае – не пройденным. Каждый не пройденный тест указывает либо на дефект в тестируемом модуле, либо в тестовом окружении, либо в описании теста. Совокупность описаний тестовых примеров составляет тест-план – основной документ, определяющий процедуру тестирования программного модуля. Тест-план задает не только сами тестовые примеры, но и порядок их следования, который также может быть важен. Структура и особенности тест-планов будут рассмотрены в данной теме, проблемы, связанные с порядком следования тестовых примеров – в теме «Повторяемость тестирования». При тестировании часто бывает необходимо учитывать не только требования к системе, но и структуру программного кода тестируемого модуля. В этом случае тесты составляются таким образом, чтобы детектировать типичные ошибки программистов, вызванные неверной интерпретацией требований. Применяются проверки граничных условий, проверки классов эквивалентности. Отсутствие в системе возможностей, не заданных требованиями, гарантируют различные оценки покрытия программного кода тестами, т.е. оценки того, какой процент тех или иных языковых конструкций выполнен в результате выполнения всех тестовых примеров. Обо всем этом пойдет речь в завершение данной темы. 2.2. Методы тестирования 2.2.1. Черный ящик Основная идея в тестировании системы, как черного ящика состоит в том, что все материалы, которые доступны тестировщику – требования на систему, описывающие ее поведение и сама система, работать с которой он может только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, таким образом, система и представляет собой «черный ящик», правильность поведения которого по отношению к требованиям и предстоит проверить. 27 С точки зрения программного кода черный ящик может представлять с собой набор классов (или модулей) с известными внешними интерфейсами, но недоступными исходными текстами. Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям. Кроме того, тестировщик должен проверить работу системы в критических ситуациях – что происходит в случае подачи неверных входных значений. В идеальной ситуации все варианты критических ситуаций должны быть описаны в требованиях на систему и тестировщику остается только придумывать конкретные проверки этих требований. Однако в реальности в результате тестирования обычно выявляется два типа проблем системы: 1. Несоответствие поведения системы требованиям 2. Неадекватное поведение системы в ситуациях, не предусмотренных требованиями. Отчеты об обоих типах проблем документируются и передаются разработчикам. При этом проблемы первого типа обычно вызывают изменение программного кода, гораздо реже – изменение требований. Изменение требований в данном случае может потребоваться ввиду их противоречивости (несколько разных требований описывают разные модели поведения системы в одной и той же самой ситуации) или некорректности (требования не соответствуют действительности). Проблемы второго типа однозначно требуют изменения требований ввиду их неполноты – в требованиях явно пропущена ситуация, приводящая к неадекватному поведению системы. При этом под неадекватным поведением может пониматься как полный крах системы, так и вообще любое поведение, не описанное в требованиях. Тестирование черного ящика называют также тестированием по требованиям, т.к. это единственный источник информации для построения тест-плана. 2.2.2. Стеклянный (белый) ящик При тестировании системы, как стеклянного ящика, тестировщик имеет доступ не только к требованиям на систему, ее входам и выходам, но и к ее внутренней структуре – видит ее программный код. Доступность программного кода расширяет возможности тестировщика тем, что он может видеть соответствие требований участкам программного кода и видеть тем самым – на весь ли программный код существуют требования. Программный код, для которого отсутствуют требования называют кодом, непокрытым требованиями. Такой код является потенциальным источником неадекватного поведения системы. Кроме того, прозрачность системы позволяет углубить анализ ее участков, вызывающих проблемы – часто одна проблема нейтрализует другую и они никогда не возникают одновременно. 2.2.3. Тестирование моделей Тестирование моделей находится несколько в стороне от классических методов верификации программного обеспечения. Прежде всего это связано с тем, что объект тестирования – не сама система, а ее модель, спроектированная формальными средствами. Если оставить в стороне вопросы проверки корректности и применимости самой модели (считается, что ее корректность и соответствие исходной системе может быть доказана формальными средствами), то тестировщик получает в свое распоряжение достаточно мощный инструмент анализа общей целостности системы. Работая с моделью можно создать такие ситуации, которые невозможно создать в тестовой лаборатории для реальной системы. Работая с моделью программного кода системы можно анализировать его свойства и такие параметры системы, как оптимальность алгоритмов или ее устойчивость. 28 Однако тестирование моделей не получило широкого распространения именно ввиду трудностей, возникающих при разработке формального описания поведения системы. Одно из немногих исключений – системы связи, алгоритмический и математический аппарат которых достаточно хорошо проработан. 2.2.4. Анализ программного кода (инспекции) Во многих ситуациях тестирование поведения системы в целом невозможно – отдельные участки программного кода могут никогда не выполняться, при этом они будут покрыты требованиями. Примером таких участков кода могут служить обработчики исключительных ситуаций. Если, например, два модуля передают друг другу числовые значения, и функции проверки корректности значений работают в обоих модулях, то функция проверки модуля-приемника никогда не будет активизирована, т.к. все ошибочные значения будут отсечены еще в передатчике. В этом случае выполняется ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода. Если в результате инспекции выявляются проблемные участки, то информация об этом передается разработчикам для исправления наравне с результатами обычных тестов. 2.3. Тестовое окружение Основной объем тестирования практически любой сложной системы обычно выполняется в автоматическом режиме. Кроме того, тестируемая система обычно разбивается на отдельные модули, каждый из которых тестируется вначале отдельно от других, затем в комплексе. Это означает, что для выполнения тестирования необходимо создать некоторую среду, которая обеспечит запуск и выполнение тестируемого модуля, передаст ему входные данные, соберет реальные выходные данные, полученные в результате работы системы на заданных входных данных. После этого среда должна сравнить реальные выходные данные с ожидаемыми и на основании данного сравнения сделать вывод о соответствии поведения модуля заданному (Рис. 9). Тестовый драйвер Ожидаемые выходные данные Тестируемый Обработка Входные данные модуль результатов Реальные выходные данные Заглушки Рис. 9 Обобщенная схема среды тестирования Тестовое окружение также может использоваться для отчуждения отдельных модулей системы от всей системы. Разделение модулей системы на ранних этапах тестирования позволяет более точно локализовать проблемы, возникающие в их программном коде. Для поддержки работы модуля в отрыве от системы тестовое окружение должно моделировать поведение всех модулей, к функциям или данным которых обращается тестируемый модуль. 29

  • 2. Системотехника вычислительных систем
  • 2.1. Интеграционные свойства систем
  • 2.2. Система и ее окружение
  • 2.3. Моделирование систем
  • 2.4. Процесс создания систем
  • 2.5. Приобретение систем
  • 3. Процесс создания программного обеспечения
  • 3.1. Модели процесса создания программного обеспечения
  • 3.2. Итерационные модели разработки программного обеспечения
  • 3.3. Спецификация программного обеспечения
  • 3.4. Проектирование и реализация программного обеспечения
  • 3.5. Эволюция программных систем
  • 3.6. Автоматизированные средства разработки программного обеспечения
  • 4. Технологии производства программного обеспечения
  • Часть II. Требования к программному обеспечению
  • 5. Требования к программному обеспечению
  • 5.1. Функциональные и нефункциональные требования
  • 5.2. Пользовательские требования
  • 5.3. Системные требования
  • 5.4. Документирование системных требований
  • 6. Разработка требований
  • 6.1. Анализ осуществимости
  • 6.2. Формирование и анализ требований
  • 6.3. Аттестация требований
  • 6.4. Управление требованиям
  • 7. Матрица требований. Разработка матрицы требований
  • Часть III. Моделирование программного обеспечения
  • 8. Архитектурное проектирование
  • 8.1. Структурирование системы
  • 8.2. Модели управления
  • 8.3. Модульная декомпозиция
  • 8.4. Проблемно-зависимые архитектуры
  • 9. Архитектура распределенных систем
  • 9.1. Многопроцессорная архитектура
  • 9.2. Архитектура клиент/сервер
  • 9.3. Архитектура распределенных объектов
  • 9.4. Corba
  • 10. Объектно-ориентированное проектирование
  • 10.1. Объекты и классы объектов
  • 10.2. Процесс объектно-ориентированного проектирования
  • 10.2.1. Окружение системы и модели ее использования
  • 10.2.2. Проектирование архитектуры
  • 10.2.3. Определение объектов
  • 10.2.4. Модели архитектуры
  • 10.2.5. Специфицирование интерфейсов объектов
  • 10.3. Модификация системной архитектуры
  • 11. Проектирование систем реального времени
  • 11.1. Проектирование систем реального времени
  • 11.2. Управляющие программы
  • 11.3. Системы наблюдения и управления
  • 11.4. Системы сбора данных
  • 12. Проектирование с повторным использованием компонентов
  • 12.1. Покомпонентная разработка
  • 12.2. Семейства приложений
  • 12.3. Проектные паттерны
  • 13. Проектирование интерфейса пользователя
  • 13.1. Принципы проектирования интерфейсов пользователя
  • 13.2. Взаимодействие с пользователем
  • 13.3. Представление информации
  • 13.4. Средства поддержки пользователя
  • 13.5. Оценивание интерфейса
  • Часть IV. Технологии разработки программного обеспечения
  • 14. Жизненный цикл программного обеспечения: модели и их особенности
  • 14.1. Каскадная модель жизненного цикла
  • 14.2. Эволюционная модель жизненного цикла
  • 14.2.1. Формальная разработка систем
  • 14.2.2. Разработка программного обеспечения на основе ранее созданных компонентов
  • 14.3. Итерационные модели жизненного цикла
  • 14.3.1 Модель пошаговой разработки
  • 14.3.2 Спиральная модель разработки
  • 15. Методологические основы технологий разработки программного обеспечения
  • 16. Методы структурного анализа и проектирования программного обеспечения
  • 17. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml
  • Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения
  • 18. Документирование этапов разработки программного обеспечения
  • 19. Планирование проекта
  • 19.1 Уточнение содержания и состава работ
  • 19.2 Планирование управления содержанием
  • 19.3 Планирование организационной структуры
  • 19.4 Планирование управления конфигурациями
  • 19.5 Планирование управления качеством
  • 19.6 Базовое расписание проекта
  • 20. Верификация и аттестация программного обеспечения
  • 20.1. Планирование верификации и аттестации
  • 20.2. Инспектирование программных систем
  • 20.3. Автоматический статический анализ программ
  • 20.4. Метод "чистая комната"
  • 21. Тестирование программного обеспечения
  • 21.1. Тестирование дефектов
  • 21.1.1. Тестирование методом черного ящика
  • 21.1.2. Области эквивалентности
  • 21.1.3. Структурное тестирование
  • 21.1.4. Тестирование ветвей
  • 21.2. Тестирование сборки
  • 21.2.1. Нисходящее и восходящее тестирование
  • 21.2.2. Тестирование интерфейсов
  • 21.2.3. Тестирование с нагрузкой
  • 21.3. Тестирование объектно-ориентированных систем
  • 21.3.1. Тестирование классов объектов
  • 21.3.2. Интеграция объектов
  • 21.4. Инструментальные средства тестирования
  • Часть VI. Управление проектом программного обеспечения
  • 22. Управление проектами
  • 22.1. Процессы управления
  • 22.2. Планирование проекта
  • 22.3. График работ
  • 22.4. Управление рисками
  • 23. Управление персоналом
  • 23.1. Пределы мышления
  • 23.1.1. Организация человеческой памяти
  • 23.1.2. Решение задач
  • 23.1.3. Мотивация
  • 23.2. Групповая работа
  • 23.2.1. Создание команды
  • 23.2.2. Сплоченность команды
  • 23.2.3. Общение в группе
  • 23.2.4. Организация группы
  • 23.3. Подбор и сохранение персонала
  • 23.3.1. Рабочая среда
  • 23.4. Модель оценки уровня развития персонала
  • 24. Оценка стоимости программного продукта
  • 24.1. Производительность
  • 24.2. Методы оценивания
  • 24.3. Алгоритмическое моделирование стоимости
  • 24.3.1. Модель сосомо
  • 24.3.2. Алгоритмические модели стоимости в планировании проекта
  • 24.4. Продолжительность проекта и наем персонала
  • 25. Управление качеством
  • 25.1. Обеспечение качества и стандарты
  • 25.1.1. Стандарты на техническую документацию
  • 25.1.2. Качество процесса создания программного обеспечения и качество программного продукта
  • 25.2. Планирование качества
  • 25.3. Контроль качества
  • 25.3.1. Проверки качества
  • 25.4. Измерение показателей программного обеспечения
  • 25.4.1. Процесс измерения
  • 25.4.2. Показатели программного продукта
  • 26. Надежность программного обеспечения
  • 26.1. Обеспечение надежности программного обеспечения
  • 26.1.1 Критические системы
  • 26.1.2. Работоспособность и безотказность
  • 26.1.3. Безопасность
  • 26.1.4. Защищенность
  • 26.2. Аттестация безотказности
  • 26.3. Гарантии безопасности
  • 26.4. Оценивание защищенности программного обеспечения
  • 27. Совершенствование производства программного обеспечения
  • 27.1. Качество продукта и производства
  • 27.2. Анализ и моделирование производства
  • 27.2.1. Исключения в процессе создания по
  • 27.3. Измерение производственного процесса
  • 27.4. Модель оценки уровня развития
  • 27.4.1. Оценивание уровня развития
  • 27.5. Классификация процессов совершенствования
  • 20. Верификация и аттестация программного обеспечения

    Верификацией и аттестацией называют процессы проверки и анализа, в ходе которых проверяется соответствие программного обеспечения своей спецификации и требованиям заказчиков. Верификация и аттестация охватывают полный жизненный цикл ПО – они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования готовой программной системы.

    Верификация и аттестация не одно и то же, хотя их легко перепутать. Кратко различие между ними можно определить следующим образом:

    Верификация отвечает на вопрос, правильно ли создана система;

    Аттестация отвечает на вопрос, правильно ли работает система.

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

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

    В процессах верификации и аттестации используются две основные методики проверки и анализа систем.

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

    2. Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы. Тестирование – это динамический метод верификации и аттестации, так как применяется к исполняемой системе.

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

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

    Рис. 20.1. Статическая и динамическая верификация и аттестация

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

    На разных этапах процесса разработки ПО применяют различные виды тестирования.

    1. Тестирование дефектов проводится для обнаружения несоответствий между программой и ее спецификацией, которые обусловлены ошибками или дефектами в программах. Такие тесты разрабатываются для выявления ошибок в системе, а не для имитации ее работы.

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

    Главная цель верификации и аттестации – удостовериться в том, что система "соответствует своему назначению". Соответствие программной системы своему назначению отнюдь не предполагает, что в ней совершенно не должно быть ошибок. Скорее, система должна достаточно хорошо соответствовать тем целям, для которых планировалась. Уровень необходимой достоверности соответствия зависит от назначения системы, ожиданий пользователей и условий на рынке программных продуктов.

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

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

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

    Как правило, в ходе верификации и аттестации в системе обнаруживаются ошибки. Для исправления ошибок в систему вносятся изменения. Этот процесс отладки обычно интегрирован с другими процессами верификации и аттестации. Вместе с тем тестирование (или более обобщенно – верификация и аттестация) и отладка являются разными процессами, которые имеют различные цели.

    1. Верификация и аттестация – процесс обнаружения дефектов в программной системе.

    2. Отладка – процесс локализации дефектов (ошибок) и их исправления (рис. 20.2).

    Рис. 20.2. Процесс отладки

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

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

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

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

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

    Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.

    В статье я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

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

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

    1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.

    2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.

    3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.

    4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.

    5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.

    6. Созданная система не соответствует описанию.

    Понятно, что все артефакты проекта появляются, как правило, в завершенном своем виде только к концу проекта и то не всегда. Но, если предположить, что разработка водопадная, то риски такие, как я описал. Проверка каждого риска – это определенная операция, которой можно дать название. Если кому интересно, можно попытаться придумать и озвучить эти термины.

    Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.

    Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация - это в том числе проверка описания на непротиворечивость, полноту и понятность.

    Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.