Tarkvara kvalitet ja stadardid

Занятие 5. Процесс тестирования ПО

Процесс тестирования

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

Пошаговое интеграционное тестирование

Методики интеграционного тестирования Top-down Начинается с верхнего уровня и собирается сверху вниз, заменяя отдельные компоненты заглушками при необходимости Bottom-up Добавляет отдельные комоненты на каждом уровне до тех пор, пока не будет собрана система целиком. На практике, тестрование бывает комбинацией этих двух методов

Tестирование top-down

Тестирование bottom-up

Методики тестирования Валидация архитектуры Интеграционное тестирование сверху вниз лучше при поиске ошибок в системной архитектуре Демонстрация системы Интеграционное тестирование сверху вниз дает частичную демонстрацию системы на ранних стадиях развития Разработка теста Часто проще для интеграционного тестирования снизу вверх

Производится тогда, когда модули или подсистемы собирают для тестирования большей системы Целью тестирования интерфейса является обнаружение отказов из-за ошибок в интерфейсе или неверных условий относительно интерфейса Особенно важно для объектно-ориентированных разработок, где объекты описываются собственным интерфейсом Тестирование интерфейса

Типы интерфейсов Интерфейсы параметров Данные, передаваемый одной процедурой другой Интерфейсы разделяемой памяти Блоки памяти, разделяемой между процедурами Процедурные интефейсы Подсистемы, включающие набор процедур, вызываемых другими подсистемами Интерфейсы передачи сообщений Подсистемы запрашивают сервисы из другой подсистемы

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

Руководство по тестированию интерфейсов Создавайте тесты таким образом, чтобы параметры для вызываемой процедуры находились на границах данных Используйте пустые указатели Создавайте тесты так, чтобы заставить компоненты работать неверно Используйте стрессовое тестирование (тестирование с нагрузкой) для систем передачи сообщений

Ежедневное построение системы Проблемы легче обнаружить, если они возникают из-за взаимодействия компонентов в начале процесса Это стимулирует тестировать компоненты тщательнее – разработчики опасаются «сломать построенное» Соблюдение правил управления процессом требует отслеживать обнаруженные и решенные проблемы

Процесс компиляции и связывания компонентов в единую работающую системы Различные системы создаются из различных наборов компонентов Одновариантно поддерживается автоматическими средствами построения, управляемыми «скриптами сборки» Построение системы

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

Верны ли ссылки между файлами данных и компонентами? Для правильной ли платформы построена система? Иногда система может быть построена для конкретной ОС илли аппаратной платформы Определена ли правильная версия компилятора и других инструментальных средств? Различные версии компилятора могут генерировать различные коды и компоненты могут вести себя различным образом Проблемы построения систем (2)

Построение системы

Проблемы построения систем (2) Построение больших систем дороже и может занять несколько часов Задействованы сотни файлов Средства построения систем должны обеспечивать Соответствующий язык спецификации Выбор инструментария и реализацию поддержки Распределенное компилирование Управление объектами

Стрессовое тестрование Использование системы с максимальной запрограммированной нагрузкой. Стресс системы часто заставляет ошибки выходить наружу. Нагрузка системы провоциует ее ошибочное поведение. Система не должна отказывать катастрофически. Стрессовое тестирование проверяет потерю данных или сервисов. Особенно важно для распределенных систем, которые могут с течением времени «забиваться данными», и все выполняемые процессы могут неограниченно замедляться.

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

Уровни тестирования Тестрование операций, связанных с объектами Тестирование классов объектов Тестирование кластеров кооперироующихся объектов Тестирование системы целиком

Тестирование классов объектов Полный тест включает в себя 1. Раздельное тестирование всех методов, ассоциированных с объектом 2. Проверка всех атрибутов, ассоциированных с объектом 3. Проверка всех возможных состояний объекта Наследование делает тестирование более сложным, потому что тестируемая информация не локализована

Интеграция объектов В ОО системах уровни интеграции выражены не слишком отчетливо Кластерное тестирование связано с интегрированием и тестированием кластеров кооперирующихся объектов Кластеры – группы классов, которые совместно предоставляют набор сервисов

Методы кластерного тестирования Тестрование по сценарию Тестироване базируется на пользовательском взаимодействии с системой Имеет то преимущество, что тестирует системные свойства подобно пользователю Тестирование потоков Тестирует ответы системы на события как потоки, проходящие через систему Тестирование взаимодействия объектов Тестирует последовательность взаимодействий объектов, которая останавливается тогда, когда когда объект не вызывает сервис другого объекта

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

Collect weather data

Weather station testing Thread of methods executed CommsController:request WeatherStation:report WeatherData:summarise Inputs and outputs Input of report request with associated acknowledge and a final output of a report Can be tested by creating raw data and ensuring that it is summarised properly Use the same raw data to test the WeatherData object

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

Тестирующая система

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

Тестирующие системы (2) Одним из дополнительных средств тестирования может служить, тандем Daikon – ESC-Java. Первое инструментальное средство, Daikon, позволяет извлечь множество предполагаемых инвариантов программы на переменных исходя из последовательного запуска программы на некоем наборе тестов. Собранные сведения передаются статическому анализатору ESC- Java, который проверяет код программы на наличие участков возможного изменения найденных на предыдущем этапе инвариантов. Полученные таким образом «подозрительные» участки могут служить источником ошибок и подлежат дополнительной проверке.

Тестирующие системы (3) TestEra или VeriSoft. TestEra реализует собственный язык управления, имеющий двусторонний Java-интерпретатор, а также компонет ACA, который позволяет формировать наборы входных данных, подозрительные на нарушение извлеченных из внутреннеязыковой модели правил корректности. VeriSoft реализует алгоритмы модельной проверки при тестировании параллелизуемых интерактивных систем. Экономическая состоятельность этого средства тестирования была наглядно продемонстрирована на примере больших промышленных телекоммуникационных систем.

Аттестационное тестирование Кроме функционального тестирования системы, реализующего проверку соответствия программного продукта внешней спецификации, процесс тестирования должен включать аттестационное тестирование. Процедура аттестационного тестирования описывается стандартом ANSI/IEEE и должна включать: 1. Тестирование целостности (сверка с пользовательской документацией) 2. Системное тестирование (сверка с системными требованиями)

Тестирование целостности Тестирование целостности обычно выполняется сторонним специалистом (не участвовавшим в данной разработке или вообще сотрудником независимого агентства) и включает следующие этапы: 1.1 Сравнение с конкурирующими продуктами 1.2 Анализ маркетинговых материалов Схожая функция тестирования на основе обратной связи с пользователем реализуется широко известным процессом бета-тестирования. Окончательная приемка системы производится на основании контракта между разработчиком и заказчиком и тестов, указанных в ней.

«адаптационное» тестирование Тестирование необходимо продолжать и на стадии сопровождения программного продукта. «адаптационное» тестирование включает следующие этапы: 1. Тестирование общего функционирования 2. Тестирование обработки ошибок операционной системы 3. Вопросы установки 4. Тестирование совместимости (в рамках новой платформы) 5. Совместимость интерфейсов 6. Тестирование прочих вносимых изменений