Валидация полей ввода
#1
Отправлено 20 февраля 2006 - 14:35
Пишем test cases валидации полей ввода в пользовательском интерфейсе (веб-приложение). Для каждого поля есть вполне определенные критерии. Например:
- обязательность
- формат значения
- диапазон допустимых символов
Остановились на следующем подходе: в рамках одного test case проверяется строго одно поле и один из критериев; все test cases независимы друг от друга.
На данный момент общее количество test case приблизилось к 50-ти (это для 5-ти полей). При этом еще есть неохваченные критерии.
Хотелось бы, собственно, услышать мнение опытных товарищей относительно выбранного подхода. А то, признаться, начинает смущать количество test case-ов. Может, где в консерватории подправить...
#2
Отправлено 21 февраля 2006 - 06:51
На мой взгляд, подход абсолютно правильный и количество тест - кейсов Вас не должно смущать... Их станет еще больше, когда Вы начнете описывать тест - кейсы для тестирования комбинаций полей :)
Два небольших примечания:
1. Если позволяет время, то писать необходимо все тест - кейсы (хотя в данном контексте "все" - это опять же субъективная "величина", зависящая от конкретной функциональность, ситуации и т.п.), а вот какой набор из написанных выполнять будет также зависеть от ряда параметров (например, время, критичность приложения, доступные ресурсы и т.д.). На данном этапе, если необходимо, можно применять различные методики по сокращению количества тест - кейсов (правда часть из них, например, метод ортогональных массивов, метод классов эквивалентности можно применять еще на этапе написания тестов).
2. Глубина тест - кейсов также может зависеть от вида проводимого тестирования (например, регрессионные тесты могут быть более поверхностные по сравнению с теми, которые предназначены для тестирования новой функциональности).
#3
Отправлено 21 февраля 2006 - 08:06
Попробуйте выделить возможные типы полей, например:
- числовое
- символьное
- дата
Напишем стандартные функции проверки, подзодящие для любого поля: формат, границы значений и т.д.. Далее все это оформим в библиотечные функции.
Переменные свойства контролла, типа обязательность, засунем в параметры вызова этих функций.
#4
Отправлено 21 февраля 2006 - 08:07
#5
Отправлено 21 февраля 2006 - 08:10
Удачи!!!
#6
Отправлено 21 февраля 2006 - 08:13
#7 Гость_drcoor_*
Отправлено 21 февраля 2006 - 10:05
15000??? Сколько же у Вас людей, что они это всё хотя бы прочитать успевают, потом понять и отработать?Привет, у нас на фирме на одно приложение может быть до 15 тыс. тесткейсов.
Или имеются ввиду скрипты?
Почему ПОСЛЕ? А первый цикл как?По моему мнению тесткейсы нужно писать хотя бы после одного цикла тестирования.
А как же регрессия и "на дым"?Думаю нет смысла тратить время на проверку того, что итак гарантированно работает.
Вообще, для самообразования интересно было бы посмотреть один из этих ста... Ну - если это не тайна коммерческая какая-то - что-то нейтральное :Я в день обычно пишу около 100 тест-кейсов.
#8
Отправлено 21 февраля 2006 - 10:45
Я в день обычно пишу около 100 тест-кейсов.
А может это очень маленькие тест-кейсы (в одну строчку например )
QUOTE(Romich @ Feb 21 2006, 10:10 AM)
По моему мнению тесткейсы нужно писать хотя бы после одного цикла тестирования.
Можно, но не желательно, обычно при наличии сопутсвующей документации, тест-кейсы пишутся еще на фазе дивелопмента апликейшена.
QUOTE(Romich @ Feb 21 2006, 10:10 AM)
Думаю нет смысла тратить время на проверку того, что итак гарантированно работает.
Ну это вообще из области фантастики, никто не может дать гарантию, на то, что в приложении, еще до тестирования, что-то гарантировано работает
#9
Отправлено 21 февраля 2006 - 11:21
Напишем стандартные функции проверки, подзодящие для любого поля: формат, границы значений и т.д.. Далее все это оформим в библиотечные функции.
Переменные свойства контролла, типа обязательность, засунем в параметры вызова этих функций.
Мы тоже думали о таком подходе... Для тестов решено использовать Canno WebTest. Так что если найдем приемлемый способ прикрутить - воспользуемся советом.
#10
Отправлено 21 февраля 2006 - 11:42
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 .,-()/'+:=?!\"%&*;<>
Все остальные (из национальных кодовых таблиц тоже) недопустимы.
Какие посоветуете подходы? "Скормить" всю это строчку сразу в одном тест-кейсе?
А как быть с недопустимыми? Их же вагон...
#11
Отправлено 21 февраля 2006 - 11:57
До кучи хотелось бы задать еще один чисто практический вопрос. Для полей ввода определены допустимые символы (набор UNOB, если кто слышал). Соответственно, надо проверить, что разрешенные символы проходят, а все остальные нет... Допустимые символы такие:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 .,-()/'+:=?!\"%&*;<>
Все остальные (из национальных кодовых таблиц тоже) недопустимы.
Какие посоветуете подходы? "Скормить" всю это строчку сразу в одном тест-кейсе?
А как быть с недопустимыми? Их же вагон...
Все допустимые символы можно свести в Reusable Matrix и из любых тест - кейсов на нее ссылаться.
Для недопустимых символов алгоритм следующий:
1. Делим их на эквивалентные классы
2. Выбираем лучших представителей из каждого класса эквивалентности (обычно это граничные значения классов)
3. Формируем Reusable Matrix с этими значениями
4. Из любых тест - кейсов ссылаемся на нее
#12
Отправлено 21 февраля 2006 - 20:52
Все допустимые символы можно свести в Reusable Matrix
А можно попросить линку на пояснения к Reusable Matrix? Что-то я нигде ничего внятного найти не могу...
#13
Отправлено 22 февраля 2006 - 08:26
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных