Введение в программную инженерию. Лекция 8

1.

Введение в программную
инженерию
Лекция 8
Тестирование

2.

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

3.

Сколько в программе
ошибок?
По оценкам Бейзсра (Bcizer), сделанным им в
1990 году, передаваемые па тестирование
программы в среднем содержат от 1 до 3
ошибок на каждые 100 исполняемых
операторов.
И хотя есть очень талантливые программисты,
у которых ошибок мало, все же совсем без
ошибок не работает никто.
От 1 до 3 ошибок на 100 строк кода в
программе остается тогда, когда программист
сдает работу тестировщику, утверждая, что
она проверена и ошибок в ней нет.

4.

Therac-25
Ошибка аппарата Therac-25 была,
пожалуй, самой дорогой ошибкой в
современной истории.
Как известно, с июня 1985 по январь
1987 года шесть пациентов получили
передозировку радиации, что
привело к гибели троих из них.

5.

НАТО
В апреле 2000 года секретный девятистраничный
документ НАТО, датированный 23 сентября 1999
года, попал в одну лондонскую издательскую
фирму.
В ходе Косовского конфликта компьютеры НАТО
подвергались атакам со стороны сербов.
Ученые НАТО, в поисках путей защиты от
дальнейших вирусных атак, создавали вирусы для
моделирования различных режимов атаки.
Однако эксперимент пошел не так, как
планировалось.
Экспериментальные вирусы сделали в точности то,
что и должны были сделать…

6.

Intel Pentium
В 1993 году корпорация Intel представила
новый процессор Pentium™, который
обещал стать самым лучшим процессором
на рынке персональных компьютеров в то
время.
Через год после выпуска профессор Томас
Найсели (Thomas Nicely) из Линчбергского
колледжа (Lynchburg College) обнаружил
ошибку и сообщил о ней в Intel.

7.

Intel Pentium
Если коротко, FPU процессора Pentium
возвращает ошибочное значение для
некоторых операций деления.
Например,
1/824633702441,0
вычисляется некорректно (ошибочны
все цифры после восьмой значащей
цифры).

8.

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

9.

Ariane 5
Ракета-носитель Ariane 5 была ответом попыткам
Европейского космического агентства (European
Space Agency) стать лидером в запусках ракет на
коммерческом космическом рынке.
Стоившая 7 миллиардов долларов и строившаяся в
течение 10 лет, Arian 5 могла вывести на орбиту два
трехтонных спутника.
При своем первом полете ракета Ariane 5 взорвалась
через 40 секунд после старта утром 4 июня 1996
года.
Анализ данных полета быстро показал, что ракета
вела себя нормально до того момента, когда она
вдруг отклонилась от курса и самоуничтожилась.

10.

Цензура…
Футбольные фанаты по всей стране не
смогли узнать по Интернету результаты
воскресного Суперкубка.
Оказалось, что программы-фильтры
доступа в Web, установленные на
браузерах (например, в некоторых
публичных библиотеках), рассматривали
«ХХХ» в словах «Суперкубок XXXIV» как
ссылку на порносайт

11.

Интернет-служба BBC
Я надеюсь, вы сохраните пристрастие к
острым словечкам, когда я заскочу к вам в
класс в субботу в Сканторп, Эссекс.
«I hope you still have your appetite for scraps
of dickens when I bump into you in class in
Scunthorpe, Essex, on Saturday».
Программа превратила его в «I hope you
still have your appetite for s****s of dickens
when I ***p into you in class in S****horpe,
Es***, on Sa****ay»

12.

F-16 “Fighting Falcon”
Испытания американского истребителя F16 “Fighting Falcon” проводились,
понятное дело, в северном полушарии. На
заключительном этапе самолет решили
проверить где-то в Латинской Америке, но
уже с другой стороны экватора.
При переводе самолета в режим
автопилота он автоматически развернулся
“вверх ногами”.

13.

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

14.

