Tipos de pruebas Hector Leonardo Arias

Que son pruebas de software

Pruebas de software Las aplicaciones (en general cualquier mecanismo diseñado e implementado por un humano) son propensas a tener fallos. A veces, pueden contribuir al fracaso de cualquier proyecto de software, e impactar de forma negativa en toda una empresa. No parece "justo" que la imagen de toda una compañía se degrade por errores que pueden ser subsanados, y a los que el código es tan "propenso" en general. Los tiempos de desarrollo, los entornos de programación, las diferencias entre versiones... todo influye para que, incluso con la máxima dedicación, puedan darse fallos que empañen la imagen y a veces la reputación, de una organización. Surge por tanto la necesidad de asegurar en lo posible, la calidad del producto.

Prueba caja negra

Descripción caja negra Descripción de las pruebas de caja negra Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo, charter o sección específica de un software, es decir, es una manera de encontrar casos específicos en ese modulo que atiendan a su especificación. Las pruebas de caja negra se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior. Pruebas de caja negra Éstas, principalmente, se centran en módulos o charters de interfaz de usuario (pantalla, ficheros, canales de comunicación…) pero suelen ser útiles en cualquier módulo ya que todos o la mayoría tienen datos de entrada y salida que se pueden comprobar y verificar. Como cualquier otra prueba, las de caja negra se apoyan y basan en la especificación de requisitos y documentación funcional, estos requisitos suelen ser más complejos que los internos, para ello realizaremos una “cobertura de especificación” que será muy recomendable para conseguir probar el mayor campo posible.

Caja Blanca La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que: Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa. Ejecuten todos los bucles en sus límites operacionales. Ejerciten las estructuras internas de datos para asegurar su validez. Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran porciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.

Prueba de Integración La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. Integración descendente Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal). Los módulos subordinados al módulo de control principal se van incorporando en la estructura, bien de forma primero en profundidad, o bien de forma primero en anchura.

Caja Blanca El proceso de integración se realiza en cinco pasos: 1. Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todo los módulos directamente subordinados al módulo de control principal. 2. Dependiendo del enfoque de integración elegido se van sustituyendo uno a uno los resguardos subordinados por los módulos reales. 3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo. 4. Tras terminar cada conjunto de prueba, se reemplaza otro resguardo con el módulo real. 5. Se hace la prueba de regresión para asegurarse de que no se han introducido errores nuevos.

Pruebas Sistema Las pruebas de evaluación son la última etapa del desarrollo del sistema: varios usuarios realizan pruebas para determinar los ajustes finales necesarios. Las pruebas deben realizarlas personas distintas a las que han estado involucradas directamente en el desarrollo del programa, por la sencilla razón de que éstas últimas tienen un interés personal en proteger su trabajo de un análisis crítico excesivo. Asimismo, es necesario elaborar un procedimiento formal de corrección de defectos, por si se cometen errores que repercutan de forma negativa en los resultados del proyecto. Las pruebas realizadas por los programadores no suelen funcionar ya que generalmente no ven los defectos funcionales del código que ellos mismos han creado. La última condición que los contratistas o consultores deben cumplir antes de cobrar por el trabajo realizado debe ser la superación satisfactoria de una prueba de evaluación.

Pruebas Compatibilidad Se comprueba el funcionamiento del software desarrollado en muchas plataformas: sistemas operativos, navegadores, redes, hardware...entre otros

Pruebas de Regresión Se evalúa el correcto funcionamiento del software desarrollado frente a evoluciones o cambios funcionales. El propósito de éstas es asegurar que los casos de prueba que ya habían sido probados y fueron exitosos permanezcan así. Se recomienda que este tipo de pruebas sean automatizadas para reducir el tiempo y esfuerzo en su ejecución.

Pruebas de integración Es el nivel de pruebas posterior a las pruebas modulares de los componentes de un sistema. Se centra principalmente en probar la comunicación entre los componentes de un mismo sistema, comunicación entre sistemas o entre hardware y software.