Предлагаем вначале прочесть первую часть статьи в блоге.
Рекомендуем публикацию по теме
Что значит быстро?
Вопросом восприятия времени ученые задавались с тех пор, как появились первые терминальные компьютеры, имеющие интерфейс между логической частью обработки данных и пользователем, в середине ХХ века.
Проводя эксперименты с реакцией пользователя, оценивая задержки восприятия на различные активности: нажатие на клавишу мышки, перелистывание страницы, просмотр страницы и другие действия, ученые выделили несколько групп восприятия человеком времени.
- до 0.1 секунды — мгновенно;
- до 1 секунды — быстро;
- до 2 секунд — достаточно быстро;
- 2 - 4 секунды — приемлемо;
- 4 - 15 секунд — медленно;
- больше 15 секунд — очень долго.
Что тестировать?
Учитывая скорость восприятия пользователей, мы все же не можем сказать, что единственным верным решением будет измерение быстродействия системы со стороны конечного пользователя.
Можно и нужно оценивать производительность отдельных частей системы, а иногда и целых алгоритмов. Для того, чтобы оценить, какой вклад они вносят в систему, и для того, чтобы их можно было отладить. Например, взяли и измерили производительность какого-нибудь алгоритма, внесли изменения для улучшения, измерили повторно и оценили результат.
В связи со сложностью эмулирования поведения системы со стороны конечного пользователя, мы можем провести экспертизу, указать в отчете реально полученные результаты поведения системы и учесть все предположения, и уточнения в конечном отчете, для дальнейшей оценки и изучения.
Рекомендуем курс по теме
Классификация проблем
Какого типа проблема может быть выявлена во время проведения тестирования производительности:
- Медленная подсистема/функция
Отдельная подсистема или функция, которая работает медленно; какая-нибудь страница, которая загружается дольше всех; скрипт, который потребляет много ресурсов.
- Узкое место (bottleneck)
Достижение предела любой из частей системы, например, предел пропускной способности сетевого соединения.
- Точка насыщения
Это состояние системы, при котором поведение меняется не количественно, а качественно. Например, при достижении определенного количества пользователей начинают появляться отказы. Такую ситуацию можно наблюдать в системах, где запросы обрабатываются не сразу, а попадают в очереди, у этой очереди есть определенная длина и, как только длина исчерпана, начинают появляться отказы в системе, так как система не может обслужить запрос.
- Функциональный дефект
Как таковые функциональные дефекты не типичны для тестирования производительности и чаще обнаруживаются при проведении функционального тестирования, где действия выполняются последовательно. Но для тестирования производительности типично параллельное выполнение операций в большом количестве, где при конфликте функциональностей, можно обнаружить функциональные дефекты.
После обнаружения любой из перечисленных проблем нам необходимо передать информацию разработчику и дальше уже изучать пути оптимизации работы системы.
Цели тестирования
Возвращаясь к целям тестирования, в конечном итоге, мы, как специалисты по тестированию, должны предоставить реальную информацию о состоянии продукта заинтересованным лицам. Эти заинтересованные лица могут интерпретировать вопросы о состоянии таким образом:
- Менеджера или разработчика может интересовать, стала ли новая версия приложения работать быстрее. Но заказчика не интересует скорость отклика или потребление ресурсов, его интересует демонстрация оценки производительности на популярном языке, а не техническими терминами. И интерпретация результатов — это будет задача либо аналитика, либо тестировщика.
- Что именно замедляет работу: софт или железо? Эта информация необходима для того, чтобы решить, покупать ли новое серверное оборудование или же оптимизировать программу. Благодаря оценке возможности к распараллеливанию, оценке запаса мощности и времени отклика, мы можем сделать вывод, на какой из сторон существует недостаток.
- Почему пользователи не завершают заказы?Может, пользователи не завершают заказы потому, что не могут дождаться завершения операции? Или существует переполнение очереди обработки заказов и система отдает ошибки.
- Выдержит ли сервер грядущие распродажи? Например, после запуска рекламы или в популярные дни распродаж по всему миру, мы должны быть уверены, что наша система сможет обеспечить корректное функционирование.
- Нередко заказчики могут задать вопрос: как ведет себя система в целом, все ли хорошо?Этот вопрос типичен не только для тестирования производительности, но и для других видов тестирования. Нет ли каких-нибудь проблем? В том числе и с производительностью. И на этот вопрос так же необходимо уметь отвечать, переводя на технические термины, где мы сможем оценить состояние приложения и на популярном языке сказать о состоянии приложения.
Исходя из вышеперечисленных возможных вопросов от заказчиков, можно сформулировать список целей для проведения тестирования производительности:
- cравнить две версии приложения;
- найти причину проблемы с производительностью;
- оценить потенциальные возможности;
- получить подтверждение, что с системой все хорошо.
Зная о потребностях и целях тестирования производительности, мы можем в дальнейшем выстроить план проектирования тестов.
Мы рассматриваем тестирование производительности, а также другие виды тестирования на курсах тестирования ПО.
