Aspectos a considerar en las pruebas de un programa

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia, video de referencia.

Objetivo de hacer pruebas

Antes de entregar, debemos hacer pruebas de los programas, debido a que nos permiten descubrir problemas.
La etapa de prueba se centra en la búsqueda de defectos, cosas que debemos corregir para la entrega del usuario, antes de la entrega.
Revisiones de requerimiento y diseño contribuyen en descubrir problemas.

Es de recordar que el propósito de las pruebas es demostrar la existencia de un defecto, no en sí que los programas operan correctamente, sino buscar defectos.

• Por eso la prueba es destructivo.
  • Para identificar origines de las fallas
  • Y corregir.

¿Que significa que el software falla?

• No hace lo que especifica los requerimientos.
  • Pudo haberse omitido algo.
  • Algo imposible de implementar con el software y hardware prescrito.
  • El diseño del sistema o del programa puede contener un defecto.
  • El código del programa puede estar errado.

Tipos de defectos

• Algorítmicos
  • La lógica desarrollada no se produce la salida apropiada, debido a algún paso está mal en el procesamiento.
  • Incluyen:
    • Condición errónea, por ejemplo no poner notas negativas.
    • Olvidar inicializar una variable.
    • Comparar variables de tipos de datos inapropiados.
• Sintaxis: Se realiza cuando no se ha utilizado correctamente las estructuras del lenguaje de programación.
• Computación y de precisión:
  • Flotantes o enteros inesperados, cuando la implementación de la forma no llega al grado de exactitud esperado, por ejemplo en planillas esto es vital.
• Documentación
  • No corresponde con lo que el programa realmente hace, se tiene a confiar en la documentación y si por ejemplo se hizo un cambio en el código y no sé hizo cambio en la documentación se da el problema.
• Defectos por estrés o sobrecarga
  • Cuando una estructura como por ejemplo tamaño de almacenamiento, se sobrecarga en el sistema hasta sobrepasar su capacidad especificada.
• Capacidad o de límites
  • Se vuelve inaceptable la actividad debido al límite del sistema, por ejemplo tratar de correr un programa de 64 bits en uno de 32 bits.
• Desempeño
  • Sistema no opera a la velocidad prescrita por los requerimientos.
• Sincronización o de coordinación
  • Se produce cuando se coordina dichos eventos es inadecuados
• Recuperación
  • Cuando hay una falla, ocurre cuando no se comporta como el cliente quiere para notificar la falla.
• Hardware y Software
  • Cuando hardware y/o software no trabajan realmente de acuerdo con las condiciones operativas y documentaciones, por ejemplo una impresora que se realizó todas las configuraciones indicadas e igualmente falla.
• Estándares y procedimientos.
  • Si no se está siguiendo en el código los estándares mínimos que se han establecido en la empresa.

Tipos de prueba:

Son los siguientes:

• Unitaria
• Integración
• Función
• Desempeño
• Aceptación
• Instalación

Pruebas de integración a más detalle:

Las pruebas integración se planean y coordinan para que al producirse una falla, se pueda tener alguna idea de lo que le ha dado origen.

Tipos:

• Ascendente (bottom - up): Desde los componentes elementales a los más generales.
• Descendente (top - bottom) Lo contrario, desde los más generales a los más elementales
• Big - Bang: No es práctico para grandes sistemas, pero muchos programadores lo ocupan para pequeños, mezclar juntos a todos los componentes como un sistema final y ver si funciona la primera vez. El problema es que es más difícil identificar cuál fue la causa de una falla.
• Intercalada: Mezcla los métodos ascendente y descendentes por medio de 3 capas, en el medio la capa objetivo, los niveles por encima del objetivo, y los niveles por debajo del objetivo.

¿Quién realiza las pruebas?

• Para evitar las opiniones personales del equipo de desarrollo es buena práctica contar con un equipo de prueba independiente, conocido como QAs.
• De esta forma igualmente se puede llevar la codificación y las pruebas concurrentemente.

Visión de los objetos de prueba:

La propia visión que se tiene del objeto de prueba, ya sea un componente, sistema, subsistema, etc. afectara la forma que se lleva a cabo la prueba.
Este puede ser:

• Caja negra: Si se ve desde afuera y el contenido, o sea sé el código se desconoce, solo es de tomar entradas y anotar las salidas que produce y verificar que es la esperada. Ejemplo: Debido a que este tipo de prueba es libre de las restricciones impuestas por la estructura interna o lógica, solo es de verificarlas con casos de uso de la lógica de negocio. Método más usado:
  • Particionamiento de Equivalencias
  • Análisis de Valores Fronteras
  • Adivinanza de defectos
• Caja blanca: Se utiliza la estructura interna del objeto para probarlo de diferentes maneras Ejemplo: Se pueden ejecutar casos de prueba que ejecuten toas las instrucciones y caminos de control que existen del objeto. Método más usado:
  • Pruebas de Cobertura (Instrucción, Decisión, Condición, Decisión/Condición, Múltiples Condiciones, De Caminos).
• Caja estructurada: Cuando se utilizan tantas pruebas de caja cerrada en un extremo y en el otro de caja abierta en un programa.

Proceso para encontrar defectos:

1. Examinar el código.
2. Comparar el código con las especificaciones
3. Desarrollar casos de prueba (test case) para demostrar que las entradas tienen salidas esperadas.

Examen de código

Para hacer un examen del código hay de 2 tipos:

• Recorridas: Programador lidera la discusión y se presenta a un equipo de revisión, es informal.
• Inspecciones: Es más formal, el equipo se reúne para hacer una revisión general y se preparan individualmente para una segunda reunión de grupo, cada inspector estudia el código y documentos relacionados.

¿Qué determina un buen test case?

• Aquel que tiene una alta probabilidad de encontrar un defecto no descubierto.
• No es redundante, ni muy simple, ni muy complejo, idealmente, el mejor de su clase.
• Un exitoso test case es aquel que descubre un defecto no descubierto.