И. Соммервилл - Инженерия программного обеспечения (1133538), страница 100
Текст из файла (страница 100)
лице идентификаторов, а отгуда к значениям переменных. Пользователи часто контролируют выполнение программы пошаговым способом, последовательно переходя от оператора к оператору. После выполнения каждого оператора проверяются значения переменных и выявляются возможные ошибки. Обнаруженная в программе ошибка исправляется, после чего необходимо снова проверить программу. Для этого можно еще раз выполнить инспектирование программы или повторить предыдущее тестирование. Повторное тестирование используется для того, чтобы убедиться, что сделанные в программе изменения не внесли в систему новых оши.
бок, поскольку на практике высокий процент"исправления ошибок" либо не завершается полностью, либо вносит новые ошибки в программу. В принципе во время повторного тестирования после каждого исправления необходимо еще раз запускать все тесты, однако на практике такой подход оказывается слишком дорогостоящим. Поэтому при планировании процесса тестирования определяются зависимости между частями системы и назначаются тесты для каждой части.
Тогда можно трассировать программные элементы с помощью специальных контрольных примеров (контрольных данных), подобранных для этих элементов. Если результаты трассировки задокументированы, то для проверки измененного программного элемента и зависимых от него компонентов можно использовать только некоторое подмножество всего множества тестовых данных. 19.1.
Планирование верификации и аттестации Верификация и аттестация — дорогостоящий процесс, Для больших систем, например систем реального времени со сложными нефункциональными ограничениями, половина бюджета, выделенного на разработку системы, тратится на процесс верификации и атте. стации. Поэтому очевидна необходимость тщательного планирования данною процесса. Планирование верификации и аттестации, как один из этапов разработки программных систем, должно начинаться как можно раньше. На рис.
19.3 показана модель разработки ПО, учитывающая процесс планирования испытаний. Здесь планирование начинается еще на этапах создания спецификации и проектирования системы. Данную модель иногда называют Ч.моделью (чтобы увидеть букву Ч, необходимо повернуть рис. 19.3 на 90'). На этой схеме также показано разделение процесса верификации и аттестации на не.
сколько этапов, причем на каждом этапе выполняются соответствующие тесты. 390 'Часть У. Верификации и аттестации Рис 19З. Плпнировпиие иены тпиий в проиеесе реирпботки и тестировлнип В процессе планирования верификации и аттестации необходимо определить соотношение между статическими и динамическими методами проверки системы, определить стандарты и процедуры инспектирования и тестирования ПО, утвердить технологиче. скую карту проверок программ (см.
раздел 19.2) и составить план тестирования программ. Чему уделить больше внимания — инспектированию или тестированию, зависит от типа разрабатываемой системы и опыта организации. Чем более критична система, тем больше внимания необходимо уделить статическим методам верификации. 'Врбзйа19.'4;".' '"' ' "' ЪйиУд':исйыУаний Пб':!~4Вба~Я~:,':!".'~"::: ' ". Ю .".:.. е ~ шдеентвтиезен: еТЕСтнроыаывсяащяи СняеиирсяатЬ таИМ Обрашы,: ПабыерамйввхяяцнщГЛрв6сыттИя В ащауйГОСтгп' Составяяется временнад график тестирования и рвспредштемьйнв ' -соглй: ' ' урбфнку. Оче.' .„видно, что графгмлестированндрриввзвдд4общее,общюмугрф)йку рйрабрры,.' ' " "тр,.„, .ец .
ог1рсцвдуры'записи тестов "" ич~~ФЙл~их-'-". г к .'хлкбк... пеке:,' твп" ." ., об "~ гзМ 'Недосшпнна тояйа проводнть тест|в-'результаты шсшрофшйятфобходимо " ', ' 'янзйейевть,': дппаРатнвые и пРогРаммные тпвбсаениЯ".,:.., =...",;;; 1г"'-Вб4 вы~;.~ ' , В атон разделе следует попытаться предвидеть: все„йеблагойривпфа фй~ор~~фИяхядне'да,,причуд",.". тестирования, например нехватку персонала. 19. Верификация и аттестация ПО 391 В плане верификации и аттестации основное внимание уделяется стандартам процесса тестирования, а не описанию конкретных тестов. Этот план предназначен не только для руководства, он в основном предназначен специалистам, занимающимся разработкой и тестированием систем.
План дает возможность техническому персоналу получить полную картину испытаний системы и в этом контексте спланирдвать свою работу. Кроме того, план предоставляет информацию менеджерам, отвечающим за то, чтобы у группы тестирования были все необходимые аппаратные и программные средства. Основные компоненты плана испытаний ПО перечислены во врезке 19.1. Хорошее описание подобных планов и их взаимосвязи с более общими планами обеспечения качества представлено в работе [118].
Подобно другим планам, план испытаний не является неизменным документом. Его следует регулярно пересматривать, так как тестирование зависит от процесса реализации системы. Например, если реализация какой-либо части системы не завершена, то невозможно провести тестирование сборки системы. Поэтому план необходимо периодически пересматривать, чтобы сотрудников, занятых тестированием, можно было использовать на других работах. 19.2. Инспектирование программных систем Системное тестирование программ требует разработки огромного количества тестов, их выполнения и проверки.
Это значит, что данный процесс достаточно трудоемкий и дорогостоящий. Каждый тест позволяет обнаруживать одну, а в лучшем случае несколько ошибок в программе. Причина такого положения заключается в том, что сбои в работе, происходящие из-за ошибок в системе, часто приводят к разрушению данных.
Поэтому трудно сказать, какое количество ошибок "ответственно" за сбой в системе. Инспектирование программ не требует их исполнения, поэтому данный метод можно использовать до завершения полной реализации программ. Во время инспектирования проверяется исходное представление системы, Это может быть модель системы, специ. фикация или программа, написанная на языке высокого уровня. Для обнаружения ошибок используется знание разрабатываемой системы и семантика ее исходного представления. Каждую ошибку можно рассматривать отдельно, не обращая внимания на то, как она влияет на поведение системы. Доказано, что инспектирование является эффективным методом обнаружения ошибок.
Также нсмаловюкно, что инспектирование значительно дешевле экстенсивного тестирования программ. И экспериментах, описанных в работе [27], сравнивалась эффективность инспектирования и тестирования. Инспектирование программного кода оюза- лось более эффективным и менее дорогостоящим, чем тестирование.
Такие же выводы сделаны в работе [129). И статье [112] утверждается, что более б0% ошибок в программах можно обнаружить с помощью неформального исследования (инспектирования) программ. При более формальном подходе, использующем математические методы, в программе можно обнаружить более 90% всех ошибок [239). Такая проверка используется в процессе разработки систем методом "чистая комната", который рассматривается в разделе 19.4, Процесс инспектирования также может оценить другие качественные характеристики систем. соот.
ветствие стандартам, переносимость н удобство сопровождения. Качествепныс характеристики систем рассматриваются в главе 24. В системных компонентах и подсистемах вылвление ошибок путем просмотра н нпспек. тирования обычно более эффективно, чем с помощью тестирования, по двум причинам. 392 Часть Ч. Верификация и аттестация 1. За один сеанс инспектирования можно выявить множесгво разнообразных про. граммных дефектов. Недостатком тестирования является то, что обычно эа один сеанс тесгировання можно обнаружить только одну ошибку, поскольку ошибки мо. тут привести к отказу системы или их эффекты мокнут накладываться друг на друга.
2. Инспектирование Йсп]зльзует знания о предметной области и языке программирования. Специалист, проводлщий инспектирование, должен знать типы ошибок, присущие конкретным языкам программирования и приложениям определенного типа. Поэтому в ходе анализа програим есть возможность сосредоточиться только на конкретных типах ошибок.
Конечно, инспектирование не может полностью заменить тестирование. Инспектиро. ванне лучше испольэовать как начальный процесс верификации для обнаружения большей части программных дефектов. Путем инспектирования проверяют соответствие ПО ее спецификации, однако таким способом нельзя проверить динамическое поведение сис. темы. Более того, нерационально инспектировать законченные системы, собранные из нескольких подсистем.
На этом уровне возможно только тестирование. Тестирование также необходимо для оценки надежности и производительности, проверки пользовательского интерфейса и соответствия системы требованиям заказчика. Инспекгирование и тестирование не являются конкурирующими методами верификации и аттестации. Каждому из них присущи свои преимугцества и недостатки, поэтому в процессе верификации и атгестации их следует использовать совместно. Одним из наиболее эффективных методов инспектирования является применение контрольных примеров [129]. В этом случае можно обнаружить програимные дефекты и разработать более эффективные методы тестирования системы.
Иногда при инспектировании в организации, разрабатывающей традиционное программное обеспечение, возникают трудности. Разработчики, имеющие опыт тестирования программ, неокотно соглашаются с тем, что инспектирование оказывается более эф фективным методом выявления ошибок, чем тестирование. Менеджеры относятся к этим технологиям с недоверием, потому что внедрение инспекгирования на этапах проектирования и разработки требует дополнительных расходов, Инспектирование всегда требует расходов, причем на начальном этапе разработки ПО, а конечная зкономия средств вследствие применения инспектирования достигается только благодаря опьпу проводящих его специалистов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
