Лекции по "Информатике"

5. Поэлементное тестирование входных данных

5.1. Определить элементы входных  данных (все поля ввода) 

5.2. Определить классы эквивалентности  для каждого элемента данных, и выбрать классы, соответствующие  валидным значениям.

5.3. Протестировать программу для  каждого элемента в отдельности,  в каждом из разрешенных состояний. 

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

Например, пусть при создании какого-нибудь объекта в интерфейсе программы имеется 5 чекбоксов. Нужно проверить что каждый чекбокс в отдельности работает, т.е. провести 10 тестов.

 

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

На этом этапе возникают тем  большие сложности, чем более  сложна тестируемая программа. Для улучшения понимания целесообразно составить схему пользовательских объектов и связей между ними.

6. Комбинирование входных данных.

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

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

Чем больше информации о взаимном влиянии параметров (точнее - о взаимном НЕвлиянии), тем больше комбинаций мы можем не тестировать. При отсутствии такой информации, а также при сложных алгоритмах поведения программы следует применить метод попарного тестирования (pairwise testing, см. лекцию 2)

 

Сюда же следует отнести тестирование при разных глобальных настройках, которые тоже следует считать  входными параметрами.

7. Тестирование граничных значений.

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

Можно выделить 2 границы:

7.1. Границы диапазона данных

7.2. Границы размера поля (длина строки)

8. Тестирование невалидных данных (не имеющих смысла)

8.1. Пустая строка

8.2. Неверные числовые данные (напр., отрицательные или дробные, там где это не имеет смысла)

8.3. Недопустимый формат (например, для даты или телефона)

8.4. Недопустимые печатные символы (служебные или национальные символы там, где это не имеет смысла)

8.5. Недопустимые непечатные символы (перевод строки или табуляция там, где это не имеет смысла)

 

Пример. Пусть нам дали на тестирование некое веб-приложение по некому адресу в интернете.

1. На первом этапе выяснилось, что никаких документальных требований нет.

 

2. При исследовательском тестировании  выяснилось, что программа предназначена  для создания почтовых ящиков, интерфейс имеет три текстовых  поля ввода: e-mail, пароль, размер ящика в МБ и кнопку Submit.

 

3. Базовые сценарии (операции  CRUD)

Имеется только операция Create. Операции Read, Update and Delete отсутствуют (получения информации о почтовом ящике, редактирования и удаления почтового ящика). Имеет смысл написать баг или спросить авторитетное лицо проекта насчет их отсутствия.

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

 

4. Анализ тенденций - проверим, какой  макс. размер почтового ящика  является допустимым.

 

5. Поэлементное тестирование входных данных

5.1. Имеется три поля ввода

5.2. Классы эквивалентности для  валидных значений:

E-mail может быть:

1. свободный/занятый

2. на домене, который обслуживается/не  обслуживается данным сервером

 Всего получается 4 класса эквивалентности. Ввод занятого E-mail следует проверять именно на этом этапе, т.к. значение является валидным E-mail согласно RFC. Нельзя считать это значение ошибочным и откладывать тестирование на последний этап.

Пароль может быть

1. Удовлетворяющий требованиям сложности или нет - 2 класса

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

Размер может быть:

1. Меньше предельного/больше предельного

2. Целый/дробный

4 класса эквивалентности.

Отрицательный размер является невалидным (не имеет смысла), его будем тестировать  на последнем шаге

Итого получается 10 тестов.

 

6. Комбинирование входных данных.

Email: free, busy, our domain, external domain

Password: safe, not safe

Size: less than limit, more than limit, integer, fractional

Всего комбинаций 4*2*4 = 32

Воспользуемся утилитой PICT, она нам даст 17 попарных комбинаций.

 

7. Тестирование граничных значений

Email: диапазон данных - неприменимо

длина данных - перед собакой как минимум 1 символ должен быть, как максимум - 64 (википедия)

Надо проверить: 0, 1, 64, 65

общая длина - 254 максимум (надо проверить 254 и 255)

 

Пароль: макс. длину можно попробовать выяснить экспериментально

 

Размер  ящика:

диапазон: 0, 0.0000001 (количество нулей подбирается  экспериментально), макс. предел (напр 100), макс. предел + 0.000001

длина строки: неприменимо

 

8. Тестирование  невалидных данных

Email - пустая строка, невалидный по RFC (несколько вариантов, например, перебрать все запрещенные символы)

Пароль - пустая строка, юникод-символы

Размер - пустая строка, отриц. числа, буквенные данные.