Тестирование. Подготовка тестовых данных

1. Тестирование ПО лек. 2

А. Задорожный
2018

2. Контрольные вопросы

1.
2.
3.
4.
5.
6.
Чем отличаются понятия дефект и ошибка?
Что такое статическое и динамическое тестирование?
Какова общая схема динамического поиска дефектов?
Можно ли выполнить тестирование на всех возможных вариантах данных?
Что такое Оракул в тестировании?
Правильно ли сказать, что тестирование основывается ТОЛЬКО на
требованиях?
a)
b)
Тестирование – проверка на соответствие требованиям.
Важны только сборка тестируемого продукта и требования.
7.
Почему тестировщиков называют Инженерами по качеству, а тестирование
– контролем качества? Почему часто вместо термина “ошибка”
применяется термин “дефект”?
8.
Какие инструменты вовлечены в разработку ПО?
a)
b)
c)
9.
Какова роль Репозитария?
Какова роль и функциональность Баг-трекера?
Что такое Среда тестирования?
Чем определяется серьезность и приоритет дефекта?

3. Содержание

1. Подготовка тестовых данных
Граничные условия
Классы эквивалентности
Парное тестирование
Инструменты
2. Оценка качества тестирования
Зачем и как оценивать
Покрытие кода
Покрытие требований
Инструменты
Другие метрики качества
3. Полезные мантры

4. Подготовка тестовых данных

Как уже знаем, одна из 2-х основных проблем
тестирования – подготовка тестовых данных.
Тестирование на всех возможных вариантах входных
данных – на практике не реализуемо.
Существуют несколько полезных методов подготовки
тестовых данных:
- Граничные условия
- Классы эквивалентности
- “Парное” тестирование (Pairwise testing)

5. Цена ошибок в ПО

Цена ошибок в программном обеспечении
бывает очень велика!
Из личного опыта:
Штрафы ГИБДД в 2000-е годы;
Загранпаспорта в 2010-е годы;
Операции налоговой инспекции в 2016;
…
|
V
К тестированию нужно относиться серьезно!

6. Подготовка тестовых данных

Рассмотрим форму регистрации клиента с
полями
Фамилия*:
Имя*:
Отчество:
Пол:
Моб*:
Email*:

7. Подготовка тестовых данных

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

8. Подготовка тестовых данных

Некоторые поля обязательные*, другие нет.
По каждому из полей имеются определенные
ограничения.
Например, может ли имя состоять из 1 символа? А из
1024?
Какие символы допустимы в имени? А в номере
мобильного?
Какой вид имеет допустимый email?

9. Подготовка тестовых данных

Мы можем разбить все множество значений
каждого поля на Допустимые и
Недопустимые значения.
Например, допустимым именем является
текст от 2 до 32 символов, которые включают:
буквы, римские цифры, дефис и пробелы.
Не менее 2-х букв.

10. Подготовка тестовых данных Граничные значения

Множество допустимых имен можно “очертить”
границами:
- Менее 2 символов | 2 символа (буквы);
- Более 32 символов | 32 допустимых символа;
- Строки, включающие недопустимые символы |
строки, включающие только допустимые символы .
Список границ можно уточнять.

11. Подготовка тестовых данных Граничные значения

Для каждой границы нужно выбрать по
несколько представителей в границе и вне
границы и включить их в набор тестовых данных.
A, Б, Ан, Хо, А1, “Джо”, Джо, Тра.мп, …
Очевидно, что недопустимых символов много начать с самых распространенных.
Аналогичные наборы нужно построить и для
других входных параметров.

12. Подготовка тестовых данных Граничные значения

Построенные таким образом наборы тестовых данных
и отвечают подходу “Граничные значения”.
Замечания
Для числовых параметров, границы обычно
определяются проще. Например, день месяца не
может быть меньше 1 и больше 31.
Это и образует естественные границы.
Для каждого экземпляра (комплекта) подготовленного
набора тестовых необходимо описать ожидаемый
результат.

13. Подготовка тестовых данных

Сколько же всего тестовых наборов возникнет в примере?
Если для каждого поля имеется 3 границы и для каждой границы
выбрано 4 значения (2 в границах и 2 вне границ), то всего будет
6 полей*3 границы*4 значения = 72 элемента данных.
Из них нужно построить тестовые наборы.
Если использовать недопустимое имя, то регистрация “не
пройдет”. Нельзя будет проверить как поведет себя регистрация
при допустимом имени и недопустимом значении одного из
других параметров.
Учитывая это, придется выбрать не одну тысячу тестовых наборов.
(и для каждого описать результат).

