Должен ли я при функциональном тестировании сравнивать все табличные данные, отображаемые в браузере, с данными, поступающими из базы данных?

Question

Я работаю над планом тестирования для веб-сайта, где некоторые тесты проходят по следующему пути:

1. Введите запрошенный URI и получите данные, отображаемые внутри некоторой таблицы (20 строк на странице).
2. Выполните запрос к базе данных, чтобы получить данные, которые должны быть представлены в этой таблице.
3. Сравните 2 данные строка за строкой, они должны совпадать.

Это правильный способ проведения функционального тестирования?Если этот запрос был Ajax-запросом, каким также будет ответ?Будет ли ответ отличаться при интеграционном тестировании?

У меня есть какая-то причина, которая заставляет меня верить, что это как-то неправильно....все еще нужно ваше мнение, ребята!

Answer 1

Да, это мог бы быть продуктивный тест.Либо у вас есть фиксированный набор данных, либо его нет.

Если у вас есть фиксированный набор данных, это намного проще протестировать, потому что все, что вы делаете, - это сравниваете с фиксированным результатом.

Если у вас нет фиксированного набора данных, то вам необходимо продублировать бизнес-логику, эффективно дублируя работу, уже проделанную разработчиком.Тогда у вас есть два набора логики для поддержания.

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

Чтобы ответить на ваш вопрос, если ваша бизнес-логика в запросе проста, то вы можете получить тест очень легко.Однако ценность, которую приносит тест, невелика, потому что вы тестируете не так уж много.

Если бизнес-логика сложная, вы получаете больше пользы от тестирования, но в долгосрочной перспективе ее будет сложнее поддерживать.

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

Answer 2

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

Не понимаю, как то, что это Ajax или нет, имеет какое-то отношение к тому, чтобы сделать ответ другим.

Answer 3

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

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

Это:

1. Загружать известные данные (предпочтительно через само приложение)
2. Загрузите запрошенный URI
3. Убедитесь, что отображаемые данные соответствуют вашим известным данным

Answer 4

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

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

Сказав это, если бы у меня была высокая уверенность в достоверности данных БД и если бы логика между запросом БД и отображением веб-страницы была очень маленькой и малорисковой, я бы, вероятно, не стал заморачиваться с макетом и позволил бы интеграционному тестированию охватить и функциональность.Я не уверен, что тестирование функциональности и интеграции по отдельности было бы большим выигрышем в качестве в этом случае, и, вероятно, есть вещи получше, которые вы могли бы сделать за доступное время тестирования.Если вокруг этих данных много логики, вам, вероятно, следует протестировать интеграцию отдельно от функциональности.Дополнительное интеграционное тестирование, вероятно, будет включать в себя такие вопросы, как "Что, если невозможно получить доступ к базе данных?" и "Что, если база данных работает медленно?".

Хотя этот метод будет работать с Ajax, убедитесь, что ваши инструменты тестирования будут работать с Ajax.В частности, подумайте о том, как вы будете фиксировать результаты запроса к базе данных и как вы будете собирать результаты, отображаемые на веб-странице.

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