Целью данного курса является изложение комплексного взгляда на процесс верификации программного обеспечения. Предметом обсуждения являются различные подходы и методы, применяемые в области верификации и, в частности, тестирования программного обеспечения. Предполагается, что разрабатываемое программное обеспечение является частью более общей системы. Подобная система включает аппаратные, информационные и организационные (человек-пользователь, человек-оператор и т.п.) компоненты, разрабатываемые, возможно, разными коллективами. Поэтому необходимы документы разработки, определяющие требования к различным компонентам системы и правила их взаимодействия. Кроме того, предполагается, что отказы системы могут приводить к последствиям той или иной тяжести, поэтому при разработке программного обеспечения необходимы и оправданы усилия, потраченные на выявление скрытых дефектов. В первую очередь, это касается средств и процедур верификации программного обеспечения. В состав курса входит ряд практических занятий, иллюстрирующих на примере простой системы приемы и методы верификации программного обеспечения в среде 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

Программные системы в настоящее время присутствуют повсеместно: практически любые электронные устройства содержат программное обеспечение (ПО) того или иного вида. Без соответствующего программного обеспечения в современном мире невозможно представить индустриальное производство, школы и университеты, систему здравоохранения, финансовые и правительственные учреждения. Многие пользователи применяют ПО для самообразования, для развлечений и т.д. Создание спецификации требований, разработка, модификация и сопровождение таких систем ПО составляет суть технической дисциплины инженерия программного обеспечения (software engineering, SE).

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

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

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

1. Общие сведения о верификации и аттестации ПО.

1.1. Введение в верификацию и аттестацию

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

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

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

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

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

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

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

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

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

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

Назначение ПО. Уровень достоверности соответствия зависит от важности (критичности) разрабатываемого программного продукта по каким-либо критериям. Например, ПО для медицинской установки «Аппарат сердце-легкие» является суперкритичным, так как от качества работы системы зависит человеческая жизнь. Можно привести пример систем малой критичности. Это, в частности, опытные образцы программных систем, разрабатываемые для демонстрации некоторых новых идей.

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

2. Верификация и аттестация ПО

2.1. Планирование верификации и аттестации

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

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

Рис. 2.1. Планирование испытаний в процессе разработки и тестирования,

Requirements specification – спецификация требований

System specification – системная спецификация

System design – проектирование системы

Detailed Design – детальное проектирование

Acceptance test plan – планирование приемочных испытаний

System integration test plan – планирование тестирования системной сборки

Sub-system integration test plan – планирование тестирования сборки подсистемы

Module and unit code and tess – кодирование и тестирование модулей и компонентов

Sub-system integration test – тестирование сборки подсистем

System integration test – тестирование системной сборки

Acceptance test – приемочные испытания

Service – программный продукт.

Из рисунка видно, что процесс верификации и аттестации разделяется на несколько этапов, причем на каждом этапе проводится определенный тест.

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

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

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

2.2. Инспектирование программных систем

Системное тестирование программ требует разработки огромного количества тестов, их выполнения и проверки. Это значит, что данный процесс достаточно трудоемкий и дорогостоящий. Каждый тест способен обнаружить в программе одну, реже несколько ошибок. Причина такого положения заключается в том, что сбои в работе, происходящие из-за ошибок в системе, часто приводят к разрушению данных. Поэтому сложно сказать, какое количество ошибок «ответственно» за сбой в системе.

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

Доказано, что инспектирование является эффективным методом обнаружения ошибок, причем оно значительно дешевле экстенсивного тестирования. Инспектированием можно обнаружить более 60% всех ошибок, а при более формальном подходе (используя математические методы) – более 90%. Процесс инспектирования также может оценить другие качественные характеристики систем: соответствие стандартам, переносимость и удобства сопровождения.

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

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

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

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

2.3. Инспектирование программ

Инспектирование программ – это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованного процесса проверки программ была сформулирована корпорацией IBM в 1970-х годах. В настоящее время данный метод верификации получил широкое распространение. На его базе разработано множество других методов, но все они основываются на базовой идее метода инспектирования, согласно которому группа специалистов выполняет тщательный построчный просмотр и анализ исходного кода программы. Главное отличие инспектирования от других методов оценивания качества программ состоит в том, что его цель – обнаружение дефектов, а не исследование общих проблем проекта. Дефектами являются либо ошибки в исходном коде, либо несоответствия программы стандартам.

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

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

Рис. 2.2. Процесс инспектирования

На рис. 2.2 показан общий процесс инспектирования. Он адаптирован к требованиям организаций, использующих инспектирование программ.

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

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

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

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

2.4. Автоматический статический анализ программ

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

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

Статический анализ состоит из нескольких этапов.

