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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

То есть:

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

Answer 4

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

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

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

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

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