Как не надо проводить нагрузочное тестирование

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

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

Ошибка первая: Непонимание цели

И вот уже на этом шаге многие, даже опытные инженеры, ошибаются, просто пропуская его и торопясь выбрать/попробовать инструмент и "нагрузить" своё приложение.

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

Совет №1:

Прежде, чем мы приступим к нагрузочному тестированию, задайте себе вопрос - какая у нас цель? Зачем мы проводим нагрузочное тестирование?

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

Когда нужна тестовая документация?

Сегодня утром пересматривал ссылки с интересными заголовками на http://mmm.software-testing.ru/library/testing и наткнулся на статью.

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

На многих проектах (по опыту моих проектов и судя по рассказам QA инженеров и менеджеров из разных компаний и команд) тестовая документация либо не ведётся совсем, либо ведётся совершенно формально, "чтобы было", и даже чек листы не отражают реального положения дел и не включают в себя все тесты, которые на самом деле проверяют инженеры перед запуском в продакшн.

Другой пример - на проектах, где из тестовой документации есть только чек листы, каждый инженер трактует тест кейсы "по-своему" (потому что нет описания того что именно надо проверить, есть только название фичи), в результате чего нет полной уверенности, что тест кейс будет выполнен так, как себе представлял тест аналитик, который его написал (даже если тест аналитиком был один из инженеров этой же команды). И от версии к версии у нас нет повторяемости проводимых тестовых испытаний, как нет и видения что на самом деле было проверено.

Так какая тестовая документация нужна и почему?