Тестирование клиентов для общедоступных веб-сервисов - PullRequest
0 голосов
/ 09 февраля 2010

Каковы подходы к тестированию пользовательских клиентов для общедоступных веб-сервисов?

Сегодня существует множество онлайн-сервисов, которые предоставляют API. Существует множество маленьких приложений, использующих эти API. Примеры: настольные / мобильные клиенты для социальных сетей и блогов, центры хранения и обработки документов, облачные базы данных, потоки данных в реальном времени, данные ГИС и т. Д.

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

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

1 Ответ

1 голос
/ 09 февраля 2010

Будьте очень ясно, что вы тестируете. Тестируете ли вы, что ваш код делает то, что должен делать, когда получает ответы от службы? И нормально, и необычно? Затем смейтесь над сервисом, чтобы вы могли легко воспользоваться этими путями.

Да, я разработал бы повторяемые тесты и запускал бы их в какой-то среде, которая позволяет запускать их автоматически, в идеале как часть сборки / фиксации.

А как же тестировать сам сервис? Некоторые тесты возникают только после проверки вашего решения. Например тяжелый груз. Что ж, хотя важно не быть антисоциальным и не стоит насытить государственную службу, если существует опубликованный SLA, я думаю, что это разумно проверить. Так что если ожидается, что ваше приложение будет отправлять n запросов в секунду, то, конечно, мы должны протестировать хотя бы это. Тестирование нашего общего решения на требуемую пропускную способность.

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

...