Лекция 1. Введение в функциональное тестирование. Общие сведения, примеры

1.

Лекция 1.
Введение в функциональное тестирование
общие сведения, примеры
Авторы: К. Хлопов, А. Родичев, А. Александров, А. Анисимов, М. Волошинов, Д.Васильев
Тренер: С. Базуев

2.

Содержание
Введение
Основные понятия и определения
Жизненный цикл ПО и место тестирования в ЖЦ
Методы тестирования
Обзор видов тестирования
Разбиение тестирования на этапы
План тестирования
Построение тестовой модели
Введение в тестовые требования
Создание тестовых сценариев и наборов сценариев
Выполнение тестирования
Различные методы проведения тестирования
Работа с дефектами
2

3.

Введение
Тестирование ПО, равно как и разработка ПО, является наиболее
востребованной профессией в IT сфере. Такие организации как the
British Computer Society или the International Software Testing
Qualifications Board (ISTQB) начали разрабатывать сертификационные
уровни тестирования.
Тестировщики должны обладать знаниями, техническими навыками и
определенными талантами для того, чтобы в сжатые сроки
протестировать продукт таким образом, чтобы он максимально полно
соответствовал потребностям Заказчика.
Тестирование не интуитивный процесс, тестировщик должен знать, как
это делается.
3

4.

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

5.

Основные понятия и определения (2 из 4)
Тестируемость - степень, до которой могут быть запланированы
объективность и реализуемость тестирования, проверяющего
соответствие требованию
Ошибка - различие между полученным и описанным или
ожидаемым результатом (поведением) системы, количественный
параметр неверности результата (поведения)
Дефект (fault) - возможная причина ошибки
Неисправность (failure) – неспособность системы выполнить
требуемое действие, результат наличия в системе дефекта
Ошибочное действие (mistake) – действие пользователя
приводящее к неверному результату
5

6.

Основные понятия и определения (3 из 4)
Регрессионное тестирование - повторное тестирование программы
после внесения изменений, с учетом ранее заявленной
функциональности и ранее обнаруженных ошибок
Среда тестирования (test environment) - инфраструктура для
подготовки и проведения тестирования и интерпретации результатов
Покрытие (test coverage) – часть функционала, тестируемая данным
набором проверок
6

7.

Основные понятия и определения (4 из 4)
Валидация (validation) - проверка того, что программа делает то, что
нужно
Верификация (verification) - проверка того, что программа делает все
правильно.
Позитивный тест - проверка на правильных данных, реакция на
корректные действия.
Негативный тест - проверка на неправильных данных, реакция на
некорректные действия
Тест кейс - выполняемый тест с конкретными входными данными,
начальными условиями и ожидаемым результатом.
Pass/ Fail Criteria - установленное правило, позволяющее
определить удачно или неудачно прошла система данный тест
7

8.

Типовой пример установки заказного ПО
8

9.

Организация процесса тестирования
ОТК должен быть независимым и могущественным.
Он не должен отчитываться перед отделом разработки.
В идеале, начальник ОТК должен иметь право вето на выпуск
продукта, который не прошёл успешного освидетельствования.
9

10.

Важность тестирования
Большинство
дефектов
вносятся на
этапе сбора
требований и
разработки
…а
обнаруживаются
на стадии
приемочных
испытаний.
10

11.

Важность тестирования
Стоимость исправления ошибки возрастает с каждым этапом ЖЦ
11

12.

Принципы тестирования (Майерс)
1.
Описание предполагаемых значений выходных данных или результатов должно быть
необходимой частью тестового набора
2.
Следует избегать тестирования программы ее автором
3.
Необходимо досконально изучать результаты применения каждого теста
4.
Тесты для неправильных и непредусмотренных входных данных следует разрабатывать
так же тщательно, как для правильных и предусмотренных
5.
Необходимо проверять не только, делает ли программа то, для чего она предназначена, но
и ни делает ли она то, что не должна делать
6.
Не следует выбрасывать тесты, даже если программа уже не нужна
7.
Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены
8.
Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу
ошибок, уже обнаруженных в этой части
9.
Тестирование - процесс творческий. Вполне вероятно, что для тестирования большой
программы требуется больший творческий потенциал, чем для ее проектирования
12

13.

Методы тестирования (1 из 4)
Белый ящик – тестирование на основе анализа структуры кода
Серый ящик - промежуточный уровень, на котором определен
интерфейс между компонентам.
Черный ящик – поведенческое тестирование, глобальное
представление, основанное на спецификации.
13

14.

Методы тестирования (2 из 4). «Белый» ящик
Данный метод включает в себя следующие процедуры:
• анализ структуры программы;
• покрытие операторов;
• покрытие ветвей.
14

15.

Методы тестирования (3 из 4). «Серый» ящик
Данный метод включает в себя следующие процедуры:
• анализ архитектуры.
• проверка навигации.
• проверка интерфейсов.
• модель событий.
15

16.

Методы тестирования (4 из 4). «Чёрный» ящик
Данный метод включает в себя следующие процедуры:
• анализ потоков.
• таблица решений.
• функциональный анализ.
• граничные значения.
• история ошибок.
• целостность данных.
• диаграмма переходов состояний.
16

17.

Задачи и виды тестирования
Функциональное тестирование (functionality)
Регрессионное тестирование (regression)
Интеграционное тестирование (integration)
Тестирование производительности (performance)
Надежность и стрессовое тестирование (reliability)
Эргономика, удобство (usability)
Совместимость с программно-аппаратной платформой
(infrastructure testing)
Тестирование документации
Тестирование поддержки (supportability)
17

18.

Тестирование функциональности
Проверка соответствия поведения системы/подсистемы и т.д.
спецификациям функциональных требований (requirements
specification)
18

19.

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

20.

Тестирование производительности
Проверка отдачи от основных процессов, контроль временных
показателей системы.
Проверка соответствия системы/подсистем критериям
производительности
• Скорость выполнения операций;
• Время отклика;
• Использование ресурсов
20

21.

Нагрузочное и стрессовое тестирование
Проверка работы программы в условиях
реальной нагрузки с целью выявить
оптимальную конфигурацию системы и
«возможности» системы.
Может проводиться на большом объеме
данных в условиях эмуляции реальных
нагрузок или в условиях превышения
планируемых нагрузок в несколько раз.
21

22.

Тестирование эргономики
человеческий фактор;
эстетичность;
логичность в
пользовательском
интерфейсе;
online и контекстнозависимая помощь;
пользовательская
документация;
учебные материалы;
22

23.

Тестирование поддержки (supportability)
тестируемость
расширяемость (открытость)
приспособляемость
удобство сопровождения
совместимость
способность к изменению конфигурации
удобство эксплуатации
удобство инсталляции
локализуемость (глобализация)
23

24.

Ход тестирования
•Планирование
•Выполнение
•Анализ результатов
24

25.

Структура плана тестирования
Введение
• Цель тестирования
• Причина тестирования
Объект тестирования
Стратегия тестирования
Углубление по видам тестирования
Планируемые результаты тестирования
Ресурсы
Требования к тестированию (тестовые требования)
25

26.

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

27.

План тестирования. Объект тестирования
Основные функции
Структурная схема
Назначение компонентов
Список систем, с которыми интегрируется
Обоснование необходимости разработки эмуляторов (если
необходимо)
27

28.

План тестирования. Стратегия тестирования
Виды тестирования
Сложности тестирования
Ограничения тестирования
Риски тестирования
Критерии окончания тестирования
28

29.

План тестирования. Виды тестирования
Цель тестирования
Ход тестирования
Критерии завершения тестирования
29

30.

План тестирования. Планируемые результаты
Документы, являющиеся результатом тестирования
• Отчет о тестировании
• Bug reports
Полученные значения настроек
Выводы о готовности системы к эксплуатации
30

31.

План тестирования. Ресурсы
Аппаратные ресурсы
Человеческие ресурсы
Программное обеспечение
Прочее
31

32.

Тестовые требования
Требование – это формализованное описание свойств системы.
• Бизнес-требования
• Функциональные требования
• Нефункциональные требования
• Тестовые требования
Тестовое требование – это формализованное описание свойств
системы, которые необходимо протестировать.
32

33.

Варианты построения модели требований
По структуре
• Плоская
• Иерархическая
По подробности
• Поверхностная
• Детальная
33

34.

Плоская структура требований
Достоинства
• Простота
• Наглядность при печати
Недостатки
• Осложненный поиск
• Сложно понять, что покрыли требованиями, а что нет
• Достаточно тяжело отразить структуру программы
34

35.

Иерархическая модель требований
Достоинства:
• Легко найти интересующее требование (или понять, что оно
отсутствует)
• Структура требований отражает структуру программы, что
облегчает определение уровня качества отдельных модулей ПО
Недостатки
• Тяжело читается в печатном виде
• Очень тяжело читается в печатном виде
35

36.

Подробность тестовых требований
Распределение времени поверхностной модели требований:
Распределение времени подробной модели требований:
36

37.

Взаимосвязь требований к функциональности
Ограничение функциональности
Рост детализации
37

38.

Классификация тестовых требований
Функциональные
Нефункциональные
• К ресурсам
• К безопасности
• К производительности
• К отказоустойчивости
• К масштабируемости
• К документации
38

39.

Назначение тестовых требований
Инструмент анализа требований к системе с точки зрения
тестирования
Исходный документ для написания тестовых сценариев (актуальный,
качественный и удобный)
Согласование объемов тестирования
Установление приоритетов тестирования на детальном уровне
Отслеживание тестового покрытия
39

40.

Разработка тестовых требований
Выявление доступной документации описывающей систему
Получение выявленной документации
Выяснение степени актуальности полученной документации
Изучение полученной документации
Подготовка иерархической структуры тестовых требований
Анализ полноты иерархической структуры тестовых требований
Наполнение требований описаниями
Анализ требований на предмет соответствия критериям качества и
внесение изменений
40

41.

Как получаются тестовые требования?
Функциональные и нефункциональные требования к ПО
Ограничения, изложенные в проектных документах
Архитектурные особенности IT окружения ПО
Общие принципы разработки ПО
• Эргономика
• Безопасность
41

42.

Задание №1
Необходимо подготовить небольшое эссе в форме ответов на вопросы:
1. Что нового Вы узнали на лекции?
2. Что Вам было известно ранее?
3. На какие вопросы Вы ожидали получить ответ, но не получили?
4. Опишите назначение тестовых требований.
5. Опишите критерии качества тестовых требований.
42

43.

Создание тестовых сценариев
Состав тестового сценария
• Название
• Описание проверок сценария
• Предварительные условия
• Необходимые действия
• Ожидаемый результат
• Полученный результат
• Отметка о прохождении
• Статус прохождения
43

44.

Пример тестового сценария
Проверка обработки ошибки деления на 0
Предусловия
Шаги
1.
2.
3.
4.
5.
6.
7.
8.
Windows калькулятор запущен
Вид калькулятора - научный
Нажать кнопку “5”
Нажать кнопку “/”
Нажать кнопку “(”
Нажать кнопку “2”
Нажать кнопку “-”
Нажать кнопку “2”
Нажать кнопку “)”
Нажать кнопку “=”
Ожидаемый результат:
•.
Приложение корректно сообщило о невозможности деления на 0. 44

45.

Оптимизация тестов: баланс между риском и
затратами
Риск – ущерб, вызванный ошибкой * вероятность возникновения
ошибки
Как определить ущерб и вероятность ошибки?
45

46.

Определение ущерба
Высокий ущерб
Средний ущерб
Низкий ущерб
Тип процесса
Вычисление /
проверка
Изменение
данных
Отображение
на экране
Частота
использования
Очень частое
Частое
Редкое
Кол-во
задействованных
пользователей
Большое число
и/или VIP
Группы /
отделы
Единицы
Как используется в
бизнес процессе
Верные данные
Не верные
данные
Не
используется
46

47.

Определение ущерба
Высокий ущерб – бизнес функция с двумя и более критериями
«высокий ущерб»; или двумя или более критериями «средний
ущерб» и одним критерием «высокий ущерб»
Средний ущерб – бизнес функция с двумя и более критериями
«средний ущерб» без критерия «высокий ущерб»; или одним
критерием «средний ущерб», одним критерием «высокий ущерб»
и несколькими критериями «низкий ущерб»
Низкий ущерб – любые другие комбинации
47

48.

Определение вероятности
Наиболее
вероятно
Вероятно
Почти не
вероятно
Изменяемая
функция
Не изменяемая
Не зрелое
(менее 5 лет)
Зрелое (5 – 10
лет)
Очень зрелое
(более 10 лет)
Большое
Среднее
Маленькое
Изменение функции Новая функция
Зрелость ПО
Кол-во дефектов
48

49.

Определение вероятности
Наиболее вероятно– бизнес функция с двумя и более критериями
«Наиболее вероятно»; или двумя или более критериями
«Вероятно» и одним критерием «Наиболее вероятно»
Вероятно– бизнес функция с двумя и более критериями
«Вероятно» без критерия «Наиболее вероятно»; или одним
критерием «Наиболее вероятно», одним критерием «Вероятно» и
несколькими критериями «Почти не вероятно»
Низкий риск – любые другие комбинации
49

50.

Определение риска
Наиболее
вероятно
Вероятно
Почти не
вероятно
Высокий ущерб
Высокий риск
Высокий риск
Средний риск
Средний ущерб
Средний риск
Средний риск
Низкий риск
Низкий ущерб
Средний риск
Низкий риск
Низкий риск
50

51.

Характеристики хорошего теста
Существует обоснованная вероятность выявления тестом ошибки
Набор тестов не должен быть избыточным
Тест должен быть наилучшим в своей категории
Он не должен быть слишком простым или слишком сложным
51

52.

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

53.

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

54.

Построение тестов (продолжение примера)
В таблице ниже каждой из этих переменных отводится отдельный столбец. В эти столбцы
помещены значения из различных классов эквивалентности рассматриваемых переменных.
Каждая строка таблицы представляет собой описание конкретного теста.
Имя
Полное имя с остающимся
пустым пространством
Полное имя с остающимся
пустым пространством
...
Штатная единица
Ранее существовавшая
штатная единица
Новая штатная единица
...
Авторизация
Санкционирован только
локальный доступ
Санкционирован только
локальный доступ
...
Количество тестовых случаев, которые необходимо построить, зависит от значения атрибута
частоты использования каждого случая использования. Один из способов оценки
соответствующего числа тестовых случаев заключается в том, что вычисляется произведение
количества различных входов и количества классов эквивалентности каждого типа ввода с
целью получения максимального количества перестановок.
54

55.

Структура тестовой модели
55

56.

Выполнение тестовых сценариев
Варианты выполнения тестовых сценариев
• Тестировщик работает с печатным носителем
• Выполнение тестов поддерживается ИС тестирования (HP
QC)
• Выполнение тестов полностью автоматизировано
56

57.

Разбиение тестирования на стадии
Для эффективной работы тестировщик должен:
• знать метод тестирования
• знать тестируемое приложение
Но неправильно считать, что тестирование осуществляется только на
предоставляемых разработчиками данных. Важен накопленный
опыт о тестировании подобных систем, о допущенных ранее
ошибках тестирования, которые проявились на этапах
тестирования и сопровождения.
Таким образом тестирование должно разбиваться на несколько
стадий.
57

58.

Стадии тестирования
Рекомендуемая последовательность проведения тестов
• ознакомление с системой. Исследовательское тестирование.
• базовый тест.
• выявление зависимостей между данными
• тестирование для различных категорий данных
• граничные оценки
• тестирование на ошибочных данных
• попытка «сломать» систему
• регрессионное тестирование
58

59.

Ознакомление с системой
В ходе изучения тестировщик узнает, как работает система, что
представляют результаты, тип входных данных и т.п.
Формы изучения:
• ознакомление по документации
• по учебным материалам
• привлечение специалиста (авторитетное лицо проекта)
• метод «тыка»
• проверка всех возможностей системы
Недостатки: принятие неверных результатов работы за верные;
сложность воспроизведения ошибок
59

60.

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

