Пример 1. Одна сущность

Представим, что мы тестируем модуль для HR, который определяет брать на работу кандидата или нет, базируясь на возрасте кандидата. Условия такие:

· 0–16 : Не нанимать

· 16–18 : Можем нанять только на part time

· 18–55 : Можем нанять на full time

· 55–99 : Не нанимать

Стоит ли в этом случае применять exhaustive testing, т.е. должны ли мы протестировать модуль на всех возможных входных данных, на всех возрастах: 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 97, 98, 99? Если бы имели на это ресурсы, то это был бы неплохой вариант. Либо в случае если девелопер реализовал модуль как нижепередставленный код, то пожалуй тоже бы пришлось тестировать все возраста.

If (applicantAge == 0) hireStatus="NO"; If (applicantAge == 1) hireStatus="NO"; … If (applicantAge == 14) hireStatus="NO"; If (applicantAge == 15) hireStatus="NO"; If (applicantAge == 16) hireStatus="PART"; If (applicantAge == 17) hireStatus="PART"; If (applicantAge == 18) hireStatus="FULL"; If (applicantAge == 19) hireStatus="FULL"; … If (applicantAge == 53) hireStatus="FULL"; If (applicantAge == 54) hireStatus="FULL"; If (applicantAge == 55) hireStatus="NO"; If (applicantAge == 56) hireStatus="NO"; … If (applicantAge == 98) hireStatus="NO"; If (applicantAge == 99) hireStatus="NO";

К счастью, наши родные девелоперы так код не пишут (по крайней мере как правило :)). На самом деле для этого модуля мы, как правило, увидим примерно такой код:

If (applicantAge > 0 && applicantAge <=16) hireStatus="NO"; If (applicantAge > 16 && applicantAge <=18) hireStatus="PART"; If (applicantAge > 18 && applicantAge <=55) hireStatus="FULL"; If (applicantAge > 55 && applicantAge <=99) hireStatus="NO";

Поэтому явно видно, что не стоит тестировать все значения 0, 1, 2, ... 14, 15, 16. Более разумно будет протестировать диапазоны каждого условия, что собственно и есть наши классы эквивалентности.:

1. Класс эквивалентности NO: 0-16.

2. Класс эквивалентности PART: 17-18.

3. Класс эквивалентности FULL: 19-55.

4. Класс эквивалентности NO: 56-99.

Вспомним правила - после определения классов эквивалентности мы должны создать тест кейс с любым значением из диапазона класса эквивалентности. Итого у нас 4 позитивных тест кейса вместо 100. Неплохая оптимизация.

Так же не стоит забывать о не валидных диапазонах, добавим классы эквивалентности и для них:

1. (-100) – (-1). Значнеие (-100) было взято наугад, по поводу подобных границ лучше консультироваться с девелоперами.

2. 100-1000. Значнеие (1000) было взято наугад, по поводу подобных границ лучше консультироваться с девелоперами.

3. 0.1-0.9. Выбрано любое дробное значение входящее в валидный диапазон.

4. Символы.

5. Пустой ввод.

6. ...

Вот собственно и всё. Осталось на каждый класс эквивалентности создать тест-кейс.

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

Для этого лучше рассмотреть следующий пример.

Пример 2. Несколько сущностей.

Допустим ситуацию, когда нам нужно протестировать форму регистрации на сайте. Для регистрации нам нужно ввести логин, пароль, возраст и способ оплаты товаров на сайте. Требования такие:

Сущность	Тип ввода	Допустимые значения
Логин	Ввод с клавиатуры	Латинские символы
Пароль	Ввод с клавиатуры	Латинские символы
Возраст	Выбор из списка (список от 1 до 100)	От 16 до 100
Способ оплаты	Выбор из списка	Оплата картой, интернет деньги, наличные

Определеим классы эквивалентности по сущностям:

· 1. Логин:

· a. Латинские символы

· b. Не латинские символы

· c. Пустой ввод

· 2. Пароль:

· a. Латинские символы

· b. Не латинские символы

· c. Пустой ввод

· 3. Возраст:

· a. От 16 до 100

· b. От 1 до 16

· 4. Способ оплаты:

· a. Любое значение из списка

Примечание: Некоторые сущности, например "не латинские символы", стоило бы разложить на подсущности, но для простоты примера мы этого делать не будем.

Для тестирования способа оплаты мы должны выбрать значение «Оплата картой», «интернет деньги» или «наличные». Это тот случай, когда здравый смысл должен победить любые правила :) Хотя правило предлагает нам выбрать одно значение из класса эквивалентности, здесь будет лучше проверить каждое из них. Это имеет смысл потому что здесь входных значений немного.

Возможно появится вопрос – а что с возрастом? Может и тут стоит все значения протестировать? А если бы мы вводили город проживания? Стоило бы все возможные значения городов из списка проверить? Ответ на эти вопросы зависит от риска пропустить серьезные дефекты и от количества времени выделенного под тестирование.

Итого у нас получатся следующие валидные тест-кейсы:

Логин	Пароль	Возраст	Способ оплаты	Результат
Латинские символы	Латинские символы	От 16 до 100	Оплата картой	Успешная регистрация
Латинские символы	Латинские символы	От 16 до 100	Интернет деньги	Успешная регистрация
Латинские символы	Латинские символы	От 16 до 100	наличные	Успешная регистрация

При составлении _не_ валидных тест кейсов советую создавать по 1 тест кейсу на каждое _не_ валидное значение 1 сущности:

Логин	Пароль	Возраст	Способ оплаты	Результат
Не латинские символы	Латинские символы	От 16 до 100	Оплата картой	Ошибка регистрации
Пустой ввод	Латинские символы	От 16 до 100	Оплата картой	Ошибка регистрации
Латинские символы	Не Латинские символы	От 16 до 100	Интернет деньги	Ошибка регистрации
Латинские символы	Пустой ввод	От 16 до 100	Интернет деньги	Ошибка регистрации
Латинские символы	Латинские символы	От 1 до 16	наличные	Ошибка регистрации

Ну вот собственно и всё. Готово. Можно тестировать.