Чтобы создать высококачественный продукт, вашим командам разработчиков следует регулярно проводить тестирование производительности. Это поможет им оперативно выявлять критические функциональные ошибки и трудно обнаруживаемые недостатки в обработке нагрузки и производительности. Если вы готовы приступить к внедрению такого тестирования, рекомендуем ознакомиться с этими рекомендациями:
При тестировании приложения важно не допустить его нестабильности и нарушения SLA (соглашения об уровне обслуживания). Это означает, что вы должны использовать свои SLA как ориентир для каждой итерации.
Если изменения, вносимые в рамках итерации, затрагивают лишь небольшую часть общего кода, они считаются приемлемыми. В таком случае проблемы с производительностью будут ограничены определенной частью приложения.
Однако, если общие условия обслуживания распространяются на все приложение, необходимо составить более широкий список ограничений. Этот список будет проверяться на каждой итерации, чтобы убедиться, что она соответствует заявленному определению «завершена» и не нарушает никакие ограничения.
Чтобы проект развивался быстрее, функции продукта и тестовые сценарии должны разрабатываться одновременно. Это позволит тестировщикам не тратить время на создание новых или пересмотр старых тестов в случае изменений в программном обеспечении.
Тестировщики должны тесно сотрудничать с разработчиками, чтобы иметь четкое представление о том, как будет проходить тестирование разрабатываемого программного обеспечения или приложения. Разработчики, в свою очередь, должны мыслить как тестировщики, работая над своим проектом. Тестировщики же должны быть в курсе задач по разработке, посещая совещания в стиле Scrum. Такое тесное взаимодействие позволит обеспечить бесперебойный и непрерывный процесс тестирования.
В отличие от традиционной модели разработки, современные процессы часто обходятся без предоставления подробных спецификаций пользователям. В таких случаях рекомендуется разрабатывать тесты, основанные на историях или сценариях, вместо того чтобы ориентироваться на жесткие наборы тестов. Благодаря этому тестировщики смогут охватить более широкий спектр сценариев, которые могут быть не задокументированы.
В прошлом для тестирования различных вычислительных задач использовался один и тот же набор тестов. Однако в современных быстро меняющихся условиях важно, чтобы тесты также были гибкими и могли адаптироваться к новым требованиям.
В связи с этим всё большую популярность приобретает подход «инфраструктура как код». Этот подход позволяет представить всё виртуальное оборудование, вычислительные ресурсы и приложения в виде программного обеспечения. Это даёт возможность программировать их соответствующим образом, в зависимости от текущих задач.
Обычно, автоматизация ограничивается начальными этапами модульного тестирования. При этом она должна быть неотъемлемой частью всего процесса развертывания, особенно на более поздних стадиях. Для этого рекомендуется разрабатывать универсальные тестовые сценарии, которые можно оформлять в виде отдельных программных сервисов или компонентов. Эти сервисы и компоненты можно использовать в различных ситуациях по мере необходимости.
В современном мире инструменты APM (Application Performance Monitoring) играют всё более важную роль в различных процессах тестирования. Их применение должно стать более активным, чтобы обеспечить постоянный мониторинг производительности и то, что называется «сдвигом вправо».
Тестирование производительности должно быть неотъемлемой частью каждой сборки. Один из способов реализовать это — запускать тесты через сервер сборки и интегрировать их результаты в инструмент сборки. Тогда специалист, ответственный за запуск, сможет легко увидеть результаты и понять, какие изменения были внесены в процесс. Это позволит оперативно выявлять и устранять потенциальные проблемы, связанные с производительностью.
Тестирование CI (непрерывной интеграции) и послеспринтерских сборок может значительно различаться. Разница может быть как в одном изменении, внесённом за день, так и во всех изменениях, сделанных в течение спринта. Поэтому при тестировании производительности для этих сборок рекомендуется начинать с небольших объёмов и использовать доступные внутренние нагрузки. Например, можно быстро провести небольшой тест производительности, охватывающий наиболее распространённые сценарии, с помощью типичной нагрузки на приложение, создаваемой вашими внутренними генераторами нагрузки.
Тесты для сборок CI должны проводиться оперативно, чтобы разработчик мог сразу увидеть результаты и оценить, как изменения, внесённые в сборку, влияют на систему. Эти результаты должны быть доступны как можно скорее, чтобы обеспечить их правильное использование.
Перепрофилирование инструментов тестирования является хорошим ходом для повышения эффективности непрерывного тестирования производительности. В настоящее время многие компании активно используют искусственный интеллект для анализа журналов операционных систем. Это позволяет выявить наиболее часто используемые пользователями пути и, на основе полученной информации, автоматизировать процессы, которые делают эти пути более приоритетными для тестирования.
Некоторые компании также адаптируют свои функциональные средства для тестирования целей на более поздних этапах конвейера развертывания. Благодаря современным методам, знаниям и опыту, полученным в результате автоматизации, эти компании могут сократить расходы на тестирование и значительно повысить свою эффективность.
Благодаря mocking, вы можете протестировать каждый компонент независимо от остальных. Это позволяет создавать высококачественные тесты, что значительно упрощает процесс тестирования.
Если вы еще не проводили тестирование производительности, то самое время приступить к этому важному шагу. Помните, что даже самые простые тесты, выполненные регулярно, могут принести ощутимую пользу.