Разработка тестов с примером

1.

Разработка тестов

2.

Перед вами обыкновенная ручка. Давайте
подумаем, как её можно протестировать?

3.

ТЕСТЫ НА ОСНОВЕ ТРЕБОВАНИЙ (REQUIREMENTS BASED TESTS)
• ИЗВЛЕ К А ЕТСЯ И ВСТ А ВЛЯ Е ТСЯ ЛИ В Р У ЧК У СТ Е Р ЖЕНЬ?
• П Р ИСУТ СТ ВУЕТ ЛИ Д Е Р ЖАТЕЛЬ, П ОЗВОЛЯ Ю Щ И Й Ц Е П ЛЯ Т Ь Р У ЧК У ЗА К Р А Й
К А Р МАНА ?
• П Е Р Е КЛЮЧА ЕТСЯ ЛИ Р У ЧК А И З Р А Б ОЧЕ Г О В НЕ Р А Б ОЧЕЕ П ОЛОЖ Е НИ Е?

4.

ФУНКЦИОНАЛЬНЫЕ ТЕСТЫ (FUNCTIONAL TEST)
• ВСТ А ВИТ Ь В Р У ЧК У СТ Е Р ЖЕНЬ.
• П Е Р Е КЛЮЧИТЬ В Р АБОЧЕ Е ПОЛОЖ Е НИЕ.
• НА П ИСА Т Ь НЕ СК ОЛЬ КО СЛОВ.
• П Е Р Е КЛЮЧИТЬ В НЕ Р А БОЧЕЕ П ОЛОЖ Е НИЕ.
• ИЗВЛЕ ЧЬ СТ Е Р ЖЕНЬ.

5.

СРАВНИТЕЛЬНЫЕ («ПАРАЛЛЕЛЬНЫЕ») ТЕСТЫ ( PARALLEL TESTING)
• ЧТ О МЫ МОЖ Е М СК А ЗА Т Ь ОБ ЭТ ОЙ Р У ЧК Е В СР А ВНЕ НИ И С Д Р У Г И М И
Р УЧК А МИ, К ОТ ОР ЫЕ ВЫПУСК АЕ Т НАША ФИР МА?
• ЧТ О МЫ МОЖ Е М СК А ЗА Т Ь ОБ ЭТ ОЙ Р У ЧК Е В СР А ВНЕ НИ И С Р У ЧК А М И ,
К ОТ ОР Ы Е ВЫ П У СК А Ю Т К ОНК У Р ЕНТЫ ?
• В ЧЁ М П Р Е ИМ У Щ ЕСТВА И М Е ННО ЭТ ОЙ М ОД Е ЛИ Р У ЧЕ К ?

6.

СЦЕНАРНЫЕ ТЕСТЫ (SCENARIO TESTS)
К А К Р У ЧК У М О Ж Е Т И С П О Л Ь ЗО В А Т Ь:
СЕ К Р ЕТА РЬ.
П Р Е П ОДА ВАТЕЛЬ.
СТ УД Е НТ.
ШК ОЛЬ НИК.
П Р ОР А Б.
СА НТ Е ХНИК.

7.

ТЕСТЫ ОШИБОЧНЫХ СИТУАЦИЙ (FAULT INJECTION TESTS)
• ЧТ О П Р ОИЗОЙ Д Ё Т, Е СЛИ П Р Е П Я ТСТВОВА ТЬ ВЫ Х ОД У СТ Е Р ЖНЯ В Р А Б ОЧЕЕ
П ОЛОЖ Е НИЕ?
• К А К ОЕ УСИЛИ Е И Г Д Е НА Д О П Р И ЛОЖ И ТЬ К Р У ЧК Е , ЧТ ОБ Ы Е Ё СЛОМ А Т Ь?
• Е СЛИ СТ Е Р ЖЕНЬ ЗА СТ Р Я Л, ЛЕ Г К О ЛИ Е Г О И ЗВЛЕ ЧЬ ?
• ЧТ О П Р ОИЗОЙД Ё Т, Е СЛИ ПИСАТ Ь ПО СТ Е К ЛУ, АСФАЛЬ ТУ?

8.

