Tarkvara kvalitet ja stadardid Занятие 5. Процесс тестирования

Tarkvara kvalitet ja stadardid
Занятие 5.
Процесс тестирования ПО
Процесс тестирования
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
testing
Integration testing
User
testing
Интеграционное
тестирование (сборочное)




Тестирует систему целиком или подсистемы,
состоящие из собранных компонентов.
Интеграционное тестирование должно быть
тестированием черного ящика с тестами,
основанными на спецификации
Основная задача – локализация ошибок
Пошаговое интеграционное тестирование
уменьшает количество проблем
Пошаговое интеграционное
тестирование
A
T1
T1
A
T1
T2
A
T2
T2
B
B
T3
T3
B
C
T4
T3
C
T4
T5
D
Test sequence
1
Test sequence
2
Test sequence
3
Методики интеграционного
тестирования

Top-down


Bottom-up


Начинается с верхнего уровня и собирается сверху вниз, заменяя
отдельные компоненты заглушками при необходимости
Добавляет отдельные комоненты на каждом уровне до тех пор,
пока не будет собрана система целиком.
На практике, тестрование бывает комбинацией этих двух
методов
Tестирование top-down
Level 1
Testing
sequence
Level 2
Level 2
stubs
Level 3
stubs
Level 1
Level 2
Level 2
. ..
Level 2
Тестирование bottom-up
Test
drivers
Level N
Test
drivers
Level N
Level N–1
Level N
Level N–1
Level N
Level N
Level N–1
Testing
sequence
Методики тестирования

Валидация архитектуры


Демонстрация системы


Интеграционное тестирование сверху вниз лучше при поиске
ошибок в системной архитектуре
Интеграционное тестирование сверху вниз дает частичную
демонстрацию системы на ранних стадиях развития
Разработка теста

Часто проще для интеграционного тестирования снизу вверх
Тестирование
интерфейса



Производится тогда, когда модули или подсистемы
собирают для тестирования большей системы
Целью тестирования интерфейса является обнаружение
отказов из-за ошибок в интерфейсе или неверных условий
относительно интерфейса
Особенно важно для объектно-ориентированных
разработок, где объекты описываются собственным
интерфейсом
Тестирование интерфейса
Test
cases
A
B
C
Типы интерфейсов

Интерфейсы параметров


Интерфейсы разделяемой памяти


Блоки памяти, разделяемой между процедурами
Процедурные интефейсы


Данные, передаваемый одной процедурой другой
Подсистемы, включающие набор процедур, вызываемых другими
подсистемами
Интерфейсы передачи сообщений

Подсистемы запрашивают сервисы из другой подсистемы
Ошибки интерфейсов

Неправильное использование интерфейсов


Неправильное понимание интерфейса


Вызывающий компонент вызывает другой компонент и возникает
ошибка, например, неправильная последовательность параметров
Вызывающий компонент использует собственные представления о
поведении вызываемого компонента, которые неверны
Ошибки синхронизации

Вызывающий и вызываемые компоненты взаимодействуют с
разными скоростями и информация устаревает
Руководство по тестированию
интерфейсов




Создавайте тесты таким образом, чтобы параметры для
вызываемой процедуры находились на границах данных
Используйте пустые указатели
Создавайте тесты так, чтобы заставить компоненты
работать неверно
Используйте стрессовое тестирование (тестирование с
нагрузкой) для систем передачи сообщений
Ежедневное построение системы



Проблемы легче обнаружить, если они возникают из-за
взаимодействия компонентов в начале процесса
Это стимулирует тестировать компоненты тщательнее –
разработчики опасаются «сломать построенное»
Соблюдение правил управления процессом требует
отслеживать обнаруженные и решенные проблемы
Построение системы



Процесс компиляции и связывания компонентов в
единую работающую системы
Различные системы создаются из различных
наборов компонентов
Одновариантно поддерживается
автоматическими средствами построения,
управляемыми «скриптами сборки»
Проблемы построения систем

Включают ли инструкции по созданиювсе необходимые
компоненты?


Соответствуют ли версии нужных компонентов?


Если существуют тысячи компонентов, из которых строится
система, нетрудно пропустить один из них.
Более серьезная проблема. Система, построенная на ошибочной
версии может работать первоначально, но отказать после поставки
Все ли файлы данных доступны?
Проблемы построения систем (2)



Верны ли ссылки между файлами данных и компонентами?
Для правильной ли платформы построена система?

Иногда система может быть построена для конкретной ОС илли
аппаратной платформы
Определена ли правильная версия компилятора и других
инструментальных средств?

Различные версии компилятора могут генерировать различные
коды и компоненты могут вести себя различным образом
Построение системы
Проблемы построения систем (2)



Построение больших систем дороже и может
занять несколько часов
Задействованы сотни файлов
Средства построения систем должны
обеспечивать




Соответствующий язык спецификации
Выбор инструментария и реализацию поддержки
Распределенное компилирование
Управление объектами
Стрессовое тестрование

