7 años de experiencia: el método de diseño de escenarios de prueba de rendimiento

fondo

Cita : Según un informe de investigación de Aberdeen Group de 2008, para los sitios web, un retraso de carga de página de 1 segundo equivale a reducir el PV (vista de página) en un 11 %, lo que equivale a reducir la satisfacción del cliente en un 16 %. Desde un punto de vista monetario, significa que si un sitio web gana 100 000 yuanes al día, puede perder un total de 250 000 yuanes en ventas en un año porque la velocidad de carga de la página es 1 segundo más lenta que la de la competencia.

Compuware analizó más de 150 sitios web y 1,5 millones de páginas vistas y descubrió que un aumento en el tiempo de respuesta de la página de 2 segundos a 10 segundos conduce a una tasa de abandono de páginas vistas del 38 %. Se puede ver que el rendimiento del sitio web tiene una relación directa con los objetivos comerciales, y es muy importante realizar pruebas de rendimiento en los sitios web.

Los estudiantes que realizan pruebas de rendimiento saben que hay muchos escenarios en la ejecución del rendimiento, y cada empresa tendrá sus propios sustantivos de escenario definidos que no se enumeran aquí. Generalmente uso cuatro escenarios para el rendimiento (escenario de referencia, escenario de capacidad, escenario de estabilidad, escenario de excepción ) para cubrir un requisito de rendimiento. Hablemos de cómo se implementan estos cuatro escenarios y cómo cubrir los requisitos de rendimiento.

aterrizaje real

Antes de hablar sobre los cuatro escenarios, hablemos sobre el proceso general de prueba de desempeño. El proceso es la regla. En Mencius - "Li Lou Chapters and Sentences": " Li Lou Zhiming, la coincidencia del público pierde al hijo, y si no sigues las reglas, no puedes hacer un cuadrado ". Después de tener este proceso, no perderá el tiempo cuando se encuentre con pruebas de rendimiento y podrá trabajar de acuerdo con este proceso.

En cuanto a lo que se debe hacer para cada acción, la persona que realiza la prueba de rendimiento sabrá lo que se debe hacer de un vistazo, por lo que no explicaré el contenido específico aquí. Una vez que hayamos completado las condiciones previas, podemos llevar a cabo el diseño y la ejecución de la escena. El análisis de rendimiento no se explicará en esta lección. Aquí se usa la herramienta de presión de Jmeter. TPS se refiere al valor de rendimiento en el componente Informe de resumen en Jmeter, y la interfaz de back-end no se considera. Para el tiempo de carga de elementos de página como js y css en la página de inicio, también se pueden usar otras herramientas de estrés en la prueba de rendimiento específica. No hay límite para qué herramienta de estrés Aquí explicamos principalmente cómo usar la escena.

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036

 

Escenario de referencia

El escenario de referencia es una interfaz única para las pruebas de estrés. Si todo el mundo sabe esto, ¿cómo debemos hacer el escenario de referencia?

• Preparación ambiental

Las empresas de Internet generalmente eligen las pruebas de estrés en línea para las pruebas de rendimiento. Todos sabemos que el costo de construir un entorno de prueba de estrés que sea consistente con el entorno en línea es relativamente alto, como los costos de hardware, costos de software, costos de mano de obra, costos de mantenimiento, etc. , por lo que las empresas de Internet eligen las pruebas de estrés en línea. Para las empresas de Internet que no son de primera línea o las industrias tradicionales, las pruebas de estrés generalmente se realizan en un entorno de prueba. Las compañías bancarias y de seguros en las que he trabajado tienen sus propios entornos de pruebas de estrés. Sus entornos son relativamente independientes y es relativamente fácil hacer pruebas de estrés y ajuste Es más conveniente.

En el entorno de prueba de estrés, se recomienda que la configuración de la máquina sea consistente con la configuración de la máquina en línea, y la configuración del contenedor de la aplicación también debe ser consistente con el entorno en línea. Solo de esta manera los resultados de la prueba de estrés pueden ser verdaderos. sin rodeos, el entorno de la prueba de estrés debe ser coherente con el entorno en línea. Si no es coherente, debe reducirse de acuerdo con una determinada proporción.

• preparación de datos

Para la preparación de datos, debemos tener en cuenta la cantidad de datos de ropa de cama en el entorno de la prueba de esfuerzo. Generalmente, la fuente de datos de ropa de cama es la base de datos de supervivencia real después de la desensibilización. Antes de que comience la prueba de esfuerzo, es necesario hacer una copia de seguridad de la base de datos para facilitar la resolución de problemas. y ubicación del problema. Si la cantidad de datos es inconsistente con la cantidad de datos en línea, los resultados de la prueba de estrés no serán confiables. Puede pensar en el rendimiento de unos pocos cientos de bases de datos y un millón o decenas de millones de bases de datos en línea. Durante la prueba, la cantidad de datos de ropa de cama en el entorno de prueba de esfuerzo debe ser considerado.

• Preparación de parámetros

Al hacer scripts de pruebas de estrés de rendimiento, necesitamos preparar datos parametrizados. Muchas personas piensan que unos pocos datos son suficientes para las pruebas de rendimiento y que no se necesita una gran cantidad de datos para las pruebas de rendimiento. Esto hará que la presión sea inconsistente. con el entorno de vida real Por ejemplo, decenas de piezas de datos Las operaciones de datos generan decenas de millones o incluso cientos de millones de negocios, por lo que es difícil decir la credibilidad de los escenarios obtenidos de la prueba de esfuerzo. Entonces, ¿cuántos parámetros son razonables?

Para responder a esta pregunta, es necesario determinar en qué escenario se utiliza la parametrización, porque el escenario es diferente y los datos parametrizados también son diferentes, si no se considera el escenario, 100 hilos, TPS es 800, el sistema se ejecuta para 1 hora, tipo de datos y restricciones y cantidades se calculan de la siguiente manera:

Si se tiene en cuenta el escenario, analizaremos qué tipo de datos se utilizan de acuerdo con el escenario comercial real para calcular la cantidad de datos parametrizados. Los datos aquí incluyen datos repetidos y no repetidos. Aquí usamos nuestro inicio de sesión unificado como ejemplo Para el inicio de sesión El negocio requiere dos parámetros, uno es el número de cuenta y el otro es la contraseña (esto no considera iniciar sesión a través del código de verificación), el número de cuenta y la contraseña deben poder iniciar sesión en el sistema , de lo contrario, las operaciones comerciales posteriores no se pueden completar. Obviamente, diferentes personas deben iniciar sesión con diferentes cuentas.

➢ Escena 1

Cuando estamos escribiendo scripts, configuramos tantos usuarios como subprocesos, y dejamos que cada subproceso use el mismo usuario para realizar operaciones comerciales en un bucle. Sin embargo, dicha configuración de parámetros solo puede cumplir con escenarios comerciales específicos. Use el token para operar el negocio, y salir del sistema después del trabajo En tal escenario, necesitamos preparar tantos datos de usuario como subprocesos.

➢ Escenario 2

Para un sistema de comercio electrónico, no es recomendable seguir los parámetros anteriores, porque el comportamiento de comprar bienes continuamente con una cuenta es completamente inconsistente con la escena real.¿Qué debemos hacer en este momento? En tal escenario, debemos considerar el TPS y la duración, la referencia del método de cálculo de datos del usuario:

➢ Escena tres

Si un subproceso puede reciclar parámetros fijos, en este caso debemos juzgar de acuerdo con el negocio real, por ejemplo, en el caso de 100 subprocesos de presión, preparamos 1000 piezas de datos, y podemos dejar que cada subproceso use 10 piezas diferentes de datos. No hay un límite fijo en la cantidad de escenarios de este tipo, y solo se puede juzgar en función del negocio real. Sin embargo, antes de configurar este parámetro, debe considerar el tipo del parámetro. Si se trata de datos reciclables, es muy raro en escenarios reales de actuación, es decir, solo No existen básicamente escenarios reales utilizando uno o varios datos de prueba.

• datos paramétricos

Después de saber cuántos parámetros se utilizan, es necesario resolver dónde obtener los datos parametrizados. El propósito de este paso es asegurar que los datos de los parámetros sean válidos. Generalmente, tenemos dos fuentes de datos parametrizados, una es la existencia de la base de datos de fondo, y la otra es la ausencia de la base de datos Datos creados por herramientas de presión.

En resumen, las fuentes de datos parametrizados deben garantizar la validez de los datos, y estos datos deben cumplir las dos condiciones siguientes:

✓ Satisfacer la distribución de datos del entorno de producción

✓ Cumplir con los requisitos de volumen de datos en escenarios de rendimiento

Para un sistema, si los datos parametrizados son razonables afectará directamente si los resultados de la prueba de estrés son significativos. Si la cantidad de datos utilizada por la herramienta de presión es pequeña, entonces el servidor de aplicaciones, el servidor de caché, el servidor de base de datos, etc. usarán una pequeña cantidad de caché para el procesamiento, lo que resultará en la incapacidad de ocupar la caché de varios servidores back-end. al tamaño que debería tener en la escena real, por lo que en este estado, no se puede probar la presión en la escena real.

También hay implicaciones para los dispositivos de almacenamiento adjuntos a bases de datos. Si la cantidad de datos es pequeña, el uso de E/S de almacenamiento correspondiente es bajo. Si se obtienen demasiados parámetros, la presión sobre el sistema será grande; si se obtienen muy pocos parámetros, que no se ajustan al volumen de datos en la escena real, no se puede probar la presión real del sistema.

Si los parámetros provienen de una base de datos, generalmente queremos verificar el histograma de datos en la base de datos. Para datos tomados directamente de producción, la distribución de datos es más precisa. Pero para algunos datos creados en el entorno de prueba, es necesario verificar si la distribución de datos es consistente con la producción después de que se crean los datos. Después de los preparativos anteriores, puede comenzar con la evaluación comparativa. Debemos prestar atención a dos puntos al realizar la evaluación comparativa:

¿Cuándo terminamos con el escenario de referencia en nuestra implementación? ¿O en qué circunstancias se puede terminar el escenario de referencia? Por lo general, durante la prueba de estrés, la tasa de utilización de los recursos del sistema de las llamadas de interfaz alcanza el 90 % o los recursos del sistema se agotan por completo, luego se puede detener el escenario de referencia. Tenga en cuenta que es necesario ajustar los problemas de rendimiento para garantizar que los recursos se utilicen por completo. , para lograr TPS y el tiempo de respuesta es el más razonable.

Escenario de capacidad

Para el escenario de capacidad, es combinar todas las interfaces del escenario de referencia anterior en una cierta proporción y ejecutarlas juntas. El propósito del escenario de capacidad es responder a la pregunta "¿cuál es la capacidad máxima en línea?". Aquí hay un problema: ¿cómo determinar la relación entre la interfaz y la interfaz? ¿Cómo configurarlo en la herramienta de presión? Si estos problemas no se pueden resolver, no podremos diseñar escenarios de capacidad. Algunos estudiantes pueden decir que es suficiente poner todas las interfaces en una escena y ejecutarlas directamente en múltiplos de 1, 2 y 3 veces. Hay no es necesario tener en cuenta la proporción de cada interfaz. Simplemente ejecute el valor máximo directamente, pero hay una brecha entre la escena y la escena real, y la escena que sale está fuera de la realidad, entonces, ¿cómo debemos diseñarla? Otra pregunta es ¿cuándo se detendrá el escenario de capacidad?

