Sin título

Página 1

FUNDAMENTOS DE PRUEBAS

CALIDAD DE SOFTWARE

TEMAS:

Fundamentos de Pruebas

Pruebas a través del ciclo de vida del Software

Técnicas de diseño de pruebas

Gestión de pruebas

OBJETIVO

Destacar los aspectos mas relevantes a tener en cuenta durante el proceso de pruebas comprendiendo la importancia de las mismas en la organización, las técnicas, y la aplicación en los casos que corresponda*, para el aseguramiento de la calidad del software.

Fundamentos de Pruebas

Que son y porque son necesarias las pruebas

Proceso de prueba básico

Desde gran Maquinaria hasta las cosas mas cotidianas dependen de un producto de software, las comunicaciones, el transporte, la salud entre otros.

si éstos software fallan, no solo se incurre en el riesgo empresarial, si no también, en el daño causado al usuario final en cuanto a su seguridad e integridad.

las fallas encontradas durante el proceso de prueba se denominan y se originan de la siguiente manera y de forma consecutiva:

Error: El error es una una acción humana, esta originado en la mente. (es física y humanamente imposible no generar un error desde el momento de la concepción del requerimiento o la documentación de la necesidad, bien sea por ambigüedades, distracciones, falta de conocimiento, tiempo, otros.)

Defecto: Se origina desde el error, manifestado en la documentación del requerimiento, se detecta en reuniones y revisiones.

Fallo: Es la manifestación física de un defecto, encontrado durante la ejecución de una aplicación.

Las pruebas también se hacen necesarias desde el punto de vista monetario:

El coste de los defectos constituyen un factor determinante puesto que un defecto detectado en una etapa temprana en el CICLO DE VIDA DEL SOFTWARE, permitirá reducir el impacto del mayor coste en una etapa avanzada

ESPECIFICACIÓN $7

DISEÑO $5

CONSTRUCCIÓN $10 7*5*10*8*12*15 = $6.048.000

PRUEBAS $8 $2800

ACEPTACIÓN $12

OPERACIÓN $15

Fundamentos de Pruebas

Que son y porque son necesarias las pruebas

Proceso de prueba básico

los tipos de pruebas se establecen según la norma ISO 9126 en 2 grandes grupos

CONSTRUCTIVAS - Previenen defectos (aplicación de métodos apropiados de ingeniería de software, desde guías, estándares, requisitos legales, herramientas, lenguajes, entre otros.)

ANALÍTICAS - Detectan defectos

en éste segundo grupo, se encuentra la definición, técnicas y estructura de los tipos de prueba y es la que compete al área de estudio.

PRUEBAS DINÁMICAS Y ESTÁTICAS:

ESTÁTICAS: son evaluaciones sin la ejecución del programa.

Técnicas: Revisiones, Análisis del flujo de control, Análisis del flujo de datos, métricas del compilador o analizador.

DINÁMICAS: incluyen la ejecución del programa

Técnicas: Caja blanca, Caja Negra y basadas en la Experiencia.

Más adelante en el tratamiento de técnicas, se ampliará detalle.

Pag. 1

PRUEBAS Y CALIDAD - ATRIBUTOS

Existen 2 tipos de tributos que sirven para evaluar y definir la calidad total del sistema, estos son FUNCIONALES y NO FUNCIONALES:

CRITERIOS DE SALIDA

los criterios de salida son eventos, elementos y condiciones que se acuerdan en equipo con todos los involucrados, para determinar que un proceso sea considerado formalmente concluido.

se hace con el propósito de evitar que una tarea se considere concluida habiendo partes destacadas de la misma sin completar. Algunos factores a tener en cuenta pueden ser:

No encontrar (mas) defectos.

Pruebas basadas en riesgos: probabilidad de la ocurrencia de fallos, aspectos relativos a factores económicos y propios del proyecto.

Pruebas basadas en plazos y presupuestos: la disponibilidad de recursos puede determinar la medida del esfuerzo del proceso de prueba

FUNCIONALES

Precisión/Exactitud las funciones representan los resultados acordados?

Interoperabilidad las interacciones con el entorno del sistema representan algún problema?

Cumplimiento Normatividad El sistema cumple con normas y reglamentos aplicables?

Adecuación/Adecuado las funciones implementadas son adecuadas para el uso esperado?

Seguridad Estan protegidos los datos/programas contra acceso no deseado o perdida.

NO FUNCIONALES

Fiabilidad La fiabilidad de un sistema se puede medir por pruebas de robustez, es decir, pruebas negativas (tolerancia a fallos)

Usabilidad las pruebas de usabilidad se caracterizan por demostrar que un sistema es estructurado, fácil de aprender y fácil de usar.