Amazon
Летом 2013 года произошло отключение
серверов американской компании
Amazon (самая известная компания в
мире по продаже различных товаров и
услуг через Интернет).
Это привело к потере файлов
пользователей, хранившихся в сетевом
хранилище.

15.

American Airlines
В 2014 году из-за ошибки в
программе была заблокирована
работа всех самолетов авиакомпании
American Airlines.
Сбой возник в системе бронирования
билетов – проводилась работа по
объединению программных платформ
нескольких компаний.

16.

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

17.

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

18.

Чего не может тестирование?
Тестирование не может показать
отсутствия дефектов!
Тестирование может показывать только
присутствие дефектов!
Важно помнить это (скорее печальное)
утверждение при проведении
тестирования.

19.

20.

Верификация и аттестация
Верификацией и аттестацией называют
процессы проверки и анализа, в ходе которых
проверяется соответствие программного
обеспечения своей спецификации и
требованиям заказчиков.
Верификация и аттестация охватывают
полный жизненный цикл ПО — они
начинаются на этане анализа требований и
завершаются проверкой программного кода
на этапе тестирования готовой программной
системы.

21.

Верификация
Отвечает на вопрос: «Правильно ли
создана система?»
Проверяет соответствие ПО
системной спецификации, в
частности функциональным и
нефункциональным требованиям

22.

Аттестация
Отвечает на вопрос: «Правильно ли работает
система?»
Аттестация — более общий процесс чем
верификация.
Во время аттестации необходимо убедиться,
что программный продукт соответствует
ожиданиям заказчика.
Проводится после верификации, для того
чтобы определить, насколько система
соответствует не только спецификации, но и
ожиданиям заказчика.

23.

Методики проверки и
анализа систем
Инспектирование ПО. Анализ и проверка
различных представлений системы, например
документации спецификации требований,
архитектурных схем или исходного кода программ.
Инспектирование и автоматический анализ — это
статические методы верификации и аттестации,
поскольку им не требуется исполняемая система.
Тестирование ПО. Запуск исполняемого кода с
тестовыми данными и исследование выходных данных
и рабочих характеристик программного продукта для
проверки правильности работы системы.
Тестирование — это динамический метод
верификации и аттестации, так как применяется к
исполняемой системе.

24.

Тестирование и
инспектирование

25.

Отладка ПО

26.

27.

Уровни тестирования
Модульное тестирование. Тестируется минимально возможный для тестирования компонент,
например отдельный класс или функция.
Интеграционное тестирование. Проверяется,
есть ли какие-либо проблемы в интерфейсах и
взаимодействии между интегрируемыми компонентами, например, не передается информация,
передается некорректная информация.
Системное тестирование. Тестируется
интегрированная система на ее соответствие
исходным требованиям.

28.

Системное тестирование.
Альфа-тестирование — имитация реальной
работы с системой штатными разработчиками либо
реальная работа с системой потенциальными
пользователями/заказчиком на стороне
разработчика. Обнаруженные ошибки могут быть
переданы тестировщикам для дополнительного
исследования в окружении, подобном тому, в
котором будет использоваться ПО.
Бета-тестирование — в некоторых случаях
выполняется распространение версии с
ограничениями (по функциональности или времени
работы) для некоторой группы лиц с тем, чтобы
убедиться, что продукт содержит достаточно мало
ошибок.

29.

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

30.

Тестирование дефектов

31.

Исчерпывающее
тестирование
Гарантирует полную проверку программы
Требует проверить все наборы исходных
данных, все варианты их обработки и
включает большое количество тестовых
вариантов.
Во многих случаях остается только мечтой
— срабатывают ресурсные ограничения
(прежде всего, ограничения по времени).

32.

Хорошие и успешные тесты
Хорошим считают тестовый вариант с
высокой вероятностью обнаружения
еще не раскрытой ошибки.
Успешным называют тест, который
обнаруживает до сих пор не раскрытую
ошибку.