En primer lugar, podemos extraer registros de producción. Creo que todas las empresas tienen un sistema de registro. Si no hay un sistema de registro, puede usar el comando awk para extraer registros, y también puede usar ELFK para extraer registros. Después de tener el datos anteriores, puede ordenar la lógica empresarial.

Nuestra empresa puede obtener los registros de prueba de estrés a través de la plataforma lambda y obtener los datos de la interfaz que queremos durante un período de tiempo a través de las condiciones de búsqueda:

Si no existe tal sistema, podemos obtener datos relevantes en los registros de Nginx, que se pueden procesar escribiendo scripts de python o usando comandos de shell para obtener los datos que queremos.Necesitamos el formato de datos como:

De esta forma, podemos saber el número de cada solicitud en cada periodo de tiempo, y podemos obtener el ratio de negocio correspondiente.

Si se trata de ELFK extrayendo registros de supervivencia, puede instalar una configuración de entorno de este tipo usted mismo, establecer las condiciones pertinentes y extraer los tipos de datos de la relación correspondiente de los datos anteriores.

Nota: Si el punto de tiempo de alta simultaneidad de una determinada solicitud no está en el mismo punto de tiempo que otras solicitudes, se deben simular varios escenarios, porque el modelo comercial en el escenario cambiará.

Suponiendo que podemos obtener la proporción de llamadas a solicitudes de la interfaz probada a través de los pasos anteriores, también podemos dividir la cantidad de ciertas solicitudes por la cantidad total de solicitudes para obtener la proporción de cada interfaz Aquí usamos una tabla para ilustrar (tenga en cuenta que los datos son hipotéticos):

Aquí hay un resumen de los pasos para obtener la relación de datos de producción:

Tenga en cuenta que puede haber varios escenarios comerciales en el proceso de estadísticas comerciales del proyecto real. Esta idea puede resolver cualquier inconsistencia entre escenarios de desempeño y escenarios de producción. Después de obtener el índice comercial, debemos ordenar los escenarios comerciales y utilizar los escenarios para cubrir el índice comercial. ¿Cómo se debe diseñar el índice del escenario? Puede pensar en ello y diseñar varios escenarios que puedan cubrir el índice comercial de la interfaz anterior. No lo explicaré aquí, y puede pensarlo usted mismo.

En JMeter, el temporizador de rendimiento se utilizará para controlar TPS.

Con respecto a la relación de escena del controlador de controlador de rendimiento, puede verificar la información y resolverlo.

Con los índices comerciales anteriores, ¿podemos pensar cuándo terminará el escenario de capacidad? Necesitamos determinar un objetivo al hacer escenarios de capacidad, de lo contrario, no habrá un punto de tiempo final. ¿Aún recuerda que cuando asignamos proporciones comerciales, asignamos una cantidad total de datos a cada interfaz como una proporción, y esta cantidad total es el objetivo de nuestra prueba de capacidad?

Escenario de estabilidad

Mencionamos anteriormente que el escenario de capacidad es para ver la capacidad máxima que el sistema puede soportar, mientras que el escenario de estabilidad analiza principalmente la estabilidad del rendimiento del sistema cuando proporciona servicios a largo plazo, y observa el efecto acumulativo del sistema durante períodos prolongados. operación a plazo. Por lo tanto, el tiempo de ejecución es un indicador muy importante en el escenario de estabilidad.

Aquí debemos entender que el tiempo de ejecución de estabilidad no es fijo, depende de los escenarios de aplicación específicos del sistema comercial, entonces, ¿cómo se debe calcular el tiempo de estabilidad? Aquí se proporciona un método de cálculo para calcular el tiempo de ejecución.

Supongamos que de acuerdo a las estadísticas del sistema de producción, en el ciclo anterior de operación y mantenimiento se tenía una capacidad comercial de 60 millones, y el máximo TPS obtenido en el escenario de capacidad fue de 1000. Entonces, podemos calcular con la siguiente fórmula:

Tiempo de ejecución estable = 60 millones (volumen de negocios acumulado) ÷ 1000 (TPS) ÷ 3600 (segundos) ≈ 16 (horas).

No importa qué tipo de sistema sea, si desea ejecutar un escenario estable, debe determinar un volumen de negocios acumulativo (el volumen de negocios total a la vez) Cuando lo ejecutamos, usamos directamente el TPS máximo para ejecutarlo. Si un sistema es normal bajo el estado de TPS máximo Solo mediante la ejecución podemos verificar si el sistema puede resistir la prueba.

escena anormal

En el diseño de escenarios anómalos, primero se analiza la arquitectura del sistema, y ​​los puntos de demanda en los escenarios anómalos se analizan primero, y luego se diseñan los casos correspondientes para cubrirlos. ¿Por qué analizar la arquitectura del sistema? Porque en una aplicación, después de haber probado la función, normalmente hay dos tipos de problemas anormales: uno es la anomalía del nivel de arquitectura, el otro es la anomalía de rendimiento causada por la capacidad. Para las excepciones a nivel arquitectónico, solo podemos analizarlas desde la perspectiva de la arquitectura.

Desde la perspectiva de la tecnología de rendimiento, se utilizan básicamente métodos de prueba comunes, como fallas de host, fallas de red y fallas de aplicaciones. Ahora hay herramientas de caos en el mercado, y también puede usar herramientas de caos para realizar pruebas anormales, lo que proporciona algunos métodos para ayudar a todos a hacer la operación:

✓ Host: apagar, reiniciar, apagar, etc.;

✓ Red: apague la tarjeta de red con el comando ifdown, simule pérdida de paquetes de jitter, retransmisión retardada, etc.;

✓ Aplicar: matar, detener, etc.

Hablemos aquí de la lógica del diseño de escenarios anormales. El primer paso es enumerar todos los componentes en la arquitectura técnica y analizar los puntos que pueden causar anomalías. El segundo paso es diseñar escenarios correspondientes basados ​​en el análisis de puntos anormales. En muchos casos, se basa en sentimientos, lo que conducirá a una cobertura incompleta de escenarios anormales. Aquí, se recomienda referirse al modelo de falla FMEA para diseñar escenarios anormales, porque FMEA nos permite tener reglas a seguir. Debe ser Observé aquí que existe una lógica para cualquier metodología. No la use en exceso cuando se trata de la práctica, pero preste atención a la racionalidad del contenido.

Esto es solo para proporcionar una idea de diseño. Cuando aterrice, puede usar los que no se ajusten a su empresa o práctica. Espero que pueda diseñar un conjunto de modelos de escenas anormales que se ajusten a su propio sistema.

Los siguientes son materiales de apoyo para el aprendizaje. Para los amigos que hacen [pruebas de software], debería ser el almacén de preparación más amplio y completo. Este almacén también me acompañó en el viaje más difícil. ¡Espero que también pueda ayudarlos!

subprograma de entrevista de prueba de software

¡El banco de preguntas de prueba de software maximizado por millones de personas! ! ! ¡Quién es quién sabe! ! ! El mini programa de cuestionarios más completo de toda la red, puedes usar tu teléfono móvil para hacer los cuestionarios, en el metro o en el autobús, ¡enróllalo!

Se cubren las siguientes secciones de preguntas de la entrevista:

1. Teoría básica de las pruebas de software, 2. web, aplicación, pruebas de funciones de interfaz, 3. red, 4. base de datos, 5. linux

6. web, aplicación, automatización de interfaz, 7. pruebas de rendimiento, 8. conceptos básicos de programación, 9. preguntas de la entrevista de hora, 10. preguntas de prueba abiertas, 11. pruebas de seguridad, 12. conceptos básicos de informática

Método de adquisición de información: