Ловушки тестирования производительности
•Download as PPTX, PDF•
0 likes•1,117 views
Доклад Владимир Марченко на конференции SQA Days-12, 30 ноября-1 декабря, Минск
![Кто такой
Владимир Марченко
Аналитик производительности
[со стажем]
в EPAM Systems
Ловлю светлый позитив
Не верю в agile, XaaS, центры совершенства,
циклонные пылесосы, и прочие buzzwords
2 / 20](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
Similar to Ловушки тестирования производительности
Similar to Ловушки тестирования производительности (20)
More from SQALab
More from SQALab (20)
Ловушки тестирования производительности
- 1. Ловушки тестирования производительности Владимир Марченко EPAM Systems 30-е ноября 2012 Минск, Беларусь
- 2. Кто такой Владимир Марченко Аналитик производительности [со стажем] в EPAM Systems Ловлю светлый позитив Не верю в agile, XaaS, центры совершенства, циклонные пылесосы, и прочие buzzwords 2 / 20
- 3. Содержание • Оговорки • Технические ловушки • Организационные ловушки • Ссылка 3 / 20
- 4. Оговорки Истины нет / истина не познаваема Цель мероприятия – насторожить Полагаю, что полезно тестировщикам Говорю про производительность веб- приложений 4 / 20
- 5. Технические ловушки Фото взято тут: http://www.archdaily.com/27245/ 5 / 20
- 6. Магический бенчмарк Среднее время отклика: 100 миллисекунд Как оказалось: быстро, но недолго 6 / 20
- 7. Цель тестирования Измерить времена отклика Найти узкие места системы Проверить стабильность Кое-что ещѐ 7 / 20
- 8. Протестируйте нам плейер Какие-то Сервера Какой-то Плейер Держите URL Какой-то Найдите причину проблем Интернет Мы пошли спать, созвонимся 8 / 20
- 9. Окружение – критично! • Сервера • Топология • Доступ • Зависимости • Данные Фото взято у автора фото 9 / 20
- 10. Нагрузите нам сервер Клиент толстый Пользователи ходят сложными путями Мы сделали классный скрипт на QTP Зовѐм вас, т.к. не получилось запустить тысячу браузеров 10 / 20
- 11. Взгляд на мир Клиент Сервер Тут грузим Тут проверяем эмоцию 11 / 20
- 12. Профиль нагрузки Есть разница, чем грузить! Профиль нагрузки должен быть реалистичным Фото взято тут: http://aasf-de.com/catalog.html 12 / 20
- 13. Терминология Самая неочевидная ловушка… • Время отклика • Запросы, клики, транзакции, страницы, байты • Пользователи! • Нагрузочное тестирование / тестирование производительности • и т.д. 13 / 20
- 14. Ловушки организации Фото взято тут: http://fotolenin.narod.ru/b/59.jpg 14 / 20
- 15. Проектный план Отсечки: 1-е января – начало проекта 1-е апреля – докурили бамбук … 1-е августа – конец интеграционного тестирования, начало оценки производительности 5-е августа – performance sign off 6-е августа – релиз 20-го июля позвоним в группу производительности... 15 / 20
- 16. Когда же начинать? Тестировать → Когда есть, что тестировать (это, кстати, спорно) Готовиться → С самого начала • Средство тестирования • Построение окружения • Получение статистики использования Требуют времени и денег! 16 / 20
- 17. Не автоматизация 17 / 20
- 18. Итого Цель тестирования – Правильное тестовое поиск узких мест окружение – критично для валидности результатов Для создания адекватной нагрузки Оговаривайте терминологию, – смотрите на мир т.к. изначально в ней бардак глазами сервера Планировать в середине Основное время занимает проекта – уже поздно анализ результатов 18 / 20
- 19. Ссылка Web Load Testing for Dummies (by Scott Barber and Colin Mason) http://www.gomez.com/ebook-web-load-testing- for-dummies-generic/ 19 / 20
- 20. Спасибо за внимание! Владимир Марченко Аналитик производительности в EPAM Systems vladimir_marchenko@epam.com Фото взято тут: http://www.zazzle.com/mouse_trap_mousepad-144827429888505359 20 / 20
Editor's Notes
- В последнее время тестирование производительности стало очень модным. Мне это очень не нравится. Дело в том, что все всегда гонятся за модными штуками, несмотря ни на что. Например, моды ради, можно попросить автоматизатора функционального теста расставить таймеры в своей регрессии, измерив, таким образом, времена отклика, и потом смело на своём промо-сайте написать модную штуку, что мы оттестировали весь функционал и на производительность. В этом докладе я попытаюсь обрисовать, как ловушки ожидают такого бедолагу-автоматизатора.
- Меня зовут Владимир Марченко, и я представляю здесь компанию EPAM Systems.Подробно рассказывать про компанию не буду, потому как надеюсь, что все слушатели и так более или менее знают нашу корпорацию добра. Скажу лишь, что у нас в епаме есть специальный немаленький отдел, полностью посвящённый вопросам тестирования, анализа, и оптимизации производительности программного обеспечения, и, собственно, я из этого отдела.В настоящий момент могу похвастаться почти семилетним стажем в области тестирования производительности, видел разные системы, наступал на разные грабли. Хотя иногда я позволяю себе такие отвлечённые занятия, как проектный менеджмент, в душе я, безусловно, инженер.
- Сначала я собираюсь сделать несколько важных оговорок касательно содержания моего доклада.Затем, быть может, немного не структурированно пройдусь по некотором моим любимым ловушкам, заботливо расставленным жизнью на пути аналитика производительности, и при этом я условно ловушки разделил на технические и организационные.Далее вас ожидает супер-ссылка, но я пока не буду говорить, какая.
- Самая главная оговорка – я не претендую на знание истины, даже если она и есть. Вполне возможно, что я буду говорить абсурдные для кого-то вещи – это нормально. Кое-где я буду немного упрощать – это тоже нормально. Ещё я не гарантирую 100%-ую полноту раскрытия темы.Цель моего доклада – предметно насторожить тех тестировщиков, которым приходится (которых заставляют) делать тестирование производительности «для галочки». Моя задача – показать, что есть некие подводные камни, каждый из которых может привести к провалу, и что если подписываетесь под тестирование производительности, то надо подходить к вопросу со всей тщательностью.Исходя из цели доклада я полагаю, что доклад будет наиболее полезен тестировщикам и их лидам. Скорее всего, для людей, кто не первый год вертится в области производительности, я не скажу ничего нового, всё будет из разряда прописных истин.Ещё учтите, что я в основном говорю про специфику тестирования производительности клиент-серверных приложений (или даже веб-приложений). Здесь не будет ничего про то, как тестировать печатные платы, например. Как тестировать компьютерные игры, я тоже не знаю и не скажу. И так далее.
- Начну обзор с так называемых технических ловушек. В общем-то, я их называю техническими, потому что они скорее описывают то, как можно сделать неправильно или что можно сделать неправильно. А уже потом в секции организационных ловушек я буду больше говорить о том, когда всё это можно сделать неправильно, и как пригласить неправильных людей. Хотя, на самом деле, граница очень условна.
- Давным-давно от наших индийских братьев по разуму мне достался один проект, в котором надо было раз в неделю делать т.н. бенчмарк-тест одного веб-сайта, и сравнивать среднее время отклика от теста к тесту. Заказчиком была информационная компания, возможно, крупнейшая в мире. Дела на баланс я принимал с таким напутствием «почему наш performance index постоянно улучшается, а реальные пользователи жалуются всё больше и больше на производительность?». Performance index – это было среднее по больнице время отклика. Сразу скажу, что скрипт был более-менее нормальным, в том смысле, что он не рисовал зелёные бубочки там, где надо рисовать красные.На самом деле, в том тестировании было много что сделано «не так», но что было точно мимо кассы, так это то, что задача тестирования была просто измерение времени отклика под некоей магической нагрузкой. Никто не пробовал выяснить, почему именно этот уровень нагрузки взят за базу. Никто не пытался смотреть, а что происходит с серверами во время теста (например, нет ли утечки памяти). Никто не пытался разобраться в том, какие страницы для пользователей более важные, чем иные. Никто не пытался разобраться, какое звено всей системы в целом является наиболее слабым. И так далее.В том конкретном случае у сервера была утечка памяти с периодическими рестартами (примерно раз в два дня). При этом время отклика было хорошим только на сравнительно «свежей», но уже немного «прогретой» системе. На «непрогретой» или на уже «усталой» системе время отклика становилось хуже. Но что ещё важно, регулярные рестарты приводили к отказам конкретным пользователям в ответах на запросы. Следует учесть, что 2-минутный простой системы в production может запросто стоить 2 миллиона долларов (цифры магические, я лишь хотел насторожить).
- А всё дело в том, что секрет успеха во многом зависит от правильного целеполагания.Это может звучать необычно, но [как правило] главная цель тестирования производительности – это вовсе не измерение времени отклика. Главная цель – это поиск [и устранение] тех мест тестируемой системы, которые ведут к проблемам с производительностью. Обычно мы говорим про так называемые узкие места системы (performance bottlenecks) и причины нестабильности системы (например, утечка памяти в одном из модулей).Дело в том, что на интуитивном уровне, когда говорят про хорошую производительность, то подразумевают при этом хорошие времена отклика, т.е. высокое быстродействие. Это правильно с точки зрения потребителя продукта, если допустить, что продукт всегда и при любых условиях отвечает быстро. Но с точки зрения разработчика продукта, хорошие времена отклика являются не причиной хорошей производительности, а во многом, её следствием. Производительность – это понятие многогранное, и включает, прежде всего, максимальные возможности системы, её стабильность, её масштабируемость, и кое-что ещё. Парадокс тут в том, что если делать тесты с целью обеспечить хорошие показатели по озвученным параметрам, то хорошие времена отклика потом подтягиваются сами собой.Собственно, ловушка тут заключается в том, что функциональные тестировщики часто мыслят о тестируемой системе с точки зрения конечного пользователя (и это правильно), но в части тестирования производительности, интуитивные выводы приводят к неправильному целеполаганию. Просто измеряя времена отклика, в лучшем случае можно лишь просто убедиться, что система отвечает с заданной быстротой в определённых условиях, но никогда нельзя понять, насколько система хорошо обрабатывает прибывшую нагрузку или насколько она стабильна во времени.P.S.В целом в докладе я нисколько не буду пытаться ломать копья на тему определений (и позже я скажу, почему), но что касается performance bottleneck, то тут всё же скажу, что это такое, т.к. считаю это понятие ключевым. Дело в том, что если у нас система в целом работает с точки зрения производительности плохо, то в большей части случаев это не значит, что система вся такая убогая от пят до головы. Скорее всего, есть какое-то ограниченное число компонент / мест системы, которые негативно влияют на производительность всей системы в целом. Каждое такое место и есть performance bottleneck, а поиск таких мест – основная задача тестирования производительности. По сути уже сейчас также важно запомнить, что тестирование производительности почти всегда является задачей обратной инженерии.
- Не так давно я участвовал в проекте по тестированию одного плейера для одной очень высокотехнологичной биржи.Задача звучала примерно так:Держите URLНам надо понять, почему при особо кассовых представлениях реальные пользователи жалуются, что не могут их посмотреть нашим же веб-плейеромТестировать надо в production (тёмной-тёмной воскресной ночью), т.к. других окружений у нас нет.Т.к. тестировать вы будете в production, то у operations нам удалось получить разрешение лишь на один weekend тестирования.Какие там у нас сервера, мы вам не расскажем, потому что мы очень секьюрная биржа.По той же причине на наши сервера мы вас не пустим.По той же причине мы не можем поставить генераторы нагрузки физически в нашем датацентре, вам надо тестировать откуда-то из интернета.Так и быть, дадим вам контакт operations инженера, он там сможет для вас запустить счётчики и выслать их потом вам для анализа (этот акт щедрости привёл в итоге к тому, что задача несмотря ни на что была выполнена).Там было ещё несколько интересных условий, но не относящихся к сути сегодняшнего разговора.Тестировали мы, как слепые котята. Вот включаем нагрузку, получаем ошибки – поди пойми, откуда они идут. И не забудь, что через 3 часа слот заканчивается, и другого не будет, так что думай быстрее. А логи потом посмотришь. Вот примерно так мы себя чувствовали в тестовые дни. Спасибо указанному инженеру, он нам после первого дня выслал промежуточные логи, так что за ночь перед вторым днём тестов мы смогли поднастроить наш прицел.И вообще здесь, наверное, всё, что можно было сделать не так, было сделано не так. Но нам несказанно повезло – узким местом оказался лимит на конкурентные соединения в firewall’е (не более 15 тыс.), что, не вдаваясь в детали, было довольно легко обнаружить уже в процессе спокойного анализа результатов. Но осадочек от почти что проваленного задания остался.
- Зачем я эту грустную историю рассказал? А затем, чтобы пояснить, что тестирование производительности делать методом «чёрного ящика» ни в коем случае нельзя. Это очень хорошо коррелирует с уже высказанной мыслью о том, что цель тестирования производительности – поиск узких мест, а вовсе не измерение времён отклика. И если вспомнить про то, что поиск узких мест – это задача обратной инженерии, то становится понятно, что критически важно иметь на ладони всю тестируемую систему до последнего винтика. Более того, надо иметь эту систему в полностью видимом адекватном окружении. Иначе поиск, скорее всего, увенчается провалом, и можно будет только вместе с заказчиком сесть и поплакать над плохими результатами.Необходимый минимум, который надо помнить об окружении:Тестовые сервера должны быть либо такими же, либо пропорционально масштабированными вниз, по сравнению с production. Иначе вы можете найти те узкие места, которые в production не «выстрелят», пропустив те, которые там себя проявят в полный рост.По той же причине важно, чтобы компоненты системы в тестовом окружении также правильно соотносились друг с другом (число серверов для каждого из компонентов, например)Необходимо иметь полный доступ к каждому винтику тестируемой системы. Желательно, чтобы ещё и можно было подкручивать то или иное (например, настраивать параметры потребления памяти JVM). Только так будет возможность успешно выполнить задачу обратной инженерии по поиску узких мест.Необходимо понимать все зависимости между компонентами системами. Например, если посылается определённый GET-запрос на сайт, то в какие последующие запросы это результируется на веб-сервис, и далее на базы данных. Без понимания взаимозависимостей между компонентами сложной системы, почти невозможно грамотно декомпозировать систему при проверке тех или иных гипотез.Ещё немаловажный пункт – это данные в том смысле, что если в production база содержит, к примеру, 100 миллионов новостей, распределённых по годам таким-то образом и запрашиваемых таким-то образом, то в тестовом окружении у нас не должна быть база с одной тестовой новостью.Коварность этой ловушки заключается в том, что запрет на проведение тестов на производительность методом «чёрного ящика» - он логический. Физически вам никто не мешает взять на вход URL или иную точку входа, и начать его бомбить. Просто смысла в этом будет немного.
- Расскажу ещё одну сказку-байку, на этот раз про то, как нас одна всемирно известная компания, специализирующаяся в разработке систем документооборота, попросила сделать им нагрузку на сервер. Сразу скажу, что нам удалось их убедить, что лучше сделать по-другому, в общем тут happy end.Была, в общем, система документооборота с богатой серверной частью (по большей части веб-сервисы) и очень толстым клиентом, работающим в браузере. Заказчик своими силами сделал неплохой скрипт автоматизации (опять на QTP), но не смог запустить 1000 браузеров на своей машине генерации нагрузки, поэтому обратился к нам за помощью, ведь мы профессионалы.Нам удалось убедить заказчика, что здесь есть противоречие, и надо выбрать: либо 1000 браузеров, либо хорошая нагрузка на сервер.
- Поясню, что здесь за противоречие.Приведу некоторую аналогию.Допустим, есть аэропорт. В аэропорт прилетают самолёты (иногда по расписанию, иногда не очень) разных мастей. Аэропорт также работает с людьми-пассажирами и грузами. В итоге если посмотреть на мир глазами аэропорта, то мы имеем некие потоки самолётов, людей, и грузов, которые надо все обработать с определёнными SLA (service level agreement). Знание вероятностных характеристик этих потоков может нам очень сильно помочь, если мы возьмёмся за задачу оптимизации пропускной способности аэропорта.Теперь посмотрим на мир глазами пассажира. Он сидит у себя дома и ему надо сегодня попасть в Барселону. Его путь такой: надо проехать до аэропорта на автомобиле, потом зарегистрироваться на рейс номер такой-то и сдать багаж, затем подождать отбытия, ну и так далее. Вероятностных потоков тут уже нет, зато есть вероятность опоздания в аэропорт из-за, например, пробки. Или вероятность потеряться между терминалами. Ну и так далее. Картина мира у пассажира иная.Можно ещё посмотреть на мир глазами самолёта, чемодана, и контейнера, а также автомобильной дороги, но мы не будем, т.к. ограничены во времени.Если у нас задача нагрузить аэропорт (или автобан), то лучший путь – это не запуск тысячи пассажиров с очень схожими путями. Лучший путь – это эмулировать потоки входных для аэропорта пассажиров, самолётов, и грузов, и проверить, что будет с аэропортом. Но при этом поверх уже грамотно нагруженного аэропорта очень даже себе полезно прогнать через всю систему целиком отдельно взятых пассажиров, и посмотреть на то, как они себя ощущают, но это, обратите внимание, уже другая задача.Так вот, если принять эту грубую аналогию, то аэропорт – это серверодной из подсистем, а пассажир – это отдельно взятый клиент. И надо чётко разделять задачи подачи нагрузки на сервер и ощущения того, как себя будут чувствовать типичные пользователи при уже сделанной фоновой нагрузке. Запуск тысячи браузеров – это не лучший способ делать нагрузку на сервер.Ловушка тут заключается в том, что никто не мешает нам взять, к примеру, функциональный тест и запустить его в многопоточном режиме, и таким образом сделать кое-какую нагрузку на сервер. Но вот будет ли это полезно и эффективно с точки зрения целей тестирования? Скорее всего, не очень.
- По этому пункту ещё хочу добавить, что кроме того, что есть разница, чьими глазами смотреть на мир, при взгляде на мир глазами сервера есть ещё огромная разница, чем конкретно сервер грузить. Это потому, что разные запросы нагружают разные компоненты системы, и распределение запросов и их параметров (т.е. профиль нагрузки) кардинальным образом влияет на загруженность разных компонент системы (и следовательно, проявлению узких мест).В случае аналогии с аэропортом, есть большая разница – грузить его одними самолётами Боинг-737, или учесть и иные «запросы» в профиле нагрузки.Это по сути та же самая ловушка, но немного в ином разрезе.
- Это моя самая любимая ловушка.Собственно, я даже пример никакой тут приводить не буду, потому что любой пример – про неё родимую.Самое главное, что я рекомендую запомнить, так это то, что в области терминологии тестирования производительности царит всепоглощающий бардак. Одни и те же термины часто обозначают разные вещи. Разные термины часто обозначают одни и те же вещи. И начинается это всё уже, например, с определения того, что такое тестирование производительности и что такое нагрузочное тестирование. Отдельный случай – это термин «пользователь», и рядом стоящие «виртуальный пользователь», «поток», и так далее (например, когда тестировщик говорит, что в тесте на определение на максимальных возможностей максимальная нагрузка была 100 виртуальных пользователей, менеджер автоматически убирает слово виртуальный, делая недопустимую подмену).И копья ломать про термины я сейчас не буду, но на чём заклинаю, так это обязательно термины каждый раз на каждом новом проекте оговаривать отдельно со всеми заинтересованными сторонами. Неоговоренность терминов – это даже более опасно, чем ситуация, кога все говорят на разных языках. Неоговоренность терминов – это когда все говорят на разных языках, но не знают об этом, думая, что говорят на одном языке.
- Теперь перейду к условно ловушкам организации, т.е. к тем ловушкам, в которые чаще попадаются менеджеры и лиды, подставляя своих тестировщиков.
- Рассмотрим типичный проектный план проекта, который составлен менеджером, слышавшим про модную штучку производительность, но не углублявшимся в детали.Самая важная штука тут – это то, что тестирование производительности поставлено на последнюю неделю перед релизом. Почему? Потому что:Канонически считается, что нет смысла тестировать на производительность до окончания тестов на функциональностьБолее того, т.к. производительность – штука сложная и многогранная, то лучше её тестировать уже против системы в сборе, т.е. после интеграционного тестированияЕсть иллюзия того, что проведение тестов на производительность – это детерминированный процесс, который можно чётко очертить временными рамками (грубо говоря, нажали кнопку старт, нажали стоп, получили таблицу с зелёными и красными бубочками, то бишь мы знаем, идти или не идти в production)Я такой подход встречаю повсеместно с каждым новым проектным менеджером.Хорошая новость тут в том, что даже если каждый отдельный менеджер не верит, что надо планировать по-другому, то это только по первому разу.Ловушка тут в том, что представленный проектный план с точки зрения тестирования производительности хорош только в том случае, если задача тестирования производительности заключается просто в измерении времён отклика (что, как я настаиваю, не будет так в большинстве случаев). В озвученном плане здесь не только велика вероятность риска того, что на performance sign off, аналитик производительности будет решать сложную задачу, а именно «как за день до релиза сообщить всем, что в кабак идти рано, и продукт не готов к релизу». Но тут весьма существеннен риск, что к этой дате аналитик производительности даже не успеет сам для себя понять, можно в релиз или нет, и если нет, то как аргументировано пояснить, почему, и что теперь делать.
- Так когда же надо начинать тестировать на производительность?В идеале тогда, когда есть уже какой-то работающий функционал, который можно начать проверять, а не трещит ли под нагрузкой, и вообще как себя чувствует во времени. Можно, на самом деле, и раньше, но в такие экстремальные случаи я не хочу сейчас углубляться.А вот планировать и готовиться к тестам – вот прямо с первого дня проекта.А всё потому, что как вы, наверное, уже заметили, одна только подготовка к тестам может занять много времени (не столько много часов активной работы, сколько много дней томительного ожидания). Надо построить и настроить тестовое окружение, оценить вероятностные характеристики потоков запросов, выбрать и купить средство тестирования (а это может оказаться отдельной историей на сотни тысяч долларов). И, кроме того, это ещё и потребует денег, а значит должно быть в бюджете.Иными словами, готовить сани надо летом.
- Более того. Я старался эту мысль неявно нести через всю презентацию, а сейчас я её говорю прямым текстом. Тестирование производительности – это не подвид автоматизированного [функционального] тестирования. С автоматизацией тут родство только по части необходимости написания скриптов.На этом слайде я попытался нарисовать некоторое облако тегов, показывающее, на что в основном тратятся основные усилия в производительности.Как видите, явственно выпирает анализ. Именно анализ – это костяк работы любого аналитика производительности. А вот, например, скриптование тут еле заметно внизу (хороший аналитик так вообще один раз сделает фреймворк, и потом будет собирать тесты как кубики, т.е. у него скриптования будет совсем мало). Много времени займёт само тестирование, и доведение результатов в понятной форме до заинтересованных сторон.Какие организационные выводы я хочу озвучить из этого облака тегов:Надо понимать, что не получится иметь результат теста на производительность сразу после его завершения. Для понимания того, что полученные результаты обозначают, и как нам с ними дальше жить, надо будет потратить много времени на анализ этих результатовБолее того, анализ не просто берёт большую часть времени, он ещё и берёт непредсказуемо большую часть времени (каждый раз по-разному то есть, но каждый раз много) – это отголосок того, что по сути анализ производительности является процессом выдвижения и проверки гипотез (и какая из них подтвердится, заранее не угадаешь).Часто результатом анализа является необходимость проведения тестов заново после каких-либо правок в системе.Заниматься этой работой должен человек, который любит анализ и которого не страшит неопределённость (90% процентов времени этот бедолага проводит с мыслью, что всё идёт не по плану)Расскажу один грустный пример (концовка умеренно счастливая).На одном проекте для одного стартапа по предоставлению очень контекстной гео-рекламы, в какой-то ударный пробивной момент проектный менеджер решил, что для того, чтобы выгоднее и лучше продать автоматизацию, можно сделать POC-проект руками программистов. На мой взгляд, уже спорное решение. Но что произошло дальше, так это то, что автоматизация оказалась особо не нужна, зато оказался необходимым сервис по анализу производительности. И проектный менеджер сделал ещё одну подмену понятий: раз у нас уже есть три супер-«автоматизатора», то пусть и сделают производительность, благо второе – это подвид первого. Результат был такой, что программисты были «немного» недовольны жизнью (ведь их заставляли делать не их работу!), заказчик был «немного» недоволен результатами работы по производительности, ну и проектный менеджер тоже был «немного» не доволен ситуацией в целом (вроде бы даже собирался выписать более мощных программистов…). Добрый ангел позвал нас.«Исправили» мы ситуацию тем, что показали, как можно сделать задачу по-другому. Конкретно взятый проект это уже не спасло, но это во-первых ускорило прекращение мучений для бедолаг-программистов, и во-вторых, у нас есть +1 проектный менеджер, который теперь в теме.
- Итого:Цель тестирования производительности – это, как правило, не измерение времён отклика, а поиск узких местПравильное тестовое окружение и полный доступ к нему тестировщиков, а также понимание ими принципов работы системы в сборе – необходимое условие для поиска узких местСоздание нагрузки и понимание чувств пользователя – разные задачи. Для выполнения первой задачи надо уметь смотреть на мир глазами сервера (вероятностные потоки запросов на обработку), для выполнения второй надо смотреть на мир глазами клиента (путь пользователя). Если перепутать методы решения задач, то будет тяжело достигнуть желаемого.Терминология у каждого в голове своя, причём все по-своему правы. Перед началом работ необходимо её каждый раз приводить к общему знаменателю среди участников проекта.Планировать тестирование производительности надо в самом начале проекта, и выделять на него много времени и денег. Если в середине проекта попытаться по-быстрому прикрутить тестирование производительности, то скорее всего получится лишь измерить времена отклика, не более.Основное и не предсказуемое время занимает анализ результатов. Планировать надо соответствующим образом.
- Супер-ссылка для тех, кто ещё с намиКнига «Web Load Testing for Dummies» Скотта Барбера – несмотря на дерзкое название, прекрасно вводит в тему тестирования производительности с нуля. Она не отвечает на все вопросы, но зато настораживает и даёт хорошие направления для дальнейшего ознакомления с темой. Для менеджера книга хороша тем, что читается за вечер (там всего около 40 страниц).
- Буду рад ответить на вопросы, а также подискутировать.Пишите vladimir_marchenko@epam.com