Особенности объектно-ориентированного тестирования. Расширение области применения тестирования.

Отличия от классического

· Тестирование объектно-ориентированных программных средств имеет ряд существенных отличий от классического тестирования:

o расширение области применения тестирования;

o изменение методики тестирования;

o учет особенностей ООП при проектировании тестовых вариантов

Расширение области применения

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

· Модели этапа анализа и этапа проектирования определяют основные функциональные и структурные свойства разрабатываемой системы, поэтому Необходимо проводить тестирование этих моделей!

Критерии тестирования моделей

· Модели разрабатываемой системы должны удовлетворять критериям:

o синтаксической и семантической правильности,

o полноты,

o согласованности

Правильность модели

· Синтаксическая правильность связана с корректным использованием нотаций языка описания моделей

· Семантическая правильность определяется соответствием модели реальной системе и связанной с ней задаче

· Тестирование подтверждает, что модель правильна в отношении конкретного тестового случая, если результат его выполнения является ожидаемым. 

Полнота модели

· Мера наличия в модели необходимых элементов

· Тестирование показывает, существуют ли сценарии, которые не могут быть представлены элементами, входящими в состав модели

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

Согласованность модели

· Мера присутствия противоречий внутри модели или между текущей моделью и моделью, на базе которой она была построена

· Тестирование выявляет такие противоречия, находя в модели различные представления подобных тестовых случаев

Особенности методики модульного тестирования объектно-ориентированных систем.

Модульное тестирование

· Наименьшим тестируемым элементом объектно-ориентированного ПО является не процедура, а класс

· Поскольку класс содержит набор свойств и методов, образующих единую сущность, изолированное тестирование методов не имеет смысла

· Методы должны тестироваться в контексте частных свойств и операций класса

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

· Автономное тестирование класса предполагает разработку драйвера, который будет:

o создавать экземпляры тестируемого класса;

o вызывать методы тестируемого класса и передавать им фактические параметры из тестовых вариантов;

o принимать результаты выполнения тестируемых методов

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

· Экземпляры отдельных классов в активно взаимодействуют между собой.

· Создание драйвера для автономного тестирования класса может оказаться не менее сложной задачей, чем разработка самого класса.

· Решение об автономном тестировании класса принимается с учетом следующих факторов:

o -роли класса в системе;

o -сложности класса, измеряемой числом состояний, операций и связей с другими классами;

o -объема трудозатрат, связанных с разработкой тестового драйвера.

Виды взаимодействия классов:

· Метод одного класса содержит в списке своих формальных параметров имена других классов.

· Метод одного класса создает экземпляр другого класса как часть своей реализации

· Метод одного класса ссылается на глобальный экземпляр другого класса

Особенности методики интеграционного тестирования объектно-ориентированных систем. Тестирование кластеров и потоковое тестирование.

Тестирование интеграции

· Объектно-ориентированное ПО не имеет иерархической управляющей структуры

· Методики нисходящего и восходящего тестирования здесь неприменимы

· Зачастую неосуществим классический прием интеграции – добавление по одной операции в класс

· Основная цель этого этапа тестирования – проверка правильности обмена сообщениями между объектами, классы которых уже прошли тестирование в автономном режиме

· Основная задача – выделение подмножества взаимодействующих классов

Наиболее популярными являются следующие методики тестирования интеграции объектно-ориентированных систем:

· тестирование, основанное на потоках;

· кластерное тестирование

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

· Объектом интеграции является набор классов, обслуживающих единичный ввод данных в систему

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

· Для контроля побочных эффектов применяют регрессионное тестирование

Кластерное тестирование

· Объектом тестирования является кластер – набор сотрудничающих классов

· Для выделения кластеров можно использовать диаграммы взаимодействия, соответствующие отдельным прецедентам

Размер кластера

· При малых размерах кластера невозможно воспроизведение в полном объеме эффекта интеграции (системного эффекта)

· Однако, с увеличением размера кластера возрастает вероятность возникновения не фиксируемых тестами ошибочных промежуточных результатов

Среда тестирования

· Тестирование кластеров можно проводить

o непосредственно в среде приложения (требуется выделять результаты тестирования из общих информационных потоков в программной системе; результаты тестирования соответствуют реальным условиям эксплуатации)

o в среде, специально созданной тестирующим драйвером (результаты тестирования получаются в «чистом» виде; соответствие результатов тестирования реальным условиям эксплуатации зависит от степени адекватности этим условиям созданной драйвером среды тестирования)

26. Понятие автоматизированного тестирования. Автотесты. Достоинства и недостатки автоматизированного тестирования.

Автоматизация тестирования

· Возрастание роли тестирования в процессе разработки ПО потребовало замены традиционного «ручного» тестирования автоматизированным, основанным на использовании специальных инструментальных средств.

Автотесты:

· Основная идея автоматизированного тестирования заключается в использовании автотестов – записанных на специальных скриптовых языках действий по проверке качества программ.

· Современные средства автоматизации позволяют вести запись действий тестировщика и создавать заготовку для автотеста.

Преимущества автоматизации

· -Экономия времени – программа-робот гораздо быстрее перебирает тестовые варианты, чем любой человек.

· -Исключение человеческого фактора – вероятность совершения ошибки при выполнении человеком рутинных операций достаточно высока.

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

· -Наличие инструментария фиксации ошибок и результатов – это позволяет моделировать различные ошибочные ситуации, строить любые отчеты и диаграммы.

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

Недостатки автоматизации:

· -Временные затраты на создание, поддержку и тестирование (!) тестов – автоматизированное тестирование всегда начинается с тестирования вручную, поскольку необходимо показать роботу, как, что и с чем он должен делать.

· -Неприменимость к некоторым объектам, оцениваемым субъективно – с помощью автомата нельзя протестировать, например, эргономику интерфейса приложения.

· -Необходимость программистских навыков у тестировщика – настоящая профессиональная автоматизация тестирования невозможна без работы непосредственно с кодом тестового скрипта.

· -Чувствительность к среде, программному и аппаратному окружению тестируемого приложения - один и тот же тест одной и той же версии повторно может проходить совершенно иначе, чем в первый раз.