Charla en profundidad sobre las pruebas de rendimiento, desde comenzar hasta darse por vencido: un primer vistazo a las pruebas de rendimiento

Originalmente quería dividirlo en 7 artículos para escribir, pero también consideré que tenía que pasar las páginas cuando veía los sentimientos profundos, así que simplemente compuse un artículo para escribir.
Antes de escribir el texto, para compartir una pequeña historia:
Gente:
Cable Small Cock: Test Manager
Gangster: Product Manager,
Small Cock wire xx recientemente haciendo un proyecto, el proyecto se anudó inmediatamente, el hermano mayor de repente pidió hacer pruebas de rendimiento del cable Small Cock.
Como dice el refrán, para hacer un proyecto, debe tener un proceso estandarizado y un plan de proyecto.
Xiao Diaosi parecía aturdido. Después de 3 segundos, Xiao Diaosi envió 4 preguntas ~ ~
Xiao Diaosi: Hermano mayor, en primer lugar, evaluamos al comienzo del proyecto, si este proyecto no requiere pruebas de rendimiento y, en segundo lugar, ¿el cliente requiere informes de rendimiento? En tercer lugar, ¿el contrato proporciona información sobre equipos de software y hardware, expectativas de rendimiento y otra información y, en cuarto lugar, tenemos que ir al sitio del cliente para la implementación?
Hermano mayor: Um ...
Xiao Diaosi: Entonces, ¿realizamos pruebas de rendimiento para reflejar la integridad del informe o para reflejar la palabrería de nuestro equipo?
Gran Hermano: ¡Solo quiero el informe de la prueba de rendimiento!
Pequeña polla de seda: ...

¡Oye! Suspiremos ~ ~ Volvamos
al tema, ya que como ingeniero de pruebas de desempeño profesional, debemos brindarle al líder del proyecto / cliente la solución más razonable y óptima. No se ría de ellos solo porque no entienden.
Después de todo, cualquier otra línea es como una montaña ~~~

A continuación, siga a Xiaoyu, aprenda en detalle, ¡cómo hacer el rendimiento!
Xiaoyuer te permitirá, desde empezar hasta rendirte, es un instante ~ ~

1. Proceso de prueba

Para citar las palabras del Sr. Lu Xun: No hay regla sin reglas.

Por supuesto, nuestra prueba de rendimiento también necesita una especificación de proceso, y está en línea con el proceso de gestión de proyectos. Dices guapo o no ~~
Echemos un vistazo a esta especificación de proceso.

