Давайте вернемся к первоначальной постановке задачи.
Давайте возьмем, например, WYSWYG editor и попробуем для него определить необходимый и достаточный набор кейсов скажем для Smoke Testing.
Давайте, в самом деле, возьмём не неизвестный WYSIWIG-редактор, а редактор этого форума. Вот в котором я сейчас пишу сообщение.
Что считать для него Smoke, а что уже не-Smoke -- думаю, никто не сможет чётко ответить. Это понятие скорее управленческое, обозначающее разные этапы процесса тестирования. Использовать его в технических целях совершенно невозможно.
Поэтому поищем что-нибудь более конкретное.
Что можно делать в этом редакторе?
Рассмотрим только часть функциональности, не связанную с отправкой данных на сервер (и ее не так уж мало).
(1) Можно в окне ввода писать текст.
(2) Вверху есть панель, на ней несколько кнопок, вставляющих в окно ввода некоторый текст.
(3) Слева вверху есть переключатель режимов, который изменяет набор кнопок на верхней панели.
(3) Слева есть кнопки, вставляющие смайлики.
(4) Слева под смайликами есть кнопка для проверки длины сообщения.
Это SRS, первый уровень детализации. Теперь расписываем каждый пункт более детально. Скажем, второй:
(2.1) Кнопка B показывает диалоговое окно с полем ввода и вставляет введенный текст в редактор, окружая его текст тегами B
(2.2) Кнопка I ...
(2.3) Кнопка U ...
(2.4) Меню выбора шрифта ...
...
(2.10) Кнопка CODE ...
После этого отмечаем, что некоторые кнопки, вставляя текст, соблюдают баланс тегов, а некоторые те соблюдают, вставляя только открывающий тег. Поэтому дописываем в SRS соответствующие требования:
(2.1) Кнопка B показывает диалоговое окно с полем ввода и вставляет введенный текст в редактор, окружая его текст тегами B, при этом баланс тегов не изменяется.
...
(2.4) Меню выбора шрифта ..., при этом баланс тегов увеличивается на единицу.
...
(2.10) Кнопка CODE ..., при этом баланс тегов не изменяется.
Теперь про последнюю кнопку (которая, в отличие от остальных почему-то оформлена как ссылка):
(2.11) Кнопка (ссылка) "Закрыть все тэги" вставляет закрывающие теги для всех незакрытых открывающих тегов, при этом баланс тегов становится равным нулю.
И ещё одно требование:
(2.12) В поле "Количество открытых тэгов" показывается текущий баланс тегов, значение этого поля должно меняться при изменении баланса тегов.
Детализации требований пока достаточно. Теперь обратимся к тестированию.
Сначала пишем план. Что будем тестировать, а что не будем.
Тестируем:
-- верхнюю панель кнопок при нажатии на них мышкой или при использовании клавиатурных сочетаний (keyboard shortcuts)
Не тестируем:
-- все остальные панели
-- переключатель режимов верхней панели
-- функциональность, связанную с отправкой данных на сервер
-- нефункциональные требования, в том числе юзабилити (помните ещё про кнопку, которая почему-то ссылка? мы это не тестируем!)
После того, как "стены" поставлены, можно посчитать, что попало внутрь этих стен. Если плана тестирования нет -- вообще ничего нельзя посчитать, потому что нет никаких границ, тесты можно создавать до бесконечности, тут STRAY совершенно прав.
Давайте считать. Для каждой кнопки нужно несколько тестов -- будем вводить разные данные. Чтобы получить грубую оценку количества тестов, оценим количество тестовых данных для одной кнопки и умножим на количество кнопок.
Например, для кнопки B -- "привет", "
привет", "
привет", "привет", "", "!@#$%%^&*(){}[]". Пока достаточно. Поулчается 6. Кнопок 10. В итоге должно получиться порядка 60 тестов для вставки текста.
Для клавиатурых сочетаний достаточно убедиться, что они работают, поэтому добавляем по одному тесту, получается ещё +10, итого 70.
Более внимательно изучив требования к отдельным кнопкам можно эту оценку уточнить. Например, кнопка для вставки ссылки имеет два поля ввода, а не одно. Зато кнопки изменения шрифта, размера и цвета вообще не имеют параметров. Если нужна более точная оценка -- нужно это учесть.
Ну, а дальше начинаем делать тесты. Не забываем в каждом тесте сделать проверку того, что правильно считается баланс тегов, в том числе при вводе текста, содержащего теги.
