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

Содержание

Слайд 2

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

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

Слайд 3

ТЕСТЫ НА ОСНОВЕ ТРЕБОВАНИЙ (REQUIREMENTS BASED TESTS) ИЗВЛЕКАЕТСЯ И ВСТАВЛЯЕТСЯ ЛИ

ТЕСТЫ НА ОСНОВЕ ТРЕБОВАНИЙ (REQUIREMENTS BASED TESTS)
ИЗВЛЕКАЕТСЯ И ВСТАВЛЯЕТСЯ ЛИ В

РУЧКУ СТЕРЖЕНЬ?
ПРИСУТСТВУЕТ ЛИ ДЕРЖАТЕЛЬ, ПОЗВОЛЯЮЩИЙ ЦЕПЛЯТЬ РУЧКУ ЗА КРАЙ КАРМАНА?
ПЕРЕКЛЮЧАЕТСЯ ЛИ РУЧКА ИЗ РАБОЧЕГО В НЕРАБОЧЕЕ ПОЛОЖЕНИЕ?
Слайд 4

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

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

СЛОВ.
ПЕРЕКЛЮЧИТЬ В НЕРАБОЧЕЕ ПОЛОЖЕНИЕ.
ИЗВЛЕЧЬ СТЕРЖЕНЬ.
Слайд 5

СРАВНИТЕЛЬНЫЕ («ПАРАЛЛЕЛЬНЫЕ») ТЕСТЫ (PARALLEL TESTING) ЧТО МЫ МОЖЕМ СКАЗАТЬ ОБ ЭТОЙ

СРАВНИТЕЛЬНЫЕ («ПАРАЛЛЕЛЬНЫЕ») ТЕСТЫ (PARALLEL TESTING)
ЧТО МЫ МОЖЕМ СКАЗАТЬ ОБ ЭТОЙ РУЧКЕ

В СРАВНЕНИИ С ДРУГИМИ РУЧКАМИ, КОТОРЫЕ ВЫПУСКАЕТ НАША ФИРМА?
ЧТО МЫ МОЖЕМ СКАЗАТЬ ОБ ЭТОЙ РУЧКЕ В СРАВНЕНИИ С РУЧКАМИ, КОТОРЫЕ ВЫПУСКАЮТ КОНКУРЕНТЫ?
В ЧЁМ ПРЕИМУЩЕСТВА ИМЕННО ЭТОЙ МОДЕЛИ РУЧЕК?
Слайд 6

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

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

Слайд 7

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

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

В РАБОЧЕЕ ПОЛОЖЕНИЕ?
КАКОЕ УСИЛИЕ И ГДЕ НАДО ПРИЛОЖИТЬ К РУЧКЕ, ЧТОБЫ ЕЁ СЛОМАТЬ?
ЕСЛИ СТЕРЖЕНЬ ЗАСТРЯЛ, ЛЕГКО ЛИ ЕГО ИЗВЛЕЧЬ?
ЧТО ПРОИЗОЙДЁТ, ЕСЛИ ПИСАТЬ ПО СТЕКЛУ, АСФАЛЬТУ?
Слайд 8

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

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

ФИРМЫ-ПРОИЗВОДИТЕЛЯ.
Слайд 9

ТЕСТЫ УДОБСТВА ИСПОЛЬЗОВАНИЯ (USABILITY TESTS) КАК МНОГО ВРЕМЕНИ У ПОЛЬЗОВАТЕЛЯ ЗАНИМАЕТ

ТЕСТЫ УДОБСТВА ИСПОЛЬЗОВАНИЯ (USABILITY TESTS)
КАК МНОГО ВРЕМЕНИ У ПОЛЬЗОВАТЕЛЯ ЗАНИМАЕТ ПЕРЕКЛЮЧЕНИЕ

РУЧКИ ИЗ НЕРАБОЧЕГО ПОЛОЖЕНИЯ В РАБОЧЕЕ И ОБРАТНО?
КАК БЫСТРО ПОЛЬЗОВАТЕЛЬ ПОНИМАЕТ, КАК ПОЛЬЗОВАТЬСЯ РУЧКОЙ?
КАК БЫСТРО ПОЛЬЗОВАТЕЛЬ ПРИВЫКАЕТ К ЭТОЙ РУЧКЕ?
ЛЕГКО ЛИ ПОНЯТЬ, КАКИЕ СТЕРЖНИ ПОДХОДЯТ К РУЧКЕ?
ЛЕГКО ЛИ ЗАМЕНИТЬ СТЕРЖЕНЬ?
МОЖЕТ ЛИ РУЧКОЙ ПОЛЬЗОВАТЬСЯ ЛЕВША?
Слайд 10

ТЕСТЫ УПАКОВКИ И ДОКУМЕНТАЦИИ (PACKAGING/DOCUMENTATION TESTS) ЯСНО ЛИ ВИДНО НА УПАКОВКЕ,

ТЕСТЫ УПАКОВКИ И ДОКУМЕНТАЦИИ (PACKAGING/DOCUMENTATION TESTS)
ЯСНО ЛИ ВИДНО НА УПАКОВКЕ, ЧТО

ВНУТРИ?
ЛЕГКО ЛИ ОТКРЫТЬ УПАКОВКУ?
НАСКОЛЬКО МАТЕРИАЛЫ УПАКОВКИ ВРЕДНЫ ДЛЯ ОКРУЖАЮЩЕЙ СРЕДЫ?
ЕСТЬ ЛИ КАКИЕ-ТО ОСОБЫЕ ТРЕБОВАНИЯ К УПАКОВКЕ?
НА САЙТЕ, В КАТАЛОГЕ, НА УПАКОВКЕ НАПИСАНО И НАРИСОВАНО ОДНО И ТО ЖЕ?
НА УПАКОВКЕ И В ДОКУМЕНТАЦИИ НЕТ ГРАММАТИЧЕСКИХ ОШИБОК, ОПЕЧАТОК И Т.Д.?
Слайд 11

СТРЕССОВЫЕ ТЕСТЫ (STRESS TESTS) ПРИ КАКОЙ ТЕМПЕРАТУРЕ РАСПЛАВИТСЯ ПЛАСТИКОВАЯ ЧАСТЬ РУЧКИ?

СТРЕССОВЫЕ ТЕСТЫ (STRESS TESTS)
ПРИ КАКОЙ ТЕМПЕРАТУРЕ РАСПЛАВИТСЯ ПЛАСТИКОВАЯ ЧАСТЬ РУЧКИ?
ПРИ КАКОЙ

ТЕМПЕРАТУРЕ ПОТЕЧЁТ СТЕРЖЕНЬ?
ПРИ КАКОЙ ТЕМПЕРАТУРЕ РУЧКА ПЕРЕСТАЁТ ПИСАТЬ?
ПИШЕТ ЛИ РУЧКА ПОД ВОДОЙ? А ПО МОКРОЙ БУМАГЕ?
ЕСЛИ РУЧКУ УРОНИТЬ В ПЕСОК – ЧТО ПРОИЗОЙДЁТ?
Слайд 12

ТЕСТЫ ПРОИЗВОДИТЕЛЬНОСТИ (PERFORMANCE TESTS) СКОЛЬКО ТЕКСТА МОЖНО НАПИСАТЬ РУЧКОЙ В ЕДИНИЦУ

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

БЫСТРО РУЧКУ МОЖНО ПРИВЕСТИ В РАБОЧЕЕ ПОЛОЖЕНИЕ?
КАК МНОГО РАЗ РУЧКУ МОЖНО ПЕРЕКЛЮЧИТЬ ИЗ НЕРАБОЧЕГО В РАБОЧЕЕ ПОЛОЖЕНИЕ, ПРЕЖДЕ ЧЕМ ЕЁ НАЧНЁТ ЗАЕДАТЬ?
Слайд 13

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

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

ОНА МОЖЕТ ПИСАТЬ?
Слайд 14

Практическое задание «Задача о треугольнике» Эту задачу предложил в 1979 году

Практическое задание «Задача о треугольнике»

Эту задачу предложил в 1979 году Гленфорд

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

Практическое задание «Задача о треугольнике» Были изучены различные версии данной программы

Практическое задание «Задача о треугольнике»

Были изучены различные версии данной программы и

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

Практическое задание «Задача о треугольнике» Составили ли вы по крайней мере

Практическое задание «Задача о треугольнике»

Составили ли вы по крайней мере три

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

Практическое задание «Задача о треугольнике» Составили ли вы тест из трёх

Практическое задание «Задача о треугольнике»

Составили ли вы тест из трёх целых

положительных чисел, таких, что сумма двух из них меньше третьего числа (т. е. «1, 2, 4» или «12, 15, 30»)?
Составили ли вы по крайней мере три теста из категории 9, в которых вами испытаны все три перестановки (например, «1, 2, 4», «1, 4, 2», «4, 1, 2»)?
Составили ли вы тест, в котором все стороны треугольника имеют длину, равную нулю (т. е. «0, 0, 0»)?
Составили ли вы по крайней мере один тест, содержащий нецелые значения?
Составили ли вы хотя бы один тест, содержащий неправильное число значений (например, два, а не три целых числа)?
Специфицировали ли вы в каждом тесте не только входные значения, но и выходные данные программы?
Слайд 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 Первым делом нужно определить все входные переменные во всех

Шаг 1

Первым делом нужно определить все входные переменные во всех шагах

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

Шаг 2 На следующем шаге следует определить существенно различные варианты для

Шаг 2

На следующем шаге следует определить существенно различные варианты для каждой
переменной.

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

Шаг 2 Вариант может считаться существенно другим, если: – Он вызывает

Шаг 2

Вариант может считаться существенно другим, если:
– Он вызывает другой ход

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

Шаг 2 Пример: Экран регистрации пользователя должен содержать список Страна и

Шаг 2

Пример: Экран регистрации пользователя должен содержать список Страна и Штат/Провинция.

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

Шаг 2 Пример: На экране оплаты кредитной картой название организации, обслуживающей

Шаг 2

Пример: На экране оплаты кредитной картой название организации, обслуживающей кредитную

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

Шаг 2 Пример: поле ввода номера телефона должно принимать текст в

Шаг 2

Пример: поле ввода номера телефона должно принимать текст в свободной

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

Шаг 3 На следующем шаге нужно скомбинировать их в последовательность шагов

Шаг 3

На следующем шаге нужно скомбинировать их в последовательность шагов тестового

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

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

Шаг 3

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

Слайд 32

Шаг 3

Шаг 3

Слайд 33

Шаг 4 На четвертом шаге следует заменить неопределенные варианты, такие как

Шаг 4

На четвертом шаге следует заменить неопределенные варианты, такие как «очень

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