Solo por claridad, la prueba de esfuerzo que he escrito aumenta constantemente la carga en el sistema hasta que alcanza un punto de ruptura. Teóricamente se ejecuta indefinidamente, pero como los recursos del sistema son finitos, se espera que falle después de algún tiempo. Tengo una carga esperada para el sistema, pero esto se prueba por separado en una prueba de carga . El propósito de esta prueba de esfuerzo es descubrir cuánta carga puedo poner en el sistema antes de que necesite implementar el escalado.
Estoy en el proceso de escribir una prueba de esfuerzo para un sistema, y me pregunto si tiene sentido tener criterios de aprobación / reprobación. Por naturaleza de la prueba, la carga aumenta constantemente hasta que alcanza un punto de ruptura (es decir, falla ). Obviamente, no sé cuál es este punto de quiebre de antemano y, por lo tanto, no se espera la carga que el sistema puede manejar (en teoría, de todos modos).
Ahora tengo otras pruebas de rendimiento para probar el sistema bajo una carga esperada, etc., para las cuales puedo establecer fácilmente criterios de aprobación / falla, y podría usar estos criterios como base para mi prueba de esfuerzo. En otras palabras, podría establecer una línea de base mínima para que alcance mi prueba de esfuerzo, pero no estoy seguro de si esto es lo correcto (¿está 'duplicando' mi otra prueba?).
Espero que alguien con más experiencia en pruebas de rendimiento pueda ayudarme aquí. ¿Qué criterios de aprobación / reprobación han utilizado otros al realizar pruebas de estrés (si las hay)?
fuente
Respuestas:
En una prueba de esfuerzo, su trabajo no es definir el estrés que el sujeto debería ser capaz de soportar. Es para medir el estrés que se necesita antes de que falle.
Puede usar los criterios de rendimiento para definir qué es una falla de estrés. Pero el resultado de una prueba de esfuerzo no es aprobado / reprobado. Es "fallido después de 90 horas bajo 100% de utilización con ventilación 50% comprometida"
fuente
Depende de los requisitos, si sus requisitos especifican que el resultado esperado para el rendimiento de la aplicación es X y en realidad obtuvo Y, entonces es un Fallo.
Si no tiene requisitos definidos, puede estresar su sistema y recopilar datos de límites y luego descubrir y documentar estos límites.
fuente
Puede actualizar fácilmente su prueba de esfuerzo primaria para admitir también una verificación de aprobación / falla de control de calidad, algo así como "capaz de alcanzar / sostener la carga X sin romperse". Idealmente con X siendo configurable (para diferentes ramas de lanzamiento, por ejemplo).
El resultado sería
failsi el sistema se rompe antes de que la carga alcance X ypasssi no se rompe. Simplemente tendría que dejar de aumentar la carga una vez que alcanza el valor X en un escenario "sostenido".En mi humilde opinión, una prueba automatizada como esta puede ser muy útil en el contexto de CI / CD, especialmente en las ramas de producción.
fuente