Я ненавижу такие расплывчатые слова, как "соответствующим образом" в "ожидаемых значениях". «Соответственно» — это просто пример «ядовитого слова» для тестирования, и если его не устранить, этот «подход» может получить широкое распространение, эффективно убивая тестирование в целом. Для тестировщика-человека этого может быть "достаточно", но такие "тесткейсы" приемлемы только при первых попытках исследовательского "дымового теста".
Каким бы ни был воспроизводимый, систематический и автоматизированный, каждый тестовый пример должен быть конкретным. (а не просто "должен"... предполагать, что мягкость "будет" может быть разрешена? Вместо этого я используйте настоящее время "должно быть" или даже лучше строгое "есть", как утверждение для подтверждения/опровержения.) И это правило абсолютно, когда дело доходит до автоматизации.
То, что сделал ваш тестер, было скорее «областью тестирования», «шаблоном сценария», а не реальным тестовым набором: поскольку может быть получено так много возможных результатов тестирования... Вы были конкретны в своем сценарии: это был очень специфическим реальным «тестовым случаем». Можно автоматизировать ваш тестовый пример, приятно: вы можете делегировать его на машину и автоматически оценивать его так часто, как вам нужно. (с бонусом автоматического отчета с сервера непрерывной интеграции)
Но "пустой шаблон тестового сценария"? Это также имеет некоторую ценность: это «шаблон сценария», пустой скелет, подготовленный для заполнения данными: поэтому я люблю называть эти ситуации «DDT»: «Тестирование на основе данных».
Представьте веб-форму, которую нужно протестировать, с проверкой ее 10 входных данных, с перекрестной проверкой... И с кнопкой отправки. Для каждого входа может быть 10 тестовых случаев:
- пустой;
- с обуглившимся, но все равно слишком коротким;
- слишком длинно для сервера, но разрешено внутри формы для копирования-вставки и дальнейших правок;
- с недопустимыми символами...
Подход, который я рекомендую, состоит в том, чтобы подготовить набор данных для прохождения: даже для их генерации (из БД или даже случайным образом), все, что вы можете предсказать, должно пройти тест, «счастливый сценарий». Держите данные в стороне, как шаблон данных, и используйте их для инициализации формы, для ее заполнения, а затем для разбивки некоторого единственного значения: Создайте тестовые примеры «на провал». Сделайте это, т.е. 10 раз для каждого отдельного входа, для каждого из 10 входов (100 тестовых случаев даже до попытки перекрестных правил) ... и затем, после 100 раз отказа формы сервером, заполните форма по проходным данным, не искажая их, чтобы форма могла быть принята окончательно. (принят статус отправки изменений в серверном приложении, поэтому нужно идти последним, чтобы проверить все 101 случай в одном и том же состоянии приложения)
Чтобы провести тест таким образом, вам нужны две вещи:
- пустой шаблон сценария,
- and a table of 100 rows of data:
- 10 columns of input data: with only one value manipulated, as passing row by row down the table (i.e. ever heard about grey-code?),
- возможно, сохранение истории наследования в описании строки, откуда получена строка и как, через какое управляемое значение.
- Также 11-й столбец, заполненный столбец (столбцы) «ожидаемый результат»: ожидаемый статус «пройдено/не пройдено», сообщение об ожидаемой ошибке/проверке, ссылка на требования для отслеживания покрытия тестами. (т.е. когда-нибудь видели FitNesse?)
- И, возможно, также столбец для реального обнаруженного результата при выполнении теста, чтобы отслеживать историю тестового примера с одной строкой. (так уже упоминался сервер CI)
Чтобы совместить «пустой каркас сценария» с одной стороны и «таблицу данных для проведения теста» с другой стороны, действительно нужен какой-то механизм. И ваши данные должны быть импортированы. Таким образом, вы можете подготовить строки в Excel, которые теоретически также могут быть импортированы, но для облегчения жизни я рекомендую либо CSV, свойства, XML, либо просто любой машиночитаемый формат, текстовый формат.
person
Franta
schedule
10.07.2017
