Перейти к содержимому

Python для начинающих
онлайн, начало 23 сентября
Школа тест-менеджеров v. 2.0
онлайн, начало 2 сентября
Docker: инструменты тестировщика
онлайн, начало 23 сентября
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 21 сентября
Фотография

Проверка в БД или интерфейсе

БД база данных сообщение интеграция

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 4

#1 lingva

lingva

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • Город:Москва

Отправлено 19 октября 2014 - 21:08

Стоит задача автоматизировать некий бизнес-процесс: интеграционное сообщение должно прийти в систему, лечь в базу и отобразиться в web-интерфейсе.

Понятное дело, обязательно проверим в интерфейсе (в сравнении с тем, что было в сообщении), но стоит ли осуществлять тестирование на уровне БД и проверять там или это лишнее?

Вопрос в том, как корректнее проверить, чтоб ничего не упустить?


  • 0

#2 wret

wret

    Активный участник

  • Members
  • PipPip
  • 124 сообщений
  • Город:Москва

Отправлено 20 октября 2014 - 04:47

Проверять в UI следует в любом случае, могу быть проблемы приведения типов данных, кодировки, форматирования, ...

 

Проверять ли в БД? Да, очень желательно, но немного зависит от контекста

Тут все может упереться в разработку класса работы с БД (трудозатраты). Если он уже существует и стоит всего лишь подставить верный запрос - проверяйте

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

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


  • 1

#3 lingva

lingva

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • Город:Москва

Отправлено 20 октября 2014 - 18:31

Проверять в UI следует в любом случае, могу быть проблемы приведения типов данных, кодировки, форматирования, ...

 

Проверять ли в БД? Да, очень желательно, но немного зависит от контекста

Тут все может упереться в разработку класса работы с БД (трудозатраты). Если он уже существует и стоит всего лишь подставить верный запрос - проверяйте

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

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

Огромное спасибо за совет и оперативный отклик. Приму к сведению.


  • 0

#4 Snap

Snap

    Специалист

  • Members
  • PipPipPipPipPip
  • 921 сообщений
  • ФИО:Роман
  • Город:Москва


Отправлено 21 октября 2014 - 08:07

Зависит от требований  :biggrin:


  • 1

http://starbugss.blogspot.ru - "Звездные баги", мой блог.


#5 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 21 октября 2014 - 09:27

Я бы разбил это на две фичи (два теста):

  1. При выполнении некоторых действий приходит сообщение.
  2. Cообщение отображается в интерфейсе.

Проверять в БД лучше, если:

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

Проверять только в интерфейсе, если:

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

Может быть я еще что-то упустил.

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


  • 1


Программирование на С# для тестировщиков
онлайн
Автоматизатор мобильных приложений
онлайн
Selenium WebDriver: полное руководство
онлайн
Программирование на Python для тестировщиков
онлайн




Темы с аналогичным тегами БД, база, данных, сообщение, интеграция

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале