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

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

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

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

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

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

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

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

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

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

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

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

2.1. Интеграционные свойства систем

2.2. Система и ее окружение

2.3. Моделирование систем

2.4. Процесс создания систем

2.5. Приобретение систем

3. Процесс создания программного обеспечения

3.1. Модели процесса создания программного обеспечения

3.2. Итерационные модели разработки программного обеспечения

3.3. Спецификация программного обеспечения

3.4. Проектирование и реализация программного обеспечения

3.5. Эволюция программных систем

3.6. Автоматизированные средства разработки программного обеспечения

4. Технологии производства программного обеспечения

Часть II. Требования к программному обеспечению

5. Требования к программному обеспечению

5.1. Функциональные и нефункциональные требования

5.2. Пользовательские требования

5.3. Системные требования

5.4. Документирование системных требований

6. Разработка требований

6.1. Анализ осуществимости

6.2. Формирование и анализ требований

6.3. Аттестация требований

6.4. Управление требованиям

7. Матрица требований. Разработка матрицы требований

Часть III. Моделирование программного обеспечения

8. Архитектурное проектирование

8.1. Структурирование системы

8.2. Модели управления

8.3. Модульная декомпозиция

8.4. Проблемно-зависимые архитектуры

9. Архитектура распределенных систем

9.1. Многопроцессорная архитектура

9.2. Архитектура клиент/сервер

9.3. Архитектура распределенных объектов

9.4. Corba

10. Объектно-ориентированное проектирование

10.1. Объекты и классы объектов

10.2. Процесс объектно-ориентированного проектирования

10.2.1. Окружение системы и модели ее использования

10.2.2. Проектирование архитектуры

10.2.3. Определение объектов

10.2.4. Модели архитектуры

10.2.5. Специфицирование интерфейсов объектов

10.3. Модификация системной архитектуры

11. Проектирование систем реального времени

11.1. Проектирование систем реального времени

11.2. Управляющие программы

11.3. Системы наблюдения и управления

11.4. Системы сбора данных

12. Проектирование с повторным использованием компонентов

12.1. Покомпонентная разработка

12.2. Семейства приложений

12.3. Проектные паттерны

13. Проектирование интерфейса пользователя

13.1. Принципы проектирования интерфейсов пользователя

13.2. Взаимодействие с пользователем

13.3. Представление информации

13.4. Средства поддержки пользователя

13.5. Оценивание интерфейса

Часть IV. Технологии разработки программного обеспечения

14. Жизненный цикл программного обеспечения: модели и их особенности

14.1. Каскадная модель жизненного цикла

14.2. Эволюционная модель жизненного цикла

14.2.1. Формальная разработка систем

14.2.2. Разработка программного обеспечения на основе ранее созданных компонентов

14.3. Итерационные модели жизненного цикла

14.3.1 Модель пошаговой разработки

14.3.2 Спиральная модель разработки

15. Методологические основы технологий разработки программного обеспечения

16. Методы структурного анализа и проектирования программного обеспечения

17. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml

Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения

18. Документирование этапов разработки программного обеспечения

19. Планирование проекта

19.1 Уточнение содержания и состава работ

19.2 Планирование управления содержанием

19.3 Планирование организационной структуры

19.4 Планирование управления конфигурациями

19.5 Планирование управления качеством

19.6 Базовое расписание проекта

20. Верификация и аттестация программного обеспечения

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

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

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

20.4. Метод "чистая комната"

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

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

21.1.1. Тестирование методом черного ящика

21.1.2. Области эквивалентности

21.1.3. Структурное тестирование

21.1.4. Тестирование ветвей

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

21.2.1. Нисходящее и восходящее тестирование

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

21.2.3. Тестирование с нагрузкой

21.3. Тестирование объектно-ориентированных систем

21.3.1. Тестирование классов объектов

21.3.2. Интеграция объектов

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

Часть VI. Управление проектом программного обеспечения

22. Управление проектами

22.1. Процессы управления

22.2. Планирование проекта

22.3. График работ

22.4. Управление рисками

23. Управление персоналом

23.1. Пределы мышления

23.1.1. Организация человеческой памяти

23.1.2. Решение задач

23.1.3. Мотивация

23.2. Групповая работа

23.2.1. Создание команды

23.2.2. Сплоченность команды

23.2.3. Общение в группе

23.2.4. Организация группы

23.3. Подбор и сохранение персонала

23.3.1. Рабочая среда

23.4. Модель оценки уровня развития персонала

24. Оценка стоимости программного продукта

24.1. Производительность

24.2. Методы оценивания

24.3. Алгоритмическое моделирование стоимости

24.3.1. Модель сосомо

24.3.2. Алгоритмические модели стоимости в планировании проекта

24.4. Продолжительность проекта и наем персонала

25. Управление качеством

25.1. Обеспечение качества и стандарты

25.1.1. Стандарты на техническую документацию

25.1.2. Качество процесса создания программного обеспечения и качество программного продукта

25.2. Планирование качества

25.3. Контроль качества

25.3.1. Проверки качества

25.4. Измерение показателей программного обеспечения

25.4.1. Процесс измерения

25.4.2. Показатели программного продукта

26. Надежность программного обеспечения

26.1. Обеспечение надежности программного обеспечения

26.1.1 Критические системы

26.1.2. Работоспособность и безотказность

26.1.3. Безопасность

26.1.4. Защищенность

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

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

26.4. Оценивание защищенности программного обеспечения

27. Совершенствование производства программного обеспечения

27.1. Качество продукта и производства

27.2. Анализ и моделирование производства

27.2.1. Исключения в процессе создания по

27.3. Измерение производственного процесса

27.4. Модель оценки уровня развития

27.4.1. Оценивание уровня развития

27.5. Классификация процессов совершенствования

20. Верификация и аттестация программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приведенные определения получены некоторым расширением определений из стандарта 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.