И. Соммервилл - Инженерия программного обеспечения (1133538), страница 108
Текст из файла (страница 108)
В языках со строгил» ко»»тролсл» типов, »»април»ер Яака, многие оя»ибкн интерфейсов помогает обнаружить компилятор. В языках со слабым ко»»тролем типов (например, С) ошибки интерфейса может выявить статический анализатор, такой как 1.!ХТ (см. главу !9). Кроме того, прн инспектировании програмл» можно сосредото. читься именно на проверке интерфейсов компонентов. 420 Часть У. Верификация и аттестация 20.2.3.
Тестирование с нагрузкой После полной интеграции системы можно оценить такие интеграционные свойства системы (сьь главу 2), как производительность и надежность. Чтобы убедиться, что система может работать с заданной нагрузкой, разрабатываются тесты для измерения произво. дительностн. Обычно планируются серии тестов с постоянным увеличением нагрузки, пока производительность системы пе начнет снижаться.
Некоторые классы систем проектируются с учетом работы под определенной нагрузкой. Например, система обработки трапеций проектируется так, чтобы обрабатывать 100 транзакций в секунду; сетевая операционная система — чтобы обрабатывать информацию от 200 отдельных терминалов. При тестировании с нагрузкой выполнение тестов начинается с максимальной нагрузки, укаэанной в проекте системы, и продолжается до тех пор, пока не произойдет сбой в работе системы. Данный тип тестирования выполняет две функции. 1.
Тестируется поведение системы во время сбоя. В процессе эксплуатации но~ус возникать ситуации, при которых нагрузка в системе превышает максимально допус. тимую. В таких ситуациях очень важно, чтобы сбой в системе ие приводил к нарушению целостности данных или к потере сервисных возможностей. 2. Чтобы выявить дефекты, которые не проявляются в обычных режимах работы, система подвергается тестированию с нагрузкой.
Хотя подобные дефекты не приводят к ошибкам при обычном использовании системы, на практике люг1т возникнуть необычные комбинации стандартных условий; именно они воспроизводятся во время тестирования с нагрузкой. Тестирование с нагрузкой чаще всего применяется в распределенных системах. В таких системах при болыцой нагрузке сеть порой "забивается" данными. которыми обмениваются разные процессы. Постепенно процессы все больше замедляются, поскольку они ожидают данные запросов от других процессов. 20.3. Тестирование объектноориентированных систем Мы рассмотрели два основных подхода к тестированию программного обеспечения— компонентное тестирование, при котором компоненты системы тестируются независимо друг от друга, и тестирование сборки, когда компоненты интегрированы в подсистемы н тестируется конечиал система.
Эгп подходы в равной мере применимы и к объектноориентированным системам. Однако системы, разработанные по функциональной модели, и объектно.ориентированные системы имеют существенные отличия. 1. Объекты, как отдельные программные коипонеиты, представляют собой нечто большее, чем отдельные подпрограммы или функции. 2. Объекты, интегрированные в подсистемы, обычно слабо связаны между собой н поэтому сложно определить "самый верхний уровень" системы. 3.
При анализе повторно используемых объектов их исходный код может быть недоступным для испытателей. Эти отличия означают, что прн проверке объектов можно применять тестирование методом белого ангина, основанное на анализе кода, а при тестировании сборки след1ст 20. Тестирование программного обеспечения 421 использовать другие подходы. Применительно к объектно. ориентированным системам можно определить четыре уровня тестирования. 1. Теппи~овоние ооьдельных левидов ~еле>ааиийд оеоьцшфовлнкых е ийехэиьии. Обычно методы представляют собой функции или процедуры.
Поэтому здесь можно использовать тестирование методами черного и белого ящиков, которые рассматривались ранее. 2. Теежировоние ождельиых классов одзекшов, Принцип тестирования методом черного ящика остается без изменений, однако, понятие "класса эквивалентности" необходимо расширить. Тестирование классов объектов обсуждается в разделе 20.3.1. 3. Тестя>аавоиие кеаеэирьм абгекмов. Нисходящая и восходящая сборки оказываются не пригодными длл создания групп связанных объектов.
Поэтому здесь следует применять другие методы тестирования, например основанные на сценариях. Эти методы рассматриваются в разделе 20.3.2. 4. Тееьлиравпиие словены. Верификация и аттестация объектно. ориентированной системы выполняется точно так же, как и для любых других типов систем. В настоящее время методы тестирования объектно-ориентироваьшых систем достаточно корошо разработаны [39, 20в).
В следующих разделах приведен обзор основных методов тестирования объектно. ориентированных систем. 20.3.1. Тестирование классов объектов Подход к тестовому покрытию систем, описанный в разделе 20.1З, требует, чтобы все операторы в программе выполнялись хотя бы один раз, а также чтобы выполнялнсь все ветви программы. При тестировании объектов полное тестовое покрытие включает: ° раздельное тестирование всех методов, ассоциированных с объектом; ° проверку всех атрибутов, ассоциированных с объектом; ° проверку всех возможных состояний объекта (для этого необходимо моделирование событий, приводящих к изменению состояния объекта). И качестве примера возьмем метеорологическую станцию, которая рассматривалась в главе 12.
Интерфейс объекта, соотвстств>ющего метеостанции, показан на рис. 20.12. У этого объекта только один атрибуг, который является его идентификатором. Это константа, значение которой необходимо задать после инсталляции объекта. Таким образом, нужен тест, который проверял бы задание идентификатора. Необходимо также определить контрольные тесты для методов отчет, калибровать, тестировать, запуск и завершение.
В идеале следует протестировать все этн методы независимо, но в некоторых случаях нужна последовательность тестов. Наприльер, чтобы протестировать метод завершение, необходимо сначала выполнить метод запуск. При тестировании состояний объекта Метеостанция используется модель состолний, показанная на рис. 12.12. С помощью этой модели можно определить последовательность состояний, которые нужно протестировать. В принципе следует проверить каждый возможный переход из одного состояния в другое, хотя на практике такой подход оказывается слишком дорогостоящим. В пашем примере необходимо протестировать такие после.
довательности состояний: Останов -ь Ожидание -ч Останов Ожидание -ь Калибровка -о Тестирование -ь Передача -ь Ожидание Ожидание -+ Калибровка -ь Ожидание -+ Обобщение -ь Передача -+ Ожидание 422 Часть Ч. Верификация и аттестация Использование наследования усложняет разработку тестов для классов обьектов. Если класс предоставляет методы, унаследованные от подклассов, то необходимо протестиро. вать все подклассы со вселги унаследованными методами.
Понятие классов эквивалентно. сти можно применить также и к классам объектов. Здесь тестовые данные из одного клас. са эквивалентности тестируют одни и те же свойства объектов. Рис. 20.12. Оноиугфейг обтенош лгетеорологи ногой пипнйии 20.3.2. Интеграция об ьектов При разработке объектно-ориентированных систем различия между уровнями интеграции менее заметны, поскольку методы и данные компонуются (интегрируются) в виде объектов и классов объектов. Тестирование квассов объектов соответствует тестированию отдельных элементов. В объекгно.ориентированных системах нет непосредственного эквивалента тестированию модулей. Однако считается.
что группы классов, которые совместно предоставляют набор сервисов, следует тестировать вместе [245[. Такой вид тест прова н ия называется гнегнш рооп нием ел пегое[гоп Для объектно-ориентированных систем пе подходит ни восходящая, пи нисходяп1ая интеграция системы, поскольку здесь нет строгой иерархии объектов. Поэтому создание кластеров основывается на выделении метолов и сервисов. реализуемых посрелством этих кластеров. При тестировании сборки объектноориентированных систем используется три подхода.
1. Тегти[говпние епенпргггв и воугипношв иепоаьэовпния. Варианты использования или сценарии (см. главу 6) описывают какой-либо один режим работы системы. Тестирование может базироваться на описании этих сценариев и кластеров объектов, реализующих данный вариант использования. 2. Тегтни[гоепние поемное. Этот подход основывается на проверке системных откликов на ввод данных нли группу входных событий. Объектно.ориентированные системы, как правило, событийно-управляемые, поэтому для них особенно подходит данный вид тестирования.
При использовании этого подхода необходимо знать, как в систелге проходит обработка потоков событий. 3, Тесогировпгггге вшгм~одейпггвий лмжду оймквнши. Это метод тестирования групп взаимо. действующих объектов, предложенный в работе [194). Этот промежуточный уровень тестированил сборки системы основан па определении путей "метод-сообщение", отслеживающих последовательности взаимодействий между объектамн.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
