Особенности тестирования объектно-ориентированных программ. Тестирование классов
Основные отличия процесса тестирования объектных программ от традиционных (процедурных) следуют из самого подхода к разработке ПО. А именно: аналитические модели непосредственно отображаются на проектные модели, которые в свою очередь отображаются на программы.
Практически отдают предпочтение следующему многократно повторяемому процессу:
- Немного анализа
- Немного проектных решений
- Немного программных кодов
- Тестировать все, что можно.
Рассмотрим кратко, какие виды тестирования должны проводиться для ОО-го ПО. На практике следуют такому порядку:
- Тестирование моделей (аналитических и проектных).
- Тестирование классов (вместо тестирования модулей).
- Тестирование взаимодействий и функционирования компонентов.
- Тестирование подсистем и систем.
- Приемочные испытания.
Основной метод (эффективный) здесь – метод целенаправленной проверки (инспекции). Для этой цели используются следующие виды диаграмм: диаграммы UseCase с описанием (текстовым) каждого варианта использования; диаграммы последовательностей для сценариев каждого варианта использования, диаграммы классов анализа и проектные диаграммы (описывают архитектуру ПО); диаграммы состояний объектов класса и диаграммы действий, которые являются комбинацией нотаций блок-схем и сетей Петри, и которые создаются для описания алгоритма метода класса или для описания алгоритма всей программы.
-------- Тестирование классов ------------
В первом приближении тестирование классов аналогично тестированию модулей в традиционных процессах тестирования. А именно – разрабатывается тестовый драйвер, который создает один или большее число экземпляров класса. Драйвер будет осуществлять прогон тестов.
Самый простой критерий тестирования класса – это полное покрытие его программного кода (белый ящик) Но чаще всего тестируемый класс рассматривается как «черный ящик», т.е. тесты готовятся на основе спецификации класса.
В любом случае тестирование класса должно проводиться до того, как возникнет необходимость использования этого класса в других компонентах ПО. И каждый раз, когда меняется что-то в реализации класса, должно проводиться регрессионное тестирование этого класса.
Тестирование взаимодействия классов и функционирования компонентов.
У большинства классов имеются партнеры по сотрудничеству, т. е. методы такого класса взаимодействуют с экземплярами других классов.
Рассмотрим случаи, когда между классами установлены отношения ассоциации. Основное назначение тестирования взаимодействий состоит в том, чтобы убедиться, что происходит правильный обмен сообщений между объектами, классы которых прошли тестирование в автономном режиме.
Выявить такие классы можно на диаграмме классов (или по спецификации классов). Процесс тестирования взаимодействий классов заметно облегчается, если число связей между ними невелико. Тогда не придется создавать много программ-драйверов.
Можно отметить, что для выявления всех связей классов особенно полезны диаграммы классов и диаграммы последовательностей. Они показывают, каким классам (объектам) нужен тестируемый класс, т.е. кто использует заявленные операции класса. И – наоборот, к операциям каких классов обращаются объекты тестируемого класса.
Вопросы автоматизации тестирования. Инструменты тестирования.
Видимо обращайтесь к Марианне.
Автоматизация обходится дорого. Это и более квалифицированные специалисты,
и дополнительное время на разработку. Может уйти от 3-х до 10-ти раз больше
времени на разработку, отладку, проверку и документирование автоматических
тестовых случаев по сравнению с тестовыми случаями для ручного
тестирования. Вот почему так важно просчитывать выгоду, выбирать
правильные типы тестов для автоматизации, и планировать эту деятельность.
В большинстве случаев для оценки выгоды от автоматизации вполне достаточно
простой арифметики и оценки только временных затрат (без расчета общего
экономического эффекта). Если есть существенный выигрыш - значит
автоматизация стоит того, чтобы ей заниматься. При оценке затрат
(подразумевается что тесты для ручного тестирования уже разработаны и
документированы) нужно лишь учитывать следующие величины:
• Время на проход теста вручную
• Количество таких проходов
• Время на разработку и отладку автоматического теста
• Время его работы
• Время на исправление скрипта при изменениях в приложении
И тогда простые арифметические действия дадут нам желаемую картину - стоит автоматизировать или нет.
Капитан не прошёл мимо:
Прежде, чем начинать автоматизацию, нужно определиться с вопросами:
• Что будем тестировать?
• Что нужно для проведения теста?
• Откуда будем брать данные?
• Что проверятся?
• Что ожидается?
• Как узнаем - прошел тест или нет?
Требования, предъявляемые к автоматическим тестам
Тест должен "сам тестировать", то есть не только эмулировать действия
пользователя с программой, но и производить необходимые проверки.
Стоит также упомянуть такой важный аспект, как синхронизация. Когда
человек работает с приложением, он соотносит свои действия с реакцией
приложения - если оно занято, он ждет. Автоматический тест должен уметь
делать то же самое, и к тому же есть дополнительное требование - тест должен
с минимальными изменениями одинаково хорошо работать и на "медленной"
версии приложения, так и на "быстрой".
Инструменты:
1) Прежде всего – это PureCoverage. Этот инструмент позволяет
разработчикам довести собственные программы до состояния эффективности,
избавиться от многих ошибок и неприятностей. Основная функция – выявление
участков кода, которые пропущены при тестировании (ни разу не
выполнялись), или, например, выявить функции, которые не вызывались.
Дополнительно собирается статистика о тестировании.
2). Для высокоуровневого тестирования, такого как: тестирование
интерфейса, тестирование компонент приложений клиент-сервер и т. п.
используются такие продукты как Visual Test, Robot и Load Test.
2.1) Visual Test– интерфейс точно такой же, как в Visual Studio от
Microsoft. Можно тестировать Windows приложения, компоненты ActiveX,
DLL, приложения на основе Web, т.е. практически любые задачи. Тесты
создаются на специальном языке Test Basic (производный от Visual Basic).
2.2) Robot – средство функционального тестирования, которое базируется
на объектно-ориентированной технологии. Можно с его помощью тестировать
отдельные классы, можно группу классов тестировать, можно все объекты
приложения целиком (системное тестирование).
2.3) Load Test– для тестирования характеристик распределенных
сетевых приложений на платформах Windows и Unix. Используется при
тестировании нагрузки сервера большим количеством виртуальных
пользователей и засекается время выполнения каждого запроса пользователя.