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

Контрольные вопросы
Чем отличаются понятия дефект и ошибка?
Что такое статическое и динамическое тестирование?
Какова общая схема динамического поиска дефектов?
Можно ли выполнить тестирование на всех возможных вариантах данных?
Что такое Оракул в тестировании?
Правильно ли сказать, что тестирование основывается ТОЛЬКО на требованиях?
Тестирование – проверка на соответствие требованиям.
Важны только сборка тестируемого продукта и требования.
Почему тестировщиков называют Инженерами по качеству, а тестирование – контролем качества? Почему часто вместо термина “ошибка” применяется термин “дефект”?
Какие инструменты вовлечены в разработку ПО?
Какова роль Репозитария?
Какова роль и функциональность Баг-трекера?
Что такое Среда тестирования?
Чем определяется серьезность и приоритет дефекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подготовка тестовых данных
Парное тестирование. 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) – консольное приложение, которое решает задачу.

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

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

Подготовка тестовых данных
Парное тестирование. PICT
Результат работы PICT для рассмотренной модели:

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

Контрольные вопросы
Какие подходы к подготовке тестовых данных рассмотрены в лекции?
В чем заключается идея “Граничных условий”?
Откуда берутся границы?
В чем заключается идея “Классов эквивалентности”?
В чем заключается идея “Парного тестирования”?
В чем заключаются достоинства парного тестирования?
В каких случаях парное тестирование не будет эффективным?
Какой инструмент подготовки парного тестирования рассмотрен в лекции?

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

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

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

Покрытие кода
Вот результат анализа кода для учебного проекта TZ_AVL05 в Visual Studio.

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

Покрытие кода
Существует несколько неплохих инструментов для unit-тестирования и оценки покрытия кода.
Скриншот CoCo - (Code Coverage)
https://www.froglogic.com/coco/free-trial/?product=coco&pk_campaign=AdWordsSearch-EU-Coco&pk_kwd=java%20test%20coverage&gclid=EAIaIQobChMI5qnx3Iml2QIVV2QZCh3CEQCTEAAYASAAEgLpx_D_BwE

Покрытие кода
Примеры инструментов unit-тестирования, том числе свободно распространяемых:
Можно больше прочесть по ссылке:
https://developer.salesforce.com/blogs/developer-relations/2012/11/how-code-coverage-works.html

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

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

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

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

Покрытие требований
Такие матрицы составляются по все совокупности требований. (Трассировка)
Они позволяют вычислить общее количество элементов требований и количество выполненных (и не выполненных) проверок (тестов).

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

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

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

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

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