Con el diagrama de flujo anterior, siguiente, vamos a introducir cada eslabón de detalle:
①Business aprendizaje : entender la función del sistema de visualización de documentos oa través de operaciones reales.
②Requirement análisis : Analizar los requisitos no funcionales del sistema, definir el alcance de las pruebas de rendimiento, y comprender indicadores de rendimiento del sistema.
③Work Evaluación : desglose carga de trabajo, la evaluación de la carga de trabajo, la entrada planificada de recursos (persona y día).
④ Diseñar modelo de prueba : después de delimitar el alcance de la prueba de rendimiento, asigne el modelo de negocio al modelo de prueba.
¿Estás confundido cuando escuchas esta oración? ¿Qué es un modelo de prueba?
En términos sencillos, es: los casos de uso del diseño de casos de prueba de desempeño + plan de prueba de desempeño
solo se enfocan en el negocio, el modelo también debe enfocarse en cómo implementar, ya sea operabilidad, verificabilidad, etc., y finalmente, debe combinarse en escenarios de prueba de acuerdo con diferentes propósitos de prueba .
⑤ Preparación del plan: planifique el trabajo de prueba, enumere claramente el alcance de la prueba, la mano de obra, la duración, el contenido del trabajo, la evaluación de riesgos, la estrategia de respuesta a los riesgos, etc. en el documento.
⑥Script desarrollo : récord de rendimiento o escribir guiones, desarrollar y programas deflectores de prueba, y se desarrollan programas de prueba. Incluso si no hay una herramienta de terceros, es necesario desarrollar y probar el programa después de la herramienta de terceros.
> Programa deflector: Desarrollamos nuestro propio programa para reemplazar el soporte de un tercero.
>> Por ejemplo, si necesitamos interactuar con el sistema de aviación, pero la aerolínea no brinda soporte técnico, tenemos que desarrollar nuestro propio programa.
⑦Preparación del entorno de prueba: el entorno de prueba de rendimiento incluye dos partes: servidor y máquina de carga.
Servidor: la plataforma operativa del sistema bajo prueba (software, hardware)
Máquina de carga: la máquina que usamos para generar cargas, instalar herramientas de carga y ejecutar scripts.
⑧Preparación de datos de prueba : prepare los datos maestros y los datos comerciales del sistema probado de acuerdo con el modelo de datos.
⑨ Ejecución de la prueba : este paso es la clave para el éxito o el fracaso, porque diferentes personas, escenarios de diseño y ejecución de la prueba, por lo que los resultados pueden ser bastante diferentes.
⑩Gestión de defectos : defectos encontrados en el proceso de prueba de desempeño
⑪Análisis de desempeño : analice los problemas que pueden ser expuestos por los resultados de la prueba de desempeño para averiguar las razones.
>> Para saber cómo realizar el análisis de rendimiento, consulte el " Proceso de análisis de rendimiento " de Xiaoyu .
⑫ Ajuste del rendimiento : esto requiere colaboración. El evaluador de rendimiento y el líder de desarrollo deben trabajar juntos para resolver los problemas de rendimiento
>> Cómo realizar el ajuste del rendimiento, Consulte " Cómo ajustar el rendimiento " de
Xiaoyu ⑬ Informe de prueba: un resumen de los resultados de la prueba.
>> Los indicadores de rendimiento comunes incluyen: TPS, RT, uso de CPU, etc.
⑭Revisión del informe : revise el contenido del informe de rendimiento, confirme los problemas y evalúe el riesgo en línea / entrega.

2. Factores de éxito o fracaso

Xiaoyu recuerda que el artículo sobre análisis de desempeño decía: Si compara cada vínculo del proyecto con varias disciplinas, las pruebas de desempeño son integrales, integrando requisitos, desarrollo, pruebas, operación y mantenimiento, y coordinación y comunicación.
Hablemos de las principales dificultades de las pruebas de rendimiento desde los siguientes puntos:
① análisis de la demanda
② diseño de escenarios
③ diagnóstico y ajuste del rendimiento
④ construcción y simulación del entorno

Muchos evaluadores de rendimiento no analizaron los requisitos establecidos durante la etapa de análisis de requisitos y no estimaron con precisión los comportamientos del usuario. No pudieron simular bien las operaciones del usuario en la escena y no pudieron simular realmente la situación de carga del sistema. El
resultado final es: en la prueba o El entorno UAT está funcionando muy bien. Después de conectarse, los problemas ocurren con frecuencia y los resultados se pueden imaginar.
Al igual que: los
Juegos Olímpicos de 2008,
11.11 2012, un tesoro,
11.11 2012, un cierto Dong,
12306 el 9 de enero de
2014 y el sitio web de Amazon el 6 de noviembre de 2014.

