Home

Автор: Оливер Эрлевайн (Oliver Erlewein)

Оригинал статьи: http://hellotestworld.com/2016/02/23/every-tester-is-a-performance-tester/

Перевод: Ольга Алифанова

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

Больше всего тестировщиков производительности бесит, когда обнаруженные в тестируемом коде проблемы можно было заметить и на глаз (ну ладно, больше всего их бесит, когда функционал не работает, но не суть). Вот где в игру должны вступить вы как их коллега.

Сколько раз вы барабанили пальцами по столу, ожидая, пока колесо загрузки в браузере наконец-то выдаст вам что-то вменяемое? Или обрабатывали что-то сразу пакетом, и успевали выпить чашку кофе в процессе? Обычная реакция тестировщика - пожать плечами и сказать "Да это просто такое окружение. В конце концов, это тест-стенд". Как вариант - "пусть у тестировщиков производительности об этом голова болит".

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

Приступим. Почему вас это вообще должно волновать?

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

Почему это важно для тестировщиков производительности?

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

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

Проще говоря, тестирование производительности останавливается, как только обнаружен дефект. Затем дефект анализируется, исправляется, и все начинается сначала. И так летят часы и дни. Следовательно, каждый баг, который можно отловить заранее, напрямую влияет на тестирование производительности, а также на сроки и бюджет проекта.

Это еще более очевидно, если команда работает по гибкой методологии (например, Agile, Scrum, XP). Прямая и быстрая обратная связь, выданная разработчику - в этом случае ваша главная задача. К моменту, когда тестировщик производительности доберется до приложения, команда уже уйдет вперед. Может, нужные люди уже и вовсе недоступны. В результате устранение проблем становится куда сложнее и дороже. Потенциально это серьезно повлияет на ваш бэклог и даты релизов.

Надеюсь, мне удалось вас замотивировать? Супер! Но как же определить, что что-то медленно работает? Как быть уверенным, баг это или не баг? Что можно сделать, чтобы начать поиск багов производительности?

Откуда берутся проблемы производительности?

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

Нагрузочное и стресс-тестирование

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

Сеть / инфраструктура

Еще одна штука, с которой справятся только тестировщики производительности. Когда нагрузка на систему повышается, проблемы могут возникнуть у инфраструктуры. Сети и серверы тоже имеют пределы по нагрузке. Если вы начали проверять на прочность физические контакты, это напрямую повлияет на производительность. Тестовое системное окружение, скорее всего, будет сильно меньшим по размеру, и инфраструктурные проблемы не будут значимыми для тестирования производительности.

Архитектура / дизайн

Очень сложная область. К моменту, когда к проекту подключаются тестировщики безопасности, она обычно вылизана и причесана. Это совершенно не означает, что в ней нет проблем! Баги архитектуры могут погубить проект. Они могут стать именно той соломинкой, которая сломает спину верблюду, и все придется начинать с самого начала (поверьте, эти случаи - не редкость)! Если проект близится к концу - то баги архитектуры его приговорят. Речь идет об исправлениях, которые могут потенциально стоить миллионы.

И да, это именно то, что можете обнаружить вы - если вы, конечно, пришли на проект не вчера.

Возьмите калькулятор, дизайн-документ, что-нибудь описывающее базовую функциональность, и уединитесь с ними в спокойной обстановке на пару часов. Посмотрите на высокоуровневые технические характеристики компонентов того решения, которое поддерживает продукт. Подумайте над его использованием, трафиком, нагрузкой на базу данных при одной транзакции, стратегией балансировки нагрузки, спецификацией файервола, а затем воспользуйтесь калькулятором. Оцените результат. Проблемы, как правило, видны тут за версту. Перепроверяете свои расчеты несколько раз, чтобы убедиться, не добавили ли вы где пару лишних нулей? Вы нашли баг. Более простой случай - вышеперечисленные (или похожие на них) метрики просто недоступны. Это означает, что над производительностью вообще никто не задумывался.

Я регулярно делаю что-то подобное на новых проектах. Это дешево и очень эффективно. Все, что вы найдете - скорее всего, критические баги.

Например, вы можете найти что-то подобное:

• Попытка протащить 125 мегабайт через соединение в 100 мегабит за одну секунду.
• Места, выделенного под базу данных, хватит на пару недель использования на проде.
• Режим мониторинга не подсвечивает серьезные проблемы.
• Балансировщик нагрузки и файервол не настроены под одинаковую пропускаемость.
• Неправильно предсказана частота использования (обычно она слишком большая, можно сэкономить!)
• Перемудрили с дизайном. Теоретически применен весь передовой опыт. Практически - ужасная каша, которая никогда не взлетит. Например - слишком многоуровневая структура, повышающая пинг, или плохой нежизнеспособный дизайн.
• Предположения о времени простоя для текущих задач не соответствуют истине - простоя вообще нет.
• Потенциальные узкие места, где все может пойти прахом, или недостаточное вертикальное масштабирование.
• Учитывались ли рекомендации производителя по настройке оборудования перед/после деплоя продукта?

