Kharkiv Quality Assurance Day 2019 АНТОН СЕРПУТЬКО «Start performance testing from scratch» Телеграм канал: wwww.t.me/goqameetup Фейсбук сторінці: www.fb.com/goqaevent Сайт: www.kharkiv.qaday.org/

1. Start performance testing
from scratch

2. Senior Performance Analyst в EPAM Systems
Performance testing mentor at StartIT Training
Center
Mentor at ITKPI
Winner of several TestUaStartups, Dev
Challenge and UaWebChallenge competitions
Anton Serputko

3. Перфоманс тестинг
Нефункциональный тип тестирования, целью которого есть проверить
поведение приложения/системы под нагрузкой

4. Перед вами задача
Нужно сделать перфоманс

5. Что делать
Проанализировать систему
Подготовить тест план и тестовую стратегию
Разработать профиль и модель нагрузки
Подготовить тестовые сценарии и тестовые данные
Подготовить енв для тестов
Провести тесты
Проанализировать результаты
Подготовить отчеты

6. Выбор инструмента
Client
Server

7. Плюсы Jmeter
Опен сорс
Можно сделать все что придет в голову
Наличие плагинов
Низкий порог входа
Большое комьюнити
Возможность получать результаты в реальном времени и сохранять в БД

9. Минимальный ликбез
Модели и профили нагрузки
Метрики для анализа
NFRs

10. Модели нагрузки ака типы тестов
Модель нагрузки состоит из нескольких параметров:
количество потоков
время за которое все потоки становятся активными(рамп-ап)
длительность теста

11. Модели нагрузки

12. Модели нагрузки
Capacity
Load
Performance test
Stress
SOAK, endurance
итд

13. Модели нагрузки

14. Профиль нагрузки
Количество/частота действий пользователя во время теста

15. App-side метрики
Респонс тайм
средний-avg-mean
медиана-median
персентили-90,95,99 percentile
мин
макс

17. App-side метрики
Пропускная способность -
throughput
Transactions per second
Hits per second

18. App-side метрики
Количество ошибок
Количество активных юзеров

19. Серверные метрики
CPU
RAM
DISK I/O
Network
Позволяют мониторить как себя чувствуют серверы во время тестов.
Помогают видеть ботлнеки, связанные с конфигурацией и железом

20. NFRs
Non-functional requirements
Данные от бизнеса, которые скажут нам норм или нет
Response time(median, percentile)
Throughput
Errors %
0-1 сек - быстро
1-2 сек - норм
2-5 сек - терпимо
5+ сек - такое

21. Анализ системы
Найдите человека который шарит в систему
Не стоит начинать с сложных сценариев
Неплохо иметь схему, где базы, балансировщики, сервера..

22. Архитектура системы

23. Подготовить тест план и тест стратегию
IEEE 829

24. Подготовить тест план и тест стратегию

25. Енв
Prod-like environment
Доступы к серверам
Ресурсы для генераторов нагрузки и мониторинга

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

27. Дебаг/функциональное тестирование сценария

28. Ну, что-то есть. И что дальше?

29. Capacity тест
Необходим для того чтобы найти максимальные возможности системы на
текущей конфигурации
Throughput / Number of users
Важно то, что количество пользователей для других типов тестов берем по
результатам capacity теста

30. Capacity тест флоу

31. Capacity тест

32. Capacity тест
Action Processing time(median) Degradation zone Capacity point
Create order 114 ms per order (throughput<121)
318 ms (121<throughput<192)
2+ sec (throughput>192)
> 121 rps 192 rps

33. Модели нагрузки
Stress
SOAK

34. Модели нагрузки

35. Анализ результатов
Для начала собираем необходимые метрики

36. Сбор метрик
Агрегированная статистика типа табличек за все тест по app-side метрикам
Тренды по метрикам
Детали по ошибкам которые были во время теста
Серверные метрики

38. Анализ результатов
Думаем, находим зависимости и учимся
Смотрим на тренды метрик
Сравниваем
Пропускная способность
Медиана, персентиль
Количество ошибок
Серверные метрики

39. Сравниваем

44. Думаем и находим зависимости

53. Перфоманс тестинг
Нефункциональный тип тестирования, целью которого есть проверить
поведение приложения/системы под нагрузкой
Иии… улучшить его

54. Ограничение производительности
Hardware
Инфраструктура
Конфигурация приложения
Код приложения
Архитектура(масштабируемость)
Подход к нагрузочному тестированию

55. Hardware
Недостаток какого либо ресурса
Мониторинг метрик серверов app/db/proxy (cpu, ram, disk, network, load
average, etc)

58. Инфраструктура
steal time(aws credits)
iops limit
read/write limit
slow network
poor auto scaling set up
load balancing

63. Конфигурация приложения
connections limit
open connections
caching
не настроенный кеш
не настроенная jvm

65. Код приложения
1-thread processing
slow db queries
memory/connection leaks
не использование паттернов
использование сторонних библиотек

68. Архитектура(масштабируемость)
Неправильно выбранный язык
Неправильная БД под задачу
Использование не масштабируемых решений

69. Подход к тестированию

70. Запуск тестів в CI

71. Получение результатов в реальном времени
https://github.com/serputko/performance-testing-framework

72. Получение результатов в реальном времени

73. Репортинг

74. Все)

75. Вопросы?
Фреймворк Фейсбучек