Организация процесса тестирования программного обеспечения

1. Организация процесса тестирования программного обеспечения

2. Тестирование программного средства - это процесс выполнения его программ на некотором наборе данных, для которого заранее

известен результат применения или известны
правила поведения этих программ.
вход
Программа
выход
Тестовый набор = вход ± выход

3.

ОБЩАЯ СХЕМА ТЕСТИРОВАНИЯ И ОТЛАДКИ
Подготовка тестового
набора
недостаточное
Тестирование
Сравнение с
эталоном
Проверка полноты
нет
Диагностика
ошибки
Локализация ошибки
тестирования
да
Корректирование
программы
Контрольное
тестирование
Окончание
Дополнительные тесты
тестирования
локализации ошибки

4.

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

5.

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

6.

Статический метод тестирования
тестирование, при котором код программы
не выполняется
Техника статического анализа заключается в методическом
просмотре (или обзоре) и анализе структуры программ, а
также в доказательстве их правильности. Статический
анализ направлен на анализ документов, разработанных на
всех этапах ЖЦ и заключается в инспекции исходного кода
и сквозного контроля программы.

7.

Динамический метод тестирования
тестирование, при котором выполняется
код программы
Динамическое тестирование ориентировано на проверку
корректности ПС на множестве тестов, прогоняемых по
ПС, в целях проверки и сбора данных на этапах ЖЦ и
проведения измерения отдельных показателей (число
отказов, сбоев) тестирования для оценки характеристик
качества, указанных в требованиях, посредством
выполнения системы на ЭВМ. Тестирование основывается
на систематических, статистических, (вероятностных) и
имитационных методах.

8.

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

9.

Детерминированное тестирование. Это наиболее трудоемкий
и детализированный вид тестирования, требующий
многократного выполнения программы с использованием
определенных, специальным образом подобранных, тестовых
наборов данных. При этом тестировании каждая комбинация
исходных данных и соответствующие выходные данные.
детерминированный
Структурный метод
Функциональный
метод
Белый ящик
Черный ящик

10.

Тестирование черного ящика (black –box testing) –
тестирование, при котором тестировщик имеет доступ к
программе только через интерфейс.
Тестировщик глазами пользователя смотрит на
программу, не имея при этом доступа к коду.
Преимущество такого вида тестирования в том, что
оно не требует знания языков программирования.
Цель этого способа тестирования в том,
чтобы проверить расхождение поведения программы
с документацией. Есть требования в документации, мы
видим, как работает программа, соответственно
проверяем, где неточность.

11.

Тестирование белого ящика – тестирование, при
котором тестировщик имеет доступ к коду.
Кроме того, что тестировщик может просматривать код,
он еще и сам может писать код, который использует
библиотеки существующего программного продукта.
Использование этого метода характерно для модульного
тестирования .
Цель этого вида тестирования в том, чтобы проверить
каждую ветвь кода, каждый путь, каждый
оператор, проверить сам код.

12.

Структурный метод тестирования
Основные критерии структурного метода тестирования
1. Покрытие операторов
Каждый оператор в результате теста должен быть пройден
хотя бы один раз
2. Покрытие узлов ветвления
3. Покрытие условий
Если узел ветвления содержит более одного условия, то
нужно разработать число тестов, достаточных для того,
чтобы возможные результаты каждого условия выполнялись
хотя бы один раз.

13.

Структурный метод тестирования
Покрытие условий
а>2
c=d
нет
да

14.

Структурный метод тестирования
4. Комбинаторное покрытие
условий

15.

Функциональный метод тестирования
Функциональный
метод
Метод
Анализ
Метод
эквивалентного
граничных
функциональных
разбиения
условий
диаграмм

16.

Метод эквивалентного разбиения
1. Исходные данные необходимо разбить на конечное число
классов эквивалентности.
Класс эквивалентности - множество входных значений,
каждый из которых имеет одинаковую вероятность
обнаружения конкретного типа ошибки.
2. Каждый тест должен включать, по возможности,
максимальное количество классов эквивалентности, чтобы
минимизировать общее число тестов.
Классы эквивалентности выделяются путём выбора каждого
входного условия, которые берутся с помощью технического
задания или спецификации и разбиваются на две и более
группы.

17.

