La capacidad de prueba del software es el grado en que un artefacto de software (es decir, un sistema de software, módulo de software, requisitos o documento de diseño) respalda las pruebas en un contexto de prueba dado. Si la capacidad de prueba del artefacto de software es alta, entonces es más fácil encontrar fallas en el sistema (si las tiene) mediante pruebas.
Formalmente, algunos sistemas se pueden probar y otros no. Esta clasificación se puede lograr notando que, para ser comprobable, para una funcionalidad del sistema bajo prueba "S", que toma la entrada "I", debe existir un predicado funcional computable "V" tal quees verdadero cuando S, dada la entrada I, produce una salida válida, falso en caso contrario. Esta función "V" se conoce como función de verificación para el sistema con la entrada I.
Muchos sistemas de software no se pueden comprobar o no se pueden comprobar de inmediato. Por ejemplo, ReCAPTCHA de Google , sin tener metadatos sobre las imágenes, no es un sistema comprobable. Sin embargo, Recaptcha se puede probar de inmediato si para cada imagen mostrada hay una etiqueta almacenada en otro lugar. Dada esta metainformación, se puede probar el sistema.
Por lo tanto, la capacidad de prueba a menudo se considera una propiedad extrínseca que resulta de la interdependencia del software que se va a probar y los objetivos de la prueba, los métodos de prueba utilizados y los recursos de prueba (es decir, el contexto de la prueba). Aunque la capacidad de prueba no se puede medir directamente (como el tamaño del software), debe considerarse una propiedad intrínseca de un artefacto de software porque está altamente correlacionada con otras cualidades clave del software, como encapsulación, acoplamiento, cohesión y redundancia.
La correlación de la 'capacidad de prueba' con un buen diseño se puede observar al ver que el código que tiene una cohesión débil, un acoplamiento estrecho, redundancia y falta de encapsulación es difícil de probar. [1]
Un menor grado de capacidad de prueba da como resultado un mayor esfuerzo de prueba . En casos extremos, la falta de capacidad de prueba puede dificultar la prueba de las piezas de software o requisitos de software en absoluto .
Para vincular la capacidad de prueba con la dificultad de encontrar fallas potenciales en un sistema (si existen) probándolo, una medida relevante para evaluar la capacidad de prueba es cuántos casos de prueba se necesitan en cada caso para formar un conjunto de pruebas completo (es decir, un conjunto de pruebas tal que, después de aplicar todos los casos de prueba al sistema, las salidas recopiladas nos permitirán determinar sin ambigüedades si el sistema es correcto o no de acuerdo con alguna especificación). Si este tamaño es pequeño, la capacidad de prueba es alta. Sobre la base de esta medida, se ha propuesto una jerarquía de testabilidad . [2] [3]
Fondo
La probabilidad, una propiedad que se aplica a la hipótesis empírica, tiene dos componentes. El esfuerzo y la eficacia de las pruebas de software dependen de numerosos factores que incluyen:
- Propiedades de los requisitos de software
- Propiedades del software en sí (como tamaño, complejidad y capacidad de prueba)
- Propiedades de los métodos de prueba utilizados
- Propiedades de los procesos de desarrollo y prueba
- Calificación y motivación de las personas involucradas en el proceso de prueba
Testabilidad de los componentes del software
La capacidad de prueba de los componentes de software (módulos, clases) está determinada por factores como:
- Controlabilidad: El grado en el que es posible controlar el estado del componente bajo prueba (CUT) según se requiera para la prueba.
- Observabilidad: el grado en el que es posible observar los resultados de la prueba (intermedios y finales).
- Capacidad de aislamiento: el grado en el que el componente sometido a prueba (CUT) se puede probar de forma aislada.
- Separación de preocupaciones : el grado en el que el componente sometido a prueba tiene una responsabilidad única y bien definida.
- Comprensibilidad: el grado en el que el componente bajo prueba está documentado o es autoexplicativo.
- Automatability: El grado en que es posible automatizar las pruebas del componente bajo prueba.
- Heterogeneidad: el grado en el que el uso de diversas tecnologías requiere utilizar diversos métodos y herramientas de prueba en paralelo.
La capacidad de prueba de los componentes de software se puede mejorar mediante:
- Desarrollo impulsado por pruebas
- Diseño para prueba (similar al diseño para prueba en el dominio del hardware)
Jerarquía de testabilidad
En función del número de casos de prueba necesarios para construir un conjunto de pruebas completo en cada contexto (es decir, un conjunto de pruebas tal que, si se aplica a la implementación bajo prueba, recopilamos suficiente información para determinar con precisión si el sistema es correcto o incorrecto según alguna especificación), se ha propuesto una jerarquía de capacidad de prueba con las siguientes clases de capacidad de prueba: [2] [3]
- Clase I: existe un conjunto de pruebas completo finito.
- Clase II: cualquier tasa de distinción parcial (es decir, cualquier capacidad incompleta para distinguir sistemas correctos de sistemas incorrectos) puede alcanzarse con una serie de pruebas finita.
- Clase III: existe un conjunto de pruebas completo contable.
- Clase IV: existe una suite de pruebas completa.
- Clase V: todos los casos.
Se ha demostrado que cada clase está estrictamente incluida en la siguiente. Por ejemplo, probar cuando asumimos que el comportamiento de la implementación bajo prueba puede ser denotado por una máquina determinista de estados finitos para algunos conjuntos finitos conocidos de entradas y salidas y con un número conocido de estados pertenece a la Clase I (y todas las clases subsecuentes ). Sin embargo, si no se conoce el número de estados, solo pertenece a todas las clases desde la Clase II en adelante. Si la implementación bajo prueba debe ser una máquina determinista de estados finitos que no cumple con la especificación para una sola traza (y sus continuaciones), y se desconoce su número de estados, entonces solo pertenece a las clases de la Clase III en adelante. Probar máquinas temporales donde las transiciones se activan si las entradas se producen dentro de un intervalo acotado real solo pertenece a clases desde la Clase IV en adelante, mientras que probar muchos sistemas no deterministas solo pertenece a la Clase V (pero no a todos, y algunos incluso pertenecen a la Clase I ). La inclusión en la Clase I no requiere la simplicidad del modelo de cálculo asumido, ya que algunos casos de prueba que involucran implementaciones escritas en cualquier lenguaje de programación y las implementaciones de prueba definidas como máquinas que dependen de magnitudes continuas, han demostrado estar en la Clase I.Otros elaborados los casos, como el marco de prueba de Matthew Hennessy bajo la semántica de must, y las máquinas temporales con tiempos de espera racionales, pertenecen a la Clase II.
Testabilidad de los requisitos
Los requisitos deben cumplir los siguientes criterios para poder ser comprobables:
- consistente
- completo
- inequívoco
- cuantitativo (un requisito como "tiempo de respuesta rápido" no se puede verificar )
- verificación / verificable en la práctica (una prueba es factible no solo en teoría sino también en la práctica con recursos limitados)
Al tratar el requisito como axiomas, la testabilidad se puede tratar afirmando la existencia de una función. (software) tal que la entrada genera salida , por lo tanto . Por tanto, el software ideal genera la tupla que es el conjunto de entrada-salida , que representa la especificación.
Ahora, tome una entrada de prueba , que genera la salida , esa es la tupla de prueba . Ahora, la pregunta es si o . Si está en el conjunto, la tupla de pruebapasa, de lo contrario el sistema falla la entrada de prueba. Por lo tanto, es de imperativa importancia averiguar: ¿podemos o no podemos crear una función que se traduzca efectivamente en la noción de función indicadora de conjunto para el conjunto de especificaciones?.
Por la noción, es la función de prueba para la especificación . La existencia no debe simplemente afirmarse, debe probarse rigurosamente. Por lo tanto, obviamente, sin consistencia algebraica, no se puede encontrar tal función y, por lo tanto, la especificación deja de denominarse comprobable.
Ver también
Referencias
- ^ Shalloway, Alan; Trott, Jim (2004). Patrones de diseño explicados, 2ª ed . pag. 133 . ISBN 978-0321247148.
- ^ a b Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "Una teoría general de testabilidad: clases, propiedades, complejidad y reducciones de prueba" . Transacciones IEEE sobre ingeniería de software . 40 (9): 862–894. doi : 10.1109 / TSE.2014.2331690 . ISSN 0098-5589 .
- ^ a b Rodríguez, Ismael (2009). "Una teoría de la testabilidad general". CONCUR 2009 - Teoría de la concurrencia, 20ª Conferencia Internacional, CONCUR 2009, Bolonia, Italia, 1 al 4 de septiembre de 2009. Actas . págs. 572–586. doi : 10.1007 / 978-3-642-04081-8_38 . ISBN 978-3-642-04080-1.
- Robert V. Binder: Prueba de sistemas orientados a objetos: modelos, patrones y herramientas, ISBN 0-201-80938-9
- Stefan Jungmayr: Mejora de la capacidad de prueba de los sistemas orientados a objetos , ISBN 3-89825-781-9
- Wanderlei Souza: Patrones abstractos de testabilidad, ISSN 1884-0760
- Boris Beizer: [1] , Técnicas de prueba de software