stringtranslate.com

Pruebas manuales

Comparar con automatización de pruebas .

Las pruebas manuales son el proceso de probar manualmente el software para detectar defectos. Requiere que un evaluador desempeñe el papel de un usuario final, en el que utiliza la mayoría de las funciones de la aplicación para garantizar un comportamiento correcto. Para garantizar la integridad de las pruebas, el evaluador suele seguir un plan de pruebas escrito que lo guía a través de un conjunto de casos de prueba importantes .

Descripción general

Un paso clave en el proceso es probar el software para verificar su correcto comportamiento antes de lanzarlo a los usuarios finales.

Para los esfuerzos de ingeniería a pequeña escala (incluidos los prototipos), las pruebas ad hoc pueden ser suficientes. Con este enfoque informal, el evaluador no sigue ningún procedimiento de prueba riguroso y simplemente realiza pruebas sin planificación ni documentación. Por el contrario, las pruebas exploratorias , que implican aprendizaje simultáneo, diseño de pruebas y ejecución de pruebas, exploran la interfaz de usuario de la aplicación utilizando tantas de sus características como sea posible, utilizando la información obtenida en pruebas anteriores para derivar intuitivamente pruebas adicionales. El éxito de las pruebas manuales exploratorias depende en gran medida de la experiencia del evaluador en el dominio, porque la falta de conocimiento conducirá a pruebas incompletas. Una de las principales ventajas de un enfoque informal es obtener una idea intuitiva de cómo se siente al usar la aplicación.

Los proyectos de ingeniería a gran escala que dependen de pruebas de software manuales siguen una metodología más rigurosa para maximizar la cantidad de defectos que se pueden encontrar. Un enfoque sistemático se centra en casos de prueba predeterminados y generalmente implica los siguientes pasos. [1]

  1. Elija un plan de pruebas de alto nivel donde se elija una metodología general y se identifiquen y adquieran recursos como personas, computadoras y licencias de software.
  2. Redactar casos de prueba detallados , identificando pasos claros y concisos que debe seguir el evaluador, con los resultados esperados.
  3. Asignar los casos de prueba a los evaluadores, quienes siguen manualmente los pasos y registran los resultados.
  4. Redactar un informe de pruebas en el que se detallen los resultados de las pruebas. Los gerentes utilizan el informe para determinar si el software puede publicarse y, en caso contrario, los ingenieros lo utilizan para identificar y corregir los problemas.

Un enfoque riguroso basado en casos de prueba suele ser tradicional para grandes proyectos de ingeniería de software que siguen un modelo en cascada . [2] Sin embargo, al menos un estudio reciente no mostró una diferencia drástica en la eficiencia de detección de defectos entre las pruebas exploratorias y las pruebas basadas en casos de prueba. [3]

Las pruebas pueden realizarse mediante pruebas de caja negra , blanca o gris . En las pruebas de caja blanca, el evaluador se ocupa de la ejecución de las instrucciones a través del código fuente. En las pruebas de caja negra, el software se ejecuta para verificar los defectos y se preocupa menos por cómo se realiza el procesamiento de la entrada. Los evaluadores de caja negra no tienen acceso al código fuente. Las pruebas de caja gris se ocupan de ejecutar el software teniendo una comprensión del código fuente y los algoritmos. [4]

También se pueden utilizar métodos de prueba estáticos y dinámicos . Las pruebas dinámicas implican la ejecución del software. Las pruebas estáticas incluyen la verificación de requisitos, la sintaxis del código y cualquier otra actividad que no incluya la ejecución real del código del programa.

Las pruebas se pueden dividir en pruebas funcionales y no funcionales . En las pruebas funcionales, el evaluador verificaría los cálculos, cualquier vínculo en la página o cualquier otro campo que, en función de la entrada, pueda esperarse que dé resultados. Las pruebas no funcionales incluyen pruebas de rendimiento, compatibilidad y aptitud del sistema bajo prueba, su seguridad y usabilidad, entre otras cosas.

Etapas

Existen varias etapas, que son:

Pruebas unitarias
Esta etapa inicial de la prueba normalmente la lleva a cabo el desarrollador que escribió el código y, a veces, un par que utiliza la técnica de prueba de caja blanca.
Pruebas de integración
Esta etapa se lleva a cabo de dos maneras: como paquete completo o como un incremento del paquete anterior. La mayoría de las veces se utiliza la técnica de prueba de caja negra. Sin embargo, a veces también se utiliza una combinación de pruebas de caja blanca y negra en esta etapa.
Prueba del sistema
En esta etapa, el software se prueba desde todas las dimensiones posibles para todos los propósitos y plataformas previstos. En esta etapa, normalmente se utiliza la técnica de prueba de caja negra.
Prueba de aceptación del usuario
Esta etapa de prueba se lleva a cabo para obtener la aprobación del cliente del producto terminado. Un "aprobado" en esta etapa también garantiza que el cliente ha aceptado el software y está listo para su uso.
Prueba de lanzamiento o implementación
El equipo en el sitio irá al sitio del cliente para instalar el sistema en el entorno configurado por el cliente y verificará los siguientes puntos:
  1. Si SetUp.exe se está ejecutando o no.
  2. Hay pantallas fáciles durante la instalación.
  3. ¿Cuánto espacio ocupa el sistema en el disco duro?
  4. ¿El sistema se desinstala por completo cuando se opta por desinstalarlo del sistema?

Ventajas

Comparación con las pruebas automatizadas

La automatización de pruebas puede reducir o eliminar el costo de las pruebas reales. [5] Una computadora puede seguir una secuencia de pasos repetida más rápidamente que una persona y puede ejecutar las pruebas durante la noche para presentar los resultados por la mañana. Sin embargo, el trabajo que se ahorra en las pruebas reales debe dedicarse a crear el programa de prueba. Dependiendo del tipo de aplicación que se va a probar y de las herramientas de automatización que se elijan, esto puede requerir más trabajo que un enfoque manual. Además, algunas herramientas de prueba presentan una gran cantidad de datos, lo que potencialmente crea una tarea que consume mucho tiempo para interpretar los resultados.

Elementos como los controladores de dispositivos y las bibliotecas de software deben probarse mediante programas de prueba. Además, las pruebas de un gran número de usuarios ( pruebas de rendimiento y pruebas de carga ) suelen simularse en el software en lugar de realizarse en la práctica.

Por el contrario, las interfaces gráficas de usuario cuyo diseño cambia con frecuencia son muy difíciles de probar automáticamente. Existen marcos de prueba que se pueden utilizar para realizar pruebas de regresión de interfaces de usuario. Se basan en la grabación de secuencias de pulsaciones de teclas y gestos del ratón, para luego reproducirlas y observar que la interfaz de usuario responde de la misma manera cada vez. Desafortunadamente, estas grabaciones pueden no funcionar correctamente cuando se mueve o se reetiqueta un botón en una versión posterior. Una prueba de regresión automática también puede resultar engañosa si el resultado del programa varía significativamente.

Véase también

Referencias

  1. ^ ANSI/IEEE 829-1983 Estándar IEEE para documentación de pruebas de software
  2. ^ Craig, Rick David; Stefan P. Jaskiel (2002). Pruebas sistemáticas de software . Artech House. pág. 7. ISBN 1-58053-508-9.
  3. ^ Itkonen, Juha; Mika V. Mäntylä; Casper Lassenius (2007). "Eficiencia en la detección de defectos: pruebas basadas en casos de prueba frente a pruebas exploratorias" (PDF) . Primer Simposio Internacional sobre Ingeniería y Medición de Software Empírico (ESEM 2007) . pp. 61–70. doi :10.1109/ESEM.2007.56. ISBN 978-0-7695-2886-1. S2CID  5178731. Archivado desde el original (PDF) el 13 de octubre de 2016 . Consultado el 17 de enero de 2009 .
  4. ^ Hamilton, Thomas (23 de mayo de 2020). "¿Qué es la prueba de caja gris? Técnicas, ejemplo". www.guru99.com . Consultado el 7 de agosto de 2022 .
  5. ^ Atlassian. «Automatización de pruebas». Atlassian . Consultado el 7 de agosto de 2022 .