Входные условия
ПКЭ
1. Входные условия
описывают
1 х 8
некоторый диапазон
значений
Пример: х от 1 до 8
2. Если входное
условие описывает 1.Почта
конечное число
2.Телеграф
конкретных
3.Телетайп
значений
Пример: способ
передачи
информации между
городами: почта,
телеграф,
телетайп.
3. Описывает
ситуацию «должно
1-ый символ - буква
быть»
Пример: имя файла
начинается с буквы
(первый символ)
НКЭ
1.х < 1
2.x > 8
Радиосвязь
1-ый символ –
не буква

18.

ПРАВИЛА ВЫДЕЛЕНИЯ КЛАССОВ
ЭКВИВАЛЕНТНОСТИ
1. Если входное условие описывает область значений,
например «Целое число принимает значение от 0 до 999», то
существует один правильный класс эквивалентности и два
неправильных.
2. Если входное условие описывает число значений, например
«Число строк во входном файле лежит в интервале (1..6)», то
также существует один правильный класс и два
неправильных.
3. Если входное условие описывает множество входных
значений, то определяется количество правильных классов,
равное количеству элементов в множестве входных значений.
4. Если входное условие описывает ситуацию «должно быть»,
например «Первый символ должен быть заглавным», тогда
один класс правильный и один неправильный.

19.

Метод анализа граничных условий
Граничные условия — это ситуации,
возникающие на высших и нижних границах
входных классов эквивалентности.
-1
1
ПРАВИЛА
Построить тесты с неправильными входными данными
для ситуации незначительного выхода за границы области
значений. Если входные значения должны быть в
интервале [-+1.0], проверяем −1.0, 1.0, −1.00001, 1.000001.
Обязательно писать тесты для минимальной и
максимальной границы диапазона.

20.

Метод функциональных диаграмм
Этапы построения теста:
1. Спецификация разбивается на рабочие участки.
2. В спецификации определяются множество причин
и следствий. Под причиной понимается отдельное
входное условие или класс эквивалентности.
Следствие представляет собой выходное условие
или преобразование системы. Здесь каждой причине
и следствию присваивается номер.
а
b
3
1
2

21.

Метод функциональных диаграмм
3. На основе анализа семантического (смыслового) содержания
спецификации строится таблица истинности, в которой
последовательно перебираются всевозможные комбинации
причин и определяются следствия для каждой комбинации
причин.
Функция ТОЖДЕСТВО
Функция тождество устанавливает, что если значение a есть 1,
то и значение b есть 1; в противном случае значение b есть 0.

22.

Метод функциональных диаграмм
Функция НЕ
Функция не устанавливает, что если значение a есть 1, то
значение b есть 0; в противном случае значение b есть 1.

23.

Метод функциональных диаграмм
Функция ИЛИ
Функция или устанавливает, что если a или b есть 1, то c есть
1, в противном случае c есть 0.

24.

Метод функциональных диаграмм
Функция И
Функция и устанавливает, что если и a и b есть 1, то c есть 1,
в противном случае c есть 0.

25.

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

26.

Метод функциональных диаграмм
ОГРАНИЧЕНИЯ ПРИЧИН
Ограничение Е (исключает, Exclusive)
устанавливает, что Е должно быть истинным, если
хотя бы одна из причин — а или b — принимает
значение 1 (а и b не могут принимать значение 1
одновременно)

27.

Метод функциональных диаграмм
Ограничение I (включает, Inclusive) устанавливает, что
по крайней мере одна из величин, а, b, или с, всегда
должна быть равной 1 (а, b и с не могут принимать
значение 0 одновременно).

28.

Метод функциональных диаграмм
Ограничение О (одно и только одно, Only one)
устанавливает, что одна и только одна из величин а
или b должна быть равна 1

29.

Метод функциональных диаграмм
Ограничение R (требует, Requires) устанавливает,
что если а принимает значение 1, то и b должна
принимать значение 1 (нельзя, чтобы а было равно 1,
a b - 0).

30.

Метод функциональных диаграмм
ОГРАНИЧЕНИЕ ДЛЯ СЛЕДСТВИЙ
Ограничение М (скрывает, Masks) устанавливает, что
если следствие а имеет значение 1, то следствие b
должно принять значение 0.

31.

