Menú

Diferencia entre el plan de prueba de rendimiento y la estrategia de prueba de rendimiento

  • Principal
  • Otro
  • Diferencia entre el plan de prueba de rendimiento y la estrategia de prueba de rendimiento

difference between performance test plan

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Cuál es la diferencia entre el plan de prueba de rendimiento y la estrategia de prueba?

En esto Serie de pruebas de rendimiento , nuestro tutorial anterior, explicado sobre Pruebas funcionales frente a pruebas de rendimiento en detalle.

=> Haga clic aquí para ver la serie completa de tutoriales de pruebas de rendimiento

En este tutorial, aprenderá la diferencia entre el plan de prueba de rendimiento y la estrategia de prueba y el contenido que se incluirá como parte de estos documentos.

Plan de prueba de rendimiento vs estrategia de prueba

Entendamos la diferencia entre estos dos documentos.

Lo que vas a aprender:

Estrategia de prueba de rendimiento

El documento Performance Test Strategy es un documento de alto nivel que nos brinda información sobre cómo llevar a cabo las pruebas de rendimiento durante la fase de prueba. Nos dice cómo probar un requisito comercial y qué enfoque se requiere para entregar con éxito el producto al cliente final.

Esto tendrá toda la información sobre el proceso empresarial a un nivel muy alto.

Este documento generalmente lo redactan los gerentes de pruebas de rendimiento en función de su experiencia previa, ya que solo habrá información limitada disponible, ya que este documento se prepara durante las etapas iniciales del proyecto, es decir, durante la fase de análisis de requisitos o después de la fase de análisis de requisitos.

Entonces, en otras palabras, un documento de Estrategia de prueba de desempeño no es más que una dirección que usted establece al inicio del proyecto con el enfoque que va a tomar para lograr los objetivos de las pruebas de desempeño.

Un documento típico de estrategia de prueba de rendimiento contiene el objetivo general de las pruebas de rendimiento, ¿qué se probará? ¿Qué entorno se utilizará? ¿Qué herramientas se utilizarán? ¿Qué tipo de pruebas se realizarán? Criterios de entrada y salida, ¿qué riesgos de un interesado se mitigan? y algunos más, que veremos en detalle a medida que avancemos en este tutorial.

Estrategia de prueba de rendimiento

El diagrama anterior explica que el documento de estrategia de prueba de rendimiento se crea durante o después de la fase de análisis de requisitos del proyecto.

Plan de prueba de rendimiento

El documento del plan de prueba de rendimiento se escribe en una etapa posterior del proyecto cuando los requisitos y los documentos de diseño están casi congelados. El documento del Plan de Prueba de Desempeño contiene todos los detalles del cronograma para implementar la estrategia o Enfoque que se describió durante la Fase de Análisis de Requisitos.

A partir de ahora, los documentos de diseño están casi listos, el plan de prueba de rendimiento contiene todos los detalles sobre los escenarios a probar. También tiene más detalles sobre los entornos que se utilizan para las pruebas de rendimiento, cuántos ciclos de pruebas, recursos, criterios de entrada y salida y más. El plan de prueba de rendimiento lo redacta el administrador de rendimiento o el jefe de prueba de rendimiento.

Plan de prueba de rendimiento

El diagrama anterior explica claramente que el plan de prueba de rendimiento se crea durante el diseño del proyecto o después de la fase de diseño en función de la disponibilidad de los documentos de diseño.

Contenido del documento de estrategia de prueba de rendimiento

Veamos ahora qué se debe incluir en un documento de estrategia de prueba de rendimiento:

#1. Introducción: Brinde una breve descripción general de lo que contendrá un documento de estrategia de prueba de desempeño para ese proyecto en particular. Además, mencione los equipos que utilizarán este documento.

¿Dónde puedo ver anime en línea?

#2. Alcance: Definir el alcance es muy importante porque nos dice cuál será exactamente el rendimiento probado. Necesitamos ser muy específicos al definir el alcance o cualquier otra sección.

Nunca escriba nada generalizado. El alcance nos dice qué se probará exactamente para todo el proyecto. Tenemos Dentro del alcance y Fuera de alcance como parte del alcance, En alcance describe todas las características que serán probadas en rendimiento y Fuera de alcance describe las características que no se probarán.

# 3) Prueba Acercarse: Aquí debemos mencionar el enfoque que vamos a seguir para nuestras pruebas de rendimiento, ya que cada script se ejecutará con un solo usuario para crear una línea de base y luego estas pruebas de línea de base se utilizarán como referencia para la evaluación comparativa en un punto posterior de tiempo durante las pruebas de funcionamiento.

Además, cada componente se probará individualmente antes de integrarlos y así sucesivamente.

# 4) Prueba Tipos: Aquí mencionamos los diferentes tipos de pruebas a cubrir, como Prueba de carga, Prueba de esfuerzo, Prueba de resistencia, Prueba de volumen, etc.

# 5) Prueba Entregables: Mencione todos los entregables que se proporcionarán como parte de las pruebas de rendimiento para el proyecto, como el informe de ejecución de la prueba, el informe de resumen ejecutivo, etc.

# 6) Medio ambiente: Aquí debemos mencionar los detalles del medio ambiente. Los detalles del entorno son muy importantes, ya que describen qué sistemas operativos se utilizarán para las pruebas de rendimiento.

Si el medio ambiente será una réplica de la producción o si se aumentará o reducirá el tamaño de la producción y también la proporción de dimensionamiento hacia arriba y hacia abajo, es decir, ¿será la mitad del tamaño de la producción o será el doble del tamaño de la producción? ?

Además, debemos mencionar claramente los parches o actualizaciones de seguridad que se considerarán parte de la configuración del entorno y también durante la ejecución de la prueba de rendimiento.

# 7) Herramientas: Aquí debemos mencionar todas las herramientas que se utilizarán como herramientas de seguimiento de defectos, Herramientas administrativas , Pruebas de rendimiento y herramientas de supervisión. Algunos Ejemplos de herramientas para el seguimiento de defectos es JIRA , Para la gestión de documentos como Confluence, para pruebas de rendimiento Jmeter y para monitorear Nagios .

# 8) Recursos: Los detalles de los recursos necesarios para el equipo de pruebas de rendimiento se documentan en esta sección. Por ejemplo , Performance Manager, Performance Test Lead, Performance Testers, etc.

# 9) Entrada & Salida Criterios: Los criterios de entrada y salida se describirán en esta sección.

Por ejemplo,

Criterio para entrar - La aplicación debe ser funcionalmente estable antes de implementar la compilación para pruebas de rendimiento.

Criterio de salida - Se cierran todos los defectos principales y se cumplen la mayoría de los SLA.

# 10) Riesgo y mitigación: Cualquier Riesgo que afecte a las Pruebas de Desempeño debe enumerarse aquí junto con el plan de mitigación para el mismo. Esto evitará que se produzcan riesgos durante las pruebas de rendimiento o, al menos, se planificará una solución alternativa para el riesgo con mucha antelación. Esto ayudará a completar los programas de pruebas de rendimiento a tiempo sin afectar los entregables.

# 11) Abreviaturas: Se utiliza para abreviaturas. Por ejemplo, PT - Prueba de rendimiento.

# 12) Historial de documentos: Contiene la versión del documento.

Contenido del documento del plan de prueba de rendimiento

Echemos un vistazo a todo lo que debería incluirse en un documento del plan de prueba de rendimiento:

#1. Introducción: Es todo lo mismo que se indica en el documento de Estrategia de prueba de rendimiento, en lugar de mencionar el Plan de prueba de rendimiento en lugar de la Estrategia de prueba de rendimiento.

# 2) Objetivo: ¿Cuál es el objetivo de esta prueba de rendimiento? ¿Qué se logra mediante la realización de pruebas de rendimiento? Es decir, cuáles son los beneficios de realizar pruebas de rendimiento.

# 3) Alcance : Aquí se define el alcance de las pruebas de rendimiento, tanto dentro como fuera del alcance del proceso empresarial.

# 4) Enfoque: El enfoque general se describe aquí, ¿cómo se llevan a cabo las pruebas de rendimiento? ¿Cuáles son los requisitos previos para configurar el entorno? etc están incluidos.

# 5) Arquitectura: Los detalles de la arquitectura de la aplicación deben mencionarse aquí, como el número total de servidores de aplicaciones, servidores web, servidores de bases de datos, firewalls, 3rdAplicación del partido Máquinas generadoras de carga, etc.

# 6) Dependencias: Todas las acciones de pruebas previas al rendimiento deben mencionarse aquí, como que los componentes que se probarán el rendimiento son funcionalmente estables, el entorno se escala a una producción como una y está disponible o no, la fecha de prueba está disponible o no, las herramientas de prueba de rendimiento están disponibles con licencias si hay alguno y así sucesivamente.

# 7) Medio ambiente: Debemos mencionar todos los detalles del sistema como la dirección IP, cuántos servidores, etc. También debemos mencionar claramente cómo se debe configurar el entorno, los requisitos previos, los parches que se actualizarán, etc.

# 8) Escenarios de prueba: En esta sección se menciona la lista de escenarios a probar.

# 9) Mezcla de carga de trabajo: La combinación de carga de trabajo juega un papel vital en la ejecución exitosa de la prueba de rendimiento y si la combinación de carga de trabajo no predice la acción del usuario final en tiempo real, entonces todos los resultados de la prueba son en vano y terminamos con un rendimiento deficiente en producción. cuando la aplicación se active.

De ahí que sea necesario diseñar adecuadamente la carga de trabajo. Comprenda cómo acceden los usuarios a la aplicación en producción y si la aplicación ya está disponible o intente obtener más detalles del equipo comercial para comprender correctamente el uso de la aplicación y definir la carga de trabajo.

# 10) Ciclos de ejecución de rendimiento: En esta sección se describirán los detalles del número de ejecuciones de prueba de rendimiento. Por ejemplo, Prueba de línea base, prueba de usuario del ciclo 1 50, etc.

# 11) Métricas de prueba de rendimiento: Los detalles de las métricas recopiladas se describirán aquí, estas métricas deben estar en criterios de aceptación con los requisitos de desempeño acordados.

# 12) Entregables de prueba: Mencione los entregables y también incorpore los enlaces a los documentos cuando corresponda.

# 13) Gestión de defectos: Aquí debemos mencionar cómo se manejan los defectos, la niveles de gravedad y niveles de prioridad también debe describirse.

# 14) Gestión de riesgos: Mencione los riesgos involucrados con el plan de mitigación, como si la aplicación no es estable y si los defectos funcionales de alta prioridad aún están abiertos, afectará el programa de ejecución de las pruebas de rendimiento y, como se dijo anteriormente, esto ayudará a que se produzcan riesgos durante las pruebas de rendimiento o Se planificará al menos una solución alternativa para el riesgo con mucha antelación.

# 15) Recursos: Mencione los detalles del equipo junto con sus roles y responsabilidades.

# 16) Historial de versiones: Realiza un seguimiento del historial del documento.

# 17) Revisiones y aprobaciones de documentos: Esta tiene la lista de personas que revisarán y aprobarán el documento final.

Por lo tanto, básicamente, la estrategia de prueba de rendimiento tiene un enfoque para las pruebas de rendimiento y el plan de prueba de rendimiento tiene los detalles del enfoque, por lo que van juntos. Algunas empresas solo tienen un plan de prueba de rendimiento que tiene un enfoque agregado al documento, mientras que otras tienen un documento de estrategia y plan por separado.

diferencia entre las pruebas de caja negra y caja blanca

Consejos para desarrollar estos documentos

Siga las siguientes pautas mientras diseña la estrategia o un documento de plan para la ejecución exitosa de las pruebas de desempeño.

  • Recuerde siempre que al definir una estrategia de prueba de rendimiento o un plan de prueba, debemos centrarnos en el objetivo y el alcance de la prueba. Si nuestra estrategia o plan de prueba no se ajusta a los requisitos o al alcance, nuestras pruebas no son válidas.
  • Intente concentrar e incorporar aquellas métricas que es importante capturar durante la ejecución de la prueba para identificar cualquier cuello de botella en el sistema o para ver el rendimiento de la aplicación.
  • Planifique las ejecuciones de prueba de tal manera que no pruebe todos los escenarios a la vez y bloquee el sistema. Realice una serie de pruebas y aumente gradualmente los escenarios y la carga de usuarios.
  • En su enfoque, intente agregar todos los dispositivos desde los que se accederá a su aplicación, esto generalmente se aplica a los dispositivos móviles.
  • Siempre tenga una sección de Riesgo y Mitigación en su documento de Estrategia, ya que los requisitos cambian de vez en cuando y estos cambios tendrán un gran impacto en los ciclos de ejecución y los plazos que deben dirigirse al cliente con mucha anticipación.

Conclusión

Estoy seguro de que este tutorial le habría informado de las diferencias entre una estrategia de prueba de rendimiento y un plan junto con su contenido, el enfoque para las pruebas de rendimiento de aplicaciones móviles y las pruebas de rendimiento de aplicaciones en la nube de manera detallada con ejemplos.

Consulte nuestro próximo tutorial para obtener más información sobre las formas de potenciar sus pruebas de rendimiento.

=> Visite aquí para ver la serie completa de tutoriales de pruebas de rendimiento

PREV Tutorial | SIGUIENTE Tutorial

Lectura recomendada

^