Unidad 2 Pruebas.

2.1 Tipos de pruebas.

2.2 Cobertura de las pruebas.

2.3 Preparación de la prueba.

2.4 Productos de la prueba.

2.5 Criterios para la realización de pruebas.

2.6 Plan Pruebas (validación y verificación).

2.7 Estructura de los casos de Prueba.

2.8 Conceptos Generales los diseño de las pruebas (validación y verificación).

2.9 Reporte y Seguimiento de errores.

2.10 Informe de la Prueba.

2.11 Fuentes de información de QA para el control estadística o métricas.

2.12 Control estadístico vs métricas.

2.13 Importancia de la calidad, las métricas y el control estadístico.

2.1 Tipos de pruebas.

Pruebas de Unidad

Se prueban los caminos de Control Importantes, para descubrir errores dentro de los límites del módulo

Se puede trabajar en varios módulos a la vez

Pruebas de Caja Blanca: Usa la estructura de control del diseño procedimental para obtener los casos de prueba.

Prueba del Camino Básico: Permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución.

Complejidad Ciclomática: Define el número de caminos independientes del conjunto básico de un programa y nos da un límite inferior para el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

Pruebas de Integración: Se comprueba la compatibilidad y funcionalidad de los interfaces entre las distintas ‘partes’ que componen un sistema, estas ‘partes’ pueden ser módulos, aplicaciones individuales, aplicaciones cliente/servidor, etc.

Pruebas de Validación: La validación del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos.

Prueba Alfa: Las pruebas alfa se llevan a cabo en un entorno controlado, pero por un cliente

Prueba Beta: Es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador

Pruebas de Sistema: Pruebas de Recuperación: Fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente.

Pruebas de Seguridad: Intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán de accesos impropios por parte de piratas informáticos.

Pruebas de Resistencia: Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales

Prueba de Rendimiento: Consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema.

2.2 Cobertura de las pruebas.

¿Qué es la cobertura?

La cobertura es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. O sea, ejecuto las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta de 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 50%. La pregunta que viene a continuación es:

¿Qué beneficio tiene medir la cobertura? y más específicamente ¿qué beneficios tiene tener una alta cobertura?

Una respuesta genérica podría ser que aumenta la calidad de mi aplicación. Siendo más concreto podría decir que si tengo una alta cobertura, significa que gran parte me mi código está siendo probado y por consiguiente podría tener cierta certeza sobre el correcto funcionamiento de mi aplicación. Al mismo tiempo medir la cobertura podría ayudarme a detectar código innecesario en mi aplicación, ya que es código que no se ejecuta.

2.3 Preparación de la prueba.

Propósito del plan de pruebas: es explicar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas. Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación, integración e integración).

UN PLAN DE PRUEBAS INCLUYE:

ü Identificador del plan:

ü  Alcance.

ü  ITEMSA aprobar.

ü  Estrategia.

ü  Categorización de la clasificación.

ü  Tangibles.

ü  Procedimientos especiales.

ü  Recursos.

ü  Calendario.

ü  Manejo de riesgos.

ü  Responsables.

2.4 Productos de la prueba.

•         La verificación consiste en corroborar que el programa respeta su especificación, mientras que validación significa corroborar que el programa satisface las expectativas del usuario

•         Una falla es el síntoma manifiesto de la presencia de un error, Es decir que un error permanecerá oculto hasta que ocurra una falla causada por aquel.

•          Ejemplo si la condición de una sentencia if es x > 0 cuando debería haber sido x > 1.

•         Las Prueba (test) es una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto

2.5 Criterios para la realización de pruebas.

Criterios de Inicio Para que el plan de pruebas se pueda llevar a cabo se deben:

ü  Contar con los equipos necesarios para poder llevar a cabo el plan de pruebas

ü  Contar con el software para realizar las pruebas de rendimiento

ü  Contar con el software de soporte

ü  Contar con el personal capacitado para realizar la prueba

2.6 Plan Pruebas (validación y verificación).

Para que el plan de pruebas Performance of AddressBook se dé por concluido se deben cumplir las siguientes actividades:

Criterios de Fin

ü  Probar el Botón de agregar

ü  Probar el Botón de editar

ü  Probar el Botón de eliminar

ü  Probar el Botón de guardar

ü  Probar el Botón de cancelar

ü  Probar el Botón de salir

ü  Probar cada una de las etiquetas (Labels)

ü  Probar cada uno de los cuadros de texto (TextBox)

ü  Probar el DataGridView

ü  Probar el rendimiento del sistema

ü  Probar la interfaz del usuario. Se realizarán las iteraciones necesarias hasta que se la aplicación funcione conforme a lo establecido.

Criterios de Suspensión y Retorno de Actividades

Las únicas posibles maneras de que la prueba se pueda suspender es por enfermedad de alguna de las personas que realizarán las pruebas y se reanudarán éstas cuando la persona vuelva a estar en condiciones de realizar la prueba o que sea remplazado por otra persona capacitada.

Criterios para el Lanzamiento

Criterios de Evaluación Para que el plan de pruebas Performance of AddressBook se dé por concluido se deben cumplir las siguientes condiciones:

ü  El botón de agregado cumpla con la función de agregar

ü  El botón de modificación

ü  El botón de eliminado permita eliminar un registro

ü  El botón de guardar cumpla con la función de guardar un cambio

ü  El botón cancelar deshaga cualquier cambio que se haga sin que éste haya sido guardado anteriormente

ü  El cuadro de texto envíe la información adecuada al lugar adecuado dentro de la Base de Datos.

ü  Las etiquetas coincidan con los cuadros de texto de acuerdo al diseño, y deben tener una buena ortografía.

ü  La interfaz este hecha y organizada conforme al diseño

ü  El rendimiento de la aplicación sea la óptima para que no se trabe a la hora de la ejecución

2.7 Estructura de los casos de Prueba.

¿Qué es el diseño de los casos de prueba?

Es una parte de las pruebas de componentes y sistemas en las que se diseñan los casos de prueba (entradas y salidas esperadas) para probar el sistema.

ü  Su objetivo es crear un conjunto de casos de prueba que sean efectivos descubriendo defectos en los programas y muestren que el sistema satisface sus requerimientos.

ü  Puntos para diseñar un caso de prueba

ü  Seleccionar una característica del sistema o componente que se está probando.

ü  Seleccionar un conjunto de entradas que ejecutan dicha característica, se documentan las salidas esperadas o rangos de salida.

Aproximaciones que pueden seguirse para diseñar los casos de prueba

ü  Pruebas basadas en los requerimientos

ü  Pruebas de particiones

ü  Pruebas estructurales

ü  Pruebas de caminos

Pruebas basadas en requerimientos ´ Son una aproximación sistemática al diseño de casos de prueba en donde el usuario considera cada requerimiento y deriva un conjunto de pruebas para cada uno de ellos.

2.8 Conceptos Generales de los diseños de las

pruebas (validación y verificación).

Verificación y validación del diseño

C. Planificación- inspección de software

ü  Pruebas del software

ü  Pruebas del sistema

ü  Pruebas de componentes

ü  Diseño de casos de prueba

ü  Automatización de las pruebas

La prueba del software se conoce también como verificación y validación

Verificación: Son las actividades que buscan asegurar si el software implementa correctamente una función específica (¿Estamos construyendo el producto correctamente?)

Validación: son las actividades que buscan asegurar si el software construido se ajusta a los requisitos del cliente (¿Estamos construyendo el producto correcto?).

Durante y después del proceso de implementación, el programa en desarrollo debe ser comprobado, para asegurar que satisface su especificación y entrega la funcionalidad esperada por el cliente.

La verificación y la validación es el nombre dado a estos procesos de análisis y pruebas

La verificación y la validación tienen lugar en cada etapa del proceso del software.

2.9 Reporte y Seguimiento de errores.

Un sistema de seguimiento de errores es una aplicación informática diseñada para ayudar asegurar la calidad de software

Componentes:

Una base de datos

·         Los hechos

·         Programadores

·         Personal asignado

·         Fecha del error

·         Código que lo corrige

·         Reporte

Uso

En un entorno corporativo, un sistema de reporte de errores puede ser utilizado para generar reportes de la productividad de programadores al reparar errores.

Ciclo de vida: Todos los sistemas de seguimiento de errores identifican un ciclo de vida es configurable

1.    Crear una entrada

2.    Otros leen la entrada

3.    El fallo es reproducido

4.    El fallo es diagnosticado

5.    El fallo es programado para su resolución

2.10      nforme de la Prueba.

Código asociado al proyecto: Código del requerimiento o proyecto según la nomenclatura definida por la organización. Este código se usa para identificar todos los documentos asociados y para registrarlo en los sistemas de gestión.

Nombre del proyecto: Nombre o descripción por lo cual se conoce al requerimiento o proyecto. Suele estar relacionado con la funcionalidad que se está desarrollando.

Fecha comienzo planificada: Fecha calendario en la cual estaba planificado iniciar, según el plan de pruebas de software.

Fecha de finalización planificada: Fecha calendario en la cual se tiene planificado finalizar las pruebas, considerando el número de casos de prueba total y las metas de casos diaria.

Casos de prueba (Total): Cantidad de casos de prueba que están incluidos en el diseño de casos de prueba. Representa el número total de casos que ejecutarán los Testers en el período definido para las pruebas.

Casos planificados: Cantidad de casos de pruebas que deberían estar completados a la fecha según la planificación.

Casos exitosos: Cantidad de casos reales completados. Esto representa el avance real de las pruebas. Sólo se cuentan los casos que las pruebas fueron superadas sin error, los casos con error no cuentan para el avance.

Avance planificado: Los casos de prueba planificados divididos entre el total de casos de prueba, dan como resultado el porcentaje de avance que deben tener las pruebas a la fecha de reporte.

Avance real: Se calcula por medio de la división de los casos exitosos entre el total de casos contemplados en el diseño de pruebas.

Desviación: La diferencia entre el avance real y el planificado resulta en la desviación. Un número negativo representa que las pruebas están avanzando por debajo de lo esperado.

Días de desviación: Los días de desviación se calculan multiplicando el porcentaje de desviación por los casos diarios. A su vez los casos diarios se determinan dividiendo el número total de casos entre los días hábiles disponibles para realizar las pruebas.

Fecha fin pronóstico: Para determinar la fecha fin pronóstico es necesario sumar a la fecha fin planificada los días de desviación.

Casos con incidencia: Cantidad de casos de prueba ejecutados que presentaron alguna incidencia. Aún después de corregir la incidencia el caso sigue siendo sumado, de esta forma al final se tendrán cuantos casos presentaron incidencias.

Casos con incidencias: División de los casos que presentaron alguna incidencia entre el total de casos. Representa un índice de la calidad del desarrollo e inclusive se pueden establecer acuerdos de nivel de servicio.

Situación actual de casos de prueba

Exitosos: Cantidad de casos de prueba que se encuentran en estado "Exitoso" a la fecha del informe. Son los casos que un Analista de pruebas ha ejecutado y ha sido superado sin error.

Con defectos: Cantidad de casos de prueba que se encuentran en estado "Fallido" a la fecha del informe. Son los casos que tienen asociados defectos con estatus distintos de cerrado.

Bloqueados: Cantidad de casos de prueba que se encuentran en estado "Bloqueado" a la fecha del informe. Un caso puede estar bloqueado por ejemplo cuando existe una incidencia identificada en otro caso pero que a su vez impide la ejecución de otros casos.

Diferidos: Cantidad de casos de prueba que se encuentran en estado "Diferido" a la fecha del informe. Un caso puede ser diferido por distintas razones, una de ellas por ejemplo es la no disponibilidad de un ambiente para un componente especifico.

Pendientes: Cantidad de casos de prueba que se encuentran en estado "Pendiente" a la fecha del informe. Son los casos que no han sido ejecutados aún.

Los estados en los cuales se puede encontrar un caso de prueba son definidos en la metodología de pruebas de software.

Situación actual de defectos

Reportados: Total de defectos reportados (incidencias) a la fecha de reporte.

En análisis: Cantidad de defectos que se encuentran en análisis, no han sido aceptados todavía.

Descartados: Cantidad de defectos descartados porque no aplicaban. Un no aplica ocurre cuando un Tester reporta un defecto que realmente no lo es. Una vez aclarada la situación se registra el defecto como descartado.

En proceso: Cantidad de defectos que fueron analizados y se encuentran en desarrollo.

Corregidos: Cantidad de defectos que han sido corregidos. La corrección del defecto implica su cierre.

Existen en el mercado herramientas de gestión de calidad de software que te permiten gestionar los casos de prueba, sus estatus, así como también los defectos.

Resultados de la jornada

Casos del día: Casos que se lograron ejecutar como exitosos durante la jornada (fecha de reporte).

Meta diaria: Casos que se esperan ejecutar cada día. Se puede calcular dividiendo los casos en diseño sobre los días planificados, o cualquier otra forma de estimación definida.

Puntos de atención y observaciones

Espacio para que la persona que elabora el reporte haga mención a los aspectos considerados relevantes para la gerencia receptora del informe. Aquí se pueden colocar por ejemplo alertas.

2.11 Fuentes de información de QA para el control estadística o métricas.

Se denominan fuentes de información, en teoría de la y telecomunicación, a cualquier origen de información susceptible de ser representado mediante una señal analógica y/o digital.

QA. Calidad de servicio o aseguramiento de la calidad.

2.12 Control estadístico vs métricas.

Producir un sistemas, aplicación o producto de alta calidad

Para lograr este objetivo se deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. Al mismo tiempo, un buen ingeniero del software y buenos administradores de la ingeniería del software deben medir si la alta calidad se va a llevar a cabo.

2.13 Importancia de la calidad, las métricas y el control estadístico.

¿Qué es la calidad?

v  “Una característica o atributo de algo.”

v  La totalidad de rasgos y características de un producto, proceso o servicio que sostiene la habilidad de satisfacer estados o necesidades implícitas”

En el campo de la ingeniería del software una métrica es cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamaño u otra característica de un software o un sistema de información, generalmente para realizar comparativas o para la planificación de proyectos de desarrollo.

Métricas en el desarrollo del software.

1. Medida de la calidad

Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de mantenimiento, integridad y facilidad de uso suministran indicadores útiles para el equipo del proyecto.

Corrección: La corrección es el grado en el que el software lleva a cabo una función requerida.

Facilidad de mantenimiento: La facilidad de mantenimiento es la habilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia o optimizar si el cliente desea un cambio de requisitos.

El tiempo medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la petición de cambio, en diseñar una modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio a todos los usuarios.

Integridad.

En esta época de intrusos informáticos y de virus, la integridad del software ha llegado a tener mucha importancia. Este atributo mide la habilidad de un sistema para soportar ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes del software, ya sea en los programas, datos o documentos.

Dos atributos para medir la integridad: amenaza y seguridad. La amenaza es la probabilidad (que se logra evaluar o concluir de la evidencia empírica) de que un ataque de un tipo establecido ocurra en un tiempo establecido. La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia empírica de que se pueda repeler el ataque.

Facilidad de uso.

Cuantificar si un programa no es “amigable con el usuario”, prácticamente está próximo al fracaso, incluso aunque las funciones que realice sean valiosas.

Y se consigue medir en función de cuatro características: destreza intelectual y/o física solicitada para aprender el sistema; el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del sistema; aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien emplea el sistema moderadamente y eficientemente, y  valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema.