Clases de equivalencia PRUEBAS
Pruebas a través de revisiones
La mayoría de las organizaciones cualquiera sea el modelo de ciclo de vida que se adopte, enmarcan las fases básicas de análisis, diseño, implementación y mantenimiento como fases de desarrollo
ANÁLISIS
Determina la viabilidad y especificación de los requerimientos.
DISEÑO
Especifica el diseño general y detallado.
IMPLEMENTACIÓN
Implica: codificación, pruebas, depuración e instalación.
MANTENIMIENTO
Mejora y modificación.
Es frecuente encontrar en muchas organizaciones, que cada una de estas actividades (de codificación, pruebas, depuración e instalación) dentro de la fase Implementación, son tenidas como fases separadas
En una visión temprana, la prueba de sistemas era vista como una fase de desarrollo, después de programar. Los sistemas eran diseñados, construidos, y después probados y depurados.
Visión temprana
diseño-construcción-prueba
Visión actual
análisis-diseño-implementación-mantenimiento
————–prueba———————
La prueba debe ser desarrollada de manera paralela al proceso de desarrollo y como una actividad que tiene sus propias fases de análisis, diseño, implementación, ejecución y mantenimiento.
ANÁLISIS
Planificar y determinar los objetivos y los requerimientos de pruebas.
DISEÑO
Especifica los casos de pruebas a ser ejecutados.
IMPLEMENTACIÓN
Construye los procedimientos de ejecución.
EJECUCIÓN
Ejecuta y re-ejecuta los casos de pruebas.
MANTENIMIENTO
Graba y actualiza los casos de pruebas en función de los cambios de software.
Las revisiones como una técnica de pruebas
Un gerente de proyecto de software no puede esperar a que el sistema esté construido para evaluar su calidad, pues puede llegarse a las etapas finales del proyecto y concluirse que tiene que ser re-hecho, pues no está en acuerdo con lo que fue solicitado.
El papel del proceso de pruebas en el proceso de desarrollo es fundamental para: mejorar de la calidad y reducir el riesgo de detectar errores.
Surgen las pruebas estáticas que son la evaluación sin la ejecución del programa.
Dentro de las llamadas prueba estáticas están contempladas las revisiones.
¿Qué puede revisarse?
Procedimentales:
tienen que ver con revisar cómo se está llevando a cabo la tarea respecto de lo que está establecido en el proceso, procedimiento o instructivo.
Documentales:
revisa la documentación y registros que se generan a través del proceso, revisando que documentalmente esté de acuerdo a lo establecido, que se haya empleado el documento
De producto:
son las revisiones de los productos generados a través del proceso de desarrollo. Ejemplo: revisiones de requerimientos, especificaciones, diseño, código
2.1.2. Plan de revisiones
Definidas a las revisiones como técnica de pruebas, sean formales o informales, las mismas requieren que se planifique cuidadosamente: qué se revisará, cuáles son los resultados esperados, y quiénes las llevarán a cabo.
Las revisiones pueden estar en cualquier punto del proceso de desarrollo
Mínimamente, un plan de revisiones tiene que especificar:
– Quién / quiénes asisten.
– Información que es necesaria antes de la revisión. Pruebas de Sistemas
– Precondiciones que se deben alcanzar antes de llevar a cabo la revisión.
– Listas de chequeos (también llamadas listas de verificación o checklists1) u otras herramientas de indicaciones de qué será cubierto.
– Criterios o condiciones finales que deben alcanzarse al concluir con la revisión.
– Registros y documentación que debe ser guardada.
– Responsabilidades asignadas para cada instancia.
También deben asignarse las responsabilidades de preparar y entrenar a los participantes de la revisión
En las revisiones formales son cada vez más utilizadas las listas de verificación por los beneficios que traen consigo, a saber:
-Estructura la revisión
– Medio para la registración de los resultados.
– Una guía para la actividad de revisión.
– Medio para aprender de instancias pasadas.
– Asegura cobertura sistemática y completa.
– Herramienta para cuantificar y medir resultados
Utilizar listas de verificación que son renovadas permanente y periódicamente genera mejoras, y asegura que las organizaciones aprenden de sus errores pasados
Tipos de revisiones
Ya se menciónó según el objeto revisado existen tres tipos de revisiones: documentales, procedimentales y de producto.
Y según el modo en que se lleven adelante, las mismas podrán ser formales o informales
Se llaman revisiones formales cuando los profesionales sienten la necesidad de llevar las evaluaciones de manera precisa y generan reportes escritos de sus hallazgos a la gerencia o a la dirección.
Las revisiones informales son muy diferentes ya que implica que los profesionales que participan compartan sus opiniones, en general no hay registros de hallazgos
El ISTQB (2011)
presenta otros tipos de revisiones además de las revisiones formales o revisión técnica y de las revisiones informales ya presentadas.
Hetzel no las mencione, sino que las relaciona directamente con el objeto revisado.
A las inspecciones las encuadra dentro del nombre revisiones lógicas de código.
Las inspecciones tienen las siguientes carácterísticas:
Usan listas de verificación (checklists) y métricas como por ejemplo, problemas por página. – Debe contar con un rol de moderador capacitado e independiente que dirija la revisión. Y cuando se dice capacitado implica con formación específica. – Previamente a la revisión, se valora la viabilidad del objeto a someter a la revisión. – Criterios de entrada y salida especificados (previamente) para la aceptación del producto software. – Se puede decir que aplica un proceso formal incluyendo las actividades de preparación, ejecución, documentación y seguimiento. Ha preparación previa a la reuníón. – Muchas veces se la desarrolla como una evaluación entre pares. – Se construye un informe de inspección incluyendo la lista de hallazgos.
Las otras son los ensayos o las revisiones guiadas:
– Opcionalmente puede haber una preparación de los revisores previa a la reuníón. – Son sesiones abiertas y la reuníón está dirigida por el autor y éste oficia de moderador. – Mientras se va realizando la presentación por el autor, los revisores tratan de detectar desviaciones y/o áreas que representen un problema.
1.4. Efectividad de las revisiones
¿Cuán efectiva es la revisión? La efectividad de cualquier técnica de pruebas depende de la ecuación entre la confianza obtenida o los defectos descubiertos o prevenidos versus el costo invertido en la prueba.
Las revisiones detectan defectos en
– Las especificaciones. – El diseño y la arquitectura del software. – En las especificaciones de interfaces.
Entre los beneficios de las revisiones efectivas están:
– Alto potencial de ahorro a costes más bajos. – Los defectos en la documentación son detectados y corregidos de forma temprana, y esto lleva a que documentos de alta calidad mejoran el proceso de desarrollo. – Mejora el índice de comunicación e intercambio de conocimiento
Hetzel (1988) da una lista de factores críticos de éxito de las revisiones:
Resultados esperados:
es importante conocer el propósito de la revisión. ¿Qué es lo que se va a probar o medir?
– Responsabilidades:
Clara asignación de responsabilidades de todos los participantes.
– Derechos individuales:
Dar seguridad a los participantes que sus opiniones y sugerencias individuales estarán protegidas, ya que no es un comité.
– Asistentes:
Se debe involucrar a la gente correcta.
– Proceso estructurado
Establecer procedimientos. –
Moderador:
debe ser experto y entrenado en esa función.
– Registros:
Reportes escritos y evaluación
Los primeros tres factores son generalmente los primeros en no cumplirse, o violarse
2.2.Prueba de requisitos
Históricamente los documentos de requisitos son los productos de trabajo menos probado. Pero con el tiempo y haciendo un análisis de los defectos que se detectan en los sistemas, esto ha ido cambiando.
Se sabe que:
-Los defectos detectados en etapas finales del ciclo de vida de desarrollo, tienen un alto costo de reparación. – Un defecto no detectado en fases tempranas tiene un efecto multiplicador, ya que se propaga y se va multiplicando a lo largo del ciclo de vida. -Si se analiza la causa raíz de los defectos detectados en etapas finales, se tendría la sorpresa que un alto porcentaje de ellos tienen su origen en la etapa de requerimientos
Probar requerimientos a través del diseño de casos de pruebas basado en requerimientos
Se llaman casos de pruebas basados en requerimientos a aquellos que se diseñan solamente a partir de las especificaciones externas o de los requerimientos del sistema y en el momento en que los requerimientos son definidos
Se puede presentar las siguientes situaciones:
1.Que el requerimiento no esté completo:
en ese caso, se emplea un caso de prueba que focalice la información que está faltando. Por ejemplo, si no está especificada una entrada o una funcionalidad.
2.Que requerimiento no sea preciso:
de manera parecida se debe construir un caso de prueba y preguntar si ese es el resultado esperado para esa situación
Matriz de validación de requerimientos
Esta matriz lista cada requerimiento y hace referencia para cada uno de ellos los casos de pruebas o situaciones que se han creado para probarlos.
Esta matriz se usa en varias instancias consecutivas: una, al crearla para la asociación entre requerimiento y caso de prueba, dos, al momento de la ejecución, por lo que registra el estado (corrido, paso/fallo), y así consecutivamente ejecución por ejecución
¿Qué columnas tendría esa matriz?
debe ir una denominada status, con el uso que cada organización quiera darle. Puede ser: estado de especificación del requerimiento, estado de los casos de pruebas asociados al requerimiento, estado del requerimiento en función de los resultados de los casos de pruebas, número de defectos detectados para ese requerimiento, número identificador de defecto/los defectos levantados para ese requerimiento, entre otros usos.
El utilizar una Matriz de validación de requerimientos trae muchos beneficios:
-Asegura que los requerimientos son listados, e identifica los casos de pruebas asociados a cada requerimiento. – Facilita las actividades de revisión, tanto de requerimientos como de pruebas. – Facilita el seguimiento de las actividades de diseño de casos, de ejecución de casos, y la medición del progreso de cada una de estas actividades. – Permite medir la cobertura de las pruebas (¿cuánto he abarcado con las pruebas?), medida en cobertura función.
El beneficio fundamental de utilizar esta matriz, es que la actividad de diseño de casos de pruebas no se pasa por alto y está forzada a que los casos de pruebas son diseñados para cada requerimiento
Prueba de requerimientos a través de prototipos o modelos
Esta estrategia de pruebas consiste en construir un modelo o prototipo del sistema, no para ser usado, sino para probarlo y confirmar que se entiende el requerimiento
Son útiles especialmente cuando se tiene poco entendimiento del requerimiento y se necesita alcanzar experiencia con el modelo de trabajo.
El desarrollo incremental consiste en el proceso de establecer los requerimientos y diseñarlos, construir y testear un sistema construido de a partes. En lugar de intentar resolver el sistema total todo de una vez, se selecciona una parte, se diseña, construye e implementa una parte.
.Pruebas del diseño o modelos
Nuestro objetivo como probadores es encontrar el diseño que mejor se ajuste a los requerimientos planteados.
Nuevamente aquí la mejor técnica a aplicar sobre los diseños es la revisión formal, por lo que las mismas deben ser planeadas y desarrolladas durante la fase de diseño
Diseño de pruebas a través de análisis de alternativas
El proceso de diseño involucra alternativas, por lo que la primera prueba a realizar es para confirmar que el enfoque que ha adoptado el diseñador es la alternativa correcta.
Las alternativas de análisis deben ser revisadas de manera temprana en el proceso de diseño, casi ni bien son planteadas.
l procedimiento de revisión de diseño a través del análisis de alternativas propuesto por Hetzel (1988) es dividir la revisión en dos partes:
1. Los revisores escuchan las alternativas de diseño propuestas por los diseñadores y repasan las ventajas y desventajas de cada una.
Se suspende la revisión.
2. Cada revisor debe generar al menos una alternativa que no haya sido tenida en cuenta aún y así, en la segunda sesíón son evaluadas
Pruebas de diseño a través de modelos
De la misma manera que para los requerimientos, fallas o errores de diseño pueden ser descubiertos como así también validaciones de diseños pueden garantizarse enfatizando en el diseño de casos de pruebas basados en diseño. Se llaman casos de pruebas basados en diseño.
Estos casos de pruebas hacen foco en el camino de los datos y los procesos dentro de la estructura del sistema. A través de la construcción de casos de pruebas especializados y analizando cómo el diseño los maneja se prueban la estructura interna
Pruebas de diseño a través de casos de pruebas basados en el diseño
De la misma manera que para los requerimientos, fallas o errores de diseño pueden ser descubiertos como así también validaciones de diseños pueden garantizarse enfatizando en el diseño de casos de pruebas basados en diseño. Se llaman casos de pruebas basados en diseño. Estos casos de pruebas hacen foco en el camino de los datos y los procesos dentro de la estructura del sistema. A través de la construcción de casos de pruebas especializados y analizando cómo el diseño los maneja se prueban la estructura interna, los procesos o caminos complejos, distintos escenarios, riesgos de diseño y áreas débiles, entre otros aspectos
Pruebas de sistemas software
Sino que se refiere a probar un sistema o programa realizando pruebas que lleven a validar el funcionamiento del programa. El desafío como probador es medir la calidad del código como así también asegurar que el programa ha sido completado correctamente.
Estas pruebas pueden comenzar con el nivel de Pruebas de Componentes, ya que se puede comenzar probando pequeñas partes, unidades, funciones, rutinas, o subrutinas que operan individualmente.
A esto se lo denomina “in the small”
Se lo deja sin traducción para mejor comprensión.
Luego, se combinan estas partes con otras partes que también ya fueron probadas “in the small” y a estas pruebas se las llama “in the large
Los pasos para seleccionar los casos de pruebas basados en requerimientos son:
1. Comenzar con los casos que naturalmente surgen a partir de las especificaciones y de la identificación de las funciones del sistema. 2. Crear un set mínimo que ejecute todas las entradas y salidas, que cubra la lista de funciones del sistema. 3. Descomponer cada condición compuesta en condiciones simples. 4. Examinar las combinaciones posibles de las condiciones simples y agregar los casos de pruebas para cada una de esas combinaciones posibles. 5. Depurar el listado eliminando todos los casos de pruebas que ya sean corridos por otros sets. 6. Revisar sistemática y cuidadosamente.
Adicionalmente a los casos de pruebas basados en requerimientos, se deben generar casos de pruebas basados en diseño o en código. Éstos deben asegurar la prueba de cada segmento lógico de programa y que con ellos se cubra el diseño completo.
2.5.Pruebas de hardware
Con el ánimo de reducir el tiempo y el costo de desarrollar y mejorar la confiabilidad de los diseños, los ingenieros de hardware involucraron la calificación virtual y la verificación física en sus procesos de manufactura
Las calificaciones virtuales es la aplicación de técnicas de simulación para determinar la habilidad del sistema-hardware en alcanzar los objetivos deseados.
La verificación física es el proceso de definir y conducir pruebas físicas sobre el producto, o sobre un producto representativo para demostrar el comportamiento con fallos inducidos.
El proceso que se lleva adelante es:
1.Definir la información de entradas:
la información de entradas para hacer las calificaciones virtuales se establecen identificando fallas potenciales basadas en los materiales y las condiciones de carga. Este proceso implica revisar la lista de materiales, los gráficos de diseño y los documentos
2) Caracterización de carga:
implica definir de manera anticipada los escenarios en los que el objeto de calificación virtual va a ser usado. Por el uso de distintos materiales en la fabricación de hardware, existen factores como la temperatura y la vibración que pueden producir lo denominado estrés mecánico
3) Análisis de los resultados y definición de rangos de valores aceptados:
no todos los resultados pueden estar dentro de rangos no aceptados.
4) Evaluación del riesgo de falla:
conociendo los resultados del comportamiento con sus rangos de valores y según las condiciones de carga anticipadas, se deben establecer los mecanismos de fallas.
Unidad 3: Técnicas de diseño de casos de pruebas
Dentro del enfoque de pruebas estáticas están las revisiones que se desarrollaron en la unidad 2, todas aquellas que evalúan el sistema sin ejecutarlo usando mecanismos automatizados (herramientas asistidas) y manuales tales como controles de escritorio.
Estas técnicas quedan enmarcadas dentro del enfoque dinámico, es decir, que apuntan a ejecutar una parte del sistema o el sistema completo para determinar si funciona según lo esperado.
La manera de llevar adelante el ciclo de pruebas depende de diversos factores que hemos visto hasta el momento:
-Nivel de prueba:
esto marca el objetivo de la prueba, qué es lo que se espera alcanzar. Se recuerdan que los niveles son: nivel de componentes, nivel de sistemas, nivel de integración y nivel de aceptación
-Enfoque de la prueba, si es estático o dinámico.
– Objeto de prueba:
si es diseño, requerimientos, código o sistema lo que se está probando. Algunos objetos determinan un enfoque en particular y único, y otros objetos pueden aplicar los dos enfoques dependiendo lo que se desee evaluar. Por ejemplo, si el objeto bajo pruebas es el diseño al momento del diseño, previo a la codificación, toma el enfoque estático a través de una revisión
Estrategia de prueba:
que está ligada al objeto que se usa para derivar los casos de pruebas, pudiendo ser de caja blanca o de caja negra
3.1Basadas en especificaciones (Black BOX)
El diseño de casos de pruebas de caja negra o también denominado pruebas funcionales, pruebas basadas en las especificaciones, o pruebas de comportamiento son las pruebas que se derivan de los requerimientos, las especificaciones, o directamente de la interfaz de usuario.
La selección de los casos de pruebas de caja negra está basada en un análisis de las especificaciones de un componente sin referenciar a detalles internos de la estructura lógica.
Puntualizando las carácterísticas, se tiene que:
– Interesa qué hace el sistema y no el cómo lo hace. – Los casos de pruebas están basados en la especificación de los requerimientos, sea funcional o no funcional. – Se conducen a nivel de interfaz, probando el comportamiento de la siguiente manera: ante una entrada tal, una salida tal. –
Prueba todas las combinaciones de entrada y salida de datos – La cobertura alcanzada con las pruebas es medida en porcentaje o cantidad de funcionalidad abarcada.
Este tipo de pruebas apuntan a verificar la corrección y la completitud
Completitud:
¿están disponibles todas las funciones especificadas en el módulo? O Correctitud:
¿son correctos los resultados de las funciones ejecutadas?
Roger S. Pressman (2006) da una lista de tipos de errores
1. Errores del comportamiento. 2. Errores en la interfaz. 3. Errores en las estructuras de datos o acceso a la base de datos. 4. Errores en las funciones que desempeña el sistema, o funciones que están faltando
3.1.1 Partición de equivalencias
Es un método sistemático que identifica clases de pruebas representativas a partir de valores de entrada y valores de salida de un programa a las que denomina clases de equivalencias
Una clase de equivalencia es un rango de valores de una clase donde cada miembro de esa clase, de acuerdo a las especificaciones, es tratado del mismo modo por el componente o lo que es lo mismo
Las reglas que se aplican para esta agrupación en clases de equivalencia de los rangos de valores son:
1. Todos los valores para los cuales se espera que el programa tenga un comportamiento común es una clase de equivalencia. 2. Las clases de equivalencia no pueden superponerse. 3. Las clases de equivalencia no pueden presentar ningún salto.
Una vez identificadas las clases de equivalencia, las mismas pueden ser divididas de forma adicional en:
– Clase de equivalencia válida:
todos los valores dentro del rango de definición.
– Clase de equivalencia no válida:
se distinguen dos casos para valores fuera del rango de definición
Como paso siguiente, una vez que se tienen todas las clases de equivalencia identificadas y considerando las inválidas también, se elige un valor representativo por cada uno de los rangos
Cualquier valor que pertenezca a la clase puede ser un representante, aunque los óptimos son:
– Valores carácterísticos, es decir, utilizados con frecuencia.
– Valores problemáticos, es decir, que son sospechosos de producir fallos.
– Valores límites, que está en la frontera del rango.
Se arman así los casos de pruebas que combinan los representantes de cada clase de equivalencia, utilizando un único representante de cada clase, pero con las siguientes consideraciones:
– Los representantes de clases de equivalencia válidas se pueden combinar. – Los representantes de clases de equivalencia no válidas no se pueden combinar. – Los representantes de una clase de equivalencia no válida sólo se puede combinar con otros representantes de clases de equivalencia válidas. – Los representantes de clases de equivalencia inválidas deben combinarse siempre con los mismos valores de otras clases de equivalencia válidas.
El beneficio de esta técnica es que una mínima cantidad de casos de prueba se puede esperar un valor de cobertura específico.
3.1.2 Análisis de valores frontera
La técnica de análisis de valores fronteras viene a complementar la partición de equivalencia donde, además de seleccionar cualquier elemento como representativo de una clase de equivalencia, se seleccionan los bordes de cada clase o rango.
Ambas técnicas sugieren la selección de representantes
Y lo hace bajo el siguiente esquema:
– De cada rango de valores o clase de equivalencia válidas identificadas, toma los valores límites, es decir, el valor mínimo y el valor máximo. Por ejemplo, dado el rango de valores donde:
0,00 ≤ x ≤ 100,00
Respecto del valor mínimo, toma el anterior y el posterior. El anterior sería igual al valor mínimo menos un incremento. Por ejemplo, si es un valor entero, sería el valor límite -1. El posterior sería igual al valor mínimo más un incremento. Si es un valor entero, sería el valor límite +1.
Pero para el caso de 0,00 sería -0,01 (negativo) y 0,01 (positivo).
– Respecto del valor máximo, también toma el anterior y el posterior de la misma manera.
Para el caso de 100,00 sería 99,99 y 100,01.
Entonces se tiene: -0,01 / 0,00 / 0,01 / 99,99 / 100,00 / 100,01
El valor posterior del valor límite inferior o mínimo del rango, es un elemento que puede ser uno de los representativos de la clase de equivalencia. Lo mismo sucede con el anterior del valor límite superior o máximo del rango
Los casos de pruebas que se agregan a los de partición de equivalencias por esta técnica serían dos, solamente el -0,01 y el 100,01.
3.1.3 Diagrama de transición de estados
Cuando se tiene una especificación donde se puede modelar el comportamiento del sistema a través de estados que toma un objeto (y ese objeto es objeto de prueba), se usa esta técnica de diagramas de transición de estado
El proceso consiste en tomar el análisis de las especificaciones para modelar el comportamiento por transición de estados, si es que no llega así a pruebas. Para ello, se deben identificar los estados que pueden tomar los objetos, las transiciones entre los estados, los eventos que provocan los cambios de estado (es decir las transiciones) y las otras acciones que puedan resultar de esas transiciones.
A partir de este diagrama se construye un árbol de transición, donde el estado inicial es la raíz del árbol, y para cada estado que pueda ser alcanzado desde el estado inicial se crea un nodo que está conectado a la raíz por una rama y así sucesivamente con todos los estados. El proceso termina cuando cada rama llega a un estado final (hoja) o bien cuando el mismo estado ya es parte del árbol.
Construido esto, restan definir los casos de pruebas, donde por cada camino desde la raíz a una hoja representa un caso de prueba. El criterio de salida para esta técnica es que todo estado ha sido alcanzado
Los defectos potenciales a detectar a través de estas técnicas son:
– Números incorrectos de estados. – Transición incorrecta para una entrada dada. – Salida incorrecta para una entrada dada. – Conjuntos de estados que se hacen equivalentes inadvertidamente. – Conjuntos de estados que se dividen para crear duplicados no equivalentes. – Conjuntos de estados que se han transformado en inalcanzables.
3.1.4 Caso de uso
Los casos de uso son elementos del Lenguaje Unificado de Modelado (UML6). Describe el comportamiento del sistema, no la secuencia de eventos, y muestra la reacción del sistema desde el punto de vista del usuario.
Todo caso de uso tiene precondiciones que deben ser cumplidas con el objeto de ejecutar el caso de uso de forma satisfactoria. También, tiene poscondiciones que describen al sistema tras la ejecución del caso de uso
El ISTQB (2011) incorpora a ésta, como una técnica más. Esta técnica consiste en tomar como fuente los casos de uso para definir los casos de prueba, donde cada alternativa del caso de uso corresponde, por lo menos, a un caso de prueba separado.
Son necesarios datos adicionales (datos de entrada, resultados esperados) para construir/desarrollar un caso de prueba.
Experimentalmente, el proceso que se lleva adelante en esta técnica es el siguiente:
1. Identificar todos los escenarios presentes en el caso de uso y asignarle un nombre a cada uno
2. Identificar aquellos escenarios que resulten redundantes y eliminarlos
3. Para cada uno de esos escenarios, se identificarán y documentarán las condiciones de ejecución
4. Se toma a cada escenario que queda luego de eliminar los redundantes, y ése será por lo menos, un caso de prueba.
5. Confeccionar una plantilla para registros de los casos de prueba con su lista de chequeo
6. Verificar lista de chequeo para validar en cuáles otros escenarios diferentes a los directamente relacionados con el caso de uso
Los casos de prueba derivados por esta técnica son apropiados para las pruebas de aceptación y pruebas de sistema, dado que cada caso de uso describe un escenario de usuario a probar
3.1.5 Tablas de decisión & gráficos causa-y-efecto
Estas técnicas tienen en cuenta el efecto de dependencias y combinaciones. Si se toma el conjunto completo de las combinaciones (matemáticamente hablando) de todas las clases de equivalencia de entrada produce, normalmente, a un número muy alto de casos de prueba.
Metodológicamente se sigue el siguiente proceso:
1. Se toma la especificación, que normalmente es informal y se la traduce en un gráfico causa-y-efecto de un objeto de prueba a un lenguaje formal.
2. Para ello, se identifican los efectos que afectan al objeto de prueba y que se remontan a sus respectivas causas.
3.Se construye una tabla de decisión de la siguiente manera: 1- se selecciona un efecto, 2- se retrocede en el diagrama para identificar la causa, 3- cada combinación de causas es representada por una columna en la tabla de decisión
4. Se analiza cada columna de la tabla detectando las combinaciones de causas idénticas que conducen a efectos distintos, para fusionarlas y formar un único caso de prueba.
Esta técnica es ventajosa por otorgar una vista sistemática de las combinaciones de entradas que no podrían ser identificadas utilizando otros métodos
. Pero tiene la desventaja que el establecimiento de un gran número de causas lleva a resultados complejos.
3.2 Basadas en estructura y código (White BOX)
El diseño de casos de pruebas de caja blanca o también denominado pruebas estructurales, o pruebas cristal son las pruebas que se derivan del análisis estructural interno de un componente
– En caja negra interesa qué hace el sistema y en caja blanca el cómo lo hace.
– Los casos de pruebas derivados están basados en la estructura lógica del código.
-La cobertura alcanzada con las pruebas es medida en porcentaje o cantidad de código abarcado y no solo funcional
-Puede emplearse en niveles tempranos de pruebas, ni bien estén generados los primeros componentes de código
Se deben derivar casos de pruebas que garanticen que cada camino en el código se ha ejecutado al menos una vez, que cada decisión lógica se haya evaluado tanto para verdadero como para falso y que cada bucle se haya ejecutado en sus límites y dentro de los límites.
Para cualquiera de las técnicas de caja blanca que se van a explicar, el probador requiere para la planificación y el diseño test cases conocimiento de:
– El lenguaje de programación utilizado. – La Base de datos utilizada. – El Sistema Operativo utilizado. – Del mismo código a testear.
Complejidad ciclomática
Tom McCabe (1976).
La complejidad ciclomática es una métrica cuantitativa de software de la complejidad lógica de un programa. Define el número de caminos independientes en el conjunto básico.
Un camino independiente es cualquier camino a través del programa que introduce al menos un nuevo conjunto de instrucciones o una nueva condición.
Roger Pressman (2006) presenta tres maneras de calcular esta métrica y en función de cada una, existe una fórmula.
CC = número de decisiones simples + 1 Ó CC = número de áreas cerradas + 1
Los estudios en la industria de sistemas, han demostrado que cuanto más alto es el valor de la complejidad ciclomática, mayor es la probabilidad de errores
3.2.1 Cobertura de sentencia
Es lograr la cobertura de un porcentaje específico de todas las sentencias, es decir que un porcentaje establecido de sentencias ejecutables hayan sido practicadas por los casos de prueba derivados
Tanto con el diagrama como con el pseudocódigo se puede ver que el mismo contiene una sentencia IF que contiene a otra sentencia IF. La segunda sentencia IF contiene una instrucción tanto para el THEN como para el ELSE, en cambio la primera sentencia IF no contiene ELSE
Esta técnica indica que se debe pensar en los caminos que son necesarios para alcanzar que cada sentencia sea ejecutada al menos una vez.
Esta técnica detectará el código muerto, es decir, código constituido por sentencias que nunca se ejecutan, eso lleva a que no se logre en ese caso el 100% de cobertura.
3.2.2 Cobertura de decisión
En lugar de las sentencias, la cobertura de decisión amplía su cobertura y se centra en los caminos del segmento de programa. Todas los caminos deben ser cubiertos al menos una vez, es decir, en un IF, se debe forzar la salida por el THEN y por el ELSE aunque no haya sentencias para ejecutar dentro.
Aquí es donde entra en uso la CC vista al inicio de las técnicas de caja blanca
. Para calcularla, se afirmó que se contaban el número de decisiones o el número de áreas cerradas y se le sumaba 1.