Другая проблема может возникнуть из-за взаимодействий между ошибками в разных программных модулях или объектах. Ошибки в одном объекте можно выявить только тогда, когда поведение другого объекта становится непредсказуемым. Например, для получения сервиса один объект вызывает другой объект и полагает, что полученный ответ правильный. Если объект неправильно понимает вычисленные значения, возвращаемое значение может быть достоверным, но неправильным. Такие ошибки можно выявить только тогда, когда оказываются неправильными дальнейшие вычисления [4,5].

Несколько общих правил тестирования интерфейсов:

1. Просмотреть тестируемый код и составить список всех вызовов, направленных к внешним компонентам. Разработать такие наборы тестовых данных, при которых параметры, передаваемые внешним компонентам, принимают крайние значения из диапазонов их допустимых значений. Использование экстремальных значений параметров с высокой вероятностью обнаруживает несоответствия в интерфейсах.

2. Если между интерфейсами передаются указатели, всегда следует тестировать интерфейс с нулевыми параметрами указателя.

3. При вызове компонента через процедурный интерфейс необходимо использовать тесты, вызывающие сбой в работе компонента. Одна из наиболее распространенных причин ошибок в интерфейсе – неправильное понимание спецификации компонентов.

1. В системах передачи сообщений нужно использовать тесты с нагрузкой, которые рассматриваются в следующем разделе. Необходимо разработать тесты, генерирующие в несколько раз большее количество сообщений, чем будет в обычной работе системы. Эти же тесты позволяют обнаружить проблемы синхронизации.

2. При взаимодействии нескольких компонентов через разделяемую память следует разработать тесты, которые изменяют порядок активизации компонентов. С помощью таких тестов можно выявить сделанные программистом неявные предположения о порядке использования компонентами разделяемых данных.

3. Обычно статические методы тестирования более рентабельны, чем специальное тестирование интерфейсов. В языках со строгим контролем типов, например Java, многие ошибки интерфейсов помогает обнаружить компилятор. В языках со слабым контролем типов (например, С) ошибки интерфейса может выявить статический анализатор, такой как LINT (обеспечивает статическую проверку, эквивалентную проверке компилятором). Кроме того, при инспектировании программ можно сосредоточиться именно на проверке интерфейсов компонентов [3,5].

1.8 Тестирование с нагрузкой

После полной интеграции системы можно оценить такие интеграционные свойства системы, как производительность и надежность. Чтобы убедиться, что система может работать с заданной нагрузкой, разрабатываются тесты для измерения производительности. Обычно планируются серии тестов с постоянным увеличением нагрузки, пока производительность системы не начнет снижаться.

Некоторые классы систем проектируются с учетом работы под определенной нагрузкой. Например, система обработки транзакций проектируется так, чтобы обрабатывать 100 транзакций в секунду; сетевая операционная система – чтобы обрабатывать информацию от 200 отдельных терминалов. При тестировании с нагрузкой выполнение тестов начинается с максимальной нагрузки, указанной в проекте системы, и продолжается до тех пор, пока не произойдет сбой в работе системы. Данный тип тестирования выполняет две функции [4].

1. Тестируется поведение системы во время сбоя. В процессе эксплуатации могут возникать ситуации, при которых нагрузка в системе превышает максимально допустимую. В таких ситуациях очень важно, чтобы сбой в системе не приводил к нарушению целостности данных или к потере сервисных возможностей.

2. Чтобы выявить дефекты, которые не проявляются в обычных режимах работы, система подвергается тестированию с нагрузкой. Хотя подобные дефекты не приводят к ошибкам при обычном использовании системы, на практике могут возникнуть необычные комбинации стандартных условий; именно они воспроизводятся во время тестирования с нагрузкой [4].

Тестирование с нагрузкой чаще всего применяется в распределенных системах. В таких системах при большой нагрузке сеть порой "забивается" данными, которыми обмениваются разные процессы. Постепенно процессы все больше замедляются, поскольку они ожидают данные запросов от других процессов.

2. Тестирование объектно-ориентированных систем

Было рассмотрено два основных подхода к тестированию программного обеспечения – компонентное тестирование, при котором компоненты системы тестируются независимо друг от друга, и тестирование сборки, когда компоненты интегрированы в подсистемы и тестируется конечная система. Эти подходы в равной мере применимы и к объектно-ориентированным системам. Однако системы, разработанные по функциональной модели, и объектно-ориентированные системы имеют существенные отличия.

1. Объекты, как отдельные программные компоненты, представляют собой нечто большее, чем отдельные подпрограммы или функции.

2. Объекты, интегрированные в подсистемы, обычно слабо связаны между собой и поэтому сложно определить "самый верхний уровень" системы.

3. При анализе повторно используемых объектов их исходный код может быть недоступным для испытателей [3-5].

Эти отличия означают, что при проверке объектов можно применять тестирование методом белого ящика, основанное на анализе кода, а при тестировании сборки следует использовать другие подходы. Применительно к объектно-ориентированным системам можно определить четыре уровня тестирования.

1. Тестирование отдельных методов (операций), ассоциированных с объектами. Обычно методы представляют собой функции или процедуры. Поэтому здесь можно использовать тестирование методами черного и белого ящиков, которые рассматривались ранее.

2. Тестирование отдельных классов объектов. Принцип тестирования методом черного ящика остается без изменений, однако, понятие "класса эквивалентности" необходимо расширить. Тестирование классов объектов обсуждается в разделе 2.1.

3. Тестирование кластеров объектов. Нисходящая и восходящая сборки оказываются не пригодными для создания групп связанных объектов. Поэтому здесь следует применять другие методы тестирования, например основанные на сценариях. Эти методы рассматриваются в разделе 2.2.

4. Тестирование системы. Верификация и аттестация объектно-ориентированной системы выполняется точно так же, как и для любых других типов систем [3,4,5].

В настоящее время методы тестирования объектно-ориентированных систем достаточно хорошо разработаны [5]. В следующих разделах приведен обзор основных методов тестирования объектно-ориентированных систем.

2.1 Тестирование классов объектов

Подход к тестовому покрытию систем, описанный в разделе 1.3, требует, чтобы все операторы в программе выполнялись хотя бы один раз, а также, чтобы выполнялись все ветви программы. При тестировании объектов полное тестовое покрытие включает:

1. раздельное тестирование всех методов, ассоциированных с объектом;

2. проверку всех атрибутов, ассоциированных с объектом;

3. проверку всех возможных состояний объекта (для этого необходимо моделирование событий, приводящих к изменению состояния объекта).

Использование наследования усложняет разработку тестов для классов объектов. Если класс предоставляет методы, унаследованные от подклассов, то необходимо протестировать все подклассы со всеми унаследованными методами. Понятие классов эквивалентности можно применить также и к классам объектов. Здесь тестовые данные из одного класса эквивалентности тестируют одни и те же свойства объектов [5,6].

2.2 Интеграция объектов

При разработке объектно-ориентированных систем различия между уровнями интеграции менее заметны, поскольку методы и данные компонуются (интегрируются) в виде объектов и классов объектов. Тестирование классов объектов соответствует тестированию отдельных элементов. В объектно-ориентированных системах нет непосредственного эквивалента тестированию модулей. Однако считается, что группы классов, которые совместно предоставляют набор сервисов, следует тестировать вместе [3,6]. Такой вид тестирования называется тестированием кластеров.

Для объектно-ориентированных систем не подходит ни восходящая, ни нисходящая интеграция системы, поскольку здесь нет строгой иерархии объектов. Поэтому создание кластеров основывается на выделении методов и сервисов, реализуемых посредством этих кластеров. При тестировании сборки объектно-ориентированных систем используется три подхода.

1. Тестирование сценариев и вариантов использования. Варианты использования или сценарии описывают какой-либо один режим работы системы. Тестирование может базироваться на описании этих сценариев и кластеров объектов, реализующих данный вариант использования.

2. Тестирование потоков. Этот подход основывается на проверке системных откликов на ввод данных или группу входных событий. Объектно-ориентированные системы, как правило, событийно-управляемые, поэтому для них особенно подходит данный вид тестирования. При использовании этого подхода необходимо знать, как в системе проходит обработка потоков событий.

3. Тестирование взаимодействий между объектами. Это метод тестирования групп взаимодействующих объектов [4,6]. Этот промежуточный уровень тестирования сборки системы основан на определении путей "метод-сообщение", отслеживающих последовательности взаимодействий между объектами.

Тестирование сценариев часто оказывается более эффективным, чем другие методы тестирования. Сам процесс тестирования можно спланировать так, чтобы в первую очередь проверялись наиболее вероятные сценарии и только затем исключительные сценарии. Поэтому тестирование сценариев удовлетворяет основному принципу, согласно которому при тестировании больше внимания необходимо уделять наиболее часто используемым частям системы.

После выбора сценариев для тестирования системы важно убедиться, что все методы каждого класса будут выполняться хотя бы один раз. Для этого можно составить технологическую карту проверок классов объектов и методов и при выборе сценария отмечать выполняемый метод. Конечно, все комбинации методов выполнить невозможно, но, по крайней мере, можно удостовериться, что все методы протестированы как часть какой-либо последовательности выполняемых методов [6].

2.3 Инструментальные средства тестирования

Тестирование – дорогой и трудоемкий этап разработки программных систем. Поэтому создан широкий спектр инструментальных средств для поддержки процесса тестирования, которые значительно сокращают расходы на него.

На рисунке 9 показаны возможные инструментальные средства тестирования и отношения между ними.

1. Организатор тестов. Управляет выполнением тестов. Он отслеживает тестовые данные, ожидаемые результаты и тестируемые функции программы.

2. Генератор тестовых данных. Генерирует тестовые данные для тестируемой программы. Он может выбирать тестовые данные из базы данных или использовать специальные шаблоны для генерации случайных данных необходимого вида.

3. Оракул. Генерирует ожидаемые результаты тестов. В качестве оракулов могут выступать предыдущие версии программы или исследуемого объекта. При тестировании параллельно запускаются оракул и тестируемая программа и сравниваются результаты их выполнения.

4. Компаратор файлов. Сравнивает результаты тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях. Компараторы особенно важны при сравнении различных версий программы. Различия в результатах указывают на возможные проблемы, существующие в новой версии системы.

5. Генератор отчетов. Формирует отчеты по результатам проведения тестов.

6. Динамический анализатор. Добавляет в программу код, который подсчитывает, сколько раз выполняется каждый оператор. После запуска теста создает исполняемый профиль, в котором показано, сколько раз в программе выполняется каждый оператор.

7. Имитатор. Существует несколько типов имитаторов. Целевые имитаторы моделируют машину, на которой будет выполняться программа. Имитатор пользовательского интерфейса – это программа, управляемая сценариями, которая моделирует взаимодействия с интерфейсом пользователя. Имитатор ввода/вывода генерирует последовательности повторяющихся транзакций [4,5].

Рисунок 9 – Инструментальные средства тестирования

Требования, предъявляемые к процессу тестирования больших систем, зависят от типа разрабатываемого приложения. Поэтому инструментальные средства тестирования неизменно приходится адаптировать к процессу тестирования конкретной системы.

Для создания полного комплекса инструментального средства тестирования, как правило, требуется много сил и времени. Весь набор инструментальных средств, показанных на рис. 9, используется только при тестировании больших систем. Для таких систем полная стоимость тестирования может достигать 50% от всей стоимости разработки системы. Вот почему выгодно инвестировать разработку высококачественных и производительных CASE-средств тестирования [4,5,6].

Заключение

В данной курсовой работе были рассмотрены различные виды тестирования программного обеспечения: тестирование дефектов, тестирование методом черного ящика, структурное тестирование, тестирование ветвей, тестирование сборки, восходящее и нисходящее тестирование, тестирование интерфейсов, тестирование с нагрузкой, тестирование объектно-ориентированных систем, тестирование классов объектов, интеграция объектов и инструментальные средства тестирования. Все эти методы должны использоваться при тестировании программного обеспечения в совокупности.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Соммервилл, И. Инженерия программного обеспечения / пер. с англ. А.А. Минько, А.А. Момотюк, Г.И. Сингаевская. – М.: ВИЛЬЯМС, 2002. – 624 с., ил.

2. Тестирование программ / В.В. Липаев. – М.: Радио и связь, 1986. – 437 с.

3. Брауде, Э. Технология разработки программного обеспечения / пер. с англ.. – Спб.: ПИТЕР, 2004. – 655 с., ил.

4. Орлов, С. Технологии разработки программного обеспечения / С.А. Орлов. – Спб.: ПИТЕР, 2002. – 464 с., ил.

5. Липаев, В. Надежность программных средств. – М.: СИНТЕГ, 1998. – 358 с.

6. Вигерс, К. Разработка требований к программному обеспечению / пер. с англ.. – М.: «Русская Редакция», 2004. – 576 с., ил.