Использование системы с максимальной
запрограммированной нагрузкой. Стресс системы часто
заставляет ошибки выходить наружу.



Нагрузка системы провоциует ее ошибочное поведение.
Система не должна отказывать катастрофически.
Стрессовое тестирование проверяет потерю данных или
сервисов.
Особенно важно для распределенных систем, которые могут
с течением времени «забиваться данными», и все
выполняемые процессы могут неограниченно замедляться.
Объектно-ориентированное
тестирование




Тестируемые компонененты – это классы объектов
Объекты – это обычно более широкая категория, чем подпрограммы
или функции
Зачастую исходный код объекта недоступен, что аннулирует
возможность применения структурного тестирования
Довольно сложно организовать восходящее/нисходящее тестирование,
так как сложно разделить систему на уровни и, в частности, выделить
самый верхний уровень
Уровни тестирования




Тестрование операций, связанных с
объектами
Тестирование классов объектов
Тестирование кластеров
кооперироующихся объектов
Тестирование системы целиком
Тестирование классов объектов

Полный тест включает в себя
1. Раздельное тестирование всех методов, ассоциированных с
объектом
2. Проверка всех атрибутов, ассоциированных с объектом
3. Проверка всех возможных состояний объекта

Наследование делает тестирование более сложным,
потому что тестируемая информация не локализована
Интеграция объектов



В ОО системах уровни интеграции выражены не
слишком отчетливо
Кластерное тестирование связано с
интегрированием и тестированием кластеров
кооперирующихся объектов
Кластеры – группы классов, которые совместно
предоставляют набор сервисов
Методы кластерного тестирования

Тестрование по сценарию
 Тестироване базируется на пользовательском
взаимодействии с системой



Имеет то преимущество, что тестирует
системные свойства подобно пользователю
Тестирование потоков
 Тестирует ответы системы на события как
потоки, проходящие через систему
Тестирование взаимодействия объектов
 Тестирует последовательность взаимодействий
объектов, которая останавливается тогда, когда
когда объект не вызывает сервис другого
объекта
Сценарное тестирование


Описание каждого сценария должно включать:
1.
описание состояния системы в начале
1.
описание нормального протекания сценария
1.
описание исключений и их обработки
1.
информация о других действиях, которые можно выполнять одновременно
со сценарием
1.
описание состояния системы в конце
При этом последовательность рассмотрения сценариев
соответствует вероятности их появления.
Collect weather data
Weather station testing


Thread of methods executed

CommsController:request
WeatherData:summarise

WeatherStation:report

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, позволяет извлечь
множество предполагаемых инвариантов программы на
переменных исходя из последовательного запуска программы на
некоем наборе тестов.
Собранные сведения передаются статическому анализатору ESCJava, который проверяет код программы на наличие участков
возможного изменения найденных на предыдущем этапе
инвариантов.
Полученные таким образом «подозрительные» участки могут
служить источником ошибок и подлежат дополнительной проверке.
Тестирующие системы (3)


TestEra или VeriSoft. TestEra реализует
собственный язык управления, имеющий
двусторонний Java-интерпретатор, а также
компонет ACA, который позволяет формировать
наборы входных данных, подозрительные на
нарушение извлеченных из внутреннеязыковой
модели правил корректности.
VeriSoft реализует алгоритмы модельной
проверки при тестировании параллелизуемых
интерактивных систем. Экономическая
состоятельность этого средства тестирования
была наглядно продемонстрирована на примере
больших промышленных телекоммуникационных
систем.
Аттестационное тестирование


Кроме функционального тестирования системы,
реализующего проверку соответствия программного
продукта внешней спецификации, процесс тестирования
должен включать аттестационное тестирование.
Процедура аттестационного тестирования описывается
стандартом ANSI/IEEE 1012-1986 и должна включать:
1.
Тестирование целостности (сверка с пользовательской
документацией)
2.
Системное тестирование (сверка с системными
требованиями)
Тестирование целостности

Тестирование целостности обычно выполняется сторонним
специалистом (не участвовавшим в данной разработке или
вообще сотрудником независимого агентства) и включает
следующие этапы:
1.1 Сравнение с конкурирующими продуктами
1.2 Анализ маркетинговых материалов


Схожая функция тестирования на основе обратной
связи с пользователем реализуется широко известным
процессом бета-тестирования.
Окончательная приемка системы производится на
основании контракта между разработчиком и заказчиком и
тестов, указанных в ней.
«адаптационное» тестирование


Тестирование необходимо продолжать и на стадии
сопровождения программного продукта.
«адаптационное» тестирование включает следующие этапы:
1.
Тестирование общего функционирования
2.
Тестирование обработки ошибок операционной системы
3.
Вопросы установки
4.
Тестирование совместимости (в рамках новой платформы)
5.
Совместимость интерфейсов
6.
Тестирование прочих вносимых изменений