Сообщений в теме: 12

[reb]

Привет!

Пишем test cases валидации полей ввода в пользовательском интерфейсе (веб-приложение). Для каждого поля есть вполне определенные критерии. Например:

- обязательность
- формат значения
- диапазон допустимых символов

Остановились на следующем подходе: в рамках одного test case проверяется строго одно поле и один из критериев; все test cases независимы друг от друга.

На данный момент общее количество test case приблизилось к 50-ти (это для 5-ти полей). При этом еще есть неохваченные критерии.

Хотелось бы, собственно, услышать мнение опытных товарищей относительно выбранного подхода. А то, признаться, начинает смущать количество test case-ов. Может, где в консерватории подправить...

[van]

Здравствуйте!

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

Два небольших примечания:
1. Если позволяет время, то писать необходимо все тест - кейсы (хотя в данном контексте "все" - это опять же субъективная "величина", зависящая от конкретной функциональность, ситуации и т.п.), а вот какой набор из написанных выполнять будет также зависеть от ряда параметров (например, время, критичность приложения, доступные ресурсы и т.д.). На данном этапе, если необходимо, можно применять различные методики по сокращению количества тест - кейсов (правда часть из них, например, метод ортогональных массивов, метод классов эквивалентности можно применять еще на этапе написания тестов).

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

[serega]

Предложу свой вариант

Попробуйте выделить возможные типы полей, например:

- числовое
- символьное
- дата

Напишем стандартные функции проверки, подзодящие для любого поля: формат, границы значений и т.д.. Далее все это оформим в библиотечные функции.

Переменные свойства контролла, типа обязательность, засунем в параметры вызова этих функций.

[serega]

"Далее все это оформим в библиотечные функции" = напишем базовые тестовые примеры, на которые будем ссылать при расширении проверок в других примерах

[Romich]

Привет, у нас на фирме на одно приложение может быть до 15 тыс. тесткейсов. По моему мнению тесткейсы нужно писать хотя бы после одного цикла тестирования. Думаю нет смысла тратить время на проверку того, что итак гарантированно работает. А вот найденные баги должны быть проверены при прохождении тест-кейсов. И старайтесь однообразней все оформлять (чтобы легче было копировать). Я в день обычно пишу около 100 тест-кейсов.
Удачи!!!

[Romich]

Если вы не асс своего дела, то не нужно все усложнять. Это и так утомительно - проходить тест-кейсы. Может это и не правильно, чем проще - тем лучше.

[Bishop_]

QUOTE(Romich @ Feb 21 2006, 10:10 AM)
Я в день обычно пишу около 100 тест-кейсов.

А может это очень маленькие тест-кейсы (в одну строчку например )

QUOTE(Romich @ Feb 21 2006, 10:10 AM)
По моему мнению тесткейсы нужно писать хотя бы после одного цикла тестирования.

Можно, но не желательно, обычно при наличии сопутсвующей документации, тест-кейсы пишутся еще на фазе дивелопмента апликейшена.

QUOTE(Romich @ Feb 21 2006, 10:10 AM)
Думаю нет смысла тратить время на проверку того, что итак гарантированно работает.

Ну это вообще из области фантастики, никто не может дать гарантию, на то, что в приложении, еще до тестирования, что-то гарантировано работает

[reb]

Спасибо всем за ответы и поддержку :-)

Напишем стандартные функции проверки, подзодящие для любого поля: формат, границы значений и т.д.. Далее все это оформим в библиотечные функции.

Переменные свойства контролла, типа обязательность, засунем в параметры вызова этих функций.

Мы тоже думали о таком подходе... Для тестов решено использовать Canno WebTest. Так что если найдем приемлемый способ прикрутить - воспользуемся советом.

[reb]

До кучи хотелось бы задать еще один чисто практический вопрос. Для полей ввода определены допустимые символы (набор UNOB, если кто слышал). Соответственно, надо проверить, что разрешенные символы проходят, а все остальные нет... Допустимые символы такие:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 .,-()/'+:=?!\"%&*;<>

Все остальные (из национальных кодовых таблиц тоже) недопустимы.

Какие посоветуете подходы? "Скормить" всю это строчку сразу в одном тест-кейсе?

А как быть с недопустимыми? Их же вагон...

[van]

До кучи хотелось бы задать еще один чисто практический вопрос. Для полей ввода определены допустимые символы (набор UNOB, если кто слышал). Соответственно, надо проверить, что разрешенные символы проходят, а все остальные нет... Допустимые символы такие:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 .,-()/'+:=?!\"%&*;<>

Все остальные (из национальных кодовых таблиц тоже) недопустимы.

Какие посоветуете подходы? "Скормить" всю это строчку сразу в одном тест-кейсе?

А как быть с недопустимыми? Их же вагон...

Все допустимые символы можно свести в Reusable Matrix и из любых тест - кейсов на нее ссылаться.
Для недопустимых символов алгоритм следующий:
1. Делим их на эквивалентные классы
2. Выбираем лучших представителей из каждого класса эквивалентности (обычно это граничные значения классов)
3. Формируем Reusable Matrix с этими значениями
4. Из любых тест - кейсов ссылаемся на нее

[reb]

Все допустимые символы можно свести в Reusable Matrix

А можно попросить линку на пояснения к Reusable Matrix? Что-то я нигде ничего внятного найти не могу...

[van]

Вот в этой книжке можно найти несколько примеров:
http://www.books.ru/...