3) Casos de Prueba

Introducción

 

En el campo de la gestión tradicional de proyectos de software, surgió hace poco una filosofía estratégica que se centra en mejorar el diseño de los casos de prueba, y que llamó la atención generalizada de los interesados en la gestión de proyectos y en la prueba del software.

Actualmente, la gestión de proyectos de software es una de las tareas más importantes en la industria de las tecnologías de la información, y más aún si el objetivo es desarrollar productos de calidad. En esa gestión, la prueba es una de las fases más importantes, y en ésta, lo que requiere más cuidado y dedicación es el diseño de los casos de prueba, por lo que es necesario estudiar cómo diseñarlos y escribirlos mejor.  (Aristegui, 2010).

Desarrollo

 

 Pruebas de Caja Blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados. Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema. A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Pruebas de Caja Negra

En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

En programación modular, donde un programa (o un algoritmo) es dividido en módulos, en la fase de diseño se buscará que cada módulo sea una caja negra dentro del sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia entre los módulos que facilita su implementación separada por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte (un módulo) del programa global; el implementador de un módulo concreto deberá conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará conocer como trabajan esos otros módulos internamente; en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras. En pruebas de software, conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con las esperadas.

Diagramas

A continuación tomaré un diagrama de flujo ejemplificando un software, a partir de este construiré un grafo del cual obtendré todos los caminos posibles para el programa.

Diagrama de flujo

Diagrama de Nodos (Grafo)

 Caminos
A continuación una lista de todos los caminos del programa, usando el número de proceso, en total encontré 11 caminos:

• I,F
• I,1,2,F
• I,1,2,3,F
• I,1,3,F
• I,1,3,2,F
• I,2,F
• I,2,3,F
• I,3,F
• I,3,2,F
• I,4,5,F
• I,4,6,F

Conclusión

Al desarrollar cualquier tipo de software es muy importante esforzarse en realizar el diseño de pruebas de la mejor manera posible, ya que son estas nuestra principal herramienta para evitar posibles desastres y fallos en el software. Ser riguroso y trabajar en este aspecto puede prevenir que posteriormente se deba realizar un trabajo aún más extenso de corrección de errores.

Referencias

1. Aristegui, José. Los casos de prueba en la prueba del software, Revista Digital Lámpsakos, No.3, pp. 27-34, Chile 2010.
2. Williams, Laurie. White-Box Testing. 2006.