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

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

Какие инструменты вовлечены в разработку ПО?
Какова роль Репозитария?
Какова роль и функциональность Баг-трекера?
Что такое Среда тестирования?

Чем определяется серьезность и приоритет дефекта?

кода
Покрытие требований
Инструменты
Другие метрики качества
Полезные мантры

– подготовка тестовых данных.

Тестирование на всех возможных вариантах входных данных – на практике не реализуемо.

Существуют несколько полезных методов подготовки тестовых данных:

Граничные условия
Классы эквивалентности
“Парное” тестирование (Pairwise testing)

личного опыта:

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

каждом наборе подготовленных данных
Оценке результата каждого исполнения.

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

определенные ограничения.

Например, может ли имя состоять из 1 символа? А из 1024?

Какие символы допустимы в имени? А в номере мобильного?

Какой вид имеет допустимый email?

Допустимые и Недопустимые значения.

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

| 2 символа (буквы);

Более 32 символов | 32 допустимых символа;

Строки, включающие недопустимые символы | строки, включающие только допустимые символы .

Список границ можно уточнять.

в границе и вне границы и включить их в набор тестовых данных.

A, Б, Ан, Хо, А1, “Джо”, Джо, Тра.мп, …

Очевидно, что недопустимых символов много - начать с самых распространенных.

Аналогичные наборы нужно построить и для других входных параметров.

подходу “Граничные значения”.

Замечания
Для числовых параметров, границы обычно определяются проще. Например, день месяца не может быть меньше 1 и больше 31.
Это и образует естественные границы.

Для каждого экземпляра (комплекта) подготовленного набора тестовых необходимо описать ожидаемый результат.

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

Из них нужно построить тестовые наборы.

Если использовать недопустимое имя, то регистрация “не пройдет”. Нельзя будет проверить как поведет себя регистрация при допустимом имени и недопустимом значении одного из других параметров.

Учитывая это, придется выбрать не одну тысячу тестовых наборов.
(и для каждого описать результат).

одинаково для некоторого подмножества входных данных.

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

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

Если длина имени вне диапазона 2-32, то независимо от других символов имя недопустимо;
….

себя одинаково называются классами эквивалентности.

Достаточно выбрать только 1 экземпляр данных из каждого класса.

! Подход позволяет существенно сократить количество тестовых данных.

вместе. Границы служат основанием для выделения классов;

Подготовка данных остается творчеством. Например,
как убедиться, что регистрация адекватно работает при любом недопустимом символе? (их очень много!)
Можно ли предположить, что при недопустимом символе и недопустимой длине параметра регистрация ведет себя одинаково (принадлежат одному классу)?

Границы одного параметра не зависят от значения других.

Часто это оказывается не так. Изменим нашу форму.

Фамилия:
Имя:
Извещать по:
Моб/Email:

SMS/Email

значений ФИО, имеется выбор всего из 2-х значений “Извещать по” и 8 значений для поля “Моб/EMail”.

Полный набор (с учетом классов эквивалентности) 4*4*2*8 = 256 комплектов данных.

С учетом сложности оценки (каждый раз нужно оценить, какой механизм доставки извещений включен) это достаточно много!

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

Такой подход к построению тестовых наборов данных называется “Парным тестированием”

Неудачный перевод Pairwise testing.

пары принимают все возможные значения) не так просто. Для этого существуют специальные приложения:

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

с описанием модели данных.

Формат описания модели

: , ,…
: , ,…
…

Где - имя одного из параметров, а - тестовые значения этого параметра.

Кроме того, можно накладывать и ограничения, например, с помощью условий и оператора IF-THE-ELSE.

формы.

имя: М, Ма, Константин Таврический, -Константин Таврический
фамилия: А, Ан, Ковалева-Хрусталева Мл, -Ковалева-Хрусталева Мл
тип: mob, email

доставка: 8917684865,89176848653,8(917)684-86-53,8(917)684-86-53-, fe-svo.aero,fe@svo.aero,lost-and-found-fe@svo.aero,lost-and-found@fe@svo.aero

IF [тип] = "mob" THEN [доставка] in {"8917684865","89176848653","8(917)684-86-53","8(917)684-86-53-"}
ELSE [доставка] in {"fe-svo.aero","fe@svo.aero","lost-and-found-fe@svo.aero","lost-and-found@fe@svo.aero"}; *)

В результате получим всего 33 строки данных (вместо 256).

применять грамотно.

Парное тестирование будет неэффективным, если:

Неправильно выбраны тестовые значения;
Наиболее вероятные комбинации данных встречаются редко;
Неправильно учтены взаимные влияния параметров.

! Таким образом, и парное тестирование требует творческого подхода.

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

всех ресурсов проекта.

Тестирование ~ Контроль качества

Необходимо оценивать (управлять) качеством самого тестирования!

качества тестирования важна!

Постулат
То, что нельзя измерять, нельзя улучшить
|
V
Нужно научиться измерять качество!

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

Оценка выполняется той же средой, что и выполнение unit-тестов.

Studio.

были исполнены в процессе тестирования*.

Анализ покрытия позволяет понять:
какие дополнительные тесты необходимо разработать;
Какова динамика покрытия кода в процессе продвижения проекта;

! Покрытие кода служит критерием качества 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

ссылке:
https://developer.salesforce.com/blogs/developer-relations/2012/11/how-code-coverage-works.html

быть недостижим.

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

Красным отмечен недостижимый вариант.

Конечно, разработчик такое бы заметил, но в более сложных случаях – довольно частое явление.

позволяют выявить дефекты как можно раньше. Устранения ранних дефектов – наиболее эффективно.

Ответственность за разработку unit-тестов несут Разработчики. Но знание их ценности необходимо для управления качеством тестирования, т.е. важно и для тестировщиков.

документируются в виде Прецедентов использования или Пользовательских историй.

Пользовательские истории – не слишком формализованные описания того, как пользователь представляет себе решение его задачи.

Зарегистрировать.

Информация о клиенте сохраняется и теперь клиент доступен в списке клиентов, при поиске и т.п.

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

общее количество элементов требований и количество выполненных (и не выполненных) проверок (тестов).

Выполняется тестировщиками в виде матрицы трассировки.

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

Excel-табличке;

Многие Issue Trackers (Jira, TFS, …) позволяют устанавливать связи между списком требований и списком тестовых сценариев и генерировать соответствующие отчеты.

Специализированные среды типа Rational Rose от IBM.

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

его стоимость!

Чем больше найдено ошибок, тем более вероятно, что остались ненайденные!

Негативные тесты так же важны как позитивные!

Разработчик не должен быть тестировщиком!

покрытие кода?
Всегда ли можно добиться 100% покрытия кода?
Как измеряется покрытие требований?
Почему важно тестирование с самых ранних этапов разработки?