Slovopyt:
+100000%. Заметила, что вопрос "а рассматриваете ли вы в будущем изучать автоматизацию?" чаще всего задают в аутсорс-конторах. И понятно, почему: автоматизатора продать проще и дороже, чем мануал. Конечно, я думаю, что заказчик может посчитать простейший ROI и задать вопрос о смысле использования автоматизации, но чаще всего такое не происходит + менеджеры навешают лапши, что с автоматизацией все будет збс точно.
И да, кстати. По поводу аквы. Не удивлена, что там вырос так сильно департамент автоматизаторов. Как я уже сказала, продавать их лучше, дороже, а менеджеры кастомерам всегда могут правильно обосновать нужность авто. Но блин) Я узнала, что в той же акве автоматизатор - это не человек, который пишет кейсы, а потом их автоматизирует. Автоматизатор в этой конторе просто автоматизирует кейсы, которые УЖЕ написаны ручником или кем-то там. То есть автоматизатор вообще не заменяет ручника, это еще один человек, на котором аутсорс рубит бабки.
Да, все так и есть. На акве я участвовал в 3-х проектах по автоматизации и все 3 были именно с таким подходом. И из всех 3-х, по моим ощущениям, только на одном был какой-то реальный профит от автоматизации 
Но крупные аутсорс-компании задают тренд на нашем рынке труда.
jackjones:
всем привет!
вопрос ПРАКТИКАМ. нагрузочное тестирование. какими способами проводите и как часто вообще? нашел инфу об использовании крутых apache Jmeter (server), Selenium (browser).
всем спасибо!
Могу немного рассказать про нагрузочное тестирование. Подразумеваю, что под этим вы имели в виду тестирование с целью проверить как система работает когда ее используют много пользователей. Для этого мы обычно использовали JMeter. Selenium не представляю как использовать для этих целей ( разве что через selenium grid запускать много тестов в параллели, но это очень плохо масштабируется и контролируется, т.к. браузеры жрут слишком много ресурсов железа при работе).
По процессу:
0. Получаем от заказчика требования по нагрузке. Обычно перед стартом проекта у заказчика уже есть примерное понимание сколько пользователей будут использовать систему обычно/в пиковое время.
1. Составляем сценарии поведения для "типичных" пользователей. Если у нас портал для покупки авиабилетов, то это будет сценарий по поиску билетов по разным направленияем/датам и последующей покупкой в каком-то проценте случаев, сценарий логина + чекина на рейс и т.д. Важно продумать сколько времени в среднем занимает каждый сценарий у реального пользователя и расставить паузы между шагами.
2. Составляем "профиль нагрузки": 1-му сценарию соответствуют XX% пользователей, 2-му YY, и т.д.
3. То, что мы сделали в шагах 1-2 обязательно согласовываем с кем-то со стороны заказчика, кто хорошо представляет как систему будут использовать в реальности. Если в рамках проекта переделывается/дорабатывается уже существующая система, то обязательно просим реальную статистику из гугл-аналитики или прочих тулов, которые трекают что делают юзеры в приложении. Еще вариант: попросить DBA выгрузить из продакшен базы статистику использования.
4. Пересматриваем еще раз требования из п. 0: стыкуются ли они с информацией, которую собрали в п. 1-3. Если стыкуются, получаем окончательный аппрув и считаем что у нас есть сформированные требования 
если нет, то разбрираемся почему так и корректируем сценарии/профиль нагрузки/инфу из п.0
5. Итак, примерное понимание того, какой будет нагрузка на нашу систему у нас есть. Теперь делаем скрипты, которые будут соответствовать нашим сценариям. Тут используем JMeter/Visual Studio/HP Loadrunner или другую тулу для нагрузочного тестирования
6. Заботимся об инфраструктуре для нагрузочного тестрования:
6.1. Решаем на каком окружении мы будем гонять нагрузочные тесты. В идеале, это отдельное окружение, где приложение будет поднято аналогично продовскому: app-сервер(а), отдельный сервер БД и т.д. Hardware этих серверов тоже должно быть близким к предполагаемому продовскому. Сейчас очень популярны облачные сервисы типа AWS/Azure, так что обычно не проблема временно увеличить размеры виртуалок на время нагрузочных тестов
6.2. Создаем отдельную виртуалку, которая будет "генератором нагрузки". Там будет стоять JMeter и с этом виртуалки будут запускаться нагрузочные тесты (никаких нагрузочных тестов с личного ПК!).
7. Проводим нагрузочные тесты, запуская скрипты в соотвествии с профилем нагрузки. Обычно это как минимум:
7.1. Load test 1 - запустить на "среднедневной" нагрузке на 8-10 часов (для многих корпоративных систем это эквивалентно длительности рабочего дня сотрудников). Кол-во пользователей не меняется в течение теста
7.2. Load test 2 - запустить на "пиковой" нагрузке на 2-3 часа, чтобы убедиться, что система держит и пиковую ожидаемую нагрузку
7.3. Stress test - плавно увеличивать нагрузку до максимума. Суть в том, чтобы понять как приложение будет вести себя под нагрузкой, выше планируемой. Ожидаемый результат в этом тесте - замедление работы системы с сохранением работоспособности. Т.е. должно работать медленно, но без ошибок
8. Анализируем результаты тестов: как менялось время отклика в зависимости от нагрузки, наличие ошибок, мониторинг железа серверов.
9. Если приложение не соответствует требованиям или кидает ошибки под нагрузкой, заводим соответствующие задачи и с помощью разработчиков разбираемся как исправить ситуацию
Конечно, первая итерация нагрузочных тестов самая сложная, трудоемкая и длительная. После нее обычно следует обсуждение результатов с заказчиком, dev командой, какие-то фиксы с последующим ретестом и т.д. Но последующие итерации требуют гораздо меньше времени и усилий, особенно есть автоматизировать рутину. Можно написать скрипт для бекапа БД перед тестом, запуск тестов с нужными длительностью и профилем нагрузки, копирование результатов hardware мониторинга, восстановление БД после теста. Кроме того, автоматизации поддается анализ результатов тестов: тот же JMeter пишет результаты в CSV-формате, который легко парсится Excel, python и т.д. Итого, стартовать тесты и анализировать результаты становится гораздо проще, чем в первый раз
По поводу частоты, можно прогонять полноценные нагрузочные тесты после окончания спринта, например. Т.е. dev-команда закрыла спринт и отгрузила код с новыми фичами, а вы чините свои нагрузочные скрипты, которые могли поломаться, проводите тесты и готовите репорт с результатами. Кроме того, иногда разработчики могут сами просить перепрогнать нагрузочные тесты после разработки конкретной фичи, которая по их мнению могла заметно повлиять на производительность. Тогда вы можете прогнать тесты на коде до этой фичи, потом после, и сравнить результаты.
Кроме того, можно подумать про:
1. Интеграцию нагрузочных тестов в CI. Конечно, в упрощенном варианте, с небольшой нагрузкой и на непродолжительное время. Задачей этих тестов будет частый сбор статистики по времени отклика для раннего обнаружения ухудшений. Кроме того, вы будете видеть, что ваши тесты требуют актуализации, если они начинают падать.
2. Stability testing. Если в связи со спецификой системы, она должна обслуживать пользователей 24/7, то есть смысл запустить тот же load test на 3-4 дня. Таким образом, можно убедиться в отсутствии ухудшения производительности/отсутствии memory leaks при длительной работе.
3. Volume testing - это когда БД набивают больших кол-вом данных (например, предполагаемый объем за год работы) и оценивают как это влияет на время отклика/загрузку железа БД.
4. Поговорить с командой разработки, возможно у них есть опасения за конкретную часть системы, либо идеи что можно дополнительно протестировать в рамках нагрузочного тестирования.
Добавлено спустя 26 минут 41 секунда
DenisN89:
Я вообще тестирование с качеством не мешаю. Мне нравится определение, что качество это ценность продукта для кого-то. Продукт приносит деньги, владелец счастлив, значит продукт качественный. А тестирование очень опосредованное отношение к этому имеет. Тестирование может указать на проблемы, на риски, но не сделать продукт качественным (или не качественным)
Поэтому я и не люблю подход, когда вешают на тестирвоание отмашку на выпуск продукта
Наконец-то я понял почему вы считаете, что тестирование слабо влияет на качество продукта, тем самым порождая споры Просто почти всегда, когда люди говорят про влияние тестирования на "качество" продукта, то под "качеством" имеют в виду соответствие продукта требованиям. Таким образом, тестирование убеждается в том, что команда разработки "качественно" сделала работу по разработке.
А вы скорее говорите про "качество" идеи продукта и "качество" его продвижения (приводящие к прибыли). К этому тестировщики действительно не имеют отношения. Как и разработчики. Как и автоматизаторы. Как и менеджеры проекта по разработке вместе с лидами команд.
Получается, качество продукта, по вашей версии, создают идейный вдохновитель продукта и маркетологи, верно?
могли воочую увидеть примеры из книги и иметь возможность интеракции с софтом, включая использование баг тракинг системы, QA automation и т.д." В общем, я стал параллельно писать англ. издание и кодировать. 
