Capítulo 1: Error: Acción humana que produce un resultado incorrecto. Defecto: Desperfecto en un componente o sistema que puede ser la causa el sistema o componente no logre llevar a cabo su función específica. Fallo: Manifestación física o funcional de un defecto.
Norma IEEE 610
Definición de error, defecto y fallo. Definición de calidad-Definición software Definición de caso de prueba Definición de pruebas de aceptación.
ISO 9126
IEEE 1028 IEEE 828 IEEE 829
Definición de calidad del Software (Atributos funcionales y no funcionales) Tipos de Revisiones Estándar gestión de la configuración (incluyendo el plan de GC) Guión de pruebas Descripción de un caso de prueba Estructura del plan de pruebas Informe de estado de pruebas Informe de incidencias (Informe de errores) Definición de Verificación y Validación Estructura y contenidos de un plan de aseguramiento de la calidad. Está conformado por: Documentos que cubren el ciclo de vida de desarrollo, Organización del proyecto, Proceso de pruebas. Glosarios de los términos de prueba de software. (Definición de verificación, validación y pruebas). Estándar Pruebas de componentes.
ISO 9000 IEEE 730/IEEE 983 BS7925 - 1
BS7925 - 2
Definiciones según BS7925 - 1: Verificación: El proceso de evaluar un sistema o componente para determinar si los productos entregados en la fase de desarrollo satisfacen las condiciones acordadas al inicio de esa fase. ¿se siguió el proceso? Validación: Determinación de la corrección de los productos de software desarrollados con respecto a las necesidades del usuario y los requerimientos. ¿El sw cumple con lo solicitado por el cliente? Pruebas: Proceso de ejercicio software para verificar que se cumple con los requerimientos especificados y para detectar errores. La calidad del software está constituida por (ISO 9126):
Atributos funcionales: Funcionalidad significa: Correctitud (Atributos requeridos) y Completitud (requisitos funcionales) Funcionalidad Incluye: IPCIS o Idoneidad /Adecuación): Las funciones implementadas son adecuadas para su uso esperado? o Precisión: Las funciones presentan los resultados correctos (acordados)? o Conformidad: El sistema cumple con normas y reglamentos aplicables? o Interoperabilidad: Las interacciones con el entorno del sistema presentan algún problema? o Seguridad: Están protegidos los datos/programas contra acceso no deseado o pérdida
Atributos No funcionales: FUEMP o Fiabilidad (Confiabilidad): Madurez, tolerancia a defectos, recuperación tras fallos Calidad/Tiempo. o Usabilidad: Fácil de usar, fácil de aprender, conforme a normas, intuitivo. o Eficiencia: Comportamiento del sistema, funcionalidad y respuesta temporal. o Mantenibilidad: Cualidad de ser analizado, modificable. o Portabilidad: Capacidad de ser reemplazado, instalable. NOTA: Los atributos de calidad se influyen mutuamente, debido a esta interdependencia y en función del objeto de prueba, los atributos deberán ser caracterizados por una prioridad a los efectos de ser tenidos en cuenta. Se realizarán distintos tipos de pruebas con el objeto de medir cada tipo de atributo. Calidad total del sistema: Atributos de la calidad funcionales + Atributos de la calidad no funcionales.
CAJA NEGRA
QA Analítico: Detectar y corregir defectos Clase de equivalencia Análisis de Valores limite Pruebas de Transición de estados Tablas de decisión Algoritmo Pairwise (En parejas)
CAJA BLANCA ESTÁTICO
DINAMICO
QA ANALÍTICO
Técnicas basadas en la experiencia Cobertura de sentencia Cobertura de rama (Decisión) Cobertura de condición Cobertura de camino Revisiones/Ensayos Análisis del flujo de control Análisis del flujo de datos Métricas del compilador/Analizador
ORGANIZACIÓN
TÉCNICO
QA CONSTRUCTIVO
QA Constructivo: Prevención de defectos Guías Estándares Listas de Comprobación Reglas de proceso y normas Requisitos legales Métodos Herramientas Lenguajes Listas/Plantillas Entorno de desarrollo integrado (IDE)
Principios del proceso de pruebas: 1. Principio 1: Las pruebas demuestran la presencia de defectos – Las pruebas pueden mostrar que hay defectos, pero no que no los hay 2. Principio 2: Las pruebas exhaustivas no existen – Es imposible en la prueba cubrir todas las combinaciones 3. Principio 3: Pruebas tempranas - Iniciar pruebas lo antes posible en el ciclo de vida del sw 4. Principio 4: Agrupación de defectos – Donde encuentres un defecto, encontraras más. 5. Principio 5: Paradoja del pesticida – La ejecución de los mismos escenarios evitan encontrar nuevos errores 6. Principio 6: Las pruebas dependen del contexto – Las pruebas son diferentes de acuerdo al tipo de sistema. 7. Principio 7: Falacia de ausencia de errores – No hay errores pero el sistema no cumple con lo que pidió el cliente Fases del Proceso de pruebas:
Planificación: Abarca actividades como la definición de la estrategia de pruebas para todos las fases así como la planificación de los recursos (tiempo, personal, máquinas).
Análisis y diseño: Abarca el diseño de casos de prueba y sus resultados esperados. Análisis: Revisión de las bases de las pruebas (requisitos, arquitectura, diseño, interfaces), Identificar condiciones de prueba especificas y los datos de prueba. Diseño: Crear casos de prueba lógicos y establecer un orden de prioridad para los mismos. Crear tanto casos de prueba positivos como negativos.
Implementación y ejecución: Abarca la definición de datos de pruebas, la ejecución de pruebas y la comparación de resultados. Incluye Creación de guiones de automatización de pruebas si fuera necesario. Configuración del entorno de pruebas, Ejecución de pruebas de forma manual o automática, Registro y análisis de los resultados de pruebas, Retest y pruebas de regresión.
Evaluación del criterio de salida y generación de informe: Abarca el análisis de defectos y la evaluación del criterio de salida. Evaluación de la ejecución de las pruebas con respecto
a objetivos definidos. Proporcionar información con el objeto de permitir decisión con respecto a si tendrá lugar pruebas adicionales.
Actividades de cierre: Recopilar datos de las actividades del proceso de pruebas finalizadas con el objetivo de consolidar la experiencia, producto de las pruebas (testware), hechos y resultados. Cierre de informes de incidencias o generación de solicitudes de cambio para cualquier punto que permaneciera abierto. Comprobar que entregables planificados han sido entregados y probados. Documentar la aceptación del sistema. Finalizar y archivar los productos de las pruebas (testware). Lecciones aprendidas.
Control (Transversal): Actividad continúa que influye en la planificación de las pruebas. El plan de pruebas puede ser modificado en función de la información adquirida a partir del control de pruebas. El progreso, la cobertura y el cumplimiento del criterio de finalización son objeto de seguimiento y son documentados.
NOTA: Las fases del proceso de pruebas se pueden superponer. Incluye backtracking (vuelta atras). Cada fase del proceso de pruebas tiene lugar de forma concurrente con las fases del proceso de desarrollo software. Objetivos de las pruebas: Adquirir conocimiento sobre los defectos en un objeto de prueba. Comprobar la funcionalidad. Generar información. Generar confianza. Pruebas dirigidas por Objetivos: Detección de defectos Verificar la funcionalidad Oráculo De Pruebas: Fuente que permite determinar los resultados esperados en un software sujeto a pruebas: comparativas “benchmarks”, manuales de usuario o conocimiento especializado. No debe ser el código. Base de la prueba: Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como fundamento para el desarrollo de casos de prueba. Criterio para la finalización: No encontrar más defectos es un criterio apropiado para finalizar las pruebas, sin embargo son necesarias otras métricas: Pruebas basadas en riesgo Pruebas basadas en plazos y presupuestos Nota: Cada prueba debe contar con un criterio para la finalización de pruebas. Al alcanzar el criterio de finalización de pruebas finalizan las actividades del proceso de pruebas. PARA CADA NIVEL DEPRUEBAS SE DEBE DEFINIR: Estrategia de pruebas: Descripción a alto nivel de los niveles de prueba a llevar a cabo y las pruebas asociadas a ellos.
Se elige el método de prueba, cómo y cuando las actividades asociadas a las pruebas deberán ser ejecutadas y cuando se debe detener el proceso de pruebas ->Criterio de finalización.
Criterio de salida: Conjunto de condiciones genéricas y específicas, acordadas con los implicados para permitir que un proceso sea considerado formalmente finalizado. El propósito de los criterios de salida es evitar que una tarea se considere finalizada habiendo partes destacadas de la misma sin completar. Los criterios de salida son utilizados como fuente para elaborar informes y planificar la suspensión de las pruebas.
Caso de prueba (IEEE610): 1. Precondiciones 2. Conjunto de valores de entrada 3. Conjunto de resultados esperados 4. Pasos (Forma en la cual se debe ejecutar el caso de prueba y verificar el resultado) 5. Pos condiciones esperadas
Capitulo 2: El modelo V general es el modelo de desarrollo software más utilizado. Desarrollo y pruebas son dos ramas iguales. Cada nivel de desarrollo tiene su correspondiente nivel de pruebas. Las pruebas (rama derecha) se diseñan en paralelo al desarrollo software (rama izquierda). Las actividades del proceso de pruebas tienen lugar a lo largo de todo el ciclo de vida software. Rama: Desarrollo software Definición de requisitos: Documentos de especificación. Diseño funcional del sistema: Diseño del flujo funcional del sistema. Diseño técnico del sistema: Definición de arquitectura – Interfaces Especificación de los componentes: Estructura de los componentes. Programación: Creación de código ejecutable. Rama: Pruebas software: Pruebas de componente: Funcionalidad del componente. Pruebas de integración: Interfaces de componentes. Pruebas de sistema: Sistema integrado especificaciones. Pruebas de aceptación: Pruebas formales de los requisitos del cliente. Modelo V: Describe los niveles de desarrollo y niveles de prueba como dos ramas relacionadas.
Verificación vs Validación (ISO 9000): Verificación: Comprobación de la conformidad con los requisitos establecidos ¿Se ha procedido correctamente en la construcción del sistema? En el modelo en V, significa comprobar si los requisitos y definiciones de niveles previos han sido implementados correctamente. Relación con el nivel precedente. -> Rama Desarrollo
Validación: Comprobación de la idoneidad para el uso esperado ¿Hemos construido el sistema software correcto? En el modelo en V, significa comprobar lo adecuado de los resultados de un nivel de desarrollo. Grado de ser correcto el producto dentro del nivel actual. - >Rama Pruebas.
Modelos de prueba iterativos: Las actividades de definición de requisitos, diseño, desarrollo y pruebas se segmentan en pasos reducidos y se ejecutan de forma continua. Se debe alcanzar el consentimiento con el cliente tras cada iteración con el objeto de modificar el rumbo del proyecto si fuera necesario. Ejemplos: Modelo prototipado. Desarrollo rápido de aplicaciones (RAD): La interfaz de usuario se implementa utilizando una funcionalidad hecha, simulando la funcionalidad que posteriormente será desarrollada. Proceso Unificado (RUP): Modelo orientado al objeto. Producto de la compañía IBM. Principalmente aporta el lenguaje de modelado UML y soporte al proceso Unificado. Programación extrema: El desarrollo y las pruebas tienen lugar sin una especificación de requisitos formalizada. Driver: Procesa la interfaz de un componente. Simulan datos de entrada, registran datos de salida y aportan una armadura de pruebas. Utilizan herramientas de programación. Stub: Reemplaza o simula un componente que aún no se encuentra disponible. Niveles en el proceso de pruebas: Pruebas de componentes: (Pruebas de módulo, de clase, de unidad y de desarrollador) Pruebas de cada componente tras su realización. Solo se prueban componentes individuales. Un componente es la unidad más pequeña especificada de un sistema. Podrán comprobar características funcionales y no funcionales de un sistema.
Se utilizan herramientas de programación como debbugers. Los efectos cruzados entre componentes quedan fuera del alcance de estas pruebas. La ejecución de pruebas de componente requiere frecuentemente de drivers (procesa la interfaz de un componente) y stubs (Reemplaza o simula un componente que aún no se encuentra disponible). El conocimiento del código fuente permitirá la aplicación de métodos de caja blanca para pruebas de componente. Fuerte orientación al desarrollo. Pruebas de integración: (Pruebas de interfaz) Comprueba la integración entre los elementos software (componentes) tras la integración del sistema. Asume que los componentes ya han sido probados. Son necesarios drivers de prueba. (Se pueden reutilizar los de los componentes) Herramientas de control apoyan las actividades de este nivel de prueba. Es la actividad en la cual se combinan componentes software individuales en subsistemas más amplios. En condiciones reales factores adicionales del entorno pueden influir en el comportamiento del componente. Por lo tanto las pruebas de integración no pueden garantizar un comportamiento correcto en el entorno real del sistema. La estrategia de desarrollo influye en la estrategia de integración. Estrategias: (Determina la magnitud del esfuerzo requerido para las pruebas) Estrategia ascendente (bottom - up): Un enfoque incremental de pruebas de integración donde los componentes de más bajo nivel son probados en primer lugar, posteriormente son utilizados para facilitar las pruebas de componentes de un nivel superior. Este proceso se repite hasta que es probado el componente en el extremo superior de la jerarquía. Estrategia descendente (top-down): Enfoque incremental de las pruebas de integración donde el componente en el nivel más alto en la jerarquía es probado primero, con los componentes del nivel inferior son simulados mediante stubs. Los componentes probados son usados luego para probar a los componentes del nivel inferior. El proceso se repite hasta que el nivel más bajo haya sido probado. Ad hoc: Inicio temprano de las actividades de prueba dando lugar a un proceso de desarrollo software más corto en términos globales. Pruebas llevadas a cabo de manera informal; no se realiza una preparación formal de la prueba, no se utilizan técnicas de diseño reconocidas, no existen expectativas para con los resultados y la arbitrariedad guía la actividad de ejecución. Big bang: Tipo de pruebas de integración en el que los elementos software, elementos hardware ó ambos son combinados en un componente o un sistema global en lugar de hacerlo por fases. NOTA: La estrategia de desarrollo influyen en la estrategia de integración Pruebas de sistema: Pruebas del sistema software integrado con el objeto de comprobar la conformidad con los requisitos especificados. La calidad del software es observada desde el punto de vista del usuario. Despliegue en el entorno real del sistema con datos reales. No son necesarios stubs o drivers. El entorno de pruebas debe coincidir con el futuro entorno real del sistema.
Se refieren a Requisitos funcionales y no funcionales. Las pruebas de sistema funcionales confirman que los requisitos para un uso específico previsto han sido satisfechos (validación). Las pruebas de sistema no funcionales verifican los atributos de calidad no funcionales. Con frecuencia estos atributos son una parte implícita de los requisitos, esto hace difícil validarlos. Enfoques para probar requisitos funcionales: Pruebas basadas en requisitos, en procesos de negocio y en casos de uso. Pruebas de aceptación: Son pruebas formales llevadas a cabo con el objeto de verificar la conformidad del sistema con los requisitos. El objetivo es aportar justificación a la confianza en el sistema para que pueda ser aceptado por el cliente. Pruebas de aceptación – Aceptación Contractual: Con la aceptación formal se cumplen hitos legales: Comienzo de fases de garantía, hitos de abono (pago), acuerdos de mantenimiento. Normalmente el cliente selecciona casos de prueba para las pruebas de aceptación. Pruebas de aceptación – Pruebas de aceptación operativa: Requiere que el software sea adecuado para su uso en un entorno operativo. Integración del software con la Tecnología de información del cliente. Con frecuencia son realizadas por el administrador de sistemas del cliente. Son las pruebas de sistema por parte del cliente. “El cliente conoce su negocio” Es una actividad de carácter contractual (satisface los requisitos del cliente?). Requiere que el software sea adecuado para su uso en un entorno operativo. Integración del software en la estructura TI del cliente. Pruebas de aceptación –Pruebas Alfa y Beta: Pruebas Alfa: El cliente ejecuta las pruebas en las dependencias de la organización que desarrolla. Pruebas Beta (Pruebas de campo): El cliente ejecuta las pruebas en dependencias propias. TIPOS DE PRUEBA: Pruebas funcionales: Objetivo: Probar la función. Se pueden llevar a cabo en todos los niveles de prueba. Se utilizan los métodos de caja negra. Se desarrollan teniendo en cuenta los requisitos funcionales. Los resultados de la ejecución de la prueba son comparados con los resultados esperados. Pruebas no funcionales: Objetivo: Probar las características del producto software. Se pueden llevar a cabo en todos los niveles. Las características de calidad no funcionales a menudo son incompletas, inexistentes por lo que hace más difícil las pruebas. Ejemplo de pruebas no funcionales: Pruebas de carga (más usuarios, más transacciones), de rendimiento (Rapidez-tarea), de volumen (Procesamiento grandes cantidades de datos), de estrés (reacción sobrecarga, recuperación tras fallos), de estabilidad (modo de operación continuo), de robustez (entradas erróneas, datos no especificados, reacción a fallos Hw, recuperación ante desastres), de seguridad de datos (protección contra accesos no autorizados), de compatibilidad (cumplimiento de normas y reglamentos. Reacción a diferentes entornos), de usabilidad.
NOTA: La conformidad con los requisitos no funcionales, se miden utilizando requisitos funcionales. Pruebas estructurales: Objetivo: Probar la estructura/arquitectura software Cobertura. Medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba. Enfoque: Caja blanca Son posibles en todos los niveles. Comprueban el flujo de control y datos midiendo la cobertura en el objeto de pruebas. Se realizan de forma conjunta a las pruebas de componente y de integración mediante el uso de herramientas. El diseño se realiza después del diseño de las pruebas funcionales, para obtener un alto grado de cobertura. Pruebas de confirmación/regresión (Pruebas relacionadas a cambios): Objetivo: Probar después de cambios Se realizan después de que un objeto de pruebas o en entorno de su sistema ha sido objeto de modificación. Pruebas de regresión: Repetir una prueba de funcionalidad que ha sido verificada previamente. Pruebas para descubrir nuevos defectos introducidos en una funcionalidad previamente sin fallos. Pruebas de confirmación (retest): Pruebas después de la corrección de defectos. Pueden ser realizadas en todos los niveles. Nota: Pruebas de mantenimiento: Probar los cambios en un sistema en operación o el impacto de un entorno modificado en un sistema en operación. Capitulo 3: Técnicas estáticas: Comprenden varios métodos que no ejecutan el componente o sistema objeto de prueba. Incluyen: Revisiones (Actividad Manual). Se utilizan para verificar la correcta transición de una fase a la siguiente, según está definido en el lado izquierdo del modelo en V. Análisis Estático (Actividad basada en herramientas) REVISIONES: Complementan los métodos dinámicos. Detectan defectos en lugar de fallos, en una fase temprana antes de que sean implementadas en el código. Objetivo: Mejorar la calidad del producto. Moderador y participantes influyen directamente en la calidad de la revisión. Las revisiones permiten detectar defectos en especificaciones, diseño/arquitectura, desviaciones con respecto al estándar, mantenibilidad insuficiente. Fases de una revisión: Planificación: Organización de la revisión, selección de miembros. Preparación de la organización e inicio “kick-off”: Distribución objetivos de la revisión e información adicional. Preparación individual: Inspección de los objetivos, se comentan los elementos en caso de aclaraciones.
Reunión de revisión: Evaluadores presentan los resultados. Seguimiento “follow-up”: Resultados ->Responsables, Recomendaciones.
Roles: Director/Responsable/Jefe de proyecto. Moderador. Autor. Evaluador/Inspector/Revisor. Secretario. Tipos de revisiones: Inspección: Basado en reglas, uso de listas de comprobación, Moderador capacitado e independiente, proceso formal. Propósito: Detección de defectos utilizando un método estructurado. Roles claramente definidos, requiere preparación. Walkthrough: Dirigida por el autor, no es necesario moderador, posibilidad limitada de control. Opcionalmente puede haber una preparación de los evaluadores previa a la reunión. El resultado queda abierto. Autor -> Influye en el resultado. Revisión técnica: Son necesarios expertos preferiblemente externos, la reunión puede tener lugar sin la presencia del autor, se presenta las recomendaciones con carácter unánime. Se requiere preparación. Ejemplo: SQA. Revisión informal (revisión por pares): Forma de revisión más simple, frecuentemente iniciada por el autor, solo están incluidos los evaluadores, no es necesaria reunión. No hay protocolo. NOTA: Para la ejecución apropiada de las revisiones es necesario un presupuesto suficiente 1015% del costo total del desarrollo. Duración: Máximo 2 Horas. Análisis Estático: Análisis del objeto de prueba (código fuente, guión/script, requisitos) llevado a cabo sin ejecutar el producto software. Se comprueba: Reglas y estándares de programación Diseño de un programa (análisis de flujo de control) Uso de datos (análisis de flujo de datos) Complejidad de la estructura de un programa (Métricas, ej: Número ciclomático) Todos los objetos de prueba deben tener una estructura formal. El análisis estático de un programa mediante el uso de herramientas, se desarrolla con menor esfuerzo que el de una inspección, por lo que con mucha frecuencia este se realiza antes de una revisión. Herramientas a utilizar: Compiladores: Detecta errores sintácticos en el código fuente de un programa, comprueba la consistencia entre los tipos de variables. Detecta variables no declaradas o código inaccesible (código muerto). Analizadores: Trata aspectos como convenciones y estándares, métricas de complejidad y acoplamiento de objetos. Análisis de flujo de control:
Detectar defectos causados por un desarrollo anómalo del código (ramas muertas, código muerto, retornos múltiples). Visión del conjunto del código de programa comprensible. Método: La estructura del código se representa como un diagrama de control de flujo (grafo dirigido). Construcción mediante herramientas. Análisis de flujo de datos: Detección de anomalías en el flujo de datos con la asistencia de los diagramas de control de flujo y conjeturas racionales respecto de la secuencia de flujos de datos. Se puede detectar fácilmente la localización exacta de los defectos. Número ciclomático: Métrica que mide la complejidad estática de un programa basada en su grafo de flujo de control. Aporta un índice del número de casos de prueba necesarios para alcanzar cobertura de decisión. También puede ser calculado como el número de decisiones independientes + 1. (Puede dar diferente valor debido a ramas superfluas o ramas faltantes). Mide los caminos linealmente independientes como índice de testeabilidad y mantenibilidad. Fórmula: V(G)=e-n+2p e: Número de aristas n: Número de nodos p: Número de partes del programa independientes inspeccionadas (normalmente 1) Valores hasta 10 son aceptables (Según McCabe) Aporta un índice del número de casos de prueba necesarios para alcanzar cobertura de decisión. NOTA: Ejemplo de otras métricas LOC (Líneas de código) Capitulo 4: Diseño de casos de prueba: Los casos de prueba y los juegos de pruebas (test suites) son obtenidos a partir de los requisitos o características de los objetos de pruebas. El diseño de casos de prueba debe ser un proceso controlado. Los casos de prueba pueden ser creados formal o informalmente dependiendo de las características del proyecto y la madurez del proceso en uso. Descripción de un caso de prueba (IEEE829): Valores de entrada Precondiciones Resultados esperados Poscondiciones Dependencias (orden de ejecución) Identificador distinguible Requisitos TÉCNICAS DE DISEÑO DE PRUEBAS: Las pruebas dinámicas se dividen en dos categorías/grupos: Técnica caja Negra (Funcional/Orientada a la especificación): La estructura del objeto de prueba es irrelevante o desconocida. Los casos de prueba se obtienen a partir del análisis de la especificación (funcional o no funcional) de un componente o sistema. Prueba del comportamiento entrada-salida. La funcionalidad es el foco de atención.
Las pruebas funcionales están dirigidas a verificar que la función sea correcta y completa. La cobertura de la especificación puede ser medida. (Ej: El porcentaje de la especificación cubierta por los casos de prueba) 1. Partición equivalente o clase de equivalencia: Es lo que la mayoría de los probadores hacen de forma intuitiva: dividen los posibles valores en clases. Mediante lo cual observan: - Valores de entrada de un programa (uso habitual del método CE) - Valores de salida de un programa (uso poco habitual del método CE) Se evalúa un valor (típico) de la clase de equivalencia. El rango de valores definido se agrupa en clases de equivalencia, se aplican las siguientes reglas: - Todos los valores para los cuales se espera que el programa tenga un comportamiento común se agrupan en una clase de equivalencia CE. - Las clases de equivalencia no se pueden superponer y no pueden presentar ningún salto (discontinuidad) - Las clases de equivalencia pueden consistir en un rango de valores o en un valor aislado. Las pruebas se ejecutan utilizando un único representante de la clase equivalente. Para otro valor perteneciente a la clase equivalente se espera el mismo comportamiento que para el valor seleccionado. La calidad de la prueba depende de la segmentación precisa de variables o elementos en clases de equivalencia. Todas las variables de entrada del objeto de entrada son identificadas. Ejemplo: Campos de una interfaz gráfica de usuario o parámetros de una función. La cobertura de clases de equivalencia puede ser utilizada como criterio de salida para finalizar las actividades del proceso de pruebas. Tratan entradas en condiciones aisladas. Dado el posible enmascaramiento de errores, se debe evitar combinaciones de representantes de CE inválidos con representantes de otras CE inválidas en un mismo caso de prueba. Cobertura CE: (Número de CE probados/Número de CE definidos)*100% 2. Análisis de valores límite: Amplia la técnica de partición en clases de equivalencia introduciendo una regla para seleccionar a los representantes. Se evalúa los valores límite (frontera) y su entorno. Se detectan errores de programación causado por un operador de comparación erróneo. Tratan entradas en condiciones aisladas. 3. Tablas de decisión & gráficos causa y efecto: Tienen en cuenta el efecto de dependencias y combinaciones de entrada.
El diagrama causa y efecto utiliza un lenguaje formal. Se genera traduciendo la especificación (normalmente informal) de un objeto de prueba a un lenguaje formal. o
Aseveración (Afirmación): Si causa A- entonces efecto E A
o
E Negación: Si causa A - entonces no efecto ~
A o
E
O (Or): Si Causa A o B - entonces efecto E A E v
B o
Y (And): Si causa A y B -entonces efecto E A
Λ E
B o
Exclusivo: O causa A o causa B A Ex B
o
Inclusivo: Por lo menos una de las dos causas A o B A
I B
o
Una y solo una (Una y exactamente una de las dos causas A o B)
A O B o
Requerido: Si causa A entonces también causa B A R B
Es difícil deducir valores límite a partir del diagrama causa y efecto o de la tabla de decisión, por esta razón es recomendable realizar una combinación entre los dos. El número de causas y efectos analizados determinarán la complejidad del diagrama causa y efecto. (Para n precondiciones cuyos posibles valores puedan ser Verdadero o falso -> 2𝑛 casos de prueba. Para sistemas de mayor tamaño este método solo es controlable con el apoyo de herramientas. 4. Pruebas de transición de estado: A través de diagramas de transición de estado se modelan los distintos estados que puede tomar un objeto de prueba. El Análisis de transición de estado se utiliza para definir casos de prueba basados en la transición de estado. Árbol de transición de estado: Sirve para determinar los casos de prueba utilizando un diagrama de transición de estado. Para todos los estados, las posibles transiciones de un estado a otro se representan como ramas. El estado inicial es la raíz del árbol. Cada camino desde la raíz hasta una hoja, representa un caso de prueba para las pruebas de transición de estado. Buen método de pruebas para aquellos objetos de prueba que pueden ser descritos como una máquina de estado. Sirve para probar clases si se dispone del ciclo de vida del objeto. El árbol de transición de estado puede ser ampliado aplicando transiciones no válidas (casos de prueba negativos, pruebas de robustez).
Con frecuencia los estados suelen ser complejos. Criterios de salida de las pruebas: Cada estado debe haber sido alcanzado al menos una vez. Cada transición debe haber sido ejecutada al menos una vez.
5. Pruebas de caso de uso: Los casos de prueba se obtienen directamente a partir de los casos de uso del objeto de prueba. El objeto de prueba es visto como un sistema reaccionando con actores. Un caso de uso describe la interacción de todos los actores involucrados conduciendo a un resultado final por parte del sistema. Todo caso de uso tiene precondiciones (deben ser cumplidas) y poscondiciones. Describe un comportamiento, no una secuencia de acciones. Muestra la reacción del sistema desde el punto de vista del usuario. Debido a que este método no obtiene casos de prueba adicionales que vayan más allá de la información aportada por el caso de uso, se debe utilizar solo en combinación con otros métodos de diseño sistemático de casos de prueba. Pruebas apropiadas para pruebas de aceptación y sistema. Cada caso de uso describe un escenario. Otras pruebas de caja negra: 6. Pruebas estadísticas: Una técnica de diseño de pruebas en la que se usa un modelo de distribución estadística de las entradas para construir casos de prueba representativos. Véase también pruebas de perfil operativo. 7. Pruebas duales (Algoritmo pairwise) 8. Pruebas de humo: Subconjunto de todos los casos de prueba definidos/planeados que cubren la funcionalidad principal de un componente o sistema, con el objeto de asegurar que las funciones cruciales de un programa funcionan, pero sin preocuparse por los detalles finos Técnica Caja blanca: (Prueba estructural o pruebas basadas en el flujo de control) Se conoce la estructura interna del programa/código Ej: Jerarquía de los componentes, flujo de control, flujo de datos. Los casos de prueba son seleccionados en basa a la estructura interna del programa/código. La estructura del programa es el foco de atención.
Principalmente, los métodos de caja blanca son utilizados en pruebas de bajo nivel como pruebas de componente o pruebas de integración. Las técnicas de caja blanca requieren el apoyo de herramientas para: La especificación de caso de prueba (generación automática del diagrama del flujo de control a partir del código fuente del programa) y Ejecución de prueba (Herramientas para monitorizar y controlar el flujo del programa dentro del objeto de prueba). El soporte de herramientas asegura la calidad de las pruebas e incrementa su eficiencia (Debido a la complejidad). La medición de la cobertura se realiza con el uso de herramientas diseñadas de forma especifica (Herramientas de Análisis de Cobertura). El código faltante no puede ser detectado utilizando técnicas de caja blanca. Grado de cobertura de un programa: Se mide con el uso de herramientas: o La instrumentación del código: Cuenta la ejecución de caminos, es decir se insertan contadores en el código del programa del objeto de prueba. Estos contadores son inicializados en cero, de esta manera cada ejecución del camino específico incrementará el contador correspondiente. Los contadores que mantienen el valor en cero tras las pruebas indican las partes del programa que aún no han sido ejecutadas. Técnicas de diseño de caja blanca: 1. Cobertura de sentencia/Cobertura de código: Porcentaje de sentencias ejecutables que han sido practicadas por los casos de prueba. También puede ser aplicado a módulos, clases, elementos de un menú, etc. El foco de atención es la sentencia del código de un programa. La base de este análisis es el diagrama del flujo de control. Se centra en los nodos. Todas las instrucciones están representadas por nodos y el flujo de control entre instrucciones está representado por una arista (flecha). Si hay código muerto en el programa no se podrá lograr una cobertura del 100%. Cobertura de sentencia 𝐶0= 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠 ∗ 100% 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎𝑠
2. Cobertura de Rama/Decisión: Porcentaje de resultados de decisión que han sido practicados por los casos de prueba. Se centra en el flujo de control de un segmento de programa (no los nodos sino las aristas del diagrama de flujo de control) El bucle no se cuenta como una decisión adicional. Cobertura de decisión 𝐶1= 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠 ∗ 100% 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠
Cobertura de rama 𝐶1= 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑎𝑚𝑎𝑠 𝑐𝑢𝑏𝑖𝑒𝑟𝑡𝑎𝑠 ∗ 100% 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑟𝑎𝑚𝑎𝑠
Una cobertura de decisión del 100% siempre incluye una cobertura de sentencia del 100%. Un solo camino a través de un bucle es suficiente. No se pude detectar sentencias faltantes. No es suficiente para probar condiciones complejas. No es suficiente para probar bucles de forma extensiva. No se consideran las dependencias entre bucles. 3. Cobertura de condición: Se tiene en cuenta la complejidad de una condición que esté constituida por múltiples condiciones atómicas. Una condición atómica no puede ser dividida en sentencias condicionales más pequeñas. Este método tiene por objetivo detectar defectos que resulten de la implementación de condiciones múltiples (condiciones combinadas). Las condiciones múltiples están constituidas por condiciones atómicas que se combinan con el uso de operadores lógicos como XOR AND, OR, etc. Las condiciones atómicas no contienen operadores lógicos solo contienen operadores relacionales y el operador NOT (<,>,=) Hay 3 tipos de cobertura de condición (De acuerdo al grado) o
Cobertura de condición simple: Cada subcondición atómica de una sentencia condicional combinada tiene que tomar, al menos una vez, los valores lógicos verdadero (“true”) así como falso (“false”).
o
Cobertura de condición múltiple: Todas las combinaciones que puedan ser creadas utilizando permutaciones de las subcondiciones atómicas deben formar parte de las pruebas, es decir se crean todas las combinaciones de valores verdadero y falso. El número de casos de prueba se incrementa de forma exponencial. n = Número de condiciones atómicas. 2𝑛 = número de casos de prueba. Asegura cobertura de sentencia y de decisión. Alto número de casos de prueba. Xor
OR
AND
o
Cobertura de condición múltiple mínima: Todas las combinaciones que puedan ser creadas utilizando los resultados lógicos de cada sub-condición deben ser parte de las pruebas, sólo si el cambio del resultado de una sub-condición cambia el resultado de la combinación combinada. El número de casos de prueba se puede reducir a un valor entre n+1 y 2n Son cubiertas las coberturas de sentencia y decisión. Tiene en cuenta la complejidad de las sentencias de decisión.
4. Cobertura de camino: Porcentaje de caminos de ejecución que han sido practicados por casos de prueba. Se centra en la ejecución de todos los posibles caminos a través de un programa. Un camino es una combinación de segmentos de programa (en un diagrama de flujo de control: una secuencia de alternante de nodos y aristas). Para cobertura de decisión, un solo camino a través de un bucle es suficiente. Para la cobertura de camino hay casos de prueba adicionales. Esto puede conducir a un número muy alto de casos de prueba. El objetivo de esta prueba (criterio de salida) es alcanzar un porcentaje definido de cobertura de camino. Cobertura de camino 𝐶= 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑐𝑎𝑚𝑖𝑛𝑜𝑠 𝑐𝑢𝑏𝑖𝑒𝑟𝑡𝑜𝑠 ∗ 100% 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑐𝑎𝑚𝑖𝑛𝑜𝑠
El 100% de cobertura de camino solo se puede lograr en programas muy simples, Todo número de posible de ejecuciones de un bucle constituye un nuevo caso de prueba.
Teóricamente es posible un número indefinido de casos de prueba. La cobertura de camino es más exhaustiva que la cobertura de sentencia y decisión. 100% cobertura de camino, incluye 100% de cobertura de decisión, que a su vez incluye 100% cobertura de sentencia.
100% Camino
100% Decisión
100% Sentencia Otras técnicas: 5. LCSAJ: Secuencia lineal de código y salto 6. Técnicas basadas en el flujo de datos Técnicas basadas en la experiencia/Intuitivas Practica para la creación de casos de prueba sin un claro enfoque metodológico, basada en la intuición y experiencia del probador. Incluyen (Técnicas de Diseño de casos de prueba): - Predicción de errores (error guessing): Pruebas orientadas a puntos débiles. - Pruebas exploratorias: Pruebas iterativas basadas en el conocimiento adquirido respecto del sistema. Complementan las técnicas sistemáticas para determinar casos de prueba. No cumple los criterios de un proceso de prueba sistemático. Dependen en gran medida de la habilidad individual del probador. Criterios para seleccionar el enfoque apropiado de diseño de casos de prueba: - Fuente de pruebas (Fuente de la información respecto de los objetos de prueba) - Objetivos del proceso de prueba (Que conclusiones de deben obtener a través de las pruebas) - Aspectos asociados al riesgo. - Estructura del proyecto/precondiciones (recursos, métodos de desarrollo… info clave del proyecto). - Requisitos contractuales/cliente. Capitulo 5: La gestión de pruebas como parte del proceso de pruebas. La gestión de pruebas es la gestión del proyecto.
El proceso de pruebas es una actividad que cubre por completo el proceso de desarrollo de software. Actividad Producto Resultado de trabajo Concepción de pruebas Plan de pruebas (Estático) Planificación de pruebas Plan de pruebas (Dinámico) Control de pruebas Informe de estado, acción de control Pruebas de aceptación Versión del producto software Roles asociados al proceso de pruebas: Jefe de pruebas/Director de pruebas/Coordinador de Pruebas: Planifica y realiza el seguimiento y control del proyecto de pruebas. Competencias: o Gestión de pruebas y calidad software o Planificación y control de pruebas o Experiencia como jefe de proyecto o Habilidades de gestor Tareas: o Organización del equipo de pruebas o Planificación de pruebas (de acuerdo con el plan de calidad corporativo) o Planificación de los ciclos de pruebas o Estrategia de pruebas o Ejecución y control de pruebas o Introducción de un sistema de gestión de incidencias adecuado o Introducción de un sistema de gestión de la configuración o Informes de resultado y progreso para la dirección de la organización/compañía (El cierre de las pruebas se confirma con el jefe de pruebas cuando todos los criterios de salida (medidos utilizando métricas) son cumplidos/alcanzados) o Evalúa el informe de problemas (Luego de que el tester detecta los errores) o Asigna prioridades a los errores detectados (de acuerdo con la dirección del proyecto, cliente, etc.) o Redacta el informe de estado en función del estado actual de las labores de corrección. o Planificación del ciclo de pruebas. Conclusión: Las tareas del jefe de pruebas son: Iniciación, control, supervisión y ciclos de pruebas. Diseñador de pruebas: Diseña los casos de prueba necesarios y establece el orden en el cual tendrán lugar la ejecución de los casos de prueba. Competencias: o Conocimiento de desarrollo y pruebas o Conocimiento de ingeniería de software o Conocimiento respecto a especificaciones técnicas o Conocimiento de requisitos funcionales Ingeniero de automatización de pruebas: Evalúa las posibilidades de la automatización de pruebas y las implementa. Competencias:
o Experiencia como tester o Conocimiento técnico Know How en el ámbito de diseño y automatización de pruebas. o Conocimientos de programación o Amplios conocimiento en el uso de las herramientas utilizadas. Administrador del sistema de pruebas: Prepara y opera el entorno de pruebas. Competencias: o Administración de sistemas o Conocimiento de herramientas de desarrollo y pruebas o Sistemas de base de datos (si aplica) o Redes (si aplica) o Instalación y operación de software del sistema Tester: Ejecuta las pruebas de acuerdo con la especificación de casos de prueba. Competencias: o Conocimiento básico del software o Conocimiento básico de pruebas o Operación y uso de herramientas de pruebas o Experiencia en la ejecución de pruebas o Conocimiento respecto de los objetos de prueba Tareas: o Asiste en la implementación del plan de pruebas o Ejecuta los casos de prueba y registra los resultados o Introduce los errores en un repositorio o Informa las pruebas o Asiste en la implementación de la automatización de pruebas Experto técnico: Asiste al equipo de pruebas cuando es necesario. Competencias: o Administración de bases de datos o diseño de bases de datos. o Experto en interfaces de usuario. o Experto en redes. Consejo de control del cambio (CCC): Decide respecto de los cambios de requisitos y sus prioridades. Desarrollador: Analiza los fallos, localiza la causa del error. Corrige la causa de error de acuerdo con la prioridad asignada. Ejecuta todos los cambios aprobados. Actividades de cada fase del proceso de pruebas: Planificación de pruebas: o La planificación de pruebas es planificación de proyectos. o Es parte de la planificación de la calidad en su conjunto. o Todas las tareas deben ser planificadas con antelación. o Planificación de recursos -> Para las distintas tareas se deben asignar recursos (personal, presupuesto, herramientas, entornos de prueba, etc.). Estimar el esfuerzo de los miembros del equipo, incluyendo sus necesidades en términos de tiempo,
herramientas, actividades de apoyo, etc. Estas estimaciones se convierten en parte del plan de pruebas (dinámico). o Realizar plan de prueba y concretarlo con el plan de proyecto. o Estrategia de pruebas -> Definir el nivel de calidad: Describe los niveles de pruebas a desarrollar y la intensidad de las pruebas en aquellos niveles. Establece los criterios de entrada y salida para cada nivel incluyendo las métricas para evaluar esos criterios. o Se debe ajustar de acuerdo a la información proveniente de las actividades de pruebas. o Prioridad de las pruebas: Los casos de prueba más importantes deben ser ejecutados de forma temprana, de esta forma partes críticas de los programas son probados incluso en el caso que las actividades de pruebas sean abortadas de forma prematura. o Soporte de herramientas: Decidir respecto de que herramientas deben ser utilizadas para probar, si las herramientas disponibles son suficientes o si hay necesidad de herramientas adicionales. Plan de pruebas estático: Cubre todas las fases del proceso de pruebas. Se fijan reglas de acuerdo a los objetivos de las pruebas, recursos, actividades e hitos. Este posteriormente es ampliado con el objeto de cubrir los resultados a partir de la fase de planificación de detalle. El plan de pruebas cuenta con una extensión dinámica que será ajustada durante el ciclo de vida del proyecto si fuera necesario. Plan de pruebas de acuerdo al estándar IEEE 829: 1. Introducción 2. Supuestos 3. Ítems de prueba 4. Características sujetas a pruebas 5. Características no sujetas a pruebas 6. Enfoque 7. Criterios de éxito/fracaso para un ítem 8. Criterios de suspensión/reanudación 9. Entregables de pruebas 10. Tareas de pruebas 11. Necesidades relativas al entorno 12. Responsabilidades 13. Dotación de personal y formación 14. Calendario 15. Riesgos y contingencias 16. Aprobación Criterios de salida de pruebas: Los criterios de salida que indican la finalización de una fase de pruebas, deben ser establecidos para cada nivel de pruebas. Son necesarias métricas para controlar estos criterios de salida. Ej: Cobertura de código, Cobertura de riesgo.
Especificación: Todas las pruebas documentadas en el plan de pruebas son especificadas, es decir, se establece como se estructura y como debe ser ejecutado. Este proceso es iniciado por el jefe de pruebas.
Ejecución y control: Ejecución -> Comparación de los resultados esperados y obtenidos en el proyecto. Control -> Todas las desviaciones deben ser informadas y tenidas en cuenta.
Evaluación: La gestión de pruebas proporciona transparencia a la evolución del proceso de pruebas y aporta indicadores a la dirección del proyecto. Los informes generados durante la ejecución de pruebas, el seguimiento de defectos e informes al cliente son una importante fuente de información para el jefe del proyecto y la dirección de la compañía.
Estimación de pruebas: Factores: o Características del producto o Calidad de la base de pruebas o Requisitos de fiabilidad y seguridad del producto o Complejidad del proceso de desarrollo o Estabilidad de la organización, madurez del proceso utilizado o Personal involucrado, restricciones temporales. Métodos: o o o
Estimación basada en tareas Estimación basada en analogías Estimación basada en porcentajes
Seguimiento y control de pruebas: Seguimiento: Control de las actividades de pruebas con el objeto de detectar desviaciones respecto al plan. El seguimiento debe ser realizado en base a consideraciones medibles y esto debe ser informado de forma regular. o Métricas en base a errores: Utilizando información del sistema de gestión de incidentes. o Métricas en base a casos de prueba: Utilizando información del sistema de gestión de pruebas. o Métricas en base a objetos de pruebas: … gestión de la configuración o Métricas en base a costes: Utilizando información del sistema de control de proyectos. Control: Corrección del rumbo de las actividades de pruebas cuando sea necesario. Es una tarea de gestión. Se deben tomar medidas correctivas como respuesta a desviaciones respecto del plan. Evaluación del cierre de pruebas. Medidas: o
Provisión de mayores recursos.
o
Reducción del esfuerzo aplicado al trabajo
Informe de estado de pruebas según IEEE 829: o o o o o o o o o
Objeto u objetos de prueba. Niveles de prueba, ciclos de prueba, período del informe. Estado de pruebas (métricas) Recursos utilizados/presupuesto consumido Hitos alcanzados Informe de defectos Evaluación del riesgo Pronóstico Evaluación general
Gestión de la configuración: Presenta un rol de apoyo dentro de un proyecto - todos los cambios deben ser registrados en un recurso común y comunicado haciendo uso de procesos definidos. Se debe realizar un plan de gestión de la configuración específico dependiendo del alcance de cada proyecto. No es una actividad particular del proceso de pruebas, sino que es necesaria durante todas las fases de un proyecto. Sin el uso de herramientas solo es posible en proyectos muy pequeños. Es necesaria para administrar los cambios sobre los objetos de prueba y sus respectivas versiones. La gestión de la configuración se refiere a un conjunto de medidas que complementan al desarrollo software: o o
o
o
Gestión del cambio: Sigue todas las actividades. Gestión de la construcción: Describe todos los pasos para crear una versión de un productos software con el objeto de ser suministrado como un todo o subsistemas individuales. Gestión de entregas (Release): Permite la definición de versiones aisladas para cada artefacto componente de una versión completa de producto a ser probado, entregado, etc. Determinar y administrar toda la información en las versiones correspondientes que conforman un subsistema. Gestión de versiones: Registra toda la información de acceso para cada artefacto.
NOTA: La información de la construcción y entrega es conservada con el objeto de poder reconstruir versiones antiguas.
Auditoría de la Configuración:
Tiene como objeto comprobar la efectividad de las actividades de la gestión de la configuración. Riesgo: Es la probabilidad de un resultado negativo (matemático) o la probabilidad de la ocurrencia de un suceso negativo multiplicada por el monto del daño económico. El riesgo asociado al proyecto y al producto deben ser tenidos en cuenta durante la planificación y el diseño de casos de prueba, cuando se prioricen casos de prueba, cuando se seleccionen métodos y durante la ejecución de pruebas. Los riesgos asociados al proyecto afectan al éxito del proyecto y deben ser gestionados. Medidas: -
Evitar el riesgo Mitigar el riesgo (preparación activa de medidas para reducir la probabilidad y/o daño potencial) - Control del riesgo (Preparar las medidas necesarias en el caso en el cual el riesgo se convierte en un problema, contar con tiempos y fondos suficientes) - Ignorancia del riesgo (rezar…) Riesgos asociados al proyecto (más frecuentes): - Riesgos asociados a la organización: Problemas personales entre equipos, falta de cooperación, conflictos de intereses entre departamentos, capacitación y disponibilidad de personal. - Riesgos tecnológicos: Requisitos defectuosos, incompletos, no realistas. Herramientas, tecnologías, métodos nuevos que presentan incertidumbre para el desarrollo software. Déficit en la calidad de productos, Disponibilidad de un entorno de pruebas complejo. - Riesgos ambientales: Deficiencias por parte de externos en la provisión de componentes, problemas contractuales con proveedores, acceso concurrente a recursos externos, cambios en requisitos legales. Riesgos asociados al producto: - Funcionalidad insuficiente del producto suministrado. - Atributos no funcionales insuficientes. - El producto no es idóneo para su uso previsto. - El producto provoca daños a la propiedad. - El producto provoca lesión o muerte accidentales. NOTA: Las pruebas se ejecutan para reducir o evitar a los riesgos asociados al producto. Gestión de riesgos asociados al producto utilizando pruebas basadas en riesgo: 1. Identificar, analizar y priorizar riesgos. 2. Influencia del riesgo tenido en cuenta durante la planificación de pruebas. (Seleccionar los métodos de pruebas para mitigar riesgos. Asignar alcance de las pruebas de acuerdo al nivel de riesgo. Priorizar los casos de prueba) 3. Actualiza la lista de evaluación de riesgos de forma regular. (Los riesgos pueden desaparecer, o aparecer nuevos o pueden cambiar) Beneficios de las pruebas basadas en riesgo:
Los métodos de pruebas son seleccionados de forma particular con el objeto de mitigar los riesgos identificados. El alcance de las pruebas se ocupa de los riesgos identificados. El alcance del proceso de pruebas tiene en cuenta los riesgos identificados, de esta manera se centra el esfuerzo de pruebas en abordar la reducción del riesgo potencial. Los fallos peligrosos son detectados de forma temprana (Más económica la corrección) Se ejecutan los casos de prueba más importantes (prioridad) aún en el caso de que se haga un aborto de pruebas. Informe de incidencias (Informe de errores) según IEEE 829: El informe de incidencias describe el efecto de un error, no su causa. 1. Datos del error: #Id Error, denominación del objeto de prueba-versión, Entorno de pruebas, Nombre del autor del informe de incidencias, fecha de la primera ocurrencia. 2. Clasificación de errores: Clase de error, estado (nuevo, reopen), Prioridad (urgencia). 3. Descripción: Caso de prueba, resultado erróneo (descripción resultado obtenido y resultado esperado), descripción de la desviación, severidad, referencias a informes relacionados, comentarios, acciones correctivas tomadas. Clase de error: La severidad. Pueden ser: Error crítico, error mayor, error medio, error menor. Prioridad del error: Tiene en cuenta el efecto del error: Impacto sobre la funcionalidad del programa, impacto sobre el proyecto, sobre el cliente, Posibilidad de aportar una solución (corrección) inmediata al problema o en la siguiente entrega. -> Rige la urgencia de la corrección. Estado de un error: Aporta información relativa al progreso/evolución del trabajo que ha sido desarrollado para este error. Solo un tester puede poner un error en estado finalizado. El jefe de pruebas decide si un error debe ser corregido o rechazado. El consejo de control del cambio puede decidir sobre la corrección de un error teniendo en cuenta el coste de reparación. Todos los cambios (incluidos los comentarios) deben ser registrados en el sistema de gestión de incidencias. NOTA: La gestión de incidencias es la gestión de desviaciones. La gestión de incidencias es un proceso por sí mismo con un flujo de trabajo (workflow) particular. Las expresiones gestión de las desviaciones o gestión de los errores son utilizados con frecuencia como sinónimos de la gestión de incidencias. Capitulo 6: Las herramientas de prueba pueden ser utilizadas para dar soporte a las actividades de pruebas. La denominación de las herramientas de pruebas se realiza según el tipo de soporte que prestan. Hay herramientas disponibles para cada nivel del proceso de pruebas. Clasificación de las herramientas de pruebas: Herramientas unitarias (single tools): Dan soporte a una tarea particular, son diseñadas para una actividad de pruebas.
Paquetes de pruebas herramientas (test tool suites): Cubren varias tareas e integran varias herramientas unitarias.
Herramientas de pruebas Intrusivas: Puede interferir en la ejecución del objeto de prueba y puede provocar que difiera respecto del objeto en el entorno real.
-
El depurador introduce puntos de corte y altera el tratamiento de interrupciones. Los “Drivers” de pruebas aportan al objeto de pruebas datos de entrada artificiales. La cobertura se determina a través de contadores introducidos en el código.
Herramientas que no alteran el objeto de prueba.
Herramientas de pruebas para implementaciones especificas: Dependen del tipo de aplicación. Ejemplos: - Aplicaciones web - Una plataforma de desarrollo especifica como Java - Pruebas de seguridad
Herramientas de pruebas propietario (Fabricación propia): - Ejemplo: Hojas de cálculo de Excel, guiones SQL, bases de datos para el tratamiento de datos de pruebas, herramientas específicas de comparación de resultados de pruebas.
Herramientas de gestión de pruebas: -
Herramientas de gestión de requisitos: -
Recopilación, categorización/clasificación y administración de casos de prueba. Evaluación/Establecimiento de métricas que describan los casos de prueba. Planificación de recursos, tiempo y presupuesto. Documentación del plan de pruebas Creación de informes de desarrollo (progreso) de pruebas, evaluación de pruebas, documentación de pruebas. Gestión de entregas y gestión de la configuración.
Acopio de los requisitos del sistema. Asignación de prioridades a los requisitos. Establecer la referencia entre los requisitos y los casos de prueba. Comprobación de la consistencia: Evaluaciones por ejemplo el grado de cobertura.
Herramientas de gestión de incidencias/Herramientas de gestión de defectos: Registro y seguimiento de defectos. Asignación de prioridades, categorización y agrupación de defectos. -
Evaluaciones: Métricas que presenten el grado de desarrollo/Progreso de las pruebas. Flujo de trabajo para el ciclo de vida de un defecto: Cambios de estado, responsabilidad (asignación).
Herramientas de gestión de la configuración: Seguimiento de las diferentes versiones de componentes: Requisitos cumplidos por una versión particular, entorno operativo, compilador en uso, etc. -
Administración del código fuente y el código objeto. Referencias a la gestión de pruebas/gestión de requisitos/gestión del cambio.
Herramientas para pruebas estáticas: Para poder realizar análisis estático las especificaciones deben estar en un lenguaje formal. Estas herramientas son muy utilizadas por los desarrolladores.
-
Herramientas para pruebas estáticas - > revisiones: Apoyo al proceso de revisión (flujo de trabajo), documentación de los resultados de revisión, Evaluación de los resultados de revisión, provisión de check list para revisiones y apoyar la ejecución de revisiones en línea (on line review).
-
Herramientas para pruebas estáticas -> Análisis Estático: Conformidad con estilos de codificación/convenciones. Análisis de la estructura del código: Análisis del flujo de control, código inalcanzable (muerto), métricas de complejidad de código. Ej: Número ciclomático. Análisis de pruebas basadas en modelos de datos / comprobación de consistencia. Análisis de documentos de especificación / modelos de diseño de objetos/diagramas de estado.
Herramientas para la especificación de pruebas: Los generadores de datos de prueba crean datos para ser utilizados en pruebas. Las herramientas producen datos a partir de descripciones formales o a partir de la definición de una estructura. Las herramientas no reemplazan el esfuerzo humano dada su carencias de creatividad e intuición y conocimiento del objeto de prueba. Las herramientas se clasifican dependiendo de la fuente de los datos: -
Generadores de datos de prueba asociados a bases de datos: Generan datos a partir de bases de datos o a partir de ficheros planos. Obtienen datos a partir del reconocimiento de estructuras y contenidos.
-
Generadores de datos de prueba basados en el código: Generan datos a partir del código fuente, por esta razón no pueden identificar una funcionalidad ausente, ni aportar los valores de resultados esperados, es decir solo pueden generar datos de prueba en base al código aportado.
-
Generadores de datos de prueba asociados a la interfaz: Generan datos de acuerdo a los parámetros de la interfaz. Obtienen clases de equivalencia y valores límite directamente para los rangos de los parámetros definidos. No pueden aportar valores de resultados esperados pero pueden ser utilizados para pruebas de robustez.
-
Generadores de datos de prueba basados en la especificación: Generan datos directamente de documentos de especificación, estos requieren el uso de una notación formal estricta.
Herramientas para la ejecución de pruebas: Incluyen: -
Entrega de datos.
-
Recepción de datos o escritura en el registro del comportamiento de la salida. Documentar la ejecución de las pruebas. Ejemplos: Depurador: Herramienta para la detección de errores en el código fuente. La secuencia de la ejecución de un programa puede ser interrumpida. Pueden ser comprobadas sentencias unitarias y condiciones. Las variables pueden ser definidas de forma individual y referenciadas. Drivers de prueba: Permiten acceder al objeto de pruebas cuando las interfaces aún no han sido implementadas. Regulan la entrada y salida de datos y registran el “log” el desarrollo de la prueba. Registran los resultados reales (obtenidos). Pueden ser productos estándar o programas desarrollados para un objeto de prueba específico. Normalmente aportan su entorno de sistemas propio. Stubs: Simulan la funcionalidad de un componente invocado. Simuladores: Son una réplica del entorno de producción (o parte del mismo) y son necesarios cuando consideraciones de seguridad impiden el uso del entorno de producción objetivo (real). Principalmente son utilizados en el nivel de pruebas de sistema y pruebas de integración y posiblemente en pruebas de componente. La emulación del entorno de producción debe ser tan próxima el mismo como sea posible. Robots de prueba: Pueden tratar la interfaz externa del objeto de prueba de forma directa. Pueden aceptar y/o suministrar datos, el desarrollo de la prueba se realiza de forma automática. Con frecuencia aportan una función que compara el resultado real (obtenido) con el resultado esperado. Las herramientas de captura-repetición son utilizadas con frecuencia, como robots de pruebas. Estas herramientas registran los pasos de la ejecución de la prueba a través de la interfaz de usuario y las guarda en un fichero en un formato de guión (script file). Permiten la repetición automática de la secuencia de prueba haciendo uso de guión (script) registrado/guardado.
Herramientas para el análisis de pruebas y análisis del objeto de prueba: Apoyan o automatizan tareas de análisis de pruebas. Su denominación es acorde con su uso. -
-
Herramientas de comparación: Comparan los resultados esperados y reales (obtenidos) en base a ficheros o bases de datos de diferentes formatos. Los datos relevantes a comparar con seleccionados haciendo uso de funcionalidades filtro. Herramientas de análisis de cobertura: Se implementan contadores que registran cada acceso. Tras completar las pruebas, los contadores serán utilizados para evaluar la cobertura.
Herramientas de análisis dinámico: Pueden soportar las pruebas dinámicas. Controlan y registran el estado interno del objeto de prueba, por ejemplo: Uso de memoria.
Herramientas para pruebas no funcionales: -
Herramientas para pruebas de carga: Seguimiento del comportamiento en tiempo real del objeto de prueba en distintas situaciones. Las herramientas generan, ejecutan una repetición de casos de prueba dirigidos por parámetros. El despliegue en entornos complejos requiere un conocimiento experto con el objeto de asegurar que los resultados son similares a las condiciones reales por ejemplo: Interacción de red.
-
Supervisores de pruebas: Analizan, verifican y documentan de forma continua el uso de recursos del sistema. Observan el comportamiento del objeto de prueba en el entorno del sistema y detecta situaciones que pudieran ser susceptibles de problemas.
-
Ventajas de las herramientas de pruebas en general: Reducción de la necesidad de la totalidad de recursos humanos (Apoyan y aceleran las tareas manuales). Incremento de la calidad de la ejecución de pruebas: Las evaluaciones automáticas aportan medidas objetivas. Mayor potencial para el control de pruebas: la gestión de datos con herramientas de pruebas hace posible una mayor variedad de evaluaciones. Riesgos de las herramientas de prueba en general:
Desviaciones en la calidad de la herramienta desplegada: La funcionalidad y usabilidad de la herramienta no cumple con las expectativas. Estimación errónea de los beneficios y costes. Los guiones de prueba deben ser redactados/alterados/modificados.
Beneficios y riesgos de las herramientas de pruebas de rendimiento:
Generalmente son utilizadas en aplicaciones (sistemas) distribuidos y cuya comunicación se realiza a través de redes. En la mayoría de los casos el entorno de pruebas no puede estar completamente aislado y es objeto de la influencia de factores que no son conocidos en detalle a la hora de preparar y ejecutar las pruebas. La complejidad del entorno de puede hacer que sea imposible repetir pruebas idénticas. En muchos casos es necesario un conocimiento experto en detalle con el objeto de analizar las salidas de la herramienta de forma correcta y extraer las conclusiones correctas.
Beneficios y riesgos de las herramientas de pruebas de análisis estático:
Examinan el código fuente con el objeto de comprobar la conformidad con convenciones. Con frecuencia es necesario preparar el código para el análisis estático. Un problema detectado con frecuencia: Una cantidad relativamente grande de indicaciones, es difícil identificar su relevancia.
Beneficios y riesgos de las herramientas de gestión de pruebas:
La información debe ser mantenida abiertamente accesible. Una hoja de cálculo es la herramienta más utilizada por los jefes de pruebas para evaluaciones de informes. Los informes y las evaluaciones de deben adaptar a la organización y no al revés!
La introducción de una nueva herramienta en organizaciones es un proceso exigente que necesita ser controlado/gestionado. Pasos hacia la introducción de una herramienta: 1. Análisis de la necesidad: ¿Cuáles son los puntos fuertes y débiles del área de pruebas? ¿Qué puede ser mejorado con el despliegue de la herramienta? 2. Definición de requisitos: Las necesidades respecto de la herramienta deben ser definidos de forma clara, deben ser establecidos criterios medibles. 3. Evaluación: Examinar la conformidad de la herramienta con la funcionalidad solicitada y los criterios de calidad adicionales. Solicitar el número de copias vendidas, servicio de posventa y la posibilidad de colaboración por parte del proveedor. 4. Lanzamiento: Apoyar la introducción de la herramienta a través de entrenamiento y formación para el uso de la herramienta. Lo ideal es establecer un proyecto piloto para introducir la herramienta.