Para los legos, o algunos grandes probadores de rendimiento, piensan que la prueba de rendimiento es usar una herramienta o escribir un script, obtener algunos servidores, "ejecutar" y luego emitir un informe, está bien.
Por lo general, preste atención a la cantidad de simultaneidad, el tiempo de respuesta que se puede ejecutar, etc.
Si la prueba de rendimiento es realmente así de simple, ¿es digno de las palabras desde empezar hasta darse por vencido? ~~~
A continuación, echemos un vistazo a los puntos importantes de las pruebas de rendimiento:
1. Evalúe el sistema y qué análisis de necesidades
no requiere claramente de los clientes. Valor,
necesitamos orientar a los líderes de operación y mantenimiento y a los líderes de demanda para que brinden datos de demanda específicos, y realizar un análisis secundario de los datos para obtener la información que necesitamos.
Para el sistema en línea por primera vez: necesitamos usar datos de pares para analizar el comportamiento del usuario y estimar la estructura de datos comerciales como un requisito previo para realizar cálculos para obtener los requisitos de rendimiento que queremos.
Para el sistema en línea: podemos obtener el TPS y el diagrama de distribución de la relación de tiempo, el número de usuario y el diagrama de distribución del tiempo, el diagrama de relación de ER de la base de datos, los datos de capacidad, etc., a través del personal de operación y mantenimiento, y obtener de manera directa y precisa el comportamiento actual del usuario del sistema y el negocio Relación de datos y luego obtener los requisitos de rendimiento que deseamos.
2. Diseño de escenarios y diseño de casos de uso
Debemos simular la carga del sistema en línea de la manera más realista posible.
¿Tenemos que decidir qué funciones deben participar en la ejecución del desempeño y cómo participar? Este es el diseño de casos de uso.
Cómo organizar eficazmente los casos de prueba es lo que debe hacer el escenario, como la asignación integral de la cantidad de usuarios, el tiempo de ejecución y el índice de ejecución de acuerdo con la distribución comercial, el volumen comercial, el período comercial y la función comercial.
Este diseño de escenarios y casos de uso lleva mucho tiempo.
3. Ejecución de la prueba, ya sea que el pase
simule diferentes escenarios de prueba de ejecución de carga para identificar debilidades del sistema, realizar varios monitoreos, detectar varios problemas, verificar la estabilidad del sistema, etc.
4. Optimización del diagnóstico de rendimiento
El líder de las pruebas de rendimiento debe tener una buena y aguda conciencia del rendimiento, ser capaz de refinar el problema (es decir, paso a paso) y ayudar a cada equipo de desarrollo en el posicionamiento, análisis y optimización del problema.

Tres, los grandes miran el rendimiento

Dado que el rendimiento es un tema integral, echemos un vistazo a los requisitos de estos grandes para el sistema desde diferentes perspectivas:
1. Perspectiva de los tipos de prueba de caja negra: se
preocupan por el tiempo de respuesta de un solo paso y el rendimiento de la aplicación. Si es bueno o malo, depende del tiempo de aplicación, es decir, el tiempo total de ida y vuelta del flujo de datos después de que el servidor / clúster de servidores se transmita a través de la red.
2. Desde la perspectiva de los jefes de desarrollo
① la racionalidad de la arquitectura
② la racionalidad del diseño de la base de datos
③ el código
④ el uso de la memoria en el sistema
⑤ el uso de subprocesos en el sistema
⑥ si los recursos del sistema son competencia despiadada e irrazonable
3. Perspectiva del jefe de operación y mantenimiento
① utilización de recursos de hardware Califique
②JVM ③DB
④ ¿El
sistema admite servicios 7x24? ⑤ Escalabilidad
, compatibilidad, capacidad máxima, posibles cuellos de botella
4. Prueba de rendimiento desde la perspectiva de ①
Rendimiento del hardware del servidor ② Objetivos de rendimiento
basados ​​en la demanda o datos históricos
③Establezca el modelo de aprobación de rendimiento ④
Sí Desarrollar el marco de código y el marco de hardware para el análisis de rendimiento
⑤ Realizar pruebas comparativas para la versión de desarrollo y lanzamiento
⑥ Realizar pruebas de estabilidad y aceptación del rendimiento del software
⑦ Proporción y optimización del entorno de producción
⑧ Realizar casos de prueba de rendimiento y diseño de escenarios
⑨ Coordinación entre la pieza
⑩ Análisis de desempeño específico

Cuatro, términos relacionados

