Hace poco me hice cargo de un nuevo proyecto. Al principio, pedí una prueba de rendimiento en este proyecto, pero el gerente de producto no pudo darme los requisitos de rendimiento, solo porque este proyecto es un proyecto de comercio electrónico, y hay puede haber escenarios de alta simultaneidad y eliminación repentina, por lo que el producto El gerente nos pidió que hiciéramos una prueba de rendimiento en este proyecto, y debido a que este proyecto es nuevo, nadie le prestó atención.
Después de un tiempo, cuando el líder preguntó cómo se implementó el plan de prueba de rendimiento de este proyecto, todos estaban confundidos y no sabían qué hacer. Luego, el líder del equipo de pruebas se fijó en mí, el único arquitecto de pruebas de todo el equipo de pruebas. En ese momento, recordé que hay arquitectos de I+D, así que busqué un arquitecto de I+D para comunicar los requisitos de rendimiento de este proyecto.
aquí viene el problema
Porque al principio, el gerente de producto no podía dar requisitos de desempeño. Si desea dar un plan de prueba de rendimiento al comienzo del proyecto, debe tener los requisitos de rendimiento correspondientes. Pero ahora este proyecto acaba de comenzar y aún no hay documentos del producto, por lo que el gerente del producto no puede proporcionar requisitos de rendimiento. Solo puede conocer la dirección general del producto y los módulos funcionales generales, por lo que en este momento solo puede confiar en que los arquitectos y los gerentes de producto se comuniquen entre sí.
¿Cómo resolví el problema?
Dado que es similar a una aplicación de comercio electrónico, es un proyecto con los extremos delantero y trasero separados, por lo que hay muchos productos de la competencia en el mercado que se pueden usar para el análisis, por lo que organicé una reunión "¿Cómo implementar pruebas de rendimiento? " Participantes: Gerente de producto, gerente de proyecto, arquitecto de I + D y líder del equipo de I + D. Sin embargo, durante el transcurso de esta reunión, se descubrió que no todos estaban muy dispuestos a discutir las pruebas de rendimiento, sino que estaban más interesados en los requisitos del producto y los requisitos de rendimiento correspondientes, porque sin los requisitos del producto y los requisitos de rendimiento, no habría paso de prueba de rendimiento. .
Aquí hay un punto más, de hecho, generalmente hacemos pruebas de rendimiento en tres situaciones en el proyecto:
1. Necesitamos tener una comprensión profunda del sistema actual, es decir, el rendimiento del sistema, para ver cuánta concurrencia puede admitir el sistema actual.
2. Presentar requisitos de rendimiento específicos, por ejemplo, quiero lograr que 3000 personas hagan algo al mismo tiempo, satisfacer 1000 simultáneos y la respuesta del sistema no exceda los 2 segundos... 3. Cuando el sistema tiene problemas de rendimiento
, necesidad de realizar pruebas de rendimiento y solución de problemas.
Parece que encontré un salvavidas
Debido a que este es un proyecto nuevo, no habrá problemas de rendimiento por el momento. Lo principal es tener requisitos de rendimiento antes de pasar a las pruebas de rendimiento. Sin embargo, nadie puede dar este requisito de rendimiento, ni el gerente de producto ni el gerente de proyecto. La investigación y el desarrollo ni siquiera pueden darlo. Entonces, en este momento, nuestro enfoque es discutir los requisitos de rendimiento. Durante la discusión en la reunión, descubrimos que actualmente estamos evaluando productos de la competencia, es decir, análisis de productos de la competencia, y descubrimos que las aplicaciones de la competencia deben cumplir al menos 1000TPS, y la respuesta del sistema no debe exceder los 2 segundos.
encontrado un nuevo problema
Después de comparar exhaustivamente varias aplicaciones de la competencia, se descubrió que una determinada aplicación de la competencia debe cumplir con la capacidad de concurrencia de 1000TPS en la primera versión, pero cómo diseñar la capacidad de concurrencia de 1000TPS es otra pregunta en este momento, y este requisito de rendimiento también es obtenido a través del análisis de productos de la competencia. No puede considerarse como un requisito de desempeño real, sino solo como un pseudo-requisito temporal. En la actualidad, el enfoque de la discusión de la reunión de todos es cómo diseñar una arquitectura de rendimiento que pueda cumplir con 1000TPS y luego ajustar y optimizar gradualmente los requisitos cuando el producto se lance y use en el futuro.
La primera versión de prueba se completó sobre la base de una arquitectura de rendimiento que satisface 1000 TPS, de modo que los evaluadores de rendimiento pueden probar el sistema para ver si el sistema puede alcanzar los 1000 TPS. Se logró el propósito de toda la reunión. El enfoque restante es cómo diseñar una arquitectura que pueda cumplir con el negocio actual de 1000TPS. Por supuesto, este trabajo no lo hace un probador, ni lo hace un simple desarrollador, sino un arquitecto de sistemas.
Entonces, al final, esta tarea se entregó al arquitecto del sistema. Por supuesto, el arquitecto de prueba también debería participar, pero el arquitecto del sistema actual no puede dar un plan de arquitectura específico por un tiempo, porque, si una arquitectura 1000TPS se da el plan, es necesario poder diseñar una solución arquitectónica específica antes de escribir el código.
Aquí viene la dificultad
Antes de escribir el código, puede evaluar y proporcionar un conjunto de soluciones de arquitectura específicas, y evaluar el rendimiento de la solución, TPS no es inferior a 1000, esta carga de trabajo solo la pueden realizar los arquitectos del sistema, después de un período de tiempo y los arquitectos del sistema descubrimiento de la comunicación. Este asunto solo se puede diseñar en función de la experiencia personal del arquitecto, varios marcos, diseño de middleware, caché de base de datos, arquitectura de microservicio, estructura de tabla, estrategia de equilibrio de carga y cuánta concurrencia puede satisfacer cada middleware.
prueba hacia adelante
Todo esto se basa en la experiencia personal del arquitecto. Después de todo, el código aún no se ha escrito, ¡y el código solo se inicia después de que se ha diseñado toda la arquitectura! Al desarrollar y escribir código, los evaluadores pueden diseñar y realizar trabajos relacionados con las pruebas de rendimiento. Una vez que se completa todo el entorno de prueba de rendimiento, ¡podemos realizar pruebas de rendimiento específicas! Entonces, si decimos que cuando el entorno de rendimiento está establecido, el código está casi completo y los datos casi creados, es demasiado tarde para comenzar a evaluar la solución de rendimiento en este momento, por lo que debe hacerse antes de escribir el código. el rendimiento TPS del sistema.
Por supuesto, esto requiere un alto nivel de experiencia técnica para los arquitectos. La mayoría de las personas no pueden hacerlo bien. Solo los arquitectos de sistemas pueden hacerlo bien, e incluso los arquitectos de sistemas experimentados pueden no ser capaces de garantizar la solución diseñada antes de escribir el código. Puede cumplir con la evaluación de rendimiento en ese momento, por lo que todavía tenemos que esperar la prueba de rendimiento para ver los resultados reales.
Caso práctico
La teoría óptica es inútil, tienes que aprender a seguirla, y tienes que hacerlo tú mismo, para que puedas aplicar lo que has aprendido a la práctica. En este momento, puedes aprender de algunos casos reales de combate.
Si te es útil, dale me gusta y recógelo para alentar al autor. También es conveniente que lo encuentre rápidamente la próxima vez.
Si no lo entiende, consulte la pequeña tarjeta a continuación. El blogger también espera aprender y progresar con evaluadores de ideas afines.
A la edad adecuada, elija la posición correcta e intente aprovechar al máximo sus propias ventajas.
Mi camino de desarrollo de pruebas automatizadas es inseparable del plan de cada etapa del camino, porque me gusta planificar y resumir,
¡Pruebe y desarrolle tutoriales en video, notas de estudio y portales de recepción! ! !