1. Анализ потока управления. Идентификация и выделение циклов, их точек входа и выхода, выявление неиспользуемого кода.

2. Анализ использования данных. Проверка переменных в программе. На этом этапе также можно выявить условные операторы с избыточными условиями.

3. Анализ интерфейса. Проверка согласованности различных частей программы, правильности объявления процедур и их использования. Данный этап оказывается лишним, если используется язык со строгим контролем типов.

4. Анализ потоков данных. Определяются зависимости между входными и выходными переменными. Хотя этот анализ не выявляет конкретных ошибок, он дает полный список значений, используемых в программе. Следовательно, легко обнаруживается ошибочный вывод данных.

5. Анализ ветвей программы. На этом этапе семантического анализа определяются все ветви программы и выделяются операторы, исполняемые в каждой ветви. Анализ ветвей программы существенно помогает разобраться в управлении программой и позволяет проанализировать каждую ветвь отдельно.

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

Анализ с помощью инструментальных средств не может заменить инспектирования, так как существуют такие типы ошибок, которые невозможно выявить с помощью статического анализа. Например, анализаторы способны обнаружить необъявленные переменные, однако они не смогут обнаружить неправильного присвоения. Конечно, для таких языков, как С, статический анализ является эффективным методом обнаружения ошибок. Но в современных языках (типа Java) удалены конструкции, способствующие появлению многих ошибок. Все переменные должны быть объявлены, отсутствуют операторы безусловного перехода, вследствие чего маловероятно случайное создание неиспользуемого кода, и осуществляется автоматическое управление памятью.

2.5 Метод «чистая комната».

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

В разработке ПО методом «чистая комната» выделяют пять ключевых моментов:

1. Формальная спецификация . Разрабатывается формальная спецификация. Для записи спецификации используется модель состояний, в которой отображены отклики системы.

2. Пошаговая разработка . Разработка ПО разбивается на несколько этапов, которые проверяются методом «чистая комната» независимо друг от друга.

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

4. Статическая верификация. Проверка статическим методом строгого инспектирования ПО. Для отдельных элементов тестирование кода не проводится.

5. Статическое тестирование системы. На каждом шаге проводится тестирование статическими методами, позволяющими оценить надежность программной системы.

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

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

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

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

3. Тестирование программного обеспечения

3.1. Планирование тестирования

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

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

Тестирование сборки должно основываться на имеющейся спецификации системы.

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

3.2. Тестирование дефектов

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

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

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

Методов тестирования дефектов существует несколько.

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

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

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

3.3. Тестирование сборки

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

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

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

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

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

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

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

Между компонентами программы могут быть разные типы интерфейсов и, соответственно, разные типы ошибок интерфейса.

Рис. 3.1. Тестирование интерфейсов

ТИ – сложный процесс, поскольку некоторые ошибки могут проявляться только в необычных условиях. Другая проблема может возникнуть из-за взаимодействий между ошибками в разных программных модулях или объектах. Ошибки в одном объекте можно выявить только тогда, когда поведение другого объекта становится непредсказуемым.

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

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

3.4. Инструментальные средства тестирования

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

Рис. 3.2. Инструментальные средства тестирования

На этом рисунке:

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

4. Аттестация критических систем

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

4.1. Аттестация безотказности

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

Неопределенность операционного профиля (профили могут неточно отражать реальное использование системы)

Высокая стоимость генерации тестовых данных (если нет возможности автоматической генерации тестовых данных, то создание большого количества тестовых данных требует больших затрат времени и, соответственно, средств)

Статистическая неопределенность в случае высокой безотказности (для точного измерения показателей безотказности необходимо сгенерировать статистически значимое число отказов).

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

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

4.2. Гарантии безопасности

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

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

4.3. Верификация и аттестация

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

При создании КС, важен всесторонний анализ разрабатываемой системы. Имеется пять типов анализа системы, обязательных для КС:

1. Анализ правильности функционирования системы

2. Анализ возможности изменения и понятности системной архитектуры

3. Анализ соответствия алгоритма обработки и структуры данных определенному в спецификации поведению системы

4. Анализ согласованности программного кода, алгоритмов и структур данных.

5. Анализ адекватности тестовых сценариев системным требованиям.

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

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

Заключение

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

В настоящее время приобретает большое значение оценка защищенности систем, поскольку все чаще системы объединяются посредством сети Интернет. Требования защищенности в некоторых отношениях подобны требованиям безопасности. В частности, они определяют нештатное поведение системы, а не ее «рабочее» поведение. Однако, как правило, невозможно определить это поведение в виде простых ограничений, контролируемых системой.

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

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

Если соблюдать все эти требования, то, скорее всего, наступит день, когда нас будут окружать системы, работающие без сбоев.

Литература.

