Без тестировщиков: тестирование интерфейса на основе документации

   На SQA Days 12 мы обсуждали "будущее тестирования". Каким оно будет через десять лет? Умные роботы, которые сами ищут баги, а лучше и сразу их исправляют?


   И вот не так давно мы начали работу над новым проектом, и для документирования API на этом проекте разработчики воспользовались сервисом apiary.

   Обычно мы пишем тесты для API на Python, запуская nosetests и получаем отчёт в Jenkins CI. Если проект активно развивается, то API постоянно расширяется и изменяется, тесты постоянно необходимо поддерживать в актуальном состоянии.
   То есть мы каждый день начинаем с проверки последних запусков автоматизированных тестов и общения с разработчиком, который подсказывает нам, как мы можем протестировать новые функции, которые он добавил вчера.
   Казалось бы, как можно иначе?

Yandex Tank для нагрузочного тестирования API интерфейсов

"Каждую печеньку заворачивай в отдельные скобки"

Из разговоров QA команды во время

написания нагрузочных сценариев

  Я занимаюсь нагрузочным тестированием не каждый день, но когда я делаю это, я использую Яндекс Танк.
  Существует множество других инструментов для нагрузочного тестирования (давайте сразу определим область, для которой я это использую - это нагрузочное тестирование API интерфейсов). Например, есть ещё всем известный JMeter, при упоминании которого у многих лицо непроизвольно становится грустным (писать на нём тестовые сценарии и отлаживать их "ещё то удовольствие") или например FunkLoad (для любителей писать тесты на Python). Есть очень много других, но я выбрал ярких представителей своих "классов" инструментов для нагрузочного тестирования.
  Что же не так и почему не JMeter? Мне вот совсем не удобно писать на нём тесты. Если мне необходимо смоделировать небольшую нагрузку (до 500 пользователей), то я лучше воспользуюсь FunkLoad и напишу тесты на Python быстро и легко, особенно, если у тестируемого приложения уже есть готовый Python-client, что не редкость.
  Но и JMeter и FunkLoad имеют один существенный недостаток, который так сразу и не замечаешь, особенно, если тестировать производительность приходится нечасто или впервые, а глубокого анализа результатов никто и не требует.
  А вот когда моделируешь серьезные нагрузки в десятки и сотни тысяч запросов в секунду, сразу понимаешь всё. Казалось бы - запустил тот же тест, просто указал другое число параллельно работающих пользователей. В результате видишь что-то странное - график скачет, дисперсия вне всякого сомнения на столько большая, что достоверность результатов под вопросом. И начинаешь сомневаться.