Рис. 2.2. Процесс инспектирования
На рис. 2.2 показан общий процесс инспектирования. Он адаптирован к требованиям организаций, использующих инспектирование программ.
Сам процесс инспектирования должен быть относительно коротким (не более двух часов) и сосредоточенным только на выявлении дефектов, аномалий и несоответствий стандартам. Инспекционная группа не должна предлагать способы исправления дефектов или рекомендовать какие-либо изменения в других программных компонентах.
После инспектирования автор изменяет программу, исправляя обнаруженные ошибки. На этапе доработки координатор принимает решение о том, необходимо ли повторное инспектирование. Если повторное инспектирование не требуется, все обнаруженные дефекты фиксируются документально.
В процессе инспектирования организация накапливает определенный опыт, поэтому результаты инспектирования можно использовать для улучшения всего процесса разработки ПО. В ходе инспектирования выполняется анализ обнаруженных дефектов. Группа инспектирования и авторы инспектируемого кода определяют причины возникновения дефектов. Чтобы подобные дефекты не возникали в будущих системах, необходимо по возможности устранить причины возникновения дефектов, что означает внесение изменений в процесс разработки программных систем.
Обеспечение инспектирования ПО требует квалифицированного управления и правильного отношения к результатам его проведения. Инспектирование – открытый процесс обнаружения ошибок, когда ошибки, допущенные отдельным программистом, становятся известны всей группе программистов. Менеджеры должны четко разграничивать инспектирование программного кода и оценку кадров. При оценке профессиональных качеств ни в коем случае нельзя учитывать ошибки, обнаруженные в процессе инспектирования. Руководителям инспекционных групп необходимо пройти тщательную подготовку, чтобы грамотно управлять процессом и совершенствовать культуру отношений, которая гарантировала бы поддержку в процессе обнаружения ошибок и отсутствие каких-либо обвинений в связи с этими ошибками.
Статические анализаторы программ – это инструментальные программные средства, которые сканируют исходный текст программы и выявляют возможные ошибки и противоречия. Для анализаторов не требуется исполняемая программа. Они выполняют синтаксический разбор текста программы, распознают различные типы операторов. С помощью анализаторов можно проверить, правильно ли составлены операторы, сделать выводы относительно потока управления в программе и во многих случаях вычислить множество значений данных, используемых программой. Анализаторы дополняют средства обнаружения ошибок, предоставляемые компилятором языка.
Цель автоматического статического анализа – привлечь внимание проверяющего к аномалиям в программе, например, к переменным, которые используются без инициализации или инициализированы, но в программе не использовались.
Статический анализ состоит из нескольких этапов.
1. Анализ потока управления. Идентификация и выделение циклов, их точек входа и выхода, выявление неиспользуемого кода.
2. Анализ использования данных. Проверка переменных в программе. На этом этапе также можно выявить условные операторы с избыточными условиями.
3. Анализ интерфейса. Проверка согласованности различных частей программы, правильности объявления процедур и их использования. Данный этап оказывается лишним, если используется язык со строгим контролем типов.
4. Анализ потоков данных. Определяются зависимости между входными и выходными переменными. Хотя этот анализ не выявляет конкретных ошибок, он дает полный список значений, используемых в программе. Следовательно, легко обнаруживается ошибочный вывод данных.
5. Анализ ветвей программы. На этом этапе семантического анализа определяются все ветви программы и выделяются операторы, исполняемые в каждой ветви. Анализ ветвей программы существенно помогает разобраться в управлении программой и позволяет проанализировать каждую ветвь отдельно.
Следует отметить, что анализ потока данных и анализ ветвей программы генерируют огромное количество информации. Эта информация не выявляет конкретных ошибок, а представляет программу в разных аспектах. Из-за огромного количества генерируемой информации эти этапы иногда исключают из процесса анализа и используют только на ранних стадиях для обнаружения аномалий в разрабатываемой программе. Статические анализаторы особенно полезны в тех случаях, когда используются языки программирования, подобные С. В языке С нет строгого контроля типов, и потому проверка, осуществляемая компилятором языка С, ограничена. В этом случае средствами статического анализа выявляется широкий спектр ошибок, что особенно важно при разработке критических систем.
Анализ с помощью инструментальных средств не может заменить инспектирования, так как существуют такие типы ошибок, которые невозможно выявить с помощью статического анализа. Например, анализаторы способны обнаружить необъявленные переменные, однако они не смогут обнаружить неправильного присвоения. Конечно, для таких языков, как С, статический анализ является эффективным методом обнаружения ошибок. Но в современных языках (типа Java) удалены конструкции, способствующие появлению многих ошибок. Все переменные должны быть объявлены, отсутствуют операторы безусловного перехода, вследствие чего маловероятно случайное создание неиспользуемого кода, и осуществляется автоматическое управление памятью.
При разработке ПО методом «чистая комната» для устранения дефектов используется процесс строгого инспектирования. Цель данного метода – создание ПО без дефектов. Название «чистая комната» взято по аналогии с производством кристаллов полупроводников, где выращивание кристаллов без дефектов происходит в сверхчистой атмосфере (чистых комнатах).
В разработке ПО методом «чистая комната» выделяют пять ключевых моментов:
1. Формальная спецификация. Разрабатывается формальная спецификация. Для записи спецификации используется модель состояний, в которой отображены отклики системы.
2. Пошаговая разработка. Разработка ПО разбивается на несколько этапов, которые проверяются методом «чистая комната» независимо друг от друга.
3. Структурное программирование. Используется ограниченное количество управляющих конструкций. Процесс разработки программы – это процедура поэтапной детализации спецификации.
4. Статическая верификация. Проверка статическим методом строгого инспектирования ПО. Для отдельных элементов тестирование кода не проводится.
5. Статическое тестирование системы. На каждом шаге проводится тестирование статическими методами, позволяющими оценить надежность программной системы.
На первых этапах разработки ПО методом «чистая комната» реализуются наиболее критичные для заказчика системные функции. Менее важные системные функции добавляются на последующих этапах. Таким образом, у заказчика есть возможность испытать систему до полной ее реализации.
Процесс разработки ПО методом «чистая комната» планируется таким образом, чтобы обеспечить строгое инспектирование программ, которое сопровождается строгими математическими доказательствами согласованности и корректности преобразований.
Обычно разработкой больших систем методом «чистая комната» занимаются три группы разработчиков: группа спецификации, группа разработки (разрабатывает и проверяет ПО), группа сертификации (разрабатывает контрольные тесты).
В результате использования метода «чистая комната» программный продукт содержит крайне мало ошибок, а его стоимость меньше, чем у разработанного традиционными методами. В процессе разработки этим методом оказывается рентабельной статическая проверка. Огромное количество дефектов обнаруживается еще до исполнения программы и исправляется в процессе разработки ПО.
При планировании процесса верификации и аттестации ПО менеджеры проекта должны определить, кто будет отвечать за разные этапы тестирования. Во многих случаях за тестирование своих программ, модулей или объектов несут ответственность программисты. За следующий этап отвечает группа системной интеграции (сборки), которая интегрирует отдельные программные модули в единую систему и тестирует эту систему в целом.
Для критических систем процесс тестирования должен быть более формальным. Такая формализация предполагает, что за все этапы тестирования отвечают независимые испытатели, все тесты разрабатываются отдельно, и во время тестирования ведутся подробные записи. Чтобы протестировать критические системы, независимая группа разрабатывает тесты, исходя из спецификации каждого компонента. При разработке некритических систем подробные спецификации для каждого компонента не создаются. Таким образом, тестирование компонентов, как правило, основывается только на понимании разработчиками того, что должен делать компонент.
Тестирование сборки должно основываться на имеющейся спецификации системы.
В контексте тестирования между объектно-ориентированными системами (ООС) и функционально-ориентированными (ФОС) системами имеется ряд отличий. В ФОС существует четкое различие между основными программными элементами и совокупностью этих элементов. В ООС этого нет. Следовательно, в ООС между тестированием компонентов и тестированием сборки нет четких границ. В таких системах процесс тестирования является продолжением процесса разработки.
Целью тестирования дефектов является выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование дефектов противоположно аттестации, в ходе которой проверяется соответствие системы своей спецификации. Во время аттестации система должна корректно работать со всеми заданными тестовыми данными. При тестировании дефектов запускается такой тест, который вызывает некорректную работу программы, и, следовательно, выявляет дефект. Тестирование дефектов демонстрирует наличие, а не отсутствие дефектов в программе.
Страницы: 1, 2, 3, 4
