Подтвердить что ты не робот

Интеграционные системы тестирования для тестирования распределенной системы?

У меня есть распределенная система с компонентами, распределенными по нескольким ящикам. Они разговаривают друг с другом, используя tcp или multicast. Каждый компонент обменивает сообщения друг с другом - это в основном структуры данных, которые становятся сериализованными.

Какие интеграционные тестовые рамки мы используем для тестирования таких систем? Я знаком с рубином, поэтому что-то на рубине определенно поможет.

4b9b3361

ОТВЕТЫ

Ответ 1

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

  • Используя подход, основанный на ведении бизнеса, четко определите сценарии, которые вы хотите проверить.
  • Сделайте модульное тестирование (Нет integration), к процедурам, которые будут представлять выходы модуля.
  • Unit test процедуры, которые должны использовать входы от других модулей, но используя mocks. Тестирование логики другого модуля в текущем.
  • Выполните тесты дыма, этот тип теста гарантирует, что ваши модули могут взаимодействовать между собой (это тип интеграционного тестирования), Я думаю, что smoke test - это всего лишь интеграционное тестирование. Если вы думаете об этом: почему модуль должен заботиться о том, что делает другой модуль? (Давайте оставим каждую часть делать все, что захотим, но только заботимся о том, как с ними общаться).

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

Всегда помните о пирамиде тестирования, помните, что интеграционные тесты и сквозные тесты могут быть очень дорогими. Поэтому разумно выбирать, когда использовать их:

enter image description here

Я пришел из мира Java, это следующая дополнительная информация, которая, как я думаю, также связана с темой и может вас заинтересовать:

  • объект передачи данных, интересен
  • RMI vs EJB vs HTTP (Интересный комментарий о различиях между технологиями удаленных вызовов)
  • Spock a BDD framework для разработчиков Java. (Если вы прекрасно понимаете бизнес-правила, то тестирование проще)

Надеюсь, вы сочтете это полезным.

Ответ 2

Вы можете проверить Zopkio: https://github.com/linkedin/Zopkio. Его структура с открытым исходным кодом для функционального тестирования производительности распределенных систем.

Ответ 3

Вы можете использовать STAF/STAX, у него есть хорошие возможности/службы для распределенных тестовых сценариев, таких как Client-Server, SAN и т.д. Также есть еще одна платформа под названием Twister by Luxoft. Это также блестяще.

Ответ 4

Я дам свой ответ за то, что мы делаем с распределенной системой, написанной на Java. У нас есть несколько демонов linux, которые действительно являются обертками вокруг программ Java, которые общаются друг с другом в основном через базу данных. Поэтому они не отправляют сериализованные сообщения взад и вперед. Мы используем dbunit и spring -test для тестирования интеграции. С dbunit вы в основном загружаете данные, запускаете свой системный тест (SUT), а затем проверяете, что база данных находится в правильном состоянии. spring -test упрощает использование приложений spring для загрузки контекста приложения во время тестирования.

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