Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Презентации / Lecture06p

.pdf
Скачиваний:
0
Добавлен:
23.06.2026
Размер:
1 Мб
Скачать
☆

Виды тестирования

Различные аспекты классификаций

•Проверяемые свойства

•Источник данных для моделирования ситуаций

•Уровень проверяемых компонентов

•Исполнитель – роль разработчика и исполнителя тестов

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

11

Виды тестирования по проверяемым свойствам

•По характеристикам качества

•Тестирование функциональности

•Тестирование надежности

•Тестирование производительности

•Тестирование совместимость

•Тестирование переносимости

•Тестирование защищенности

•Тестирование удобства использования – бывает, но устроено как валидация

•Тестирование удобства сопровождения – не бывает

•Аттестационное тестирование или тестирование на соответствие (conformance testing) – соответствие опр. стандарту или нормативу

•Регрессионное тестирование (regression testing)

Проверка того, что в новой версии старые тесты выполняются успешно

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

12

Виды тестирования по источнику данных

•По использованию структуры системы (и ее кода) для выявления разных ситуаций

•Тестирование черного ящика (black-box testing) – используют только требования

•Тестирование белого ящика (white-box testing, glass-box testing) – только структуру кода

•Тестирование серого ящика – смешанное

•Тестирование на отказ

Нацеленное на определенные возможные ошибки

•Тестирование работоспособности (sanity testing, smoke testing) – нацеленное на простейшие ошибки, нарушения базовых функций

•Нагрузочное тестирование (load testing) – большая нагрузка в пределах требований

•Стрессовое тестирование (stress testing) – нагрузка немного за пределами требований

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

13

Виды тестирования по уровню компонентов

• Модульное тестирование (unit testing)

Выделяется компилируемый компонент (исходно – минимальный, процедура или функция) и тестируется отдельно от всего остального

•Нужны заглушки

•Цель – покрытие кода

•Компонентное тестирование (component testing)

Достаточно крупный компонент (класс, несколько связанных классов)

•Цель – покрытие кода

•Интеграционное тестирование (integration testing)

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

•Цель – покрытие разных возможных условий и способов взаимодействия

•Тестирование отдельных функций (feature testing)

Тестируется отдельная feature на системном уровне (через интерфейс системы)

•Цель – покрытие разных вариантов работы этой функции

•Системное тестирование (system testing)

Тестируется система в целом

• Цель – покрытие разных сценариев работы системы в целом

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

14

Пример ошибки интеграции

•Космический телескоп (Hitomi, до запуска

Astro-H)

•Запущен 17.02.2016, связь потеряна 26.03.2016 (два коротких эпизода 28 и 29.03)

•Причина – многочисленные ошибки в бортовых системах управления и ориентирования

•Последняя ошибка, ставшая роковой:

•Подсистема управления двигателями корректировки ожидала на входе матрицу моментов 3x3, симметричную с неотрицательными элементами

•Переданная матрица содержала отрицательные числа

•Это привело к чрезмерной раскрутке спутника, после чего несколько его частей, включая солнечные батареи, оторвались

•За 2 суток внутренние аккумуляторы полностью разрядились

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

15

Виды тестирования по исполнителю

•Тестирование разработчиков (developer testing)

•Разработчики, в окружении разработки

•Альфа-тестирование (α-testing)

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

•Бета-тестирование (β-testing)

•Пользователи (отобранные, незадолго до выпуска релиза), строят тесты на основе нужных им действий

•Независимое тестирование (independent testing, third-party testing)

•Независимая команда (не разработчики, не заказчик и не пользователи)

•Приемочное тестирование (acceptance testing)

•Представители заказчика перед передачей в эксплуатацию, по итогам подписывается акт приемки

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

16

Выбор тестовых ситуаций

Обоснованный выбор небольшого множества ситуаций возможен, поскольку ПО обычно устроено регулярно

function(double x, double y)

{

double z = abs(x); if(z >= 2.0) {

…

}

if(y >= 4.0) {

…

}

else {

…

}

}

Вместо 2128 ситуаций для проверки достаточно рассматривать

(x >= 2.0, y >= 4.0), (x >= 2.0, y < 4.0),

(-2.0 < x < 2.0, y >= 4.0), (-2.0 < x < 2.0, y < 4.0), (x <= -2.0, y >= 4.0), (x <= -2.0, y < 4.0),

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

+комбинации +∞, -∞, NaN

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

17

Критерий полноты тестирования

•На основе регулярности ситуаций формируют критерий полноты тестирования, определяющий, сколько и какого рода ситуаций достаточно протестировать для адекватных выводов о качестве системы

•Критерий полноты зависит от текущего состояния и целей разработки системы

•Есть множество типовых, шаблонных критериев Нужный критерий часто строят как их комбинацию

•100% требований + 75% ветвлений в коде + 100% интерфейсных операций

•Это всегда попытка приблизить адекватный критерий с помощью шаблонов

•Часто отдельно добавляются окрестности границ классов

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

18

Типовые критерии по используемым данным

•На основе структуры входных (и выходных) данных

•Разбиение значений входных типов данных

double [ -∞, -MAX, -MAX..-10300, -10300..-1030, -1030..-1000, -1000..-1, -1, -1..-0.001, -0.001..-10-30, -10-30..-10-300, -10-300..-2-1022, -2-1022..-2-1074, -2-1074,

-0, +0, 2-1074, 2-1074..2-1022, 2-1022..10-300, 10-300..10-30, 10-30..0.001, 0.001..1, 1, 1..1000, 1000..1030, 1030..10300, 10300..MAX, MAX, +∞, NaN]

•Разбиение возможных результатов sin(x) = 1, -1, ½, -½

•На основе структуры тестируемой системы и ее кода

•Покрытие инструкций, ветвлений

•Покрытие потоков данных между модулями

•На основе структуры требований

•Покрытие требований, отдельных условий в требованиях

•На основе явных предположений о возможных ошибках

(все предыдущие – используют неявные предположения)

• Возможные переполнения буферов, обращения к пустым буферам

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

19

Типовые критерии по математической основе

•Грамматики (включая любые описания структур данных)

•A ::= (b)? ( c | d ) e (f)?

•Логические выражения

•A0 && !A1 || A1 && !A2 || !A0 && A2

• Графы

•Покрытие вершин

•Покрытие ребер

•Покрытие цепочек ребер, простых путей

•Покрытие du-пар и du-путей

oВсе можно свести к графам, но это непрактично

Кулямин В.В. ФКН ВШЭ, ПИ / ВМК МГУ

Основы инженерии программного обеспечения

20

Соседние файлы в папке Презентации