Программы верификации что это

Валидация и верификация требований к системе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Верификация и валидация

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

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

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

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

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

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

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

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

Источник

Верификация и валидация ПО: технологии и инструменты

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

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

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

Сегодня организации вкладывают около 30% бюджета, выделяемого на ИТ, в обеспечение качества и тестирование, что неудивительно — более половины всех систем являются критически важными для бизнеса [1]. При этом компаниям и организациям необходимо максимально гибко реагировать на изменения и внедрять формализованные процессы и методы контролируемого выпуска безопасного ПО. Активно внедряются механизмы автоматического обновления ПО по Сети, методы DevOps и «непрерывная инженерия» (continuous software engineering) [2], что повышает потребность в процессах непрерывной верификации и валидации, требующих намного более тщательного, чем еще совсем недавно, выполнения процедур испытания на общую работоспособность.

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

Выбор методов верификации и валидации ПО зависит от модели разработки (V-модель, каскадная, спиральная и т. д.) и стандарта (ISO/IEC 25000 SQUARE, ISO/IEC 12207:2017) (рис. 1).

Рис. 1. Стандарты обеспечения качества процесса разработки ПО и конечного продукта

За качество собственно процесса разработки ПО отвечают стандарт ISO/МЭК 12207, регламентирующий процессы верификации и валидации, а также V-модель, в рамках которой каждой задаче разработки ставится в соответствие процесс тестирования. Например, модульный тест проверяет соответствие исходного кода низкоуровневой архитектуре, интеграционные тесты проверяют совместимость (интеграцию) ранее протестированных компонентов, системные тесты позволяют выяснить, соответствует ли полностью интегрированный продукт спецификациям, а приемочные тесты — отвечает ли продукт ожиданиям пользователя.

В стандартах серии ISO 25000, относящихся к качеству программного продукта, выделены следующие характеристики ПО:

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

Рис. 2. Инструменты для проверки основных характеристик качества ПО

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

Технологии и инструменты

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

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

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

Инструментов тестирования так же много, как и языков программирования. В табл. 1 приведены основные средства тестирования для первой десятки наиболее популярных языков программирования (согласно рейтингу Tiobe).

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

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

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

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

Средства непрерывной верификации и валидации. Принцип непрерывного обеспечения качества предполагает тесную интеграцию процессов верификации и валидации на всех этапах разработки. Типичный пример — разработка с ориентацией на тестирование: плановые показатели качества задаются еще до разработки ПО. С учетом преимуществ непрерывной интеграции, одной из основ DevOps, все большее значение придается инструментам, помогающим не только автоматизировать верификацию и валидацию, но и интегрировать эти процессы в цикл разработки. Перечисленные в табл. 6 инструменты позволяют проверять характеристики качества в рамках сред непрерывной интеграции Jenkins, Travis CI, Bamboo, GoCD, Ansible и т. п. Требуется встроить валидацию и верификацию в жизненный цикл ПО, обеспечив автоматическое, прозрачное для разработчиков выполнение соответствующих процессов. Представленные в табл. 6 инструменты проверяют несколько характеристик качества и позволяют получить данные для глобальной оценки и визуализации. В рамках процессов непрерывной верификации и валидации также могут применяться инструменты модульного тестирования, фиксации и замены и статического анализа.

Для управления действиями, выполняемыми при помощи всех перечисленных видов инструментов, и контроля над процессом верификации и валидации в целом, применяются средства управления тестовыми случаями: Test Link, Test Rail, Microfocus Quality Center, VSTS, IBM Rational Quality Manager, XStudio и др.

Перспективы

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

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

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

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

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

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

1. Capgemini. MicroFocus, and Sogeti. World quality report. 2018. [Online]. URL: https:// www.capgemini.com/service/world-quality-report-2018-19/ (дата обращения: 16.05.2019).

2. B. Fitzgerald, K. Stol. Continuous software engineering: A roadmap and agenda // J. Syst. Softw.— 2017 (Jan). — Vol. 123. — P. 176–189.

Моисес Родригес (mrodriguez@aqclab.es) — доцент, Марио Пьяттини (mario.piattini@uclm.es) — профессор, Университет Кастилии-Ла-Манчи (Испания); Кристоф Эберт (christof.ebert@vector.com) — директор, Vector Consulting Services.

Moises Rodriguez, Mario Piattini, Christof Ebert, Software Verification and Validation Technologies and Tools. IEEE Software, March/April 2019, IEEE Computer Society. All rights reserved. Reprinted with permission.

Поделитесь материалом с коллегами и друзьями

Источник