Метод функциональных диаграмм
Шаги анализа причинно-следственных связей
1)
для каждого модуля перечисляются причины
(условия ввода или классы эквивалентности условий
ввода) и следствия (действия или условия вывода).
Каждой причине и следствию присваивается свой
идентификатор;
2) разрабатывается граф причинно-следственных
связей;
3) граф преобразуется в таблицу решений;
4) столбцы таблицы решений преобразуются в
тестовые варианты.

32.

33.

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

34.

Ошибки программного обеспечения
По времени появления ошибки можно разделить на три
вида:
• структурные ошибки набора (несоответствие числа
открывающих скобок числу закрывающих, отсутствие
парного оператора (например, try без exept), неправильное
употребление синтаксических знаков и т. п.). В некоторых
средах разработки эти ошибки относят к ошибкам
компиляции.
• ошибки компиляции. Возникают из-за ошибок в тексте
кода. Они включают ошибки в синтаксисе, неверное
использование конструкций языка, использование
несуществующих объектов или свойств, методов у объектов.
• ошибки периода выполнения. Такие ошибки возникают,
когда программа выполняется и компилятор (или
операционная система, виртуальная машина) обнаруживает,
что оператор делает попытку выполнить недопустимое или
невозможное действие. Например, деление на ноль.

35.

Ошибки программного обеспечения
В теоретической информатике программные ошибки
классифицируют по степени нарушения логики на:
• синтаксические. заключаются в нарушении правописания
или пунктуации в записи выражений, операторов и т. п., т. е. в
нарушении грамматических правил языка, например
несогласованность скобок, пропуск знаков/символов, неверное
написание зарезервированных слов. Все ошибки данного типа
обнаруживаются компилятором.
• семантические. Заключаются в нарушении порядка
операторов, параметров функций и употреблении выражений.
Семантические ошибки также обнаруживаются компилятором.
• прагматические (или логические). Заключаются в
неправильной логике алгоритма, нарушении смысла
вычислений и т. п. Они являются самыми сложными и крайне
трудно обнаруживаются. Компилятор может выявить только
следствие прагматической.

36.

37.

Тестирование элементов
Цель: индивидуальная проверка каждого
модуля
Используются способы тестирования «белого
ящика»

38.

Тестирование элементов
Тестированию подвергаются:
• интерфейс модуля
• внутренние структуры данных
• независимые пути
• пути обработки ошибок
• граничные условия

39.

Тестирование элементов
Интерфейс модуля
тестируется для проверки правильности вводавывода тестовой информации
Исследование внутренних структур данных
Гарантирует целостность сохраняемых данных

40.

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

41.

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

42.

Тестирование элементов
Источниками ошибок сравнения и
неправильных потоков управления являются:
сравнение различных типов данных;
некорректные логические операции;
неправильное прекращение цикла;
некорректное сравнение переменных;
отказ в выходе при отклонении итерации;
неправильное изменение переменных цикла.

43.

Тестирование элементов
Тестирование путей обработки ошибок
ориентирован на различные исключительные
ситуации

44.

Тестирование элементов
При тестировании граничных условий
возможны ошибки:
• при обработке n-го элемента n-элементного
массива;
• при выполнении m-й итерации цикла с m
проходами;
• при появлении минимального (максимального)
значения.

45.

Тестирование интеграции
Цель: тестирование сборки модулей
Используются способы тестирования
«черного ящика»

46.

Тестирование интеграции
Тесты проводятся для обнаружения ошибок
интерфейса.
Категории ошибок интерфейса:
потеря данных при прохождении через
интерфейс;
отсутствие в модуле необходимой ссылки;
неблагоприятное влияние одного модуля на
другой;
проблемы при работе с глобальными данными.

47.

Тестирование интеграции
Сборка программ при тестировании:
1) монолитная сборка при тестировании;
2) пошаговая:
нисходящая
восходящая

48.

Тестирование интеграции
Монолитная сборка:
Независимо друг от друга тестируются все
модули (автономное тестирование модулей).
Затем вся программа собирается и проводится
тестирование в комплексе.

49.

Тестирование интеграции
Монолитная сборка:
М1
М5
М2
М3
М4
М6
М7
М8
М9

50.

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

51.

Тестирование интеграции
Пошаговая:
Нисходящее тестирование.
М1
З1
З2
З3

52.

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

53.

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

54.

Тестирование интеграции
Пошаговая:
Восходящее тестирование.
Модули тестируются детально и независимо.
При этом используются модули – драйверы.

55.

Тестирование интеграции
Пошаговая:
Восходящее тестирование.
Д2
Д3
Д4
М2
М3
М4

56.

Тестирование интеграции
Пошаговая:
Восходящее тестирование.
Достоинства:
1.Меньшие временные затраты на
тестирование за счет распараллеливания
процесса тестирования.
2.Упрощается разработка тестовых вариантов

57.

Тестирование интеграции
Пошаговая:
Восходящее тестирование.
Недостатки:
1.Система не существует как объект до тех
пор, пока не будет добавлен последний
модуль.
2.Поздно обнаруживаются ошибки в
интерфейсе между модулями.

58.

Тестирование правильности
Цель: проверить реализацию в программной
системе всех функциональных и
поведенческих требований
Используются способы тестирования «черного
ящика»

59.

Тестирование правильности
Важным элементом подтверждения правильности
является проверка конфигурации программного
средства.
Конфигурацией ПС называют совокупность всех
элементов информации, вырабатываемых в
процессе конструирования программного средства.

60.

Тестирование правильности
Минимальная конфигурация включает следующие
базовые элементы:
1) системную спецификацию;
2) план программного проекта;
3) спецификацию требований к ПС;
4) предварительное руководство пользователя;
5) спецификацию проектирования;
6) листинги исходных текстов программ;

61.

Тестирование правильности
7) план и методику тестирования; тестовые
варианты и полученные результаты;
8) руководства по работе и инсталляции;
9) exe – код программы;
10) описание базы данных;
11) руководство пользователя по настройке;
12) документы сопровождения;
13) стандарты и методики конструирования ПС.

62.

Системное тестирование
Цель: проверить правильность объединения
и взаимодействия всех элементов системы,
реализации всех системных функций.
Используются способы тестирования «черного
ящика»

63.

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

64.

Тестирование безопасности
Тестирование безопасности проверяет
фактическую реакцию защитных механизмов,
встроенных в систему, на проникновение.
Тестирование безопасности предусматривает:
попытки узнать пароль с помощью внешних
средств;
целенаправленное введение ошибок;
атаку с помощью утилит, анализирующих
защиты.

65.

Стрессовое тестирование
Стрессовое тестирование производится при
ненормальных запросах на ресурсы системы
(по количеству, частоте, размеру – объему)
Разновидность стрессового тестирования –
тестирование чувствительности, т.е.
обнаружение комбинации данных, которые
могут вызвать нестабильность или
неправильность обработки.

66.

Стрессовое тестирование
Примеры:
генерируется 10 прерываний в секунду (при
средней частоте 1-2 прерывания в секунду);
скорость ввода данных увеличивается прямо
пропорционально их важности;
формируются варианты, требующие максимума
памяти и других ресурсов;
генерируются варианты, вызывающие
переполнение виртуальной памяти;
генерируются варианты на чрезмерный поиск
данных на диске.

67.

Тестирование производительности
Тестирование производительности проверяет
скорость работы ПО в системе.
Внешний инструментарий регулярно
отслеживает интервалы выполнения,
регистрирует события (например,
прерывания) и машинные состояния.

68. Отладка – локализация и устранение ошибок

69.

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

70. Критерии завершенности тестирования программного обеспечения

71.

Критерии завершенности тестирования
1.Временные – истекло время, отведенное
по графику на тестирование
2.Отсутствие ошибок – все тесты
выполняются без выявления ошибок, т.е.
все тесты являются неудачными.
3. Прогнозирование ошибок по графику –
строят график зависимости количества
ошибок от времени их выявления

72.

Тестирование необходимо продолжать, т.е. предполагается чем
больше ошибок выявляется при тестировании, тем больше еще
можем выявить
N
ошибок
t

73.

Количество выявленных ошибок стремится к нулю, следовательно
процесс тестирования можно завершить.
N
ошибок
t

74.

Критерии завершенности тестирования
4.Количественные показатели
надежности
Критерий завершенности тестирования по
показателям надежности, которые
рассчитываются по модулю надежности
программного изделия.