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

Фотография

Организация тестирования разделенного бэкэнда и фронтэнда


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

#1 Dison

Dison

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

  • Members
  • Pip
  • 17 сообщений
  • ФИО:Diana Son

Отправлено 06 июня 2019 - 07:42

Помогите разобраться. 
 
Делаем систему для гос.учереждения. Разработку фронтэнд и бэкэнд было решено разделить и разработка ведётся в разных ИТ компаниях. Нам достался бэкэнд, а мне задание организовать его тестирование. Архитектура миркосервисная и общается через RestAPI. Для теститования я составила план, где прописала, что буду тестировать энд пойнты и использовать Swagger. Теперь значит со мной связался тестировщик из компании где делают фронтэнд с целью чтобы мы синхронизировали тестирование, чтобы не осталось ни одного места не покрытого тестами. С микросервисами сталкиваюсь впервые и может я что-то не допоняла, но зачем нам общее тестирование? И если оно нужно, то объясните вкратце как это сделать?

  • 0

#2 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 06 июня 2019 - 08:17

общее тестирование нужно чтобы удостовериться что фронт работает с бэком

 

например Вы протестировали что энд-пойнт принимает 2 параметра

а тестировщик фронта протестировал что их фронт посылает 3 параметра на замоканный бэк

 

или Вы протестировали что энд-пойнт изменения статуса работает правильно

а на фронте вообще забыли ту кнопку для изменения статуса добавить

 

в итоге "всё у всех работает", но когда фронт и бэк поставят вместе - работать не будет

 

 

"как сделать общее тестирование" - запустить бэк и фронт вместе, тестировать по требованиям к системе


  • 0

#3 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 06 июня 2019 - 08:26

Какой интересный кейс. А что у вас прописано в ПМИ?


  • 0

#4 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 06 июня 2019 - 08:28

 

 

Какой интересный кейс. А что у вас прописано в ПМИ?

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

 

а ПМИ и необязательно для всех


  • 0

#5 Dison

Dison

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

  • Members
  • Pip
  • 17 сообщений
  • ФИО:Diana Son

Отправлено 06 июня 2019 - 08:33

общее тестирование нужно чтобы удостовериться что фронт работает с бэком

 

например Вы протестировали что энд-пойнт принимает 2 параметра

а тестировщик фронта протестировал что их фронт посылает 3 параметра на замоканный бэк

 

или Вы протестировали что энд-пойнт изменения статуса работает правильно

а на фронте вообще забыли ту кнопку для изменения статуса добавить

 

в итоге "всё у всех работает", но когда фронт и бэк поставят вместе - работать не будет

 

Так, ну если исходить из примера про кнопку, и чтобы такого не произошло, тогда нам надо как-то тест кейсами обмениваться? 


  • 0

#6 Dison

Dison

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

  • Members
  • Pip
  • 17 сообщений
  • ФИО:Diana Son

Отправлено 06 июня 2019 - 08:38

Какой интересный кейс. А что у вас прописано в ПМИ?

у нас его нет.


  • 0

#7 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 06 июня 2019 - 08:49

 

 

 

Какой интересный кейс. А что у вас прописано в ПМИ?

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

 

а ПМИ и необязательно для всех

Госучереждение и без ПМИ? Даже не знаю кто в этой ситуации больший идиот заказчик или подрядчик.
Мой вопрос о том, что конкретно заказали и кто ответственен за интеграцию.
Если вы покупаете отдельно кузов и отдельно двигатель, то собрать их в автомобиль - ваша забота. И если одно не лезет в другое - ваша проблема. Не говоря уже о таких мелочах, что юридически ваш конструктор никогда не станет автомобилем, на учет вы его не поставите и ездить сможете только вокруг своего гаража.


  • 0

#8 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 06 июня 2019 - 09:30

 

Какой интересный кейс. А что у вас прописано в ПМИ?

у нас его нет.

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


  • 0

#9 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 06 июня 2019 - 09:39

Да, интересная продажа слона по частям...))
Вам нужна общая интеграция. Без этого две части программы могут работать раздельно, а вместе вряд ли)
  • 0

#10 Dison

Dison

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

  • Members
  • Pip
  • 17 сообщений
  • ФИО:Diana Son

Отправлено 06 июня 2019 - 10:15

Да, интересная продажа слона по частям...))
Вам нужна общая интеграция. Без этого две части программы могут работать раздельно, а вместе вряд ли)

 

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

  • 0

#11 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 06 июня 2019 - 10:53

 

Да, интересная продажа слона по частям...))
Вам нужна общая интеграция. Без этого две части программы могут работать раздельно, а вместе вряд ли)

 

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

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


  • 0


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

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