Ing. Noretsys Rodríguez

Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de un sistema en ejecución.  Defecto: tiene lugar en el código del programa. La existencia de un defecto puede ocasionar una falla.  Error: acción humana que provoca que el software contenga un defecto.

Niveles de pruebas  Pruebas de unidad: solo una unidad es probada, ejemplo: una clase módulo o subsistema.  Pruebas de integración: se verifica que las unidades trabajen juntas correctamente. Pueden ser realizadas mediante casos de uso de pruebas.  Pruebas de sistemas: verifica el sistema completo o su aplicación como tal, desde el punto de vista del usuario final.

Pruebas de unidad  Pruebas de especificación o caja negra: verifica las relaciones de entrada y salida de cada unidad. Su objetivo es verificar “QUE” hace la unidad sin averiguar como lo hace.  Pruebas basadas en estados: verifica las interacciones entre operaciones de una unidad según cambios en los parámetros de entrada salida.  Prueba estructural o de caja blanca: verifica que la estructura interna de cada unidad sea correcta, es necesario conocer como está implementada la unidad.

Pruebas de integración  Después de haber probado todas las unidades se deben integrar en unidades más grandes hasta generar todo el sistema. En esta prueba se incluyen:  De paquetes de servicios.  Casos de usos.  Subsistemas.  Sistema completo.

Pruebas de sistemas.  Al principio las pruebas de casos de uaso se hacen de manera independientes basadas en el modelo de requisitos, luego se prueba el sistema como un todo. Se ejecutan varios casos de uso en paralelo sometiendo al sistema a varios tipos de cargas. Las pruebas de sistemas involucran:  Pruebas de operación.  De escala completa.  Negativas.  Casos de uso.  De documentación de usuario.

Estrategias de pruebas  Existen múltiples estrategias de pruebas, las más destacadas son:  Orden de pruebas.  Alcance de pruebas.  Automatización de pruebas.

Orden de pruebas  Define en que momento y orden se aplican las pruebas.  Existen dos enfoques:  De arriba hacia abajo: se desarrollan inicialmente las interfaces para probar los protocolos de alto nivel antes de ir a los niveles inferiores.  De abajo hacia arriba: se certifica las unidades de bajo nivel y luego las interfaces.  Depende de la estrategia de diseño, ya que, se debe corresponder con el proceso de desarrollo.

Alcance de pruebas  Tiene como propósito identificar el tipo, número y casos de pruebas que se aplicarán para revisar los diferentes aspectos del sistema. El objetivo es seleccionar un número pequeño pero razonable de casos de pruebas donde la posibilidad de encontrar defectos y fallas se alta.

Automatización de pruebas  Tiene como propósito reducir el esfuerzo y costo de las pruebas. Esto se logra mediante programas de pruebas especiales asociados a un conjunto de datos de pruebas.

Técnicas de pruebas  Prueba de regresión: verifica el sistema luego de haberle introducido cambios, ejemplo: tras corregir una falla o defecto.  Prueba de operación: verifica el sistema en operación por un largo periodo de tiempo bajo condiciones normales de uso. Mide la confiabilidad.  Prueba de escala completa: verifica el sistema en su carga máxima mediante la asignación de parámetros a su valor límite y la interconexión del sistema con un máximo de equipos y usuarios simultáneos.

Técnicas de pruebas  Prueba de rendimiento o de capacidad: Mide la capacidad de procesamiento y respuesta del sistema bajo diferentes cargas, incluyendo espacio de almacenamiento.  Prueba de sobrecarga: prueba como se comporta el sistema cuando se le aplica una sobrecarga, más allá de las pruebas de escala completa y rendimiento.  Prueba negativa: mide el Estrés del sistema en situaciones inesperadas.

Técnicas de pruebas  Pruebas de casos de uso: Se llevan a cabo pruebas directamente en la especificación de requisitos. Se trata de verificar que el sistema final cumple con las especificaciones del usuario.  Pruebas ergonómicas: prueba las interfaces hombre – máquina, la congruencia del sistema, usabilidad, amigabilidad.

Técnicas de prueba  Pruebas de documentación de usuario: Prueba que los documentos entregados al usuario final sean congruentes con el sistema.  Prueba de aceptación o validación: Es la prueba por parte del usuario final, se realiza en un ambiente real por un periodo extenso, al te3rminar se toma la decisión de aprobar o no el producto.

Proceso de Inspección  Es un repaso detallado y formal del trabajo en proceso.  4 o 5 personas estudian el producto de trabajo independientemente y luego se reúnen para examinar el trabajo en detalle.  El proceso se divide en 6 fases:  Planificación:.  Overview.  Preparación.  Examen.  Retrabajo.  Seguimiento.

Fases de la inspección  Planificación: Cuando el desarrollador completa un producto se forma el grupo de inspección y se designa un moderador. El moderador asegura que el producto satisfaga el criterio de inspección. Se le asignan diferentes roles a las personas que integran el grupo de inspección, así como la planificación de tiempos y recursos necesarios.  Overview: Es una vista general es necesaria en éste momento. Este es un paso opcional, pero no menos importante, ya que en esta etapa se dará al grupo de inspección un "background" y el contexto a cubrir por las inspecciones.  Preparación: Los inspectores se preparan individualmente para la evaluación en la reunión, estudiando los productos y el material relacionado. Se usan listas de chequeos para ayudar a encontrar defectos comunes, el tiempo que pueda llevar esta etapa depende de cuan familiarizado esté el inspector con el trabajo que debe analizar.

Fases de la inspección  Examen: En esta etapa, los inspectores se reúnen para analizar su trabajo individual en forma conjunta. El moderador deberá asegurarse que todos los inspectores están suficientemente preparados. La persona designada como lector presenta el producto, interpretando o parafraseando el texto, mientras que cada participante observa en busca de defectos. Es recomendable que este examen no dure mas de 2 horas ya que la atención en busca de defectos va disminuyendo con el tiempo. Al terminar con la reunión, el grupo determina si el producto es aceptado o debe ser retrabajado para una posterior inspección.  Retrabajo: El autor corrige todos los defectos encontrados por los inspectores.  Seguimiento: El moderador chequea las correcciones del autor. Si el moderador está satisfecho, la inspección está formalmente completa, y el "producto de trabajo" es puesto bajo el control de configuración.

Gracias!