1. Carga :
simule el proceso de operaciones comerciales que ejercen presión sobre el servidor, como 2000 usuarios que realizan pedidos.
2. Prueba de rendimiento:
simule la carga de usuarios para probar si el tiempo de respuesta del sistema, el rendimiento y otros indicadores cumplen con los requisitos de rendimiento bajo carga.
3. Prueba de carga (prueba de carga)
en un determinado entorno de software y hardware, aumentando continuamente la carga (el número de usuarios virtuales diferentes) para determinar el número máximo de usuarios que pueden soportar los indicadores de rendimiento.
>> Los indicadores de rendimiento aquí incluyen: TPS (transacciones por segundo), RT (tiempo de respuesta de transacción promedio), uso de CPU (uso de CPU), uso de memoria (uso de memoria) y otros indicadores de hardware y software.
4. Pruebas de configuración
Con el fin de asignar recursos de manera racional y mejorar la eficiencia del funcionamiento del sistema, el proceso de obtener, verificar y ajustar la información de configuración a través de métodos de prueba.
5. Stress Testing (Stress Testing)
en un determinado entorno de software y hardware, a través de medios de alta carga para hacer que los recursos del servidor (enfatizando los recursos del servidor, los recursos de hardware) estén en un estado límite, el sistema de prueba está en el estado límite durante mucho tiempo ¿Es estable la operación?
>> Determine indicadores estables, que incluyen: TPS (transacciones por segundo), RT (tiempo de respuesta de transacción promedio), uso de CPU (uso de CPU), uso de memoria (uso de memoria), etc.
6. Prueba de resistencia
En un determinado entorno de software y hardware, ejecute una determinada carga durante un tiempo prolongado para determinar si el sistema está funcionando de manera estable bajo la premisa de cumplir con los indicadores de rendimiento. Se hace hincapié aquí en que la prueba de estabilidad no se realiza por debajo del estado límite, que es diferente de la prueba de presión / resistencia del artículo 5 anterior.
Generalmente, aumentaremos la carga de 1,5 a 2 veces para realizar pruebas bajo la carga que cumpla con los requisitos de rendimiento.
7. El
número de transacciones completadas por TPS por segundo, generalmente se refiere al número de transacciones exitosas por segundo, un índice de desempeño integral importante en las pruebas de desempeño. Una transacción es una unidad de medida empresarial.
Por ejemplo: para
operaciones de pago, el sistema back-end puede experimentar sistemas de membresía, sistemas financieros, sistemas de pago, sistemas de contabilidad, pasarelas bancarias, etc. Sin embargo, para los usuarios, quiero saber cuánto gasto desde el pedido hasta el pago. Largo tiempo.
8. El tiempo de
respuesta / tiempo de respuesta promedio de RT / ART (tiempo de respuesta / tiempo de respuesta promedio) se refiere al tiempo que tarda una transacción en completarse. Más a menudo, contamos el tiempo de respuesta muchas veces y luego lo promediamos, lo que garantiza la precisión del tiempo y también es más representativo.
>> Por lo general, escribimos RT en lugar de ART.
9.PV (Vista de página)
El número de veces que el usuario visita la página por segundo.
>> Este parámetro se utiliza para analizar el número medio de usuarios que visitan la página por segundo
10. Vuser (usuario virtual)
número de usuarios virtuales. Es decir, el usuario virtual que simula los pasos lógicos del negocio real y los pasos operativos de la simulación del usuario virtual se registran en el script de usuario virtual. El usuario de la secuencia de comandos de Vuser describe las operaciones realizadas por el Vuser en el escenario.
11. Simultaneidad: hay
dos puntos principales para la simultaneidad: nivel de puntos y nivel de línea.
①En el nivel de puntos:
por ejemplo, a las 7:30 de la mañana del lunes, los estudiantes de la escuela primaria deben ir al patio de recreo para izar la bandera nacional.
>> Es decir: hacer algo al mismo tiempo ②En el
nivel de la línea:
Por ejemplo: 11: 30-13: 00 del mediodía, algunos estudiantes de la escuela primaria saltan bandas elásticas, algunos juegan fútbol, ​​pero al mismo tiempo ejercen presión sobre el servidor.
>> Es decir: hacer cosas diferentes en un período de tiempo. No
introduciré demasiado aquí. Para obtener más detalles, consulte los " Problemas comunes de concurrencia " escritos por Xiaoyu , que contiene una interpretación detallada de la concurrencia.
12. En el
proceso de prueba de desempeño del escenario , para simular el proceso de procesamiento comercial de usuarios reales, se denomina una colección de acciones basadas en transacciones, scripts, usuarios virtuales, configuraciones en ejecución, planes en ejecución, monitoreo y análisis integrados en LR. Este es el escenario de prueba de rendimiento.
>> El escenario incluye: scripts a ejecutar, grupos de scripts, números concurrentes, generadores de carga, objetivos de prueba, condiciones de configuración durante la ejecución de la prueba, etc.
13. Think Time (Think Time)
simula el intervalo de tiempo que los usuarios reales hacen una pausa durante las operaciones reales.
>> Desde una perspectiva empresarial: el tiempo de pensamiento es el intervalo de tiempo entre cada solicitud cuando el usuario está operando;
>> Del script de prueba: es el intervalo de tiempo entre dos declaraciones de solicitud.
14. La desviación estándar (Std. Desviación)
se deriva del concepto de estadística de datos, cuanto menor es la desviación estándar, menor es la fluctuación y más estable el sistema, por el contrario, más estable es el sistema.
>> Incluye: desviación estándar del tiempo de respuesta, desviación estándar de TPS, desviación estándar de Vuser en ejecución, desviación estándar de carga, CPU usando desviación estándar, etc.

