При функциональном тестировании следует ли сравнивать все табличные данные, отображаемые в браузере, с данными из БД? - PullRequest
1 голос
/ 15 декабря 2009

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

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

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

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

Ответы [ 4 ]

1 голос
/ 30 ноября 2010

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

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

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

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

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

1 голос
/ 18 декабря 2009

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

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

То есть:

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

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

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

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

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

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

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

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

1 голос
/ 15 декабря 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...