ТЕСТЫ ИНТЕРФЕЙСА (INTERFACE TESTS, GUI TESTS)
• ИЗМЕ Р ЕНИЯ: ВЫ СОТ А , ШИ Р И НА , Д ЛИ НА , ВЕ С.
• ЦВЕ Т .
• ЧИТ А Е МОСТЬ ЛОГ ОТ И П А Ф И Р М Ы -П РОИ ЗВОДИ ТЕЛЯ.

9.

ТЕСТЫ УДОБСТВА ИСПОЛЬЗОВАНИЯ (USABILITY TESTS)
• К А К МНОГ О ВР Е М ЕНИ У П ОЛЬ ЗОВА Т ЕЛЯ ЗА НИ М А ЕТ П Е Р Е КЛЮЧЕНИ Е
Р УЧК И ИЗ НЕ Р А БОЧЕГ О П ОЛОЖ Е НИ Я В Р А Б ОЧЕ Е И ОБ Р А Т НО?
• К А К БЫ СТ Р О П ОЛЬ ЗОВА Т ЕЛЬ П ОНИ М А Е Т, К А К П ОЛЬ ЗОВА Т ЬСЯ Р У ЧК ОЙ ?
• К А К БЫ СТ Р О П ОЛЬ ЗОВА Т ЕЛЬ П Р И ВЫ К А ЕТ К ЭТ ОЙ Р У ЧК Е ?
• ЛЕ Г К О ЛИ П ОНЯ Т Ь , К А К И Е СТ Е РЖНИ П ОД Х ОД ЯТ К Р У ЧК Е ?
• ЛЕ Г К О ЛИ ЗА М Е НИ ТЬ СТ Е Р ЖЕНЬ?
• МОЖ Е Т ЛИ Р У ЧК ОЙ П ОЛЬ ЗОВА Т ЬСЯ ЛЕ ВША ?

10.

ТЕСТЫ УПАКОВКИ И ДОКУМЕНТАЦИИ
(PACKAGING/DOCUMENTATION TESTS)
• Я СНО ЛИ ВИД НО НА УПАК ОВК Е , ЧТ О ВНУТ Р И?
• ЛЕ Г К О ЛИ ОТ К Р Ы ТЬ У П А К ОВК У ?
• НА СК ОЛЬ К О М А Т ЕРИ А ЛЫ У П А К ОВК И ВР Е Д НЫ Д ЛЯ ОК Р У Ж А ЮЩЕЙ СР Е Д Ы?
• Е СТ Ь ЛИ К А К ИЕ -ТО ОСОБЫ Е Т Р Е БОВАНИЯ К УП А К ОВК Е ?
• НА СА ЙТ Е , В К А Т А ЛОГ Е, НА У П А К ОВК Е НА П И СА НО И НА Р И СОВА НО ОД НО
И ТО ЖЕ?
• НА УП А К ОВК Е И В Д ОК У М ЕНТА ЦИ И НЕ Т Г Р А М М АТИ ЧЕСК И Х ОШИ Б ОК ,
ОП Е ЧА Т ОК И Т . Д .?

11.

СТРЕССОВЫЕ ТЕСТЫ (STRESS TESTS)
• П Р И К А К ОЙ Т Е М П ЕРАТУ РЕ Р А СП ЛА ВИ Т СЯ П ЛА СТ И К ОВАЯ ЧА СТ Ь Р У ЧК И ?
• П Р И К А К ОЙ Т Е М П ЕРАТУ РЕ П ОТ Е ЧЁ Т СТ Е Р ЖЕНЬ?
• П Р И К А К ОЙ Т Е М П ЕРАТУ РЕ Р У ЧК А П Е Р ЕСТА ЁТ П И СА Т Ь ?
• П ИШЕ Т ЛИ Р УЧК А П ОД ВОД ОЙ ? А П О М ОК Р ОЙ Б У М А Г Е ?
• Е СЛИ Р УЧК У У Р ОНИ Т Ь В П Е СОК – ЧТ О П Р ОИ ЗОЙ Д Ё Т?

12.

ТЕСТЫ ПРОИЗВОДИТЕЛЬНОСТИ (PERFORMANCE TESTS)
• СК ОЛЬ К О Т Е К СТА М ОЖ НО НА П И СА Т Ь Р У ЧК ОЙ В Е Д И НИ Ц У ВР Е М Е НИ ?
• К А К БЫ СТ Р О Р У ЧК У М ОЖ НО П Р И ВЕ СТ И В Р А Б ОЧЕ Е П ОЛОЖ Е НИ Е?
• К А К МНОГ О Р А З Р У ЧК У М ОЖ НО П Е Р ЕКЛЮЧИ Т Ь И З НЕ Р А БОЧЕГ О В
Р А БОЧЕ Е П ОЛОЖ Е НИ Е, П Р Е Ж ДЕ ЧЕ М Е Ё НА ЧНЁ Т ЗА Е Д АТЬ?

13.

КОНФИГУРАЦИОННЫЕ ТЕСТЫ (CONFIGURATION TESTS)
• К А К ИЕ СТ Е Р ЖНИ П ОД Х ОДЯТ К НА ШЕ Й Р У ЧК Е ?
• НА К А К ИХ П ОВЕ Р Х НОСТЯ Х ОНА М ОЖ Е Т П И СА Т Ь ?

14.

Практическое задание «Задача о
треугольнике»
Эту задачу предложил в 1979 году Гленфорд Майерс в своей книге
«Искусство тестирования программ» («The Art Of Software Testing»). С тех
пор она известна как «задача о треугольнике» и является своего
классическим вопросом на множестве собеседований на должность
тестировщика.
Программа производит чтение с перфокарты трёх целых чисел, которые
интерпретируются как длины сторон треугольника. Далее программа
печатает сообщение о том, является ли треугольник неравносторонним,
равнобедренным или равносторонним.
Напишите на листе бумаги (или в файле) набор тестов, которые, как вам
кажется, будут адекватно проверять эту программу. На это у вас десять
минут.

15.

Практическое задание «Задача о
треугольнике»
Были изучены различные версии данной программы и составлен список
общих ошибок. Оцените ваш набор тестов, попытавшись с его помощью
ответить на приведенные ниже вопросы. За каждый ответ «да»
присуждается одно очко.
1. Составили ли вы тест, который представляет правильный неравносторонний
треугольник? (Ответ «да» на этот вопрос не засчитывается, если вы имеете в
виду тесты, проверяющие значения длин сторон вида «1, 2, 3» или «2, 5, 10»,
так как не существует треугольников, имеющих такие стороны.)
2. Составили ли вы тест, который представляет правильный равносторонний
треугольник?
3. Составили ли вы тест, который представляет правильный равнобедренный
треугольник? (Тесты со значениями сторон «2, 2, 4» принимать в расчёт не
следует, т.к., опять же, не бывает таких треугольников.)

16.

Практическое задание «Задача о
треугольнике»
4.
5.
6.
7.
8.
Составили ли вы по крайней мере три теста, которые представляют правильные
равнобедренные треугольники, полученные как перестановки двух равных
сторон треугольника (например, «3, 3, 4», «3, 4, 3», «4, 3, 3»)?
Составили ли вы тест, в котором длина одной из сторон треугольника принимает
нулевое значение?
Составили ли вы тест, в котором длина одной из сторон треугольника принимает
отрицательное значение?
Составили ли вы тест, включающий три положительных целых числа, сумма двух из
которых равна третьему? (Другими словами, если программа выдала сообщение о
том, что числа «1, 2, 3» представляют собой стороны неравностороннего
треугольника, то такая программа содержит ошибку.)
Составили ли вы по крайней мере три теста с заданными значениями всех трёх
перестановок, в которых длина одной стороны равна сумме длин двух других сторон
(например, «1, 2, 3», «1, 3, 2», «3, 1, 2»)?

17.

Практическое задание «Задача о
треугольнике»
9. Составили ли вы тест из трёх целых положительных чисел, таких, что сумма
двух из них меньше третьего числа (т. е. «1, 2, 4» или «12, 15, 30»)?
10. Составили ли вы по крайней мере три теста из категории 9, в которых вами
испытаны все три перестановки (например, «1, 2, 4», «1, 4, 2», «4, 1, 2»)?
11. Составили ли вы тест, в котором все стороны треугольника имеют длину,
равную нулю (т. е. «0, 0, 0»)?
12. Составили ли вы по крайней мере один тест, содержащий нецелые
значения?
13. Составили ли вы хотя бы один тест, содержащий неправильное число
значений (например, два, а не три целых числа)?
14. Специфицировали ли вы в каждом тесте не только входные значения, но и
выходные данные программы?

18.

Практическое задание «Задача о
треугольнике»
Конечно, нет гарантий, что с помощью набора тестов, который удовлетворяет
вышеперечисленным условиям, будут найдены все возможные ошибки. Но
поскольку вопросы 1+13 представляют ошибки, имевшие место в различных
версиях данной программы, адекватный тест для неё должен их обнаруживать.
Отметим, что опытные профессиональные программисты набирают в среднем
только 7-8 очков из 14 возможных.
Выполненное упражнение показывает нам, что тестирование даже тривиальных
программ, подобных приведенной, – непростая задача.
И коль скоро это так, представьте трудности тестирования программ размером,
например, в 1’000’000 и более операторов. А если это программа по управлению
реактором АЭС?

19.

Практическое задание «Задача о
треугольнике»
На только что рассмотренных примерах с ручкой и треугольником вы могли
убедиться, что набор тестов у вас получается неидеальным. А как его сделать
лучше? Как убедиться, что тестов достаточно, и в то же время их не слишком
много?
Для этого есть прекрасная техника – продумывание классов эквивалентности и
граничных условий.

20.

Классы эквивалентности
Если мы ожидаем одинакового результата от выполнения двух и более тестов, эти тесты
эквивалентны. Такие множества тестов называются классами эквивалентности.
Признаки эквивалентности (несколько тесто эквивалентны, если):
◦
◦
◦
◦
◦
◦
◦
◦
Она направлены на поиск одной и той же ошибки.
Если один из тестов обнаруживает ошибку, другие её тоже, скорее всего, обнаружат.
Если один из тестов НЕ обнаруживает ошибку, другие её тоже, скорее всего, НЕ обнаружат.
Тесты используют одни и те же наборы входных данных.
Для выполнения тестов мы совершаем одни и те же операции.
Тесты генерируют одинаковые выходные данные или приводят приложение в одно и то же
состояние.
Все тесты приводят к срабатыванию одного и того же блока обработки ошибок («error handling
block»).
Ни один из тестов не приводит к срабатыванию блока обработки ошибок («error handling block»).

21.

Классы эквивалентности
Граничные условия (или просто – границы) – это те места, в которых один класс
эквивалентности переходит в другой.
Например, одна группа тестов вызывает сообщение «вы ввели слишком
маленькое число», а другая вызывает сообщение «вы ввели слишком большое
число». Граница будет лежать где-то в районе чисел «самых больших из слишком
маленьких» и «самых маленьких из слишком больших».
Граничные условия очень важны, и их обязательно следует проверять в тестах,
т.к. именно в этом месте чаще всего и обнаруживаются ошибки.
Рассмотрим на примере.

22.

Пример
Необходимо проверить, как работает поле, в которое можно ввести целое число в
диапазоне от 1 до 99.
Классы эквивалентности здесь:
Любое целое в диапазоне от 1 до 99. Как правило, это будет середина числового отрезка. Позитивный
тест.
Любое число меньше 1. Негативный тест.
Любое число больше 99. Негативный тест.
Дробь и «не число» (буквы, спецсимволы). Негативный тест.
Тесты, которые мы выполним:
Ввести 1, 99, 50
Ввести 0
Ввести 100
Ввести 50.5, букву, спецсимвол: ~`!”@’#$;%:^&?*()[]{},.\/+=-_

23.

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

24.

Шаг 1
Первым делом нужно определить все входные переменные во всех шагах в
представленном сценарии (алгоритме).
Например, если на некотором шаге пользователь вводит свой логин и пароль, это две
переменных. Первая переменная – Логин, вторая – Пароль.
Переменной также может быть выбор, который пользователь должен сделать (такой как
выбор рейса из списка).

25.

Шаг 2
На следующем шаге следует определить существенно различные варианты для каждой
переменной. Варианты считаются «существенно разными», если они могут вызывать различное
поведение системы.
Например, если выбрать Логин, который предполагается быть длиной до 10-ти символов,
следующие приведенные значения будут существенно разными:
Alex – слишком короткий и мы ожидаем появления сообщения об ошибке.
Alexandra – верный Логин.
Alexandrena – слишком длинный, и мы ожидаем, что система не позволит нам вводить
слишком длинный Логин.
Однако, Alexandria или JohnGordon различны не существенно, т.к. оба являются верными
логинами, вызывающими одно поведение системы.

26.

Шаг 2
Вариант может считаться существенно другим, если:
– Он вызывает другой ход процесса (обычно альтернативный поток).
Пример: Ввод неверного пароля вызовет Альтернативный Поток 2.
Он вызывает другое сообщение об ошибке.
Пример: Если адрес электронной почты слишком длинный, сообщение должно быть:
«E-mail должен быть не более 50-ти символов».
Пример: Если адрес электронной почты не содержит символа «@», сообщение должно быть: «Неверный E-mail
адрес».
– Он вызывает другой вид пользовательского интерфейса.
Пример: Если кредитная карта была выбрана в качестве способа оплаты, система должна отображать экран с
полями для ввода номера кредитной карты, даты окончания срока действия и название организации,
обслуживающей карту.
– Он вызывает различный набор значений списков.

27.

Шаг 2
Пример: Экран регистрации пользователя должен содержать список Страна и
Штат/Провинция. Список Штат/Провинция будет содержать значения на основе
выбранной страны: для США он должен содержать все штаты, для Канады – все
провинции, для других стран он должен быть недоступен.
– Он является условием ограничения.
Пример: Пароль должен быть не менее 6-ти символов.
В этом случае мы должны протестировать следующее:
Пароль с пятью символами.
Пароль с шестью символами
– Что-то должно быть изменено вместо использования значения по умолчанию.

28.

Шаг 2
Пример: На экране оплаты кредитной картой название организации, обслуживающей
кредитную карту, должно быть заполнено именем лица, размещающего заказ.
Пользователь должен иметь возможность хранить это значение по умолчанию или ввести
новое.
– Это создает два различных варианта:
Хранить установленное по умолчанию название организации, обслуживающей кредитную
карту.
Изменить установленное по умолчанию название организации на другое.
– Формат ввода точно не определен и может быть интерпретирован разными способами.

29.

Шаг 2
Пример: поле ввода номера телефона должно принимать текст в свободной форме.
Номера телефонов разными лицами пишутся по-разному:
Использования скобок: (973) 123-4567
Использование тире: 973-123-4567
Использование пробелов: 973 123 4567
Без пробелов: 9731234567
Все доступные варианты должны быть протестированы.
– Стандартные варианты могут быть разными для разных стран.
Формат даты срока окончания действия кредитной карты может быть разным для США и
Европы.

30.

Шаг 3
На следующем шаге нужно скомбинировать их в последовательность шагов тестового
сценария.
Один из способов это сделать – создать Матрицу Распределения Тестовых Сценариев (Test
Case Allocation Matrix).
Строки этой матрицы содержат все переменные для всех шагов, требующие ввода данных
он пользователя.
Первая колонка содержит номер шага, вторая – название переменной, а остальные –
тестовые сценарии. Их можно назвать Т1, Т2, и т.д.
Обычно типичный сценарий охватывают от пяти до семи тестовых сценариев. Тем не
менее, иногда в особых случаях требуется больше тестовых сценариев.

31.

Шаг 3
Пример Матрицы распределения тестовых сценариев

32.

Шаг 3

33.

Шаг 4
На четвертом шаге следует заменить неопределенные варианты, такие как «очень
длинная фамилия» или «длинный номер телефона с ext. (дополнительным номером)» на
действительные значения, например «Georgiamistopolis» и «011-48 (242) 425-3456 ext.
1234» соответственно.
На этом шаге также разделяют все тестовые сценарии из Матрицы Распределения
Тестовых Сценариев, создавая отдельную таблицу для каждого тестового сценария.

34.

Шаг 4
Метод извлечения функциональных тестовых сценариев (test cases) из сценариев
использования (use cases) имеет несколько преимуществ:
Тестовые сценарии получаются с использованием более автоматического подхода.
Уход от дублирования тестовых сценариев.
Достигается больший охват тестового пространства.
Легкость мониторинга тестового процесса.
Легкость распределения работы между тестерами.
Легкость регрессионного тестирования.
Раннее обнаружение пропущенных требований.
Созданные тестовые сценарии могут быть использованы для ручного тестирования, также
как и для автоматического тестирования