И. Соммервилл - Инженерия программного обеспечения (1133538), страница 109
Текст из файла (страница 109)
Тестирование сценариев часто оказывается более эффективным, чем другие методы тестирования. Сам процесс тестирования можно спланировать так, чтобы в первую очередь проверялись наиболее вероятные сценарии и только затем исквючительпые сцена. 20. Тестирование программного обеспечения 423 рии. Поэтому тестирование сценариев удовлетворяет основному принципу, согласно которому при тестировании больше внимания необходимо уделять наиболее часто используемым частям системы. Чтобы проиллкктрировать тестирование сценариев, вновь рассмотрим систему метеостанции.
Сценарии можно определить, исходя из разработанных вариантов использования, однако их может быть недостаточно для тестирования. Поэтому при планировании тестирования можно использовать диаграммы взаимодействия, отображающие реализацию вариантов использования посредством системных объектов. Рассмотрим рис. 20.13 (взятый из главы 12), на котором изображена последовательность операций, выполняемых при сборе метеоданных. Эту диаграмму можно использо. вать для определения тестируемых операций и для разработки тестовых сценариев. Рис. 20. 13.
Дияз)>ямал ноомд>интел ьносми сбоун> лгзиодлн них На р>к. 20.13 видно, что при получении запроса на отчет о метеоданных в системс бу. дет выполняться следующий поток методов> КонтропперКоммуникацнй:запрос -> Метеостанция:отчет -> МетеоДаиные:обобщение После выбора сценариев для тестирования системы важно убедиться, что все методы кюкдого класса будут выполплться хотя бы одни раз. Для этого можно составить технологическую карту проверок классов объектов и методов и при выборе сценария отмечать выполняемый метод.
Конечно, все комбинации методов выполнить невозможно, по по крайней мере люжно удостовериться, что все методы протестированы как часть какой- либо последовательности выполняемых методов. 20.4. Инструментальные средства тестирования Тестирование — дорогой и трудоемкий этап разработки программных систем. Поэтому создан широкий спектр инструментальных срелств для поддержки процесса тестиро.
ванна, которые значительно сокращают расходы на него. 424 'Часть и. Верификация и аттестация На рис. 20.14 показаны возможные инструментальные средства тестирования и отно. щения между ними. Перечислим их. 1. Ореляиэляюр ямсизз. Управляет выполнением тестов. Он отслеживает тестовые дан- ные, ожидаемые результаты и тестируемые функции программы. 2. Генеулгтюржгсзювык длинмк. Генерирует тестовые данные для тестируелюй программы.
Он может выбирать тестовые данные из базы данных или использовать специ. альные шаблоны для генерации случайных данных необходимого вида. Я. Оракул. Генерирует ожидаемые результаты тестов. В качестве оракулов могут выступать предыдущие версии программы или исследуемого объекта. При тестировании параллельно запускаются оракул и тестируемая программа и сравниваются результаты их выполнения, 4. Канларамзд файала. Сравнивает результаты тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях.
Компараторы особенно важны при сравнении различных версий программы. Различия в результатах указывают на возможные проблемы, существующие в новой версии системы. 5. Геягрлзар озгмякм. Формирует отчеты по результатам проведенил тестов. 6. Динамический пншиилзиф. Добавляет в программу код, который подсчитывает, сколько раз выполняется каждый оператор. После запуска теста создает исполняемый профиль, в котором показано, сколько раз в программе выполняется каждый оператор. 7.
Имкзюмо~. Существует несколько типов имитаторов. Целевые имитаторы моделируют машину, на которой будет выполняться программа. Имитатор пользовательского интерфейса — зто программа, управляемал сценариями, которая молелирует взаимодействия с интерфейсом пользователя. Имитатор ввода-вывода генерирует последовательности повторяющихся транзакций. Ркс.
20.34. Ияснручгятяллаяые сумдсзмл яисткукмлния 20. Тестирование программного обеспечения 425 Требования, предъявляемые к процессу тестирования больших систем, завнслт от типа разрабатываемого приложения. Поэтому инструментальные средства тестирования неизменно приходится адаптировать к процессу тестирования конкретной системы. Для создания полного комплекса инструментального средства тестирования, как правило, требуетсл много снл н времени.
Весь набор инструментальных средств, показанных на рнс. 20.14, используется только прн тестировании больших систем. Для таких систем полная стоимость тестирования может достигать 50% от всей стоимости разработки снс. темы. Вот почему выгодно инвестировать разработку высококачественных н производи. тельных САБЕ. средств тестирования. чньэьг 'о Фу'н ' ом"'~ 'йз~!юь' э~к '"':н %. " щ' г чэабэьь ФФ""»г "~;ЕПВПХЬЧ ":-' '"':.'::::,", ! ФфВМ Эъ Ъ.
-:КЕ' 'НЬГЬЧГ'1ЧММЩйак'444 КЛЮЧЕВЫЕ ПОНЯТИЯ . ':,':,:::::;"'.. ',-., ' ' 10 в-'г .и'.!4гг." 'айг~4фЩФ. гкфпяцм1йкчы дОЧГ «фкцч «-дзян КГжху"-ПО Сьнялкк:я уз» МУЗА% йГ гСФйдс-.фй ;-,'е'.;"'.,Прм тестировании систем прежде всего тестируются наиболее часто используемые части спсте- ' в.уьс ОбпаСГМг аКВНВапвНГНОСтп ЗХОдНЫХ дзННЫХ яВЛЛЮГСя Одпим йЗ СПОСОбОВ Првдртаепвипя 'Сцвиарйва ' 'ф~~ твсгнрованпя. Часто значения, которые с наибольшей вероятностью ведут к результативному тес', '„'~,"тированию, лежат на границе областей эквивалентности.; ,"~~МфсПРи гестпРованнн методам чеРного Ящика не ТРебУетса'достУп к исходномУ щи. Тйстовые данг ,;;:вьэ=' нью получают на основе программной спецификации. '.,- ',:: - " -' ' -::1Ч *-.
"'-э'-",:.' Во'вэршш тестирования системной сборки исслвдуюгся взаимодействия между компоненгамп сне; ', "„',; -' рамы н'ингерфейсамн компонентов, ' ° ".Фдафекты 'йнтерфейса часто возникают из-за ошибок, сделанных прн интерпретдгщн сппогфнгоацпн' ;;фтребований. Тестирование интерфейсов должю обнаруживать дефекты в интерфейсах обьектов н .:е~~ При шстирований классов обьектов следует гак проектйровагь гесты, чтобы провершь все нето-"' 4.'.: -' ," 'фудн, ассоциированные с классамн, апределшь н оценить все свойства обьекгов и протестировать :обьеку во всех возможных состоя ежг...::„- -' ' Упражнения 20.1.
Обсудите различии между тестированием методом черного ящика н структурным тестированием. Подумайте, каким образом можно совместно использовать эгп методы в процессе тестнровання дефектов. 20.2. Какие проблемы тестирования могуг возникнуть в программах, которые обрабатывают как очень больше, гак н очень малые числа? 20,3, Разработайте набор тестовых данных для следующих компонентов: ° программа сортировки массивов целых чисел; ° программа, каторая вычисляет количество символов (отличных от пробелов) в текстовых строках; ° программа, которая проверяет текстовые строки и заменяет последовательности пробелов сд. ним пробелом; ° объект, реализующий символьные строки разной длины. Среди операций, ассоциированных с этим объектом, должны быть операция конкатенации, операция определения длины строка н операция выбора подстроки.
20.4. Напишите код для первых трех перечисленных выше программ, используя любой язык программы. ровання. Для каждой программы рассчитайте цнкломатнческое число. 426 класть т'. Верифмкация и аз хестаххим 20.5. На примере небольшой программы покажите, почему практически невозможно полностью протестировать программу. 20.6. Для проверки созданных вами программ, разработайте контрольные тесты в дополнение к тем, которые уже были рассмотрены.
Выявил ли анализ корд упущения в первоначальных наборах тестовых данных? 20.7. Реализуйте (на языке йакв или С++( класс обьектов ЗтМВО(,ТАИ.Е, который будет использоваться как часть системы компиляции. Этот класс должен иметь следующие методы: добавление имени и типа данных в таблицу идентификаторов, удаление имени, изменение информации, связанной с именем, и поиск по таблице.
Организуйте инспектирование кода етого объекта (см, главу (9) и сделайте подсчет обнаруженных ошибок. Протестируйте объект методом черного ящика и сравните ошибки, выявленные при тестировании и при инспеюнровании. 20.8. Объясните, почему методы нисходящего и шкходящего тестирования не подходят дгш объектноориентированных систем. 20.9. Создайте сценарии тестировшшя состояний микроволновой печи, модель состояний которой гюказана на рис. 7.6. Аттестация критических систем И настоящей главе рассматриваются методы верификации н аттестации критических систем. Прочитав зту главу, вы должны: С1 знать преимущества и недостатки использования формальных методов верификации критических систем; иметь представление о методах оцепивания безотказности программных системы и модели возрастания безотказности; познакомиться с основной идеей доказательства безопасности и уметь доказывать невозможность появления аварийных ситуаций в системе.
!Содетйкан~е''."-',уды%%""» '. 4 Ж и'"з'1адж:.,т1к й М!:.ЙЫЙ 21.1. Формальные методы п критические системы 21.2. Аттестация безотказности 21.3. Гарантии безопасности 21.4. Оцениванпс защищенности ПО 428 'Часть Ч. Верификация и аттестация Верификация и аттестация критической системы имеют много общего с подобными процессами, выполняемыми над любой другой программной системой. В ходе этих про. цессов проверяется соответствие системы своей спецификации и соответствие поведения системы требованиям заказчика.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