61.

Выявление зависимостей между данными
Анализ тенденций – это необязательная стадия, необходимая если:
• знакомство с системой весьма поверхностно
• входные/выходные данные содержат численные значения
• неизвестны граничные значения
• сложно вычислить ожидаемые результаты
• имеется предположение относительно диапазона ожидаемых
результатов
61

62.

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

63.

Проверка граничных значений
Ошибки концентрируются на границах значений
Необходимы позитивные и негативные проверки
Продолжение метода эквивалентных разбиений
Правило тестирования границ: граничное значение, ГЗ+1, ГЗ-1
63

64.

Артефакты процесса тестирования
Отчеты о тестировании
История прохождения тестов
План проведения тестирования
Отчеты по дефектам
64

65.

Критерии оценки качества ПО
Формальные
– Число ошибок
– Распределение серьезности ошибок
– Процент нахождения ошибки (отношение общего числа
сценариев к числу непрошедших сценариев)
Неформальные
– Качество пользовательской документации
– Качество процедуры установки
65

66.

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

67.

Понятие и классификация ошибок
Классификация по типу
ошибки в функциональности
ошибки эргономики модуля или бизнес-процесса
ошибки документирования
ошибки производительности
ошибки локализации
ошибки совместимости
ошибки безопасности
Степени критичности
Максимальная критичность
Высокая критичность
Нормальная критичность
Низкая критичность
67

68.

Действия при обнаружении ошибок
Можно привести два отношения к найденным ошибкам на примере
автомобильной промышленности:
- принцип Форда (GM)
- принцип Таичи Оно (Taiichi Ohno, Toyota)
68

69.

Принцип Форда
Принцип Форда
• Все должно непрерывно двигаться к нам и от нас. Заминки вызывают
огромные убытки.
• В организованном производстве рабочий во время работы не должен
делать более одного шага и ничуть не наклоняться вперед или в
стороны.
69

70.

Принцип Оно
Принцип Оно
Над десятилетиями казавшейся незыблемой американской автомобильной
«большой тройкой» - Genaral Motors, Ford и Chrysler — нависла опасность. В
2003 г. впервые в истории японская Toyota продала в Америке больше
автомобилей, чем американские производители. Западных менеджеров и
экономистов всегда интересовали секреты эффективности японских
производителей.
Оказалось, что весь секрет — в уникальной по эффективности организации
производства. При ближайшем рассмотрении выяснилось, что японцы очень много
внимания уделяют таким, казалось бы, очевидным вещам, как удовлетворение
потребностей клиентов, качество продукции, экономия, исключение лишних
операций.
■
При появлении ошибки следует сразу же найти ее причину, устранить ее и не
допустить ее появления в будущем. Цель: отсутствие ошибок.
■
Все сотрудники и поставщики должны постоянно повышать качество продукции и
70
совершенствовать производственный процесс.

71.

Действия при обнаружении ошибок
Необходимо убедиться, что ошибка произошла не из-за ввода
тестируемым неверного значения.
Следует как более полно описать действия, которые привели к ошибке,
понять, не проявляется ли ошибка на других типах данных.
71

72.

Дефект. Атрибуты дефекта
Минимальные данные о дефекте:
• краткое наименование
• дата
• автор (обнаруживший дефект)
• ссылка на систему и ее версию (build)
• приоритет (Priority)
• серьезность проблемы (Severity)
• описание (предусловия, шаги для воспроизведения,
ожидаемый результат, фактический результат)
• состояние, статус
72

73.

Баг-трекинг
Работа с дефектами:
■
■
Баг-трекинговые системы;
Почтовая переписка
Плюсы баг-трекинговых систем:
■
■
■
Дефекты не теряются
Возможность построения любой отчётности по дефектам
Удобство работы с полной базой данных с дефектами
73

74.

Диаграмма состояний дефекта
74

75.

Задание №2
Необходимо составить набор тестов для проверки корректности работы
следующей программы:
• На вход подается 3 целых числа, обозначающие длины сторон
треугольника
• Программа сообщает, является ли указанный треугольник
равнобедренным или равносторонним
75

76.

Спасибо!