Cinco, herramientas de rendimiento

Hay bastantes herramientas de prueba de rendimiento en el mercado, pero estamos familiarizados y usamos los JMeter y Loadrunner más utilizados. Entonces, ¿cómo elegimos las herramientas de prueba de rendimiento y qué herramientas de prueba de rendimiento hay?
No se preocupe, lo presentaremos lentamente.
1. Cómo elegir las herramientas de prueba de desempeño Cuando
elegimos herramientas, solo podemos considerar los siguientes aspectos:
①Profesional, estable y eficiente.
②Simple y fácil de usar, no es necesario dedicar demasiado tiempo a los scripts de prueba.
③Con soporte técnico y documentación sólida.
④La relación entre la entrada y la salida.
2. ¿Cuáles son las herramientas comunes de funcionamiento
①Loadrunner de la empresa HP
②Apache JMeter
③Grinder ④QALoad de
Compuware Compañía
⑤WAS de Microsoft Company
⑥WebLoad de RadView
Compañía ⑦RPT de IBM Company
⑧OPENSTA etc.
Aquí, Xiaoyu hace hincapié en que el núcleo de las pruebas de rendimiento no es la herramienta que se ha seleccionado, pero Es análisis de desempeño, lo importante es el pensamiento y la implementación, no tiene nada que ver con la elección de herramientas,
por lo que debemos analizar la prioridad.

Seis, pasa el estándar

Para juzgar si la prueba de rendimiento pasa, no solo depende de TPS y RT, sino que también se analiza el rendimiento del servidor, el rendimiento del front-end y el rendimiento de la experiencia del usuario.
Los estándares comunes para aprobar las pruebas son los siguientes:

Siete, resumen

Les he compartido la situación básica de la prueba de rendimiento. Creo que todos pueden entender y digerir bien estas posturas. No, es conocimiento.
Las pruebas de rendimiento requieren muchos requisitos, no solo habilidades profesionales, sino también habilidades de comunicación.
Para aprender mejor y dominar las pruebas de desempeño, también creo que necesita mejorarse desde una perspectiva de análisis. Después de todo, el punto central es el análisis de desempeño.