Ожидания пользователей. Здесь следует отметить, что у большинства пользователей в настоящее время очень низкие требования к программному обеспечению. Это связано с тем, что пользователи привыкли к разнообразным сбоям, которые происходят при работе с ПО, а значит, они не удивляются этому. Они согласны терпеть сбои в работе ПО, если выгода от использования ПО перекрывает недостатки. Однако, все же, в последнее время терпимость пользователей по отношению к ПО снижается. Создание недоброкачественного ПО становится недопустимым. Теперь фирмы, изготовляющие программные продукты, стремятся уделять больше внимания верификации и аттестации ПО. Еще один важный момент: условия рынка программных продуктов. При оценке программной системы разработчик должен знать конкурирующие системы, цену, которую покупатель согласен заплатить за продукт и назначенный срок выхода этой системы на рынок. Цель разработчика – не допустить выхода конкурирующей системы на рынок раньше. Если покупатели не желают приобретать ПО по высокой цене, они, возможно, согласны терпеть большее количество дефектов таких систем. При определении расходов на верификацию и аттестацию все эти факторы должны учитываться.
При проведении верификации и аттестации в системе, как правило, обнаруживаются ошибки, которые должны исправляться. После исправления ошибок необходимо снова проверить программу. Для этого можно еще раз выполнить инспектирование программы или повторить тестирование. Разработчик должен знать, что простых методов исправления ошибок в программах не существует. Повторное тестирование необходимо проводить для того, чтобы убедиться, что сделанные в программе изменения не внесли в систему новых ошибок, поскольку на практике высокий процент «исправления ошибок» либо не завершается полностью, либо вносит новые ошибки в программу. При разработке крупных систем каждое повторное тестирование всей системы обходится очень дорого; при этом для экономии средств определяют связи и зависимости между частями системы и проводят тестирование именно этих отдельных частей.
Верификация и аттестация – дорогостоящие процессы. Для сложных систем, например, характерно такое соотношение: половина всего бюджета, выделенного на реализацию системы, тратится на верификацию и аттестацию. Поэтому очевидна необходимость тщательного планирования верификации и аттестации.
Планирование верификации и аттестации должно начинаться как можно раньше. На рисунке 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 – программный продукт.
Из рисунка видно, что процесс верификации и аттестации разделяется на несколько этапов, причем на каждом этапе проводится определенный тест.
В процессе планирования верификации и аттестации необходимо определить соотношение между статическими и динамическими методами проверки системы, определить стандарты и процедуры инспектирования, составить план тестирования программ. От типа разрабатываемой системы зависит то, чему следует уделить больше внимания – инспектированию или тестированию. Чем более критична система, тем больше внимания следует уделять статическим методам верификации.
План испытаний ПО обязательно должен включать в себя: описание основных этапов процесса тестирования, возможность отслеживания требований (тестирование следует спланировать так, чтобы протестировать все требования в отдельности), тестируемые элементы (следует определить все «выходные» продукты процесса разработки ПО, которые необходимо тестировать), график тестирования (составляется временной график тестирования и распределение ресурсов проводится согласно этому графику, причем график тестирования привязан к более общему графику разработки проекта), процедуры записи тестов (для проверки правильности выполнения тестов), аппаратные и программные требования, ограничения (попытаться предвидеть все неблагоприятные факторы, влияющие на процессы тестирования, например, нехватку средств, персонала…).
Подобно другим планам, план испытаний не является неизменным документом. Его следует регулярно пересматривать, так как тестирование зависит от процесса реализации системы. Например, если реализация какой-либо части систем не завершена, то невозможно провести тестирование сборки системы. Пересмотр плана позволяет использовать сотрудников (не занятых в данный момент) на других работах.
Системное тестирование программ требует разработки огромного количества тестов, их выполнения и проверки. Это значит, что данный процесс достаточно трудоемкий и дорогостоящий. Каждый тест способен обнаружить в программе одну, реже несколько ошибок. Причина такого положения заключается в том, что сбои в работе, происходящие из-за ошибок в системе, часто приводят к разрушению данных. Поэтому сложно сказать, какое количество ошибок «ответственно» за сбой в системе.
Инспектирование программ не требует от последних быть завершенными, поэтому инспектировать можно даже на начальных стадиях разработки. Во время инспектирования проверяется исходное представление системы. Это может быть модель системы, спецификация или программа, написанная на языке высокого уровня. Обнаружение ошибок достигается путем использования знаний рассматриваемой системы и семантики ее исходного представления. Каждую ошибку можно рассмотреть отдельно, не обращая внимания на то, как она влияет на поведение системы.
Доказано, что инспектирование является эффективным методом обнаружения ошибок, причем оно значительно дешевле экстенсивного тестирования. Инспектированием можно обнаружить более 60% всех ошибок, а при более формальном подходе (используя математические методы) – более 90%. Процесс инспектирования также может оценить другие качественные характеристики систем: соответствие стандартам, переносимость и удобства сопровождения.
В системных компонентах выявление ошибок путем инспектирования более эффективно, чем путем тестирования. Во-первых, за один сеанс инспектирования можно обнаружить очень многие дефекты программного кода; при применении тестирования за один сеанс обнаруживается обычно лишь одна ошибка, поскольку ошибки могут привести к полному останову (отказу) системы, а эффекты ошибок могут накладываться друг на друга. Во-вторых, инспектирование использует знание о предметной области и языке программирования. Специалист, проводящий инспектирование, должен знать типы ошибок, что дает возможность сосредоточиться на конкретных видах дефектов.
Понятно, что инспектирование не может заменить тестирование. Инспектирование лучше применять на начальных стадиях для выявления наибольшего количества ошибок. Инспектированием проверяют соответствие ПО его спецификации, но таким способом, например, невозможно оценить динамическое поведение системы. Более того, нерационально инспектировать законченные системы, собранные из нескольких подсистем. На этом уровне возможно только тестирование.
Ошибочно полагать, что тестирование и инспектирование являются конкурирующими методами верификации и аттестации. У каждого из них есть свои преимущества и недостатки. Следовательно, в процессе верификации и аттестации инспектирование и тестирование следует использовать совместно.
Иногда при инспектировании в организации возникают трудности. Эксперты, имеющие большой опыт в тестировании программ, неохотно соглашаются с тем, что инспектирование является более эффективным методом устранения дефектов системы, чем тестирование. Менеджеры относятся к этим технологиям с недоверием, потому что внедрение инспектирования требует дополнительных расходов. Конечная экономия средств при применении инспектирования достигается только благодаря опыту проводящих его специалистов.
Инспектирование программ – это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованного процесса проверки программ была сформулирована корпорацией IBM в 1970-х годах. В настоящее время данный метод верификации получил широкое распространение. На его базе разработано множество других методов, но все они основываются на базовой идее метода инспектирования, согласно которому группа специалистов выполняет тщательный построчный просмотр и анализ исходного кода программы. Главное отличие инспектирования от других методов оценивания качества программ состоит в том, что его цель – обнаружение дефектов, а не исследование общих проблем проекта. Дефектами являются либо ошибки в исходном коде, либо несоответствия программы стандартам.
Процесс инспектирования – формализованный. В нем принимает участие небольшая группа людей (обычно не более, чем четыре человека). У каждого в группе есть своя роль. Обязательно должны присутствовать: автор, рецензент, инспектор, координатор. Рецензент «озвучивает» программный код, инспектор проверяет его, координатор отвечает за организацию процесса. По мере накопления опыта инспектирования в организациях могут появляться другие предложения по распределению ролей в группе (например, одно лицо может исполнять несколько ролей, поэтому количество членов в группе инспектирования может варьироваться).
Для начала процесса инспектирования программы необходимы следующие условия: наличие точной спецификации кода (без полной спецификации невозможно обнаружить дефекты в проверяемом программном компоненте); члены инспекционной группы должны хорошо знать стандарты разработки; в распоряжении группы должна быть синтаксически корректная последняя версия программы (нет смысла рассматривать код, который «почти завершен»).
Страницы: 1, 2, 3, 4
