.png "English"){kind=small}
17:42
Mizael Tekax
4.1.1.- Pruebas, Caso de Prueba de Defecto, Falla , Error, Verificación y Validación.
Pruebas (test):
Es una actividad en la cual un sistema o uno de sus componentes se ejecutan para verificar el funcionamiento de un proceso, los resultados se observan y registran para realizar una evolución de dicho proceso.
Pruebas (test):
Es una actividad en la cual un sistema o uno de sus componentes se ejecutan para verificar el funcionamiento de un proceso, los resultados se observan y registran para realizar una evolución de dicho proceso.
Referente a la programación una prueba de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación.
Caso de prueba (test case):
Un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular, un caso de prueba es utilizado por el analista para determinar si el requisito de una aplicación es parcial o completamente satisfactorio.
Defecto (defect, fault, bug):
Un defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora u otro dispositivo. Por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.
Error (error):
Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método, una acción humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de manifestación del defecto en el sistema que se ejecuta.
Falla (failure):
Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.
Verificación:
La verificación del software es el proceso a través del cual se analiza y revisa que el software satisfaga los objetivos propuestos al inicio del desarrollo.
Validación:
El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.
4.1.2 Relación entre defecto-falla y error.
Un error puede conducir a uno o más defectos. Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. Un defecto es haber utilizado el operador “<” en vez de “<=“. En este caso una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, respecto a la ejecución del programa correcto. Es decir, una falla es el síntoma de un defecto. Por ejemplo: una consulta que no arroje ningún resultado.
4.1.3 Pruebas estructurales, funcionales y aleatorias.
El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito de una prueba)
Existen tres enfoques principales para el diseño de casos o pruebas
A. El enfoque estructural o de caja blanca.
Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Las pruebas de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran:
· La cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución).
· Pruebas sobre las expresiones lógico-aritméticas.
· Pruebas de camino de datos (definición-uso de variables).
· Comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno).
B. El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas.
Se centra en las funciones, entradas y salidas. Intenta encontrar errores de las siguientes categorías:
· Funciones Incorrecta o ausente.
· Errores de Interfaz.
· Errores en estructuras de datos o acceso a base de datos externas.
· Errores de rendimiento.
· Errores de inicialización y de terminación.
C. PRUEBAS ALEATORIAS
En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podrían aparecer en la Práctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automáticos de casos de prueba.
Consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba
CRITERIOS DE COBERTURA LÓGICA
Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute al menos una vez.
Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias)
Cobertura de condiciones. Se trata de diseñar tantos casos como sea necesario para que cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones)
Criterio de decisión/condición. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla también el criterio de decisiones.
Criterio de condición múltiple. En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultánea, se puede considerar que cada decisión multicondicional se descompone en varias condiciones unicondicionales. Ejemplo en la siguiente diapositiva.
Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable).
4.1.4 Documentación del diseño de las pruebas
Se compone de los siguientes pasos:
Plan De Pruebas
Señala el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos asociados.
Especificación Del Diseño De Pruebas
Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas.
Especificación De Caso De Prueba
Define uno de los casos de prueba identificando por una especificación del diseño de las pruebas.
Especificación De Procedimiento De Prueba
Especificar los pasos para la ejecución de un conjunto de casos de prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo.
Estructura de los pasos fijada en el estándar
Plan de Pruebas
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
Especificación del diseño de pruebas
· Identificador único para la especificación. Proporcionar también una referencia del plan asociado (si existe)
· Características a probar de los elementos software (y combinaciones de características)
· Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados
Especificación de caso de prueba
Elementos software (por ejemplo, módulos) que se van a probar: definir dichos elementos y las características que ejercitará este caso
· Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas)
· Especificaciones de todas las salidas y las características requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar
· Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)
Especificación De Procedimiento De Prueba
Identificador único de la especificación y referencia a la correspondiente especificación de diseño de prueba
· Objetivo del procedimiento y lista de casos que se ejecutan con él
· Requisitos especiales para la ejecución (por ejemplo, entorno especial o personal especial)
· Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar:
· La secuencia necesaria de acciones para preparar la ejecución
· Acciones necesarias para empezar la ejecución
· Acciones necesarias durante la ejecución
· Cómo se realizarán las medidas ( por ejemplo, el tiempo de respuesta)
· Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen)
· Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos puntos
· Acciones necesarias para detener ordenadamente la ejecución
· Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de las pruebas
· Acciones necesarias para tratar los acontecimientos anómalos.