1. Соммервилл И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. – М.: Издат. Дом. «Вильямс», 2002. – 624 с.: ил.

2. А.Г. Гейн, В.Г. Житомирский. Основы информатики и вычислительной техники: проб. Учеб. Для 10-11 кл. сред. шк. – 3-е изд. – М.: Просвещение, 1993. – 254 с.: ил.

3. Ю. Г. Карпов. Теория автоматов. – Спб.: Питер, 2002 – 224 с.: ил.

4. Электронный Архив для инженеров программного обеспечения. http://www.cs.queensu.ca/Software-Engineering/

5. Software Engineering Questions and Answers. http://www.cs.queensu.ca/Software-Engineering/questions.html

6. Ресурсы сервера Института Инженерии Программного Обеспечения Карнеги Меллона (Carnegie Mellon Software Engineering Institute). http://www.sei.cmu.edu/

7. SybaseDevel.Ru – русский портал для разработчиков. http://www.sybasedevel.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод установления правильности программ при помощи строгих средств известен как верификация программ.

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

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

спецификацию ввода-вывода (описание данных, не зависящих от процесса обработки);

свойства отношений между элементами векторов состояний в выбранных точках программы;

спецификации и свойства структурных подкомпонентов программы;

спецификацию структур данных, зависящих от процесса обработки.

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

Суть этого метода состоит в следующем:

1) формулируются входное и выходное утверждения: входное утверждение описывает все необходимые входные условия для программы (или программного фрагмента), выходное утверждение описывает ожидаемый результат;

2) предполагая истинным входное утверждение, строится промежуточное утверждение, которое выводится на основании семантики операторов, расположенных между входом и выходом (входным и выходным утверждениями); такое утверждение называется выведенным утверждением;

3) формулируется теорема (условия верификации):

из выведенного утверждения следует выходное утверждение;

4) доказывается теорема; доказательство свидетельствует о правильности программы (программного фрагмента).

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

Условия верификации можно построить и в обратном направлении, т.е., считая истинным выходное утверждение, получить входное утверждение и доказывать теорему:

из входного утверждения следует выведенное утверждение.

Такой метод построения условий верификации моделирует выполнение программы в обратном направлении. Другими словами, условия верификации должны отвечать на такой вопрос: если некоторое утверждение истинно после выполнения оператора программы, то, какое утверждение должно быть истинным перед оператором?

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

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

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

1) Построить структуру программы.

2) Выписать входное и выходное утверждения.

3) Сформулировать для всех циклов индуктивные утверждения.

4) Составить список выделенных путей.

5) Построить условия верификации.

6) Доказать условие верификации.

7) Доказать, что выполнение программы закончится.

Этот метод сравним с обычным процессом чтения текста программы (метод сквозного контроля). Различие заключается в степени формализации.

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

Для автоматизированной диалоговой системы программист должен задать индуктивные утверждения на языке исчисления предикатов. Синтаксис и семантика языка программирования должны храниться в системе в виде аксиом на языке исчисления предикатов. Система должна определять пути в программе и строить условия верификации.

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

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

Перечисленные методы имеют одно общее свойство: они рассматривают программу как уже существующий объект и затем доказывают ее правильность.

Метод, который сформулировали К. Хоар и Э. Дейкстра основан на формальном выводе программ из математической постановки задачи.

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

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

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

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

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

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

Различие между верификацией и валидацией проиллюстрировано на рисунке 1.

Приведенные определения получены некоторым расширением определений из стандарта IEEE 1012 на процессы верификации и валидации . В стандартном словаре терминов программной инженерии IEEE 610.12 1990 года определение верификации по смыслу примерно то же, а определение валидации несколько другое - там говорится, что валидация должна проверять соответствие полученного в результате разработки ПО исходным требованиям к нему. В этом случае валидация являлась бы частным случаем верификации, что нигде в литературе по программной инженерии не отмечается, поэтому, а также потому, что оно поправлено в IEEE 1012 2004 года, это определение следует считать неточным. Частое использование фразы B. Boehm"а :

Верификация отвечает на вопрос "Делаем ли мы продукт правильно?", а валидация- на вопрос "Делаем ли мы правильный продукт?"

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

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

Библиографический список

• В.В. Кулямин "Методы верификации программного обеспечения". Институт системного программирования РАН 109004, г. Москва, ул. Б. Коммунистическая, д. 25.
  http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf
• IEEE 1012-2004 Standard for Software Verification and Validation. IEEE, 2005.
• IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, February 1991.
• B. W. Boehm. Software Engineering; R&D Trends and Defense Needs. In R. Wegner, ed. Research. Directions in Software Technology. Cambridge, MA:MIT Press, 1979.
• ISO/IEC 12207 Systems and software engineering - Software life cycle processes. Geneva, Switzerland: ISO, 2008.