14. Подготовка тестовых данных Классы эквивалентности

В данном подходе предполагается, что функция ведет себя одинаково для
некоторого подмножества входных данных.
Например,
• Если имя недопустимо, то независимо от значений остальных параметров в
регистрации будет оказано и сообщение будет содержать ограничения на
значения имени.
Если имя допустимо, но недопустима фамилия, то независимо от значений
остальных параметров в регистрации будет оказано и сообщение будет
содержать ограничения на значения фамилии.
…
Если в имени присутствует 1 недопустимый символ, то независимо от
остальных символов имя недопустимо;
Если длина имени вне диапазона 2-32, то независимо от других символов имя
недопустимо;
….

15. Подготовка тестовых данных Классы эквивалентности

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

16. Подготовка тестовых данных Обсуждение

Рассмотрели 2 подхода: граничные значения и классы
эквивалентности.
1. Часто применяются вместе. Границы служат
основанием для выделения классов;
2. Подготовка данных остается творчеством. Например,
как убедиться, что регистрация адекватно работает при
любом недопустимом символе? (их очень много!)
Можно ли предположить, что при недопустимом символе
и недопустимой длине параметра регистрация ведет себя
одинаково (принадлежат одному классу)?

17. Подготовка тестовых данных Парное тестирование

В примере с формой поля данных (параметры)
независимы. Границы одного параметра не
зависят от значения других.
Часто это оказывается не так. Изменим нашу
форму.
Фамилия:
Имя:
Извещать по:
Моб/Email:
SMS/Email

18. Подготовка тестовых данных Парное тестирование

Пусть на основании классов эквивалентности
выбрали 4 тестовых значений ФИО, имеется
выбор всего из 2-х значений “Извещать по” и 8
значений для поля “Моб/EMail”.
Полный набор (с учетом классов
эквивалентности) 4*4*2*8 = 256 комплектов
данных.
С учетом сложности оценки (каждый раз нужно
оценить, какой механизм доставки извещений
включен) это достаточно много!

19. Подготовка тестовых данных Парное тестирование

Как показывает практика, эффективным методом
является подготовка такого набора, что каждая
пара параметров приобретает все возможные
значения – количество комбинаций
существенно сокращается, а % выявленных
ошибок оказывается большим.
Такой подход к построению тестовых наборов
данных называется “Парным тестированием”
Неудачный перевод Pairwise testing.

20. Подготовка тестовых данных Парное тестирование. PICT

Приготовить такой минимальный набор данных (где все пары
принимают все возможные значения) не так просто. Для этого
существуют специальные приложения:
• IBM FoCuS – ‘Functional Coverage Unified Solution’, от IBM.
• ACTS – ‘Advanced Combinatorial Testing System’, от NIST, агентство
правительства США.
Hexawise
Jenny
Pairwise от Inductive AS
VPTag свободный Pairwise Testing инструмент.
Рассмотрим одно из них – PICT от Microsoft
PICT (Pairwise Independent Combinatorial Testing) – консольное
приложение, которое решает задачу.

21. Подготовка тестовых данных Парное тестирование. PICT

Дли использования PICT необходимо подготовить текстовый файл
с описанием модели данных.
Формат описания модели
<parameter name>: <value>, <value>,…
<parameter name>: <value>, <value>,…
…
Где <parameter name> - имя одного из параметров, а <value> тестовые значения этого параметра.
Кроме того, можно накладывать и ограничения, например, с
помощью условий и оператора IF-THE-ELSE.

22. Подготовка тестовых данных Парное тестирование. PICT

Пример описания тестовой модели данных для рассматриваемой формы.
имя:
М, Ма, Константин Таврический, -Константин Таврический
фамилия: А, Ан, Ковалева-Хрусталева Мл, -Ковалева-Хрусталева Мл
тип:
mob, email
доставка: 8917684865,89176848653,8(917)684-86-53,8(917)684-86-53-, fesvo.aero,[email protected],[email protected],lost-andfound@[email protected]
IF [тип] = "mob" THEN [доставка] in
{"8917684865","89176848653","8(917)684-86-53","8(917)684-86-53-"}
ELSE [доставка] in {"fe-svo.aero","[email protected]","[email protected]","lost-and-found@[email protected]"}; *)
В результате получим всего 33 строки данных (вместо 256).

23. Подготовка тестовых данных Парное тестирование. PICT

Результат работы PICT для рассмотренной
модели:
имя
-Константин Таврический
-Константин Таврический
Ма
М
Константин Таврический
Ма
Ма
М
М
М
Константин Таврический
-Константин Таврический
Ма
Константин Таврический
Константин Таврический
-Константин Таврический
-Константин Таврический
Ма
Ма
М
-Константин Таврический
Константин Таврический
Ма
-Константин Таврический
М
Константин Таврический
Константин Таврический
Константин Таврический
Ма
М
М
-Константин Таврический
Константин Таврический
фамилия
Ан
-Ковалева-Хрусталева Мл
Ан
А
Ковалева-Хрусталева Мл
Ковалева-Хрусталева Мл
А
Ан
Ковалева-Хрусталева Мл
-Ковалева-Хрусталева Мл
А
А
-Ковалева-Хрусталева Мл
-Ковалева-Хрусталева Мл
Ан
Ковалева-Хрусталева Мл
Ан
-Ковалева-Хрусталева Мл
-Ковалева-Хрусталева Мл
Ковалева-Хрусталева Мл
А
Ковалева-Хрусталева Мл
А
-Ковалева-Хрусталева Мл
А
Ан
Ковалева-Хрусталева Мл
Ан
Ковалева-Хрусталева Мл
А
А
-Ковалева-Хрусталева Мл
Ан
тип
mob
email
email
mob
mob
mob
email
mob
email
email
mob
mob
mob
mob
email
email
mob
email
mob
mob
email
mob
mob
email
mob
email
email
email
email
email
email
mob
mob
доставка
89176848653
[email protected]
[email protected]
8917684865
8(917)684-86-53
8917684865
lost-and-found@[email protected]
8(917)684-86-53
lost-and-found@[email protected]
[email protected]
8(917)684-86-538(917)684-86-53
89176848653
8(917)684-86-53fe-svo.aero
fe-svo.aero
8(917)684-86-53fe-svo.aero
8(917)684-86-53
8(917)[email protected]
89176848653
8(917)684-86-53lost-and-found@[email protected]
89176848653
[email protected]
[email protected]
lost-and-found@[email protected]
[email protected]
fe-svo.aero
[email protected]
8917684865
8917684865

24. Парное тестирование Заключение

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

25. Контрольные вопросы

1. Какие подходы к подготовке тестовых данных
рассмотрены в лекции?
2. В чем заключается идея “Граничных условий”?
3. Откуда берутся границы?
4. В чем заключается идея “Классов эквивалентности”?
5. В чем заключается идея “Парного тестирования”?
6. В чем заключаются достоинства парного
тестирования?
7. В каких случаях парное тестирование не будет
эффективным?
8. Какой инструмент подготовки парного тестирования
рассмотрен в лекции?

26. Оценка качества тестирования

Тестирование (подготовка, поиск дефектов,
устранение дефектов) занимает около 50%
всех ресурсов проекта.
Тестирование ~ Контроль качества
Необходимо оценивать (управлять)
качеством самого тестирования!

27. Оценка качества тестирования

Зачем оценивать?
• Мотивация команды;
• Управление контролем качества;
• Планирование о оценка прогресса;
|
V
Задача оценки качества тестирования важна!
Постулат
То, что нельзя измерять, нельзя улучшить
|
V
Нужно научиться измерять качество!

28. Покрытие кода

Один из параметров, за которым нужно
следить – покрытие кода.
Осуществляется
совместно
с
тестированием,
когда
доступен
тестируемого модуля (“белый ящик”).
unitкод
Оценка выполняется той же средой, что и
выполнение unit-тестов.

29. Покрытие кода

Вот результат анализа кода для учебного
проекта TZ_AVL05 в Visual Studio.
Not Covered
Blocks
TZ_AVLFilter
135
BinaryData
3
DataHolder
0
DataUserToken
17
GPSData
10
SensorData
4
TZ_AVLHandler
50
Utils
51
Модуль
%
37,82%
100,00%
0,00%
100,00%
100,00%
100,00%
48,54%
23,61%
Covered
%
Blocks
222 62,18%
0 0,00%
4 100,00%
0 0,00%
0 0,00%
0 0,00%
53 51,46%
165 76,39%

30. Покрытие кода

Измеряется количество (и % к общему числу) блоков кода,
которые были исполнены в процессе тестирования*.
Анализ покрытия позволяет понять:
• какие дополнительные тесты необходимо разработать;
• Какова динамика покрытия кода в процессе
продвижения проекта;
!
Покрытие кода служит критерием качества unitтестирования.

31. Покрытие кода

Существует несколько неплохих
инструментов для unit-тестирования и оценки
покрытия кода.
Скриншот CoCo - (Code
Coverage)
https://www.froglogic.com/c
oco/freetrial/?product=coco&pk_cam
paign=AdWordsSearch-EUCoco&pk_kwd=java%20test%
20coverage&gclid=EAIaIQobC
hMI5qnx3Iml2QIVV2QZCh3CE
QCTEAAYASAAEgLpx_D_BwE

32. Покрытие кода

Примеры инструментов unit-тестирования, том числе
свободно распространяемых:
Инструмент
Характеристики
Cobertura
Java
CodeCover
Java & COBOL
Coverage.py
Python
Coco
C, C++, Qt, C# (бесплатно только
пробная версия)
Devel::Cover
Perl
PHPUnit
PHP
Можно больше прочесть по ссылке:
https://developer.salesforce.com/blogs/developerrelations/2012/11/how-code-coverage-works.html

33. Покрытие кода

Можно ли добиться 100% покрытия кода?
Не всегда. Часть кода может быть недостижим.
Рассмотрим на модельной задаче.
Високосный год – делится на 4, но не делится на 100 или делится на 400.
Разработчик предусмотрел обработку всех возможных вариантов
Делится на 4
Не делится на 4
Не делится на 100
Делится на 100
+
+
Красным отмечен недостижимый вариант.
Конечно, разработчик такое бы заметил, но в более сложных случаях – довольно частое явление.

34. Покрытие кода Заключение

Контроль покрытия кода unit-тестами – важный
инструмент управления качеством продукта.
Unit-тесты позволяют выявить дефекты как
можно раньше. Устранения ранних дефектов –
наиболее эффективно.
Ответственность за разработку unit-тестов несут
Разработчики. Но знание их ценности
необходимо для управления качеством
тестирования, т.е. важно и для тестировщиков.

35. Покрытие требований

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

36. Пользовательская история

Регистрация клиентов.
Заходим на форму регистрации. Вводим атрибуты
клиента, кликаем на Зарегистрировать.
Информация о клиенте сохраняется и теперь
клиент доступен в списке клиентов, при поиске и
т.п.
Конечно, тестировщик дополнит это случаями
неуспешной регистрации, сообщениями, который
должна вывести система в каждом случае и т.п

37. Покрытие требований

Такие матрицы составляются по все совокупности требований.
(Трассировка)
Регистрация
Успешно
Сообщение об
успехе
Отказ
Сообщение о
причине
отказа
Допустимые
данные
+
+
Недопустимое Недопустимая Недопустимое
имя
фамилия
Mob/Email
-
-
-
-
Они позволяют вычислить общее количество элементов требований и
количество выполненных (и не выполненных) проверок (тестов).

38. Покрытие требований

Более реалистичный вид матрицы трассировки

39. Покрытие требований

Контроль покрытия требований применяется
при тестировании со стратегией “черного
ящика”.
Выполняется тестировщиками в виде матрицы
трассировки.
Позволяет контролировать общее количество
требований, количество подготовленных
тестовых сценариев, объем выполненных и не
выполненных работ по тестированию.

40. Покрытие требований Инструменты

1. Полезные практические рекомендации на
https://habrahabr.ru/post/270365/
2. В простейшем случае можно вести в Excelтабличке;
3. Многие Issue Trackers (Jira, TFS, …) позволяют
устанавливать связи между списком требований и
списком тестовых сценариев и генерировать
соответствующие отчеты.
4. Специализированные среды типа Rational Rose от
IBM.

41. Другие метрики качества

Можно численно оценивать:
• Процесс
– Количество выявленных дефектов в расчете на 1000
строк кода. Классификация по Severity;
– Покрытие кода и требований;
– Динамику процесса тестирования (количество
сценариев за период времени);
– … (будут рассмотрены в привязке к конкретным
процессам)
• Результат (после выпуска продукта)
– Количество дефектов от пользователей;
– Ресурсы (человеко-дни) на устранение дефекта;

42. Полезные мантры

• Программ без ошибок не бывает!
• Чем раньше найден дефект, тем меньше его
стоимость!
• Чем больше найдено ошибок, тем более вероятно,
что остались ненайденные!
• Негативные тесты так же важны как позитивные!
• Разработчик не должен быть тестировщиком!

43. Контрольные вопросы

1. Зачем оценивать качество тестирования?
2. Какие метрики для этого могут
использоваться?
3. Как измеряется покрытие кода?
4. Всегда ли можно добиться 100% покрытия
кода?
5. Как измеряется покрытие требований?
6. Почему важно тестирование с самых
ранних этапов разработки?