 |
|
Объектно-ориентированных системах.
Комплексная отладка ПС
Тестирование при комплексной отладке - применение ПС к
конкретным данным, которые могут возникнуть у пользователя, но,
возможно, в моделируемой (а не в реальной) среде.
Тестирование архитектуры ПС. Целью тестирования является поиск
несоответствия между описанием архитектуры и совокупностью программ ПС.
К моменту начала тестирования архитектуры ПС должна быть уже закончена
автономная отладка каждой подсистемы.
Тестирование внешних функций. Целью тестирования является поиск
расхождений между функциональной спецификацией и совокупностью
программ ПС. Несмотря на то, что все эти программы автономно уже
отлажены, указанные расхождения могут быть,
Тестирование качества ПС. Целью тестирования является поиск
нарушений требований качества, сформулированных в спецификации
качества ПС. Завершенность ПС проверяется уже при тестировании внешних
функций.Тестирование документации по применению ПС. Целью тестирования
является поиск несогласованности документации по применению и
совокупностью программ ПС, а также выявление неудобств, возникающих
при применении ПС. Этот этап непосредственно предшествует подключению
пользователя к завершению разработки ПС (тестированию определения
требований к ПС и аттестации ПС).Тестирование определения требований к ПС. Целью тестирования
является выяснение, в какой мере ПС не соответствует предъявленному
определению требований к нему. Особенность этого вида тестирования
заключается в том, что его осуществляет организация-покупатель или
организация-пользователь. Обычно производится с помощью контрольных
задач - типовых задач, для которых известен результат решения.
Тестирования в объектно-ориентированных системах.
Тестирование является достаточно независимым процессом,
применимым к программному обеспечению, разработанному с помощью
любого метода проектирования. Тем не менее объектно-ориентированный
подход привносит свои особенности.Традиционно тестирование делится на тестирование элементов,
интеграционное тестирование и системное тестирование.На уровне элементов тестирование объектно-ориентированныхпрограмм отличается по следующим показателям:
определение единиц тестирования;
тестирование наследования;
тестирование полиморфизма.
Естественной единицей тестирования является класс. Разбиение его на более мелкие элементы (методы) нецелесообразно, поскольку они несуществуют отдельно от классов. Иногда за единицу тестирования
принимается тесно связанная группа классов.Тестирование наследования состоит в тестировании методов,
унаследованных классом от своего базового класса. Если базовый класс уже прошел тестирование, нужно ли повторять тестирование для унаследованных методов- Вопреки достаточно распространенным надеждам программистов
перетестирование необходимо. Основная причина та, что методы
выполняются в новом контексте. Применимость тестовых сценариев базового класса для тестирования
производного класса зависит от того, является ли наследование классификацией. Если нет, то даже для унаследованных методов необходимо разрабатывать новые тестовые сценарии.
Тестирование полиморфизма сходно с тестированием наследования в
том, что в тестовых сценариях необходимо предусмотреть все варианты
связывания, т.е. все варианты конкретной реализации полиморфизма. Интеграционное тестирование представляет собой тестирование того, как отдельные элементы программы работают вместе. Свойства объектно- ориентированных языков исключают целый ряд возможных ошибок, преждевсего за счет строгого определения внешних интерфейсов классов иобъектов. Однако это не означает, что интеграционное тестирование
становится легче. Планирование интеграционного тестирования немного отличается.При традиционном тестировании имеется такая характеристика, как степень покрытия кода. При тестировании по принципу открытого, или
белого ящика (т.е. в случае, когда тестирующему известна структура кода) необходимо обеспечить прохождение управления по всем ответвлениям программы. Иными словами, требуется выполнить как можно больший
процент инструкций, имеющихся в программе. Наряду с этой характеристикой планирование тестов для объектно-ориентированной программы должно включать «покрытие состояний».То, что объект соединяет в себе состояние и поведение, обусловливаетнеобходимость проверки всех возможных переходов из состояния в состояние. В планировании таких тестов должна помочь модель состояний класса, построенная на этапе анализа и проектирования.
Системное тестирование проверяет всю программную систему целиком и строится в большинстве случаев по принципу «черного ящика». Тестирующий знает только внешние характеристики системы, но не знает,
как она работает. Построение требований к системе в форме вариантов использования
обеспечивает естественный и простой способ планирования системного тестирования. Фактически система вариантов использования становится основой плана тестов на этапе системного тестировании.