33.

Характеристики тестов
Детективность: тест должен с большой
вероятностью обнаруживать возможные
ошибки
Покрывающая способность: один тест
должен выявлять как можно больше ошибок.
Воспроизводимость: ошибка должна
выявляться независимо от изменяющихся
условий (например, от временных
соотношений) — это труднодостижимо для
времязависимых программ, результаты
которых часто невоспроизводимы.

34.

Ошибки данных
Все ли переменные в программе
инициализированы до начала использования
их значений?
Все ли константы именованы?
Равна ли верхняя граница массива его
размеру или на единицу меньше этого
размера?
Какой разделитель используется для
разделения символьных строк?
Возможно ли переполнение буфера?

35.

Ошибки управления
Выполняются ли условия для каждого
условного оператора? Все ли циклы
завершаются?
Правильно ли в составных операторах
расставлены скобки?
Все ли выборы выполняются в
операторах выбора?

36.

Ошибки ввода-вывода
Используются ли в программе
входные переменные?
Всем ли выходным переменным перед
выводом присваиваются значения?
Могут ли какие-нибудь входные
данные привести к нарушению
системных данных?

37.

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

38.

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

39.

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

40.

Информационные потоки
процесса тестирования

41.

Потоки данных
Входные:
текст программы;
исходные данные для запуска программы;
ожидаемые результаты.
Выходные:
прогноз надежности системы;
найденные ошибки.

42.

Процесс тестирования (1)
Выполняются тесты, все полученные результаты
оцениваются — реальные результаты тестов
сравниваются с ожидаемыми результатами.
Когда обнаруживается несовпадение, фиксируется
ошибка — начинается отладка.
Процесс отладки непредсказуем по времени.
На поиск места дефекта и исправление может
потребоваться час, день, месяц.
Неопределенность в отладке приводит к большим
трудностям в планировании действий.

43.

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

44.

Процесс тестирования (3)
Если функции ПО реализованы
правильно, а обнаруженные ошибки легко
исправляются, может быть сделан один из
двух выводов:
качество и надежность ПО
удовлетворительны;
тесты не способны обнаруживать
серьезные ошибки.

45.

Процесс тестирования (4)
Если тесты не обнаруживают ошибок,
появляется сомнение в том, что тестовые
варианты достаточно продуманы и что в
ПО нет скрытых ошибок.
Скрытые ошибки будут обнаруживаться
пользователями и корректироваться
разработчиком на этапе сопровождения
(когда стоимость исправления возрастает
в 60-100 раз по сравнению с этапом
разработки).

46.

Процесс тестирования (5)
Результаты, накопленные в ходе
тестирования, могут оцениваться и
более формальным способом.
Для этого используют модели
надежности ПО, выполняющие
прогноз надежности по реальным
данным об интенсивности ошибок.

47.

Принципы
тестирования программ
функциональное тестирование
(тестирование «черного ящика»)
структурное тестирование
(тестирование «белого ящика»)

48.

Тестирование
«черного ящика»
Известны: функции программы.
Исследуется: работа каждой функции на
всей области определения.
Основное место приложения тестов:
интерфейс ПО

49.

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

50.

При тестировании
«черного ящика»
Рассматриваются только системные
характеристики программ
Игнорируется внутренняя логическая структура
программ
Исчерпывающее тестирование невозможно.
Если в программе 10 входных величин и каждая
принимает по 10 значений, то потребуется 1010
тестовых вариантов.
Тесты не реагируют на многие особенности
программных ошибок.

51.

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

52.

При тестировании
«белого ящика»
Проверяется корректность построения всех
элементов программы и правильность их
взаимодействия друг с другом.
Обычно анализируются управляющие связи
элементов, реже — информационные связи.
Характеризуется степенью, в какой тесты
выполняют или покрывают логику (исходный
текст) программы.
Исчерпывающее тестирование затруднительно.

53.

Области эквивалентности

54.

