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

Тестирование ПО – запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности системы.

Тестирование – это динамический метод верификации и аттестации, так как применяется к исполняемой системе.

Верификацией и аттестацией - называют процессы проверки и анализа, в ходе которых проверяется соответствие ПО своей спецификации и требованиям заказчика. Верификация и аттестация охватывают полный жизненный цикл ПО, они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования готовой программной системы.

Верификация отвечает на вопрос, правильно ли создана система. Аттестация отвечает на вопрос, правильно ли работает система.

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

Инспектирование ПО – анализ и проверка различных представлений (артефактов) системы на всех этапах процесса разработки. Инспектирование – это статический метод верификации и аттестации, поскольку им не требуется исполняемая система.

Во многих книгах, посвященных тестированию ПО, описывается процесс тестирования программных систем, реализующих функциональную модель ПО, но не рассматривается отдельно тестирование объектно-ориентированных систем

Системы, разработанные по функциональной модели и объектно-ориентированные системы имеют существенные отличия:

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

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

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

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

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

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

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

· Тестирование отдельных классов объектов

Принцип тестирования методом черного ящика остается без изменений, однако понятие «класса эквивалентности» необходимо расширить.

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

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

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

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

Например, нужны тесты, которые проверяли бы задания атрибутов объекта после его инсталляции. Нужно также определить контрольные тесты для методов объекта и протестировать эти методы независимо. При тестировании состояний объекта, используется модель его состояний (Диаграмма состояний UML), с помощью которой можно определить последовательность состояний, которые нужно протестировать.

Использование наследования усложняет разработку тестов для классов объектов. Если класс представляет методы, унаследованные от подклассов, то необходимо протестировать все подклассы со всеми унаследованными методами.

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

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

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

- Тестирование сценариев и вариантов использования.

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

- Тестировании потоков.

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

- Тестирование взаимодействий между объектами.

Этот метод тестирования групп взаимодействующих объектов. Этот промежуточный уровень тестирования сборки системы основан на определении путей «метод - сообщение», отслеживающих последовательности взаимодействий между объектами. Диаграммы последовательности UML можно использовать для определения тестируемых операций и для разработки тестовых сценариев. Тестирование сценариев часто оказывается более эффективным, чем другие методы тестирования. Сам процесс тестирования можно спланировать так, чтобы в первую очередь проверялись наиболее вероятные сценарии и только затем исключительные сценарии. Сценарии определяются исходя из разработанных вариантов использования и, при необходимости, можно использовать диаграммы взаимодействия, которые отображают реализацию вариантов использования посредством системных объектов.

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

Тестирование интерфейсов

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

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

Между компонентами программы могут быть разные типы интерфейсов и соответственно разные типы ошибок интерфейсов. К таким типам интерфейсов относятся: параметрические интерфейсы, интерфейсы разделяемой памяти, процедурные интерфейсы и интерфейсы передачи сообщений.

Ошибки в интерфейсах являются наиболее распространенными типами ошибок в сложных системах и делятся на три класса: неправильное использование интерфейсов, неправильное понимание интерфейсов и ошибки синхронизации.

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

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

- тестируйте интерфейс с нулевыми параметрами указателя;

- при вызове компонента через процедурный интерфейс, используйте тесты, вызывающие сбой в работе компонента;

- разрабатывайте тесты, генерирующие в несколько раз большее количество сообщений, чем будет в обычной работе в системах передачи сообщений;

- при взаимодействии нескольких компонентов через разделяемую память, разрабатывайте тесты, которые изменяют порядок активизации компонентов.

⇐ Предыдущая24252627282930313233Следующая ⇒

Поделиться: