329.56K

Category:

software

Тестирование и отладка ПО. Системы автоматизации тестирования ПО

1.

Системы автоматизации
тестирования ПО
Лекция 13
Тема 4: Тестирование и отладка ПО
1

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

3.

Тесты
Исходная информация – требования и
алгоритм
Требования :
Функциональные – явно описывают, что
система должна делать и какие выполнять
преобразования входных данных в выходные
Нефункциональные – определяют свойства
системы, напрямую не связанные с
функциональностью, например – время отклика на
действие пользователя, время непрерывной работы
…
3

4.

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

5.

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

6.

Управление тестированием
Тестирование не только выявляет ошибки, но и
позволяет предупреждать их появление в
дальнейшем за счет:
Проектирования тестов
Тестирование(проверка) на всех этапах ЖЦ
Тестированию подлежат:
Программа
Требования к программе
Архитектура
Исходный код
ТЕСТЫ
Это позволяет организовать управляемый
процесс тестирования
6

7.

Управление и документирование
тестирования
Системность тестирования
Документирование – основа управляемости и
повторяемости процесса тестирования
Назначение документации - координация совместных
действий большого количества разработчиков в
течение более или менее длительных промежутков
времени
Документация тестирования ведется на всех этапах
разработки ПО
Виды документации:
План тестирования
Результаты тестирования
7

8.

План тестирования
План тестирования – документ, определяющий стратегию
тестирования, содержащий:
1.
Цели тестирования
2.
Объекты тестирования (функции, элементы и т.п.)
3.
Этапы и задачи тестирования
4.
Сроки и ответственность за выполнение задач и этапов
5.
Ресурсы, необходимые для проведения тестирования на
каждом этапе
6.
Инструментальные средства, необходимые для
проведения тестирования на каждом этапе
7.
Правила оформления тестов и их результатов
8.
Подходы к тестированию (методики тестирования)
9.
Критерии успешности/неуспешности, начала/окончания
тестирования
10. Перечень тестов, их назначение и порядок выполнения
8

9.

Результаты тестирования
Содержат:
Результаты выполнения тестов, позволяющие без их
повторного проведения судить об успешности или
неуспешности их выполнения
Выходные данные для соответствующих входных данных
Выявленные аномалии в поведении системы при тестировании
На основании результатов тестирования – выводы о:
Корректности работы системы
Соответствии системы внешним спецификациям
Наличии определенных дефектов, требующих
устранения
9

10.

Требования
Тестовое
окружение
Набор тестов
Отчет о
результатах
выполнения
тестов
Отчет о
проблемах
Запрос на
изменение
10

11.

Тестирование и качество
Качество – степень соответствия совокупности характеристик
объекта требованиям
Документированная статистика по результатам тестирования
=> можно анализировать ошибки (какие, где, у кого, чаще-реже)
=> можно количественно оценить и сравнить
=> Контроль качества
Повторяемость и предсказуемость результатов тестирования +
информация о текущем состоянии протестированности +
критерии (уровня качества, объемы тестов, что конкретно
тестировать) => Управление качеством
Понимание, что обнаружение и устранение дефекта дороже,
чем его недопущение => более раннее обнаружение или
предотвращение ошибок => Обеспечение качества
(На всех этапах и во всех процессах ЖЦ)
Все что снижает количество ошибок – повышает качество
11

12.

Отладка
Тестирование = выявление дефектов
Отладка = тестирование + локализация и
устранение дефектов
Процесс отладки:
1. Стабилизация ошибки – обеспечение гарантированного
воспроизведения ошибки
2. Локализация ошибки – определение источника
ошибки или понимание еще больших ошибок
3. Исправление ошибки
4. Тестирование исправления
5. Поиск схожих ошибок и их исправление
6. Задокументировать и поделиться опытом
Устранение причин, а не последствий
12

13.

Методы локализации ошибок
Аналитические – основаны на
результатах тестирования и анализе
текста программы
Экспериментальные
(инструментальные) – основаны на
использовании специальных средств
отладки (отладчики и т.п.)
13

14.

Аналитический метод
1. Сбор всевозможной информации об ошибке, действиях и
данных приводящих к возникновению ошибки
2. Анализ собранных данных и выявление закономерностей
в появлении ошибки (при необходимости проведение
дополнительного тестирования и п.1.)
3. Формирование гипотез об ошибке, выбор одной гипотезы
путем повторного выполнения п.п.1-2.
4. Проверка гипотезы – подтверждение или опровержение
гипотезы путем тестирования или инспектирования
программы, при опровержении гипотезы – сбор
дополнительных данных и формулирование новой
гипотезы (п.п. 1-3)
5. Гипотеза подтвердилась – ошибка найдена
14

15.

Экспериментальный метод
Средства аварийной печати – выдача
информации при возникновении
аварийной ситуации
Выдача на экран текущего состояния регистров
процессора, сохранения dump программы,
позволяющие проводить последующий разбор
произошедшего
Встраивание разработчиком в программу средств
печати вспомогательной информации (логические
состояния программы или объекта, значения
переменных)
15

16.

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

17.

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

18.

Экспериментальный метод
Средства печати в узлах выполнения
программы – вставка в текст
дополнительных операторов вывода
информации о состоянии вычислений при
нахождении программы на определенном
шаге вычислений
18

19.

Принципы экспериментального
метода
Планирование
Минимальное количество данных при
аварийной печати или выводе
информации на экран
Автоматизация процесса отладки (лог)
Сохранение отладочных средств в тексте
программы (debug)
19

20.

Принципы исправления ошибок
Обнаруженная ошибка либо исправляется немедленно,
либо фиксируется факт наличия ошибки с принятием
решения об откладывании действий по исправлению
Исправление ошибки требует возврата к тому этапу
разработки ПО, на котором она была допущена
Вероятность правильного исправления ошибки ≠ 100%
Чем крупнее программный продукт, тем больше
вероятность внесения новых ошибок при исправлении
существующих
Документирование исправлений – изменения вносятся не
только в программный код, но и в сопутствующую
документацию (заголовки модулей, комментарии,
техническую документацию)
Исправление ошибок, а не их симптомов
20

21.

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

22.

Системы автоматизации
тестирования
Без автоматизации
Разработка плана
тестирования
Разработка набора
тестов
Проведение
тестирования путем
запуска каждого теста
из набора
Фиксация результатов
тестирования каждого
теста
С автоматизацией
Разработка плана
тестирования
Разработка набора
тестов на языке
системы тестирования
Проведение
тестирования путем
запуска системы
тестирования
Получение результатов
тестирования от системы
тестирования
23

23.

Объект тестирования
Модули
модульное, интеграционное тестирование
регрессионное модульное тестирование
ПО в целом
системное тестирование
регрессионное системное тестирование
Пользовательский интерфейс
системное тестирование
регрессионное системное тестирование
24

24.

Реализация
Библиотеки на языке программирования
модульное, интеграционное
регрессионное модульное тестирование
Кто проводит: разработчики, тестировщики-разработчики
Пример: Boost unit test framework, CppUnit, Google testing
framework (gtest)
Header-файлы (без дополнительных библиотек)
модульное, интеграционное
регрессионное модульное тестирование
Кто проводит: разработчики, тестировщики–разработчики
Пример: Catch
25

25.

Реализация
Отдельное ПО
тестирование функционально-законченного программного
продукта
системное тестирование
регрессионное системное тестирование
Кто проводит: тестировщики–не разработчики
Виды:
программы, работающие по сценарию (набор тестов)
программы–имитаторы действий пользователя
генераторы потоков данных для нагрузочного
тестирования
Пример: HP QuickTest, HP LoadRunner, IBM Rational
TestStudio, IBM Rational Performance Tester, Selenium,
TestComplete
26

26.

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

27.

Возможности автоматизации
Кроссплатформенность – большинство систем
реализовано в виде открытых исходных кодов
(Linux, Windowx, Mac, Solaris и т.д.)
Возможность генерации отчетов в различных
форматах, удобных для последующего
автоматического анализа
28

28.

Принципы
Любое изменение исходного текста
программы должно сопровождаться
набором тестов, доказывающим
корректность изменений
Интеграция ПО только из модулей с
доказанной корректностью
функционирования модулей =
соответствующими наборами тестов
Дополнительные тесты, доказывающие
корректность интеграции и корректность
функционирования ПО в целом
29

29.

Достоинства
Отсутствие человеческого фактора
(программа тестирует программу, ошибки
возможны только в алгоритме тестирования и
самих тестах)
Дешевле и быстрее в долгосрочной
перспективе
Легкость повторного использования
Легкость организации нагрузочного (с большим
количеством пользователей) и регрессионного
тестирования
Отсутствие человека (может заняться другим)
30

30.

Недостатки
Сложность тестирования графического
пользовательского интерфейса (имитаторы
поведения, средства распознавания элементов
управления)
Дороже и медленнее в краткосрочной
перспективе
Существенное изменение ПО приводит к
необходимости переписывания набора
тестов (изменение алгоритма ПО)
Невозможность сразу тестировать мелкие
локальные изменения (не написан набор тестов)
31

31.

Недостатки
Сложность изменения сценария
тестирования в зависимости от результатов
тестирования (должно быть учтено в наборе тестов
и алгоритме тестирования)
Отсутствие человека (человек может заметить
какие-то особенности поведения тестируемого ПО и
сосредоточиться на определенных моментах или
сменить вектор тестирования, набор тестов
тестирует только то, что ему написано)
32

32.

Системы автоматизации
тестирования ПО
Лекция 13
Тема 4: Тестирование и отладка ПО
34

33.

Вопросы
1.
2.
3.
Определение теста. Типы тестов.
Управление и документирование процесса
тестирования – план и результаты
тестирования.
Тестирование и отладка ПО. Основные шаги
процесса отладки. Методы локализации
ошибок.
Системы автоматизации тестирования.
Назначение. Пример.
35

34.

Catch
Заголовочный файл (catch.hpp)
Не требует отдельной установки
Подключается на этапе компиляции
Подходит для:
Модульного тестирования (+регрессионное)
Интеграционного тестирования (+регрессионное)
Самих разработчиков
Разработчиков тестов
36

35.

Набор тестов
TEST_CASE(test_name,[group_name][…])
test_name – название набора теста (уникальное)
group_name – название группы наборов тестов
Набор тестов является единицей управления
и отказов:
Возможность запускать
Все наборы тестов
Конкретный набор тестов
Конкретную группу тестов
В зависимости от результатов тестов в наборе,
весь набор может прекращать тестирование
37

36.

Проверка условий (тест)
REQUIRE(условие) – при невыполнении
условия TEST_CASE прекращает работу
CHECK(условие) – при невыполнении
условия TEST_CASE продолжает работу
Проверка невыполнения условия:
REQUIRE_FALSE
CHECK_FALSE
38

37.

Пример
Файл модуля:
int sum(int a, int b){
if (a==0 && b==0) throw
std::runtime_error("Example throw");
return a + b;
}
Файл с тестами:
// внимание! define CATCH_CONFIG_MAIN должен быть
выше include "../catch.hpp"
// иначе будет ошибка вида
// .../tests.cpp:23: undefined reference to
Catch::StringRef::StringRef(char const*)
#define CATCH_CONFIG_MAIN // This tells Catch to
provide a main() - only do this in one cpp file
#include "catch.hpp"
39

38.

Пример(продолжение)
Файл с тестами:
…
TEST_CASE("test1", "[testgroup1]")
{
REQUIRE(sum(5, 10) == 15);
REQUIRE(sum(5,5) != 15);
}
В выводе будет информация о количестве успешных и
неуспешных тестов.
При ошибке будет сообщение.
Example.cpp:9: FAILED:
REQUIRE( sum(5,10) == 10 )
with expansion:
15 == 10
40

39.

Другие тесты
Проверка отсутствия исключений
Проверка наличия исключений
REQUIRE_THROWS
CHECK_THROWS
Проверка конкретных исключений по типу
REQUIRE_NOTHROW
CHECK_NOTHROW
REQUIRE_THROWS_AS
CHECK_THROWS_AS
Проверка конкретных исключений по
строке(описанию)
REQUIRE_THROWS_WITH
CHECK_THROWS_WITH
41

40.

Пример теста исключений
TEST_CASE("test2","[testgroup1]")
{
REQUIRE_THROWS_AS(sum(0,0), std::runtime_error);
REQUIRE_THROWS(sum(0,0));
}
42

41.

Структурная программа
Набор тестов может делиться на секции
(SECTION) и описывать сценарии
тестирования (SCENARIO)
Каждая SECTION выполняется отдельно с
повторением всего предшествующего кода
SCENARIO меняет поведение тестов по
условиям
Позволяет упростить тестирование,
чтение и понимание результатов
тестирования
43

42.

SECTION
Код
SECTION1
SECTION2
SECTION3
Код
SECTION1
SECTION2
SECTION3
Код
SECTION1
Код
SECTION2
Код
SECTION3
44

43.

TEST_CASE( "vectors can be sized and resized", "[vector]" )
{
std::vector<int> v( 5 );
REQUIRE( v.size() == 5 );
REQUIRE( v.capacity() >= 5 );
SECTION( "resizing bigger changes size and capacity" )
{
v.resize( 10 );
REQUIRE( v.size() == 10 );
REQUIRE( v.capacity() >= 10 );
}
SECTION( "resizing smaller changes size but not
capacity" )
{
v.resize( 0 );
REQUIRE( v.size() == 0 );
REQUIRE( v.capacity() >= 5 );
}
}
45

44.

SCENARIO( "vectors can be sized and resized", "[vector]" ) {
GIVEN( "A vector with some items" ) {
std::vector<int> v( 5 );
REQUIRE( v.size() == 5 );
REQUIRE( v.capacity() >= 5 );
WHEN( "the size is increased" ) {
v.resize( 10 );
THEN( "the size and capacity change" ) {
REQUIRE( v.size() == 10 );
REQUIRE( v.capacity() >= 10 );
}
}
WHEN( "the size is reduced" ) {
v.resize( 0 );
THEN( "the size changes but not capacity" ) {
REQUIRE( v.size() == 0 );
REQUIRE( v.capacity() >= 5 );
}
}
…
46

45.

…
WHEN( "more capacity is reserved" ) {
v.reserve( 10 );
THEN( "the capacity changes but not the size" ) {
REQUIRE( v.size() == 5 );
REQUIRE( v.capacity() >= 10 );
}
}
WHEN( "less capacity is reserved" ) {
v.reserve( 0 );
THEN( "neither size nor capacity are changed" ) {
REQUIRE( v.size() == 5 );
REQUIRE( v.capacity() >= 5 );
}
}
}
}
47