Проверка класса эквивалентности
EC-тестирование - это когда у вас есть несколько тестовых элементов (например, значений), которые вы хотите протестировать, но из-за затрат (времени / денег) у вас нет времени, чтобы протестировать их все. Поэтому вы группируете тестовый элемент в класс, где все элементы в каждом классе должны вести себя одинаково. Теория заключается в том, что вам нужно протестировать только один из каждого элемента, чтобы убедиться, что система работает.
Пример 1
Дети до 2 лет катаются на автобусе бесплатно. Молодежь платит 10 долларов, взрослые 15 долларов и пенсионеры 5 долларов.
Классы:
Цена: 0 -> Возраст: 0-1
Цена: 10 -> Возраст: 2-14
Цена: 15 -> Возраст: 15-64
Цена: 5 -> Возраст: 65-бесконечность
Пример 2 (более одного параметра)
Мобильные телефоны K80, J64 и J54 работают под управлением Java 5. K90 и J99 работают под управлением Java 6. Но есть два возможных браузера FireFox и Opera, модели J работают под управлением FF, а модели K - O.
Классы:
Браузер: FF, Java: 5 -> Телефоны: J64, J54
Браузер: FF, Java: 6 -> Телефоны: J99 * 1022 *
Браузер: O, Java: 5 -> Телефоны: K80
Браузер: O, Java: 6 -> Телефоны: K90
Опасность тестирования класса эквивалентности
Существует опасность использования ЕС-тестирования, которое редко упоминается в книгах по тестированию, но очень важно помнить.
То, что два элемента / значения должны принадлежать к одному классу и вести себя одинаково, не означает, что они действительно ведут себя одинаково.
Это означает, что только потому, что вы проверяете одно значение в классе, ВСЕ значения в классе ведут себя одинаково. Мой реальный пример - это мобильные телефоны, у которых была определенная платформа Java. Они должны были работать одинаково, но на самом деле это не так. Поэтому тестирование только одного значения в классе - это хорошо, но недостаточно. EC-тестирование - это хороший инструмент, но он не дурак, и будьте осторожны с ним. Если контрольные примеры дешевые и быстрые (например, автоматизация), протестируйте больше или почему бы не проверить их все!
Тестирование граничных значений
Тестирование BV - это когда вы решаете проверить значения на границе каждого класса, который вы определили. Теория состоит в том, что большинство дефектов происходит по краям класса.
Пример * * тысячу сорок один
Классы:
Цена: 0 -> Возраст: 0-1 (граничные значения 0, 1)
Цена: 10 -> Возраст: 2-14 (Граничные значения 2, 14)
Цена: 15 -> Возраст: 15-64 (граничные значения 15, 64)
Цена: 5 -> Возраст: 65-бесконечность (граничные значения 65)
Критика тестирования граничных значений
1) Я и другие специалисты по тестированию, у которых я проходил курсы, не уверены, что большинство дефектов скрыто по краям каждого класса. И я никогда не видел исследований, подтверждающих это.
2) Тот факт, что вам нужно использовать BV Testing, доказывает, что EC Testing имеет недостатки, так как вы тестируете более одного значения каждого класса.
3) Легко использовать при использовании значений, таких как целые числа. Но каково граничное значение класса моделей телефонов или версий браузеров?
Тестирование скрытых граничных значений
Граничные значения класса часто основаны на спецификации того, как должна работать система. Это все хорошо и хорошо, но большинство систем содержат границы, которые не описаны ни в одной спецификации, и вам придется искать их самостоятельно. Например. «Сколько символов я могу вставить в тестовое поле до того, как система выйдет из строя и выйдет из строя.», «Насколько большим может быть файл данных, прежде чем он станет таким медленным для чтения, что это раздражает».
Примеры из реальной жизни
- Вставка миллиона символов в текстовую область в FireFox 3.5 на win 7 приводит к сбою
- ReCaptcha имеет ограничение в 16003 символа, обрабатывает ли ваша система 413, которые она возвращает ему, если кто-то поместит 16004+ символов в поле. Или это ломается
Резюме
EC-тестирование и BV-тестирование - отличные инструменты, и вы должны их использовать, но они не идеальны и не ожидают, что при их использовании обнаружатся все дефекты. Используйте свое ноу-хау о системе, а также свой интеллект и интуицию, чтобы попробовать больше предметов и искать другие способы, которые могут привести к сбою. Ищи скрытые границы!