Особенности тестирования
«белого ящика»
Основано на анализе управляющей структуры
программы.
Программа считается полностью проверенной, если
проведено исчерпывающее тестирование маршрутов
(путей) ее графа управления. В этом случае
формируются тестовые варианты, в которых:
гарантируется проверка всех независимых маршрутов
программы;
проходятся ветви True, False для всех логических
решений;
выполняются все циклы (в пределах их границ и
диапазонов);
анализируется правильность внутренних структур
данных.

55.

Недостатки тестирования
«белого ящика» (1)
1. Количество независимых маршрутов может быть
очень велико. Например, если цикл в программе
выполняется k раз, а внутри цикла имеется n
ветвлений, то количество маршрутов вычисляется
k
по формуле
m n
i 1
i
При n = 5 и k = 20 количество маршрутов m =
1014. Примем, что на разработку, выполнение и
оценку теста по одному маршруту расходуется 1
мс. Тогда при работе 24 часа в сутки 365 дней в
году на тестирование уйдет 3170 лет.

56.

Недостатки тестирования
«белого ящика» (2)
2. Исчерпывающее тестирование маршрутов не
гарантирует соответствия программы исходным
требованиям к ней.
3. В программе могут быть пропущены некоторые
маршруты.
4. Нельзя обнаружить ошибки, появление которых
зависит от обрабатываемых данных (ошибки,
обусловленные выражениями типа
if abs (a-b) < eps ...
if(a+b+c)/3=a ....

57.

Достоинства тестирования
«белого ящика» (1)
Cвязаны с тем, что принцип «белого ящика»
позволяет учесть особенности программных
ошибок.
1. Количество ошибок минимально в «центре» и
максимально на «периферии» программы.
2.Предварительные предположения о вероятности
потока управления или данных в программе
часто бывают некорректны. В результате
типовым может стать маршрут, модель
вычислений по которому проработана слабо.

58.

Достоинства тестирования
«белого ящика» (2)
3. При записи алгоритма ПО в виде текста на языке
программирования возможно внесение типовых
ошибок трансляции (синтаксических и
семантических).
4. Некоторые результаты в программе зависят не от
исходных данных, а от внутренних состояний
программы.
Каждая из этих причин является аргументом для
проведения тестирования по принципу «белого
ящика». Тесты «черного ящика» не смогут
реагировать на ошибки таких типов.

59.

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

60.

Тестирование сборки

61.

Нисходящее
тестирование сборки

62.

Восходящее
тестирование сборки

63.

Способ тестирования
базового пути
Основан на принципе «белого ящика»
Автор этого способа — Том МакКейб (1976)
Позволяет получить оценку комплексной сложности программы и использовать её для определения
необходимого количества тестовых вариантов.
Тестовые варианты разрабатываются для проверки
базового множества путей (маршрутов) в программе. Они гарантируют однократное выполнение
каждого оператора программы при тестировании.
Для представления программы используется
потоковый граф.

64.

Особенности
потокового графа (1)
1. Граф строится отображением
управляющей структуры программы.
В ходе отображения закрывающие скобки
условных операторов и операторов циклов
(end if; end loop) рассматриваются как
отдельные (фиктивные) операторы.
2. Узлы (вершины) потокового графа
соответствуют линейным участкам
программы, включают один или несколько
операторов программы.

65.

Особенности
потокового графа (2)
3. Дуги потокового графа отображают поток
управления в программе (передачи управления
между операторами). Дуга — это
ориентированное ребро.
4. Различают операторные и предикатные узлы. Из
операторного узла выходит одна дуга, а из
предикатного — две дуги.
5. Предикатные узлы соответствуют простым
условиям в программе. Составное условие
(используется одна или несколько булевых
операций OR и/или AND) программы
отображается в несколько предикатных узлов.

66.

Особенности
потокового графа (3)
if a OR b then
x
else
у
end if;

67.

Особенности
потокового графа (4)
6. Замкнутые области,
образованные дугами и узлами,
называют регионами.
7. Окружающая граф среда
рассматривается как
дополнительный регион.
Показанный здесь граф имеет
три региона: R1, R2, R3.

68.

Пример
процедура сжатия
0 Процедура сжатие
1 выполнять пока нет EOF
1
читать запись;
2
если запись пуста
3
то удалить запись:
4
иначе если поле а >= поля b
5
то удалить b;
6
иначе удалить а;
7а
конец если;
7а
конец если;
7b конец выполнять;
8 конец сжатие;

69.

Цикломатическая сложность
Метрика ПО, которая обеспечивает
количественную оценку логической
сложности программы.
В способе тестирования базового пути
Цикломатическая сложность определяет:
количество независимых путей в базовом
множестве программы;
верхнюю оценку количества тестов, которое
гарантирует однократное выполнение всех
операторов.

70.

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

71.

Пример
независимых путей
Независимые пути:
Путь 1: 1-8.
Путь 2: 1-2-3-7а-7b-1-8.
Путь 3: 1-2-4-5-7а-7b-1-8.
Путь 4: 1-2-4-6-7а-7b-1-8.
Заметим, что каждый новый
путь включает новую дугу.
Все независимые пути
графа образуют базовое
множество путей.

72.

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

73.

Способы вычисления
цикломатической сложности
1) цикломатическая сложность равна
количеству регионов потокового графа;
2) цикломатическая сложность
определяется по формуле V(G)-E-N+2,
где Е — количество дуг, N — количество
узлов потокового графа;
3) цикломатическая сложность
формируется по выражению V(G) =p + 1,
где р — количество предикатных узлов в
потоковом графе G.

74.

Вычисление цикломатической сложности
1) потоковый граф имеет
4 региона;
2) V(G) = 11 дуг - 9 узлов +
+ 2 = 4;
3) V(G) = 3 предикатных
узла +1 = 4.
Цикломатическая
сложность потокового
графа равна четырем.

75.

Способ тестирования
базового пути (1)
Шаг 1.
На основе текста программы формируется
потоковый граф:
нумеруются операторы текста
производится отображение
пронумерованного текста программы в
узлы и вершины потокового графа

76.

Пример: вычисления
среднего значения
Процедура сред;
1 i := 1;
1 введено := 0;
1 колич := 0;
1 сум := 0;
вып пока 2 - вел( i ) <> stop и введено <= 500 - 3
4
введено:= введено + 1;
если 5 - вел( i ) >= мин и вел( i ) <= макс - 6
7
то колич := колич + 1;
7
сум := сум + вел( i );
8
конец если;
8
i := i + 1;
9 конец вып;
10
если колич > 0
11
то сред := сум / колич;
12
иначе сред := stop;
13
конец если;
конец сред;

77.

Способ тестирования
базового пути (2)
Шаг 2. Определяется
цикломатическая
сложность потокового
графа — по каждой из
трех формул:
1) V(G) = 6 регионов;
2) V(G) = 17 дуг - 13
узлов + 2 = 6;
3) V(G) = 5 предикатных
узлов + 1 = 6.

78.

Способ тестирования
базового пути (3)
Шаг 3. Определяется базовое множество
независимых линейных путей:
Путь 1: 1-2-10-11-13; /вел=stор, колич>0.
Путь 2: 1-2-10-12-13;/вел=stop, колич=0.
Путь 3: 1-2-3-10-11-13;
/попытка обработки 501-й величины.
Путь 4: 1-2-3-4-5-8-9-2-... /вел<мин.
Путь 5: 1-2-3-4-5-6-8-9-2-... /вел>макс.
Путь 6: 1-2-3-4-5-6-7-8-9-2-...
/режим нормальной обработки.

79.

Способ тестирования
базового пути (4)
Шаг 4. Подготавливаются тестовые варианты,
инициирующие выполнение каждого пути.
Каждый тестовый вариант формируется в
следующем виде:
Исходные данные (ИД):
Ожидаемые результаты (ОЖ.РЕЗ.):
Исходные данные должны выбираться так, чтобы
предикатные вершины обеспечивали нужные
переключения — запуск только тех операторов,
которые перечислены в конкретном пути,
причем в требуемом порядке.

80.

Способ тестирования
базового пути (5)
Определим тестовые варианты,
удовлетворяющие выявленному множеству
независимых путей.
Тестовый вариант для пути 1 ТВ1:
ИД: вел(k) = допустимое значение,
где k < i; вел(i) = stop, где 2 < i < 500.
ОЖ.РЕЗ.: корректное усреднение
основывается на k величинах и
правильном подсчете.

81.

Способ тестирования
базового пути (6)
Тестовый вариант для пути 2 ТВ2:
ИД: вел(1)=stор.
ОЖ.РЕЗ.: сред=stор, другие величины имеют
начальные значения.
Тестовый вариант для пути 3 ТВЗ:
ИД: попытка обработки 501-й величины, первые
500 величин должны быть правильными.
ОЖ.РЕЗ.: корректное усреднение основывается
на k величинах и правильном подсчете.

82.

Способ тестирования
базового пути (7)
Тестовый вариант для пути 4 ТВ4:
ИД: вел(i)=допустимое значение, где i ≤ 500;
вел(k) < мин, где k < i.
ОЖ.РЕЗ.: корректное усреднение основывается
на k величинах и правильном подсчете.
Тестовый вариант для пути 5 ТВ5:
ИД: вел(i)=допустимое значение, где i ≤ 500;
вел(k) > макс, где k < i.
ОЖ.РЕЗ.: корректное усреднение основывается
на п величинах и правильном подсчете.

83.

Способ тестирования
базового пути (8)
Тестовый вариант для пути 6 ТВ6:
ИД: вел(i)=допустимое значение, где i ≤
500.
ОЖ.РЕЗ.: корректное усреднение
основывается на п величинах и
правильном подсчете.

84.

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

85.

Способы
тестирования условий
Цель — строить тестовые варианты для
проверки логических условий программы.
При этом желательно обеспечить охват
операторов из всех ветвей программы.
Если условие некорректно, то
некорректен по меньшей мере один из
элементов условия.

86.

Терминология
Простое условие — булева переменная или
выражение отношения. Выражение отношения
имеет вид Е1 <оператор отношения> E2, где
E1, Е2 — арифметические выражения, а в качестве оператора отношения используется один из
следующих операторов: <, >, =, >=, <+, <>,.
Составное условие состоит из нескольких
простых условий, булевых операторов и круглых
скобок. Будем применять булевы операторы
NOT, OR, AND, XOR. Условия, не содержащие
выражений отношения, называют булевыми
выражениями.

87.

Типы ошибок в условии
ошибка булева оператора (наличие
некорректных / отсутствующих /
избыточных булевых операторов);
ошибка булевой переменной;
ошибка булевой скобки;
ошибка оператора отношения;
ошибка арифметического выражения.

88.

Достоинства методики
тестирования условий
Достаточно просто выполнить
измерение тестового покрытия
условия.
Тестовое покрытие условий в
программе — это фундамент для
генерации дополнительных тестов
программы.

89.

Цель тестирования условий
определение ошибок в условиях
определение других ошибок в программах
Если набор тестов для программы А эффективен
для обнаружения ошибок в условиях,
содержащихся в А, то вероятно, что этот набор
также эффективен для обнаружения других
ошибок в А.
Кроме того, если методика тестирования
эффективна для обнаружения ошибок в условии,
то вероятно, что эта методика будет эффективна
для обнаружения ошибок в программе.

90.

Простейшая методика
тестирование ветвей.
Здесь для составного условия С
проверяется:
каждое простое условие
(входящее в него);
Тruе-ветвь;
False-ветвь.

91.

Сложная методика (1)
Тестирование области определения.
В ней для выражения отношения
требуется генерация 3-4 тестов.
Выражение вида Е1 <оператор
отношения> Е2
Проверяется тремя тестами, которые
формируют значение Е1 большим, чем
Е2, равным Е2 и меньшим, чем Е2.

92.

Сложная методика (2)
Если оператор отношения неправилен, а
Е1 и Е2 корректны, то эти три теста
гарантируют обнаружение ошибки
оператора отношения.
Для определения ошибок в Е1 и Е2 тест
должен сформировать значение Е1
большим или меньшим, чем Е2, причем
обеспечить как можно меньшую разницу
между этими значениями.

93.

Сложная методика (3)
Для булевых выражений с n
переменными требуется набор из 2n
тестов. Этот набор позволяет
обнаружить ошибки булевых
операторов, переменных и скобок, но
практичен только при малом n.
Если в булево выражение каждая булева
переменная входит только один раз,
то количество тестов легко уменьшается.

94.

Тестирование циклов
Цикл — наиболее распространенная
конструкция алгоритмов, реализуемых в
программах.
Тестирование циклов производится по
принципу «белого ящика», при проверке
циклов основное внимание обращается
на правильность конструкций циклов.

95.

Типы циклов
Простые
Вложенные
Объединенные
Неструктурированные

96.

Простые циклы
Для проверки простых циклов с количеством
повторений n может использоваться один из
следующих наборов тестов:
1) прогон всего цикла;
2) только один проход цикла;
3) два прохода цикла;
4) m проходов цикла, где m<n;
5) n - 1, n, n + 1 проходов цикла.

97.

Вложенные циклы
С увеличением уровня вложенности
циклов количество возможных путей
резко возрастает. Это приводит к
нереализуемому количеству тестов.
Для сокращения количества тестов
применяется специальная методика, в
которой используются такие понятия,
как объемлющий и вложенный циклы

98.

Объемлющий
и вложенный циклы

99.

Порядок тестирования
вложенных циклов

100.

Шаги тестирования (1)
1. Выбирается самый внутренний цикл.
Устанавливаются минимальные
значения параметров всех остальных
циклов.
2. Для внутреннего цикла проводятся
тесты простого цикла. Добавляются
тесты для исключенных значений и
значений, выходящих за пределы
рабочего диапазона.

101.

Шаги тестирования (2)
3. Переходят в следующий по порядку
объемлющий цикл. Выполняют его
тестирование. При этом сохраняются
минимальные значения параметров для
всех внешних (объемлющих) циклов и
типовые значения для всех вложенных
циклов.
4. Работа продолжается до тех пор, пока не
будут протестированы все циклы

102.

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

103.

Неструктурированные циклы
Неструктурированные циклы
тестированию не подлежат.
Этот тип циклов должен быть
переделан с помощью
структурированных программных
конструкций.

104.

Предваряющее
тестирование
Часто используют при экстремальном
программировании.
Способ создания и последующего
улучшения ПО, при котором сначала
пишутся тесты, а затем
программируется код, который будет
подвергаться этим тестам.

105.

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

106.

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

107.

Как перейти от поиска
ошибок к тестированию?
Анализ продукта и документирование
тестов
Оценка тестирования
Обсуждение целей тестирования
командой
Понимание пользователей и их бизнеспроцессов
Техническая квалификация и понимание
архитектуры

108.

Как стать хорошим
тестировщиком?
Учитесь узнавать, что не так, что не нравится
другим участникам команды разработки.
Обязательно исследуйте пропущенные ошибки и
делайте всё для того, чтобы больше их не
пропускать.
Не гонитесь за заведением багов — вашей
мантрой должны быть «счастье пользователя»,
«качественный продукт» и «успешный проект», а
не «завести как можно больше багов» — ОЧЕНЬ
часто эти 2 цели оказываются слишком далеки
друг от друга.

109.

Спасибо за внимание!