Такой анализ требует некоторых знаний и навыков, и я не думаю, что все осилят размышления над любой из вышеперечисленных задачек, но даже если вы справитесь с одной - это уже здорово. Вы можете просто начать задавать эти "дурацкие вопросы тестировщиков" - проверяли ли емкость жесткого диска и ее соответствие необходимым размерам базы данных для прода? Если это проверено, вопрос, конечно, всех раздражает - "Ну естественно, что за вопрос?" Если нет - они скажут ровным счетом то же самое, но вы увидите, как вытянутся их лица :-)

Окружение

Ваше окружение менее мощное, чем требует спецификация. Естественно, все будет работать медленнее! Однако и тут можно что-нибудь накопать. Производительность, как правило, штука относительная (не относительно разных окружений, а относительная в пределах одного окружения). Например, авторизация на сайте занимает 2 минуты, но когда вы уже вошли в систему, любые действия занимают доли секунд - что и близко не похоже на время, потраченное на авторизацию. Функциональность логина уникальна, и, возможно, для таких тормозов есть причина, но он не соответствует другим областям приложения по производительности. Люди непременно это заметят и пожалуются на авторизацию. Нелишним будет посоветовать разработчику взглянуть на логин еще раз - может быть, что-то пошло не так, или можно что-нибудь подкрутить, чтобы такая ситуация не возникала.

Уровни приложения

Даже если вы функциональный или неспециализированный тестировщик, познакомьтесь с тестируемой системой. Запросите доступ к статистике и логам сервера и приложения. Если при беглом просмотре вы видите замедления в графике потребления оперативной памяти, вы можете вычислить виновника торжества. Виноват веб-сервер? Приложение? База данных? Опять же, чем раньше вы обратите внимание на это - тем лучше, и это непременно заинтересует ваших коллег.

Код

Нет, я не предлагаю вам продираться через код, который в вас метнули разработчики, или который вы вытащили из GitHub. Я подразумевал вещи попроще. Если ваш сайт кажется вам медленным, посмотрите в HTML-код. Как вариант (и это даже лучше) - вызовите консоль разработчика в браузере и посмотрете, как загружается ваша страничка, и что с ней происходит (раскрою эту тему чуть ниже).

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

Если ваш драгоценный разработчик - джуниор или недавний выпускник, убедитесь, что код прошел код-ревью. Им не только не хватает опыта - они еще склонны к использованию "передовых практик", что зачастую выходит им боком, потому что в реальной жизни эти практики не масштабируемы. Большинство опытных разработчиков инстинктивно подмечают такие вещи. Зачастую код-ревью - это все, что вам нужно.

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

Другое

Все проекты уникальны, и невозможно учесть все возможные моменты. В свободное время (например, пока вы ждете - снова - нового билда) поразмышляйте над возможными проблемами производительности в вашем проекте, а также над тем, что вы можете быстро предпринять, чтобы ущучить их. Я уверен, вам будет над чем подумать.

А теперь перейдем к вопросу "КАК"

Я уже говорил о своем любимом инструменте тестирования производительности. Вот он:

А если у вас нет такого, то вот этот всегда под рукой (ну или его аналог):

Побалуйтесь с цифрами! ;-)

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

Помимо этого, есть действительно простые вещи, которыми вы можете заняться. Всегда имейте под рукой нечто, демонстрирующее вам общую скорость отклика вашего приложения. Так как львиная доля приложений сейчас доступна через браузер - это несложно. К примеру, для FireFox есть дополнение - "Расширенная Строка состояния" (https://addons.mozilla.org/en-GB/firefox/addon/extended-statusbar/?src=search).

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

Хотите больше подробностей? У большинства современных браузеров есть режим разработчика и/или специальные расширения (Firebug для Firefox, встроенный режим Chrome). На вкладке "Сеть" можно посмотреть, сколько реально занимает загрузка страницы. Пара кликов - и вам доступна эта информация.

Кроме того, попробуйте что-нибудь вроде YSlow (http://yslow.org/), GTmetrix (https://gtmetrix.com) и другие анализаторы производительности. Они оценивают страницу, и сообщают, соответствует ли она стандартным метрикам производительности. Протяните руку и воспользуйтесь ими! Отчеты этих инструментов зачастую можно напрямую передавать разработчикам.

Итак!

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

(L)oad (нагрузка)

(А)рхитектура

(N)etwork (сеть)

(D)esign (дизайн)

(E)nvironment (окружение)

(T)iers (уровни системы)

(C)ode (код).

Удачи и спасибо за помощь нам, тестировщикам производительности!

Обсудить в форуме