¿Cuáles son los métodos de prueba de rendimiento más utilizados?

1. Pruebas de carga

Aquí, las pruebas de carga se refieren a las pruebas de rendimiento más comunes realizadas para verificar los requisitos generales de rendimiento. Anteriormente mencionamos que los requisitos de rendimiento más comunes de los usuarios son "tanto los caballos corriendo como yo quiero que los caballos coman". menos pasto”. Por lo tanto, las pruebas de carga examinan principalmente el rendimiento del sistema de software bajo una carga determinada. Podemos tener la siguiente comprensión de las pruebas de carga:

(1) Las pruebas de carga consisten en observar el rendimiento del sistema de software bajo ciertas condiciones desde la perspectiva del usuario.

(2) El resultado esperado de la prueba de carga es que se cumplan los requisitos de rendimiento del usuario. Este indicador generalmente se refleja en el tiempo de respuesta, capacidad de transacción, capacidad de concurrencia, uso de recursos, etc.

2. Pruebas de estrés

Las pruebas de estrés consisten en examinar el rendimiento del sistema en condiciones extremas que pueden sobrecargar el volumen de transacciones y el número de usuarios concurrentes. Tenga en cuenta que esta condición extrema no es necesariamente el requisito de rendimiento del usuario; puede ser mucho mayor que el requisito de rendimiento del usuario. Se puede entender que la diferencia entre las pruebas de estrés y las pruebas de carga es que el resultado esperado de las pruebas de estrés es que ocurran problemas en el sistema, y ​​lo que queremos examinar es la forma en que el sistema maneja los problemas. Por ejemplo, esperamos que un sistema permanezca estable bajo estrés y que las velocidades de procesamiento puedan disminuir, pero no colapsar. Por lo tanto, las pruebas de estrés nos permiten identificar las debilidades del sistema y cómo se desempeñará el programa bajo una carga extrema.

Ejemplo: las pruebas de carga se ocupan de las reglas y requisitos del usuario, mientras que las pruebas de estrés se ocupan del sistema de software en sí. Para conocer sus diferencias, podemos usar el ejemplo de la teoría de la espada de Huashan para describirlas más vívidamente. Si se considera a Guo Jing como el sujeto de la prueba, entonces la prueba de estrés es como Guo Jing y Ouyang Feng, que se ha vuelto loco y no tiene rutina, tratando de derrotar al oponente tanto como sea posible. Guo Jing debe poder manejarlo sin perder la vida. La prueba de rendimiento convencional es como el acuerdo entre Guo Jing, Huang Yaoshi y Hong Qigong de que mientras Guo Jing pueda realizar cien movimientos de los dos maestros respectivamente, Guo Jing ganará. En cuanto a que Guo Jing pierda después de trescientos movimientos, no se preocupe. Mientras pueda realizar los siguientes cien movimientos, pasará.

Pensamiento

Cuando realizamos pruebas de estrés de software, a menudo necesitamos agregar más usuarios y transacciones concurrentes que las pruebas de carga.

3． Pruebas de concurrencia

Verifica las capacidades de procesamiento concurrente del sistema. Generalmente, se establece una gran cantidad de conexiones simultáneas con el servidor y el tiempo de respuesta del cliente y el monitoreo del rendimiento del servidor se utilizan para determinar si el sistema ha alcanzado el índice de concurrencia establecido. Las pruebas de carga a menudo utilizan la concurrencia para crear carga. La razón por la que las pruebas de concurrencia se mencionan por separado es porque las pruebas de concurrencia a menudo involucran la capacidad concurrente del servidor y los problemas que pueden surgir de la coordinación y sincronización de múltiples procesos/multiprocesos. Esto requiere atención especial y debe ser probado.

4. Pruebas comparativas

Cuando se agrega un nuevo módulo al sistema de software, se requieren pruebas comparativas para determinar el impacto en el rendimiento del nuevo módulo en todo el sistema de software. De acuerdo con el método de prueba comparativa, debe abrir/cerrar el nuevo módulo y probarlo al menos una vez cada uno. Los indicadores de rendimiento del sistema antes de apagar el módulo se marcan como puntos de referencia y luego se comparan con los indicadores de rendimiento del sistema cuando se enciende el módulo para determinar el impacto del módulo en el rendimiento del sistema.

5． Prueba de estabilidad

"El camino está lejos para conocer los caballos de fuerza", de lo que estamos hablando aquí es de la prueba de estabilidad relacionada con la prueba de rendimiento, es decir, para probar si el sistema tendrá problemas después de ejecutarse. bajo una determinada carga durante mucho tiempo. Algunos problemas de los sistemas de software no se pueden exponer de inmediato o lleva tiempo acumularlos hasta un nivel mensurable. ¿Por qué se necesita tal prueba? Porque algunos problemas de software sólo quedan expuestos después de ejecutarse durante un día, una semana o incluso más. Este problema generalmente se debe a que el programa ocupa recursos pero no los libera a tiempo. Por ejemplo, el problema de la pérdida de memoria se hará evidente gradualmente después de un período de acumulación, pero es difícil de detectar en las primeras etapas de operación, y también hay clientes y servidores que han establecido una gran cantidad de rutas de conexión después de la carga; funcionando durante un período de tiempo, pero no se puede reutilizar de manera efectiva ni liberar rápidamente.

6． Pruebas recuperables

Prueba si el sistema puede recuperarse rápidamente de un estado de error a un estado normal. Por ejemplo, en un sistema equipado con equilibrio de carga, después de que el host está bajo presión y no puede funcionar normalmente, si la máquina de respaldo puede hacerse cargo de la carga rápidamente. Las pruebas recuperables generalmente se realizan junto con las pruebas de estrés.

Consejo: Cada prueba tiene su lugar y finalidad. Cuando nos hacemos cargo de un proyecto de software, con recursos limitados, la elección de qué tipo de pruebas realizar debe basarse en la etapa actual del proceso de software y las características del proyecto en sí. Por ejemplo, las pruebas comparativas deben realizarse durante las pruebas de integración y las pruebas de rendimiento deben realizarse en cada punto de lanzamiento del producto de software.