functional testing vs performance testing
Pruebas funcionales frente a pruebas de rendimiento:
Diferencias entre Pruebas de rendimiento, pruebas de carga y pruebas de estrés se explicaron con ejemplos en nuestro último tutorial.
Las pruebas de software cubren una amplia gama de áreas donde puede ocurrir cualquier verificación o validación de la funcionalidad del software. En ocasiones, los aspectos no funcionales se vuelven menos relacionados con los aspectos funcionales. No se realizan prácticamente; simultáneamente durante las pruebas de software.
=> Haga clic aquí para ver la serie completa de tutoriales de pruebas de rendimiento
Este artículo explica los beneficios adicionales de la calidad del producto de software durante varios escenarios en el ciclo de vida de las pruebas de software. cuando tanto los funcionales como los no funcionales se toman simultáneamente.
Lo que vas a aprender:
- Diferencia rápida entre las pruebas de rendimiento y las pruebas funcionales
- ¿Por qué las pruebas funcionales y las pruebas de rendimiento deben realizarse simultáneamente?
- Caso de estudio
- Conclusión
- Lectura recomendada
Diferencia rápida entre las pruebas de rendimiento y las pruebas funcionales
| Si. No | Pruebas funcionales | Pruebas de rendimiento |
|---|---|---|
| 1 | Para verificar la precisión del software con entradas definidas contra la salida esperada | Verificar el comportamiento del sistema en diversas condiciones de carga. |
| 2 | Puede ser manual o automatizado | Se puede realizar de forma eficaz si se automatiza |
| 3 | Un usuario realiza todas las operaciones | Varios usuarios que realizan las operaciones deseadas |
| 4 | Se requiere la participación del cliente, probador y desarrollador | Se requiere la participación del cliente, probador, desarrollador, DBA y equipo de administración de N / W |
| 5 | El entorno de prueba del tamaño de producción no es obligatorio y los requisitos de H / W son mínimos | Requiere cerca del entorno de prueba de producción y varias instalaciones de H / W para poblar la carga |
¿Por qué las pruebas funcionales y las pruebas de rendimiento deben realizarse simultáneamente?
Las pruebas funcionales se vuelven mucho más importantes para cualquier versión preliminar de software. Basado en resultados reales verificación y validación en el entorno de prueba o producción replicado es donde normalmente se realizan las pruebas.
La fuga de defectos puede convertirse en uno de los mayores problemas:
Los probadores tienen más responsabilidad que los desarrolladores en términos de la calidad del producto. Básicamente, no quieren que el producto probado tenga fugas por defecto. Los probadores generalmente tienden a realizar solo pruebas funcionales para lograr esto.
La siguiente es una conversación entre unTest Manager y Tester :
(Test Manager se conoce como 'TM' y Tester como 'TR')
TM : Hola amigo ... ¿Cómo nos va en la prueba del producto 'A'?
TR : Sí ... Estamos progresando de una manera mayor.
TM : Eso es fantástico ... ¿Y cuál es nuestro alcance en términos de pruebas de rendimiento mientras se están ejecutando pruebas funcionales?
TR : No los cubrimos, se supone que nuestros entregables deben estar solo en el área funcional y no en el área no funcional. Además, el entorno de prueba que estamos usando no es una réplica exacta de la producción.
Hay algunas preguntas de la conversación anterior para ser consideradas:
- ¿Las pruebas funcionales tienen un factor dependiente sobre el rendimiento?
- ¿Qué pasa si el rendimiento del software se degrada, pero la entrega del producto ocurre sin verificar el rendimiento?
- Prueba de rendimiento: ¿coexiste dentro del proceso de prueba funcional?
Se ha convertido en una práctica generalizada para los probadores no trabajar en los aspectos no funcionales a menos que se les solicite. Es común evitar pruebas no funcionales hasta que el cliente haya informado problemas con el rendimiento del software bajo prueba.
Entonces, hay 2 preguntas que debe considerar:
- Rendimiento: ¿afecta las pruebas funcionales?
- ¿Mantenemos las pruebas de rendimiento como una entrega separada, incluso si preocupa al cliente?
Las pruebas de rendimiento son importante !
preguntas de la entrevista de servicios web .net
El software funciona según varias arquitecturas y los siguientes modelos, que incluyen:
- Modelos de respuesta de respuesta requerida
- Sistemas basados en transacciones
- Sistemas basados en carga
- Sistemas basados en replicación de datos
El comportamiento de las pruebas funcionales del modelo sistemático mencionado anteriormente depende del rendimiento del sistema.
El punto de vista de la automatización requiere mucha atención hacia las pruebas de rendimiento.
La siguiente es una conversación entre uncliente y el administrador de pruebas.
(El cliente se conoce como 'CL' y el administrador de pruebas como 'TM')
CL : Por lo tanto, al llegar a la solución que hemos solicitado, espero que haya múltiples iteraciones de las pruebas que están sucediendo actualmente.
TM : Si, esto se puede hacer. Como ha dicho, habrá una mayor probabilidad de las pruebas iterativas, nos gustaría proponer la automatización para hacer frente a las pruebas funcionales (regresión).
CL : Muy bien, envíenos su enfoque para que podamos aprobarlo. La automatización tendrá un rendimiento mucho mayor con un esfuerzo mínimo.
TM : Exactamente. Trabajaremos en el enfoque y nos comunicaremos con usted con una prueba de concepto.
De la conversación anterior, queda claro que la necesidad de los clientes es optimizar la eficiencia.
Caso de estudio
La empresa ABC trabaja en un proyecto para desarrollar el software A. La empresa XYZ está realizando las pruebas del software A.
El contrato de la Compañía ABC y XYZ tiene algunas restricciones para su colaboración. Cualquier discusión entre las 2 empresas debe realizarse una vez a la semana o tres veces al mes. El sistema funciona en un modelo de modo de solicitud-respuesta. La fase de desarrollo ha sido completada por la Compañía ABC.
Ahora es el momento de que la empresa XYZ realice las pruebas funcionales formales en el software A. XYZ comienza a trabajar en las pruebas del software A. Han dado una buena nota al software y han dado el visto bueno para la implementación en vivo después de 2 ciclos de prueba.
A pesar del certificado de calidad del equipo de pruebas, la implementación en vivo no fue bien. Hubo muchos errores de posproducción. Hubo una gran cantidad de problemas que enfrentaron los clientes, incluida una interrupción en la funcionalidad de los procesos comerciales de un extremo a otro.
Entonces, ¿cuál es elproblema?
- ¿Es un problema con una restricción en la colaboración entre el equipo de desarrollo y prueba?
- ¿Es que los requisitos no se captaron al 100%?
- ¿Es que el producto no se probó en un entorno de prueba adecuado?
- ¿O alguna otra causa?
Después de una cuidadosa investigación y análisis, elsiguientes fueron inferidos:
- Hubo pocas de las aplicaciones dependientes e interdependientes que tuvieran problemas de rendimiento al obtener las respuestas.
- Las entradas de prueba utilizadas no fueron absolutas.
- No se ocupó de la robustez del software.
- Muchos problemas de sincronización entre las múltiples aplicaciones independientes.
- La prueba del software había realizado múltiples reelaboraciones que no se consideraron.
Por lo tanto, después de laacciones correctivasEl equipo de planificación intervino, se sugirió lo siguiente:
- Debe aumentarse la interacción entre el equipo de desarrollo y el equipo de pruebas.
- Todas las aplicaciones dependientes deben estar conectadas e incluidas en las pruebas funcionales del sistema.
- El valor de tiempo de espera de solicitud y respuesta debe aumentarse para dar espacio a entornos que no son de producción.
- En las pruebas funcionales deben utilizarse diversas entradas que van desde lo simple a lo complejo.
- Las pruebas no funcionales, especialmente las pruebas de rendimiento y carga, deben realizarse según las recomendaciones del equipo de recuperación.
- Además de las pruebas del sistema, se deben realizar pruebas de integración del sistema.
- Debe proporcionarse un intervalo de tiempo mínimo entre dos iteraciones de prueba. Esto es para volver a probar los errores previamente identificados.
- Todos los errores identificados en iteraciones anteriores deben corregirse en la iteración actual.
El equipo de pruebas implementó todas las acciones propuestas y se descubrieron una gran cantidad de defectos en poco tiempo.
Observaciones:
- El cronograma de implementación en vivo del software mejoró significativamente al optimizar los tiempos del ciclo de prueba.
- Hubo un buen progreso en la optimización de la calidad del software. Por lo tanto, hubo una tremenda disminución en los tickets de soporte posteriores a la implementación.
- Se redujeron los reprocesos y se probaron iteraciones en lugar de reelaborar. Entre las diferentes iteraciones, se observaron mejores mejoras en la calidad.
Conclusión
Realizar pruebas no funcionales durante la ejecución de pruebas funcionales es más ventajoso y agregará más beneficios a la calidad general del software. Esto identificará errores de rendimiento (restringidos al entorno de prueba y la dependencia) y, por lo tanto, reducirá las situaciones de supuestos de problemas funcionales.
Se debe realizar una planificación suficiente para realizar pruebas funcionales y no funcionales (a un nivel mínimo) a fin de mantener una relación sólida entre las otras partes interesadas del proyecto.
Sobre el autor: Este es un artículo escrito por Nagarajan. Trabaja como líder de pruebas con más de 6 años de experiencia en Pruebas en diversas áreas funcionales como Banca, Aerolíneas, Telecom en términos tanto de manual como de automatización.
Nuestro próximo tutorial explicará más sobre el plan de prueba de rendimiento y la estrategia de prueba.
=> Visite aquí para ver la serie completa de tutoriales de pruebas de rendimiento
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Pruebas funcionales versus pruebas no funcionales
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Pruebas de rendimiento frente a pruebas de carga frente a pruebas de estrés (diferencia)
- Georgia Tech estandariza sus pruebas de rendimiento en RadView WebLOAD
- Diferencia entre pruebas de escritorio, cliente-servidor y pruebas web
- Descarga del libro electrónico Testing Primer
- Las diferencias entre pruebas unitarias, pruebas de integración y pruebas funcionales
- Prueba de rendimiento en la nube: proveedores de servicios de prueba de carga basados en la nube