Eficiencia Estas pruebas permiten evidenciar el rendimiento de un sistema, la rapidez con la cual se ejecuta determinada función

Mantenibilidad Las pruebas de estabilidad evidencian el rendimiento en "modo de operación contínua"

Portabilidad La portabilidad hace referencia a la respuesta del sistema cuando se debe adaptar a un nuevo entorno, al ser reemplazado, al des instalarse e instalarse nuevamente.

LOS 7 PRINCIPIOS DEL PROCESO DE PRUEBA

El proceso de prueba demuestra la presencia de defectos

La causa de un fallo puede no ser obvia

El proceso de prueba no puede demostrar la ausencia de defectos

El mismo proceso de prueba puede contener errores

No es posible realizar pruebas exhaustivas

Es imposible hacer un conjunto de pruebas que abarque todas las combinaciones de valores de entrada y pre condiciones, la explosión de casos de prueba define el incremento factorial de esfuerzo y coste en el caso de pruebas exhaustivas.

Se debe diseñar una prueba de muestra o prueba aleatoria que abarque los posibles valores de entrada (Técnicas de diseño de pruebas)

Pruebas Tempranas

Cuanto mas temprano se detecta un defecto menos costosa es su corrección

La preparación de una prueba también consume tiempo

Las actividades de prueba deben ser ejecutadas en paralelo a la especificación y diseño de software.

Agrupamiento de defectos

se ha demostrado que donde se encuentra un defecto se encontraran mas.

"los defectos se encuentran agrupados como hongos" de allí que en algunas herramientas, el icono para reportar un defecto es como una cucaracha.

Repetir pruebas en las mismas condiciones NO es EFECTIVO

Las pruebas deben ser revisadas y modificadas regularmente para los distintos módulos de código.

La automatización de pruebas puede resultar conveniente si un conjunto de casos de prueba se debe ejecutar con frecuencia.

Las pruebas dependen del contexto

se llevan a cabo de forma diferente, en diferente contexto (según atributos y prioridades)

Las pruebas tienen lugar en un entorno distinto al de producción, pero debe ser muy similar al de producción.

La falacia de la ausencia del error

Al finalizar el proceso de prueba o no detectar mas fallos, no representa que el sistema no tiene defectos, un proceso adecuado encontrará los fallos mas importantes. Esto por si solo no prueba la calidad del Software.

La calidad tiene que construirse desde el principio.

Pag. 2

El proceso de prueba, esta inmerso en el proceso de desarrollo de software, la prueba constituye un proceso en sí misma, y esta determinado por las siguientes fases:

1. Planificación de pruebas

la planificación consiste en determinar en un documento oficial:

El alcance: donde se discrimina que se prueba o hasta donde se prueba, que no y porque.

Enfoque: se definen las técnicas de pruebas, equipo de pruebas, la asignación del personal, entorno o ambiente, presupuesto, tiempo para el desarrollo de actividades.

2. Análisis y diseño de pruebas

se requiere para ello:

Bases de prueba: (todo tipo de documento o soporte) referente a los requisitos, arquitectura del sistema, interfaces.

Diseño de casos de prueba: positivos que muestran la funcionalidad y negativos que comprueban situaciones en las que hay tratamiento de errores

Identificar condiciones de prueba: se evalúa la disponibilidad de datos de prueba y la viabilidad de generación de datos de prueba

3. Implementación y ejecución de pruebas

Finalizar , implementar y priorizar casos de prueba

para el caso de pruebas automatizadas, en esta fase se redactan los guiones con los casos de prueba seleccionados

Verificación del entorno de prueba

Ejecución de pruebas (manual o automática)

Registrar resultados de prueba y análisis

Comparar resultados reales con esperados e informar sobre incidencias detectadas

Repeticion de pruebas para confirmar correcciones (retest)

Ejecutar pruebas de regresion (test regresion)

4. Evaluación de criterios de salida

Evaluar la ejecución de pruebas con respecto a los objetivos definidos

Evaluar los registros de prueba

Proporcionar información con el objeto de dar lugar a la decisión de llevar a cabo pruebas adicionales

Generar informe de pruebas

5. Actividades de cierre

luego de finalizar las actividades desde planeacion, ejecucion y generacion de informe, se realizan las siguientes actividades con el fin de retroalimentar la experiencia obtenida y las lecciones aprendidas:

Cerrar informes de incidencia o generación de solicitudes de cambio para cualquier punto que permaneciera abierto.

comprobar que entregables previamente planificados han sido entregados y probados

Documentar la aceptación del sistema

Analizar las lecciones aprendidas para futuros proyectos

Pag. 3

los modelos de desarrollo de software son utilizados para el desarrollo de software incluyendo las actividades del proceso de prueba.

El modelo mas conocido es el modelo -V, el cual describe los niveles de desarrollo y los niveles de prueba como dos ramas relacionadas

Pruebas a través del modelo V - general

Las pruebas (rama derecha) son diseñadas en paralelo al desarrollo de software (rama izquierda).

cada etapa durante el desarrollo de software debe ser verificado y validado en los diferentes niveles de prueba

Pruebas de componente:

Son las mismas pruebas unitarias, o de desarrollador, se denominan componente porque consiste en probar cada módulo, clase o unidad tras su construcción.

En las pruebas de componentes se pueden validar tanto atributos funcionales como no funcionales

En la mayoría de los casos para éste nivel de pruebas se requieren "arnes" de prueba (driver´s o stubs)

El conocimiento de código fuente permitirá la aplicación de métodos de caja blanca.

Pruebas de integracion

Las pruebas de integración también se conocen como pruebas de interfaz.

La integración significa construir grupos de componentes

Comprueban la interacción entre componentes respecto de la especificación

existen 3 estrategias para llevar a cabo la integración, puede ocurrir de forma ascendente (bottom up), descendente (top down) o en forma de "Big bang"

Cualquier otra estrategia distinta a las anteriores se llama "Ad-hoc" (especcífico) y consiste en probar inmediatamente después de finalizada la construcción y las pruebas de componente, y puede ser aplicada en cualquier etapa del proyecto. Se usa generalmente en metodologías ágiles.

Pruebas de Sistema

las pruebas de sistema se diferencian con las pruebas de integración, porque para esta fase se requiere la construcción total y final del software, y no son válidos los simuladores o arnés.

en este punto la calidad del software es observada desde el punto de vista del usuario, es un acercamiento a la realidad.

El objetivo de éstas pruebas es comprobar que la funcionalidad implementada presenta las características requeridas (ISO 9126) y se desarrollan utilizando casos de prueba

Para los aspectos no funcionales, es recomendable tratar de cuantificar los tributos, puesto que son una parte implícita de los requisitos y ésto hace difícil validarlos.

Pruebas de Aceptacion

Se conocen también como pruebas de certificación, estas pruebas son realizadas por el cliente en un entorno o ambiente propio diferente a pruebas de sistema, mas conocido como pre-producción. (en el cual se pueden producir nuevos fallos)

con la aceptación formal se cumplen hitos legales: comienzo de fase de garantía, pagos, acuerdos de mantenimiento entre otros.

Normalmente el cliente selecciona los casos de prueba o tiene su propio set de pruebas

la certificación también se puede dar aplicando pruebas alfa y prueba beta.

Alfa: entorno de desarrollo

beta: entorno del cliente

Pag 4.

RESUMEN GENERAL TIPOS DE PRUEBAS:

En niveles de prueba distintos, se utilizan tipos de pruebas distintos

Los tipos de pruebas son: funcionales, no funcionales, estructurales y asociados al cambio

Las pruebas funcionales comprueban el comportamiento entrada/salida de un objeto de prueba

Las pruebas no funcionales comprueban las características de un producto, éstas pruebas incluyen pero no están limitadas a, pruebas de carga, pruebas de estrés, rendimiento, robustez.

las pruebas estructurales habituales comprueban el flujo de control y datos en el objeto de prueba midiendo el grado de cobertura (más adelante en técnicas de pruebas)

las pruebas asociadas al cambio son importantes porque se deben hacer después de un cambio (retest y regresion test).

TECNICAS DE PRUEBAS

Como se mencionó en la sección de Fundamentos, el QA ANALÍTICO está compuesto por dos ramas ESTÁTICA y DINÁMICA, durante el desarrollo de éste tema se evidenciarán las técnicas de pruebas para cada una de ellas.

ESTÁTICAS:

Revisiones (acción manual a cargo de los involucrados en el proyecto)

Análisis estático (acción basada en herramientas como analizadores y compiladores)

Revisiones

Documentos de alta calidad conducen a productos de alta calidad, incluso si una especificación revisada no contiene ningún defecto, la interpretación de la especificación y creación del diseño pueden ser defectuosa. Sin embargo mejoran la calidad del producto y ahorran costes

Existen 4 tipos de revisión:

Inspección

Revisión Guiada

Revisión Técnica

Revisión Informal

siendo la Inspección, la forma mas rigurosa y metódica; y la informal la mas simple

Análisis Estático

Consiste en revisar un Elemento

fundamentos

Pruebas a través del ciclo de vida del sw

fundamentos

PROCESO DE PRUEBA BASICO

INTRODUCCIÓN tecnicas