Недавно я взялся за новый проект. В самом начале я попросил провести тест производительности для этого проекта, но менеджер по продукту не смог дать мне требования к производительности, просто потому, что этот проект является проектом электронной коммерции, и там могут быть сценарии с высокой степенью параллелизма и уничтожения флэш-памяти, поэтому менеджер продукта попросил нас провести тест производительности в этом проекте, и, поскольку этот проект является новым проектом, все не обратили на него внимания.
Через некоторое время, когда руководитель спросил, как реализован план тестирования производительности этого проекта, все растерялись и не знали, что делать. Затем руководитель группы тестирования обратил внимание на меня — единственного архитектора тестов из всей команды тестирования. В это время я вспомнил, что есть архитекторы НИОКР, поэтому я нашел архитектора НИОКР, чтобы сообщить о требованиях к производительности этого проекта.
вот проблема
Потому что в начале менеджер по продукту не мог дать требования к производительности. Если вы хотите дать план тестирования производительности в начале проекта, у вас должны быть соответствующие требования к производительности. Но сейчас этот проект только стартовал, и документации по продукту еще нет, поэтому продакт-менеджер не может дать требования к производительности. Вы можете знать только общее направление продукта и общие функциональные модули, поэтому в настоящее время вы можете полагаться только на архитекторов и менеджеров по продукту, чтобы общаться вместе.
Как я решил проблему?
Поскольку оно похоже на приложение для электронной коммерции, это проект с разделенными интерфейсом и сервером, поэтому на рынке есть много конкурирующих продуктов, которые можно использовать для анализа, поэтому я организовал встречу «Как внедрить тестирование производительности? Участники: менеджер по продукту, менеджер проекта, архитектор НИОКР и руководитель группы НИОКР. Однако в ходе этой встречи выяснилось, что все не очень охотно обсуждали тестирование производительности, а больше интересовались требованиями к продукту и соответствующими требованиями к производительности, потому что без требований к продукту и требований к производительности не было бы шага тестирования производительности. .
Вот еще один момент, на самом деле мы обычно делаем тестирование производительности в трех ситуациях в проекте:
1. Нам нужно иметь полное представление о текущей системе, то есть о производительности системы, чтобы увидеть, сколько параллелизма может выдержать текущая система.
2. Выдвинуть конкретные требования к производительности, например, я хочу добиться того, чтобы 3000 человек делали что-то одновременно, удовлетворить 1000 параллелизма, а ответ системы не превышал 2 секунд... 3. Когда у системы возникают проблемы с производительностью,
мы необходимо провести тесты производительности и устранить неполадки.
Похоже, я нашел спасательный круг
Так как это новый проект, проблем с производительностью пока не будет.Главное иметь требования к производительности перед переходом к тестированию производительности.Однако это требование к производительности не может дать никто, ни продакт-менеджер, ни проджект-менеджер , Исследования и разработки не могут дать даже этого. Поэтому в настоящее время наше внимание сосредоточено на обсуждении требований к производительности.Во время обсуждения на собрании мы обнаружили, что в настоящее время мы оцениваем конкурирующие продукты, то есть анализ конкурирующих продуктов, и обнаружили, что конкурирующие приложения должны соответствовать как минимум 1000TPS, и реакция системы не должна превышать 2 секунд.
нашел новую проблему
После всестороннего сравнения нескольких конкурирующих приложений было обнаружено, что определенное конкурирующее приложение должно соответствовать возможностям параллелизма 1000TPS в первой версии, но как спроектировать возможности параллелизма 1000TPS — это еще один вопрос в настоящее время, и это требование к производительности также полученный в результате анализа конкурирующих продуктов, нельзя рассматривать как реальное требование к производительности, а только как временное псевдотребование. В настоящее время всеобщее обсуждение на собраниях сосредоточено на том, как спроектировать архитектуру производительности, которая может соответствовать 1000TPS, а затем постепенно корректировать и оптимизировать требования, когда продукт будет фактически запущен и использоваться в будущем.
Первая тестовая версия была завершена на основе архитектуры производительности, соответствующей 1000 транзакций в секунду, чтобы тестировщики производительности могли протестировать систему, чтобы увидеть, может ли система достичь 1000 транзакций в секунду.Цель всей встречи достигнута. Остается сосредоточиться на том, как спроектировать архитектуру, которая может соответствовать текущему бизнесу 1000TPS. Конечно, эту работу делает не тестировщик и не простой разработчик, а системный архитектор.
Так что в итоге эту задачу передали системному архитектору.Конечно, в ней должен участвовать и тестовый архитектор, но текущий системный архитектор пока не может дать конкретный план архитектуры, потому что, если архитектура 1000TPS дан план, необходимо уметь спроектировать конкретное архитектурное решение до набора кода.
Вот и трудности
Перед набором кода можно оценить и дать набор конкретных архитектурных решений, а также оценить пропускную способность решения, TPS не менее 1000, эту нагрузку могут выполнять только системные архитекторы, через некоторое время и системные архитекторы коммуникативное открытие. Этот вопрос может быть разработан только на основе личного опыта архитектора, различных сред, дизайна промежуточного программного обеспечения, кэша базы данных, микросервисной архитектуры, структуры таблиц, стратегии балансировки нагрузки и степени параллелизма, которую может удовлетворить каждое промежуточное программное обеспечение.
тест вперед
Все это основано на личном опыте архитектора, ведь код еще не набран, а код запускается только после проектирования всей архитектуры! При разработке и наборе кода тестировщики могут проектировать и выполнять работу, связанную с тестированием производительности! После того, как вся среда тестирования производительности завершена, мы можем фактически выполнить определенные тесты производительности! Тогда, если мы скажем, что когда среда производительности урегулирована, код почти завершен, а данные почти созданы, слишком поздно начинать оценку решения производительности в это время, поэтому это необходимо сделать до ввода кода. пропускная способность TPS системы.
Конечно, это требует от архитекторов высокого уровня технического опыта.Большинство людей не могут сделать это хорошо.Хорошо это могут сделать только системные архитекторы, и даже опытные системные архитекторы не могут гарантировать спроектированное решение до набора кода. В то время он может соответствовать оценке производительности, поэтому нам все еще нужно дождаться теста производительности, чтобы увидеть реальные результаты.
Практический случай
Оптическая теория бесполезна, вы должны учиться следовать за ней, и вы должны делать это сами, чтобы вы могли применить то, что вы узнали, на практике.В настоящее время вы можете учиться на некоторых реальных боевых случаях.
Если это полезно для вас, пожалуйста, поставьте лайк и соберите его, чтобы поддержать автора. Это также удобно для вас, чтобы быстро найти его в следующий раз.
Если вы не понимаете, обратитесь к небольшой карточке ниже. Блогер также надеется учиться и прогрессировать с единомышленниками-тестерами.
В нужном возрасте выберите правильную позицию и постарайтесь полностью раскрыть свои преимущества.
Мой путь автоматизированной разработки тестов неотделим от плана каждого этапа на этом пути, потому что мне нравится планировать и подводить итоги,
Тестируйте и разрабатывайте видеоуроки, изучайте конспекты и получайте порталы! ! !