Подскажите, пожалуйста, кто как тестирует системы состоящие из нескольких звеньев?
Как мы делаем:
После билда система полностью разворачивается на 5 серверах (где-то просто web сервисы, где-то Windows Service, где-то база, где-то просто время от времени запускаются exe'шники по scheduler task).
Если всё развернулось нормально, то запускаются тесты. Тесты разные, но меня сейчас больше интересуют функциональные тесты.
При запуске могут возникать проблемы, чаще всего они связаны с Windows Servic'ами и exe'шниками, которые должны запускаться по шедулеру.
Проблемы следующего характера:
1. Долгое ожидание: через webservice размещаем некую заявку, которую должен обработать windows service. Разместили и ждём пока на web-service не появится результат. Ждём следущим образом: запросили результат, если его нет, то sleep 10 секунд. Если сумарно прошло больше 60 секунд, то падаем с timeout. Обычно мы в тестовой среде у сервиса прописываем чтобы он новые заявки смотрел каждую секунду (на production 30 секунд). Если вдруг в сервисе какая-то ошибка, то мы это видим только тем, что тест упал по timeout.
Т.е. тут сразу две проблемы: не понятно что произошло и долго ждать если что-то с сервисом не так. У нас около 900 тестов из них какая-то часть вот так вот ждёт результата. Если вдруг кто-т ломает сервис, то время выполнения тестов стремится к часам.
2. Влияние компонентов друг на друга: Например, нужно простестировать "плохой" сценарий (как раз ситуацию когда сервис по каким-то причинам не может обработать заявку. Мы сечас из тестов стали останавливать сервис, чтобы проверить такую ситуацию. Но тесты запускаются на одной машине, а разворачивается, всё очень далеко, в другой сети, а порой в облаке, т.е. туда банально может не быть доступа чтобы можно было удалённо остановить сервис.
3. Как подмножество второго: если есть ферма сервисов обработчиков, то хочется знать, что все они работают, а не просто какой-то берет все задачи. Как тут протестировать — вообще не понятно.
А порой возникает, что тесты просто не успевают отследить изменения сущности, т.к. серввисы слишком быстро могут отработать и сущность уже два раза поменалась, а мы всё ждём предыдущее состояние, и тоже падаем по timeout, т.к. не дождались.
4. Подготовка тестовых данных. У нас они где-то в базу с помощью прямого доступа к БД заливаются, где-то с помощью обращения к web-сервисам. И тот и другой способ сильно зависят от того как разработчики в следующий раз поменяют структуру или интерфейс веб-сервисов. И получается, что вместо тестов мы занимаемся правкой тестовых данных, при этом не понятно не вносим ли при этом ошибки.
5. Не получается использовать только blackbox: у системы есть ряд публичных API которые видны из интернета конечным пользователям, сама система же внутри себя тоже работает с кучей внутренних web-servic'ов. И проблема, что с помощью публичных API невозможно получить полность состояние каких-то сущностей, чтобы отследить как она менялась в процессе теста. Приходится обращаться ко внутренним сервисам, что увеличивает риск завязывания на контракты, которые часто меняются.
Примерно такие проблемы, спрашиваем у разработчиков, они говорят, что не знают.
