Как автоматизировать интеграционное тестирование, которое требует нескольких компьютеров? - PullRequest
4 голосов
/ 02 марта 2010

Как вы автоматизируете интеграционное тестирование, которое требует 2 или более ПК (распределенное приложение)? Какова ваша стратегия проведения интеграционного тестирования (или тестирования производительности) в тех случаях, когда задействовано несколько машин?

Пример

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

Ответы [ 2 ]

1 голос
/ 02 марта 2010

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

Ниже приведены три способа решения этой проблемы в прошлом:

  1. использовать VMWare Server / ESX. В последнее время мы фактически создали образы виртуальных машин для сервера и клиентского компьютера с подключаемым вторым диском (диском данных). Затем мы собираем и тестируем наше программное обеспечение, перед тестом производительности запускаем виртуальную машину, затем внедряем код на диск данных. После этого мы развертываем на компьютерах набор тестовых сценариев и запускаем их (через Powershell). Это работает довольно хорошо, имеет хорошие возможности воспроизведения и позволяет нам предоставлять тестовые серверы другим командам / клиентам для их оценки. Недостатком является то, что он очень ресурсоемкий.
  2. Тестовые наборы для выделенного сервера и клиента - у нас было два разных репозитория исходного кода, один для сервера и один для клиента. Затем мы выполнили сборку, как описано выше, но по одному, развернув сервер (и протестировав его на старом клиенте), развернув клиент (и протестировав его на старом сервере), а затем развернув оба и протестировав комбинацию. Это работало довольно хорошо, но требовало некоторого ручного тестирования для определенных сценариев и могло стать громоздким, если бы нам нужно было проверить несколько изменений сервера или изменений клиента одновременно.
  3. Проверка только в отношении производства - мы обновляли только клиент ИЛИ сервер, а затем обновляли эту часть и проверяли ее в соответствии с текущими настройками производства. Недостатком этого, конечно, является то, что нам пришлось развертывать намного медленнее и вносить постепенные изменения в одну или другую систему, развертывать, тестировать и выпускать, а затем вносить изменения в другой компонент. Промыть и повторить.

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

0 голосов
/ 02 марта 2010

Это зависит от вашей настройки. Например, мне нужно было протестировать группу веб-сервисов, которые моя команда создала / изменила. Во время теста мы развернули приложение на одной машине в качестве производителя и использовали SoapUI для генерации нескольких тысяч транзакций через множество потоков (от 1 до 100 потоков, насколько я помню). Таким образом, мы гарантировали ответ и SLA (соглашение об уровне обслуживания).

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