Capacidad de prueba del software

La testabilidad del software es el grado en el que un artefacto de software (es decir, un sistema de software, un módulo de software, un documento de requisitos o de diseño) admite la realización de pruebas en un contexto de prueba determinado. Si la testabilidad del artefacto de software es alta, será más fácil encontrar fallas en el sistema (si las tiene) mediante pruebas.

Formalmente, algunos sistemas son comprobables y otros no. Esta clasificación se puede lograr observando que, para que sea comprobable, para una funcionalidad del sistema bajo prueba "S", que toma la entrada "I", debe existir un predicado funcional computable "V" tal que sea verdadero cuando S, dada la entrada I, produzca una salida válida, falso en caso contrario. Esta función "V" se conoce como la función de verificación para el sistema con la entrada I. ${\displaystyle V(S,I)}$

Muchos sistemas de software no se pueden probar o no se pueden probar de inmediato. Por ejemplo, el ReCAPTCHA de Google , que no tiene metadatos sobre las imágenes, no es un sistema que se pueda probar. Sin embargo, el ReCAPTCHA se puede probar de inmediato si para cada imagen mostrada hay una etiqueta almacenada en otro lugar. Con esta metainformación, se puede probar el sistema.

Por lo tanto, la capacidad de prueba suele considerarse una propiedad extrínseca que resulta de la interdependencia entre el 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 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 la encapsulación, el acoplamiento, la cohesión y la redundancia.

La correlación entre la "capacidad de prueba" y 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 implica un mayor esfuerzo de prueba . En casos extremos, la falta de capacidad de prueba puede impedir la prueba de partes del software o de los requisitos del software .

La capacidad de prueba, una propiedad que se aplica a las hipótesis empíricas, implica dos componentes. El esfuerzo y la eficacia de las pruebas de software dependen de numerosos factores, entre ellos:

• Propiedades de los requisitos del software
• Propiedades del propio software (como tamaño, complejidad y capacidad de prueba)
• Propiedades de los métodos de ensayo utilizados
• Propiedades de los procesos de desarrollo y prueba
• Cualificación y motivación de las personas implicadas en el proceso de prueba

La capacidad de prueba de los componentes de software (módulos, clases) está determinada por factores como:

• Controlabilidad: Grado en el que es posible controlar el estado del componente bajo prueba (CUT) según sea necesario para la prueba.
• Observabilidad: Grado en el que es posible observar los resultados de las pruebas (intermedias y finales).
• Aislabilidad: Grado en el cual el componente bajo prueba (CUT) puede probarse de forma aislada.
• Separación de preocupaciones : Grado en el cual el componente bajo prueba tiene una responsabilidad única y bien definida.
• Comprensibilidad: El grado en el cual el componente bajo prueba está documentado o se explica por sí solo.
• Automatización: Grado en el que es posible automatizar las pruebas del componente bajo prueba.
• Heterogeneidad: Grado en el cual 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 basado en pruebas
• Diseño para capacidad de prueba (similar al diseño para pruebas en el dominio del hardware)

Los requisitos deben cumplir los siguientes criterios para poder probarse:

• coherente
• 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 sólo en teoría sino también en la práctica con recursos limitados)

Si se considera el requisito como axioma, la capacidad de prueba se puede tratar afirmando la existencia de una función (software) tal que la entrada genere la salida , por lo tanto . Por lo tanto, el software ideal genera la tupla que es el conjunto de entrada-salida , que representa la especificación. $Estilo de visualización F_{S}$${\displaystyle I_{k}}$${\displaystyle O_{k}}$${\displaystyle F_{S}:I\to O}$${\displaystyle (I_{k},O_{k})}$${\estilo de visualización \Sigma}$

Ahora, tomemos una entrada de prueba , que genera la salida , que es la tupla de prueba . Ahora, la pregunta es si o no . Si está en el conjunto, la tupla de prueba pasa, de lo contrario, el sistema falla la entrada de prueba. Por lo tanto, es de importancia imperativa averiguar: ¿podemos o no podemos crear una función que se traduzca efectivamente en la noción de la función indicadora de conjunto para el conjunto de especificación ? ${\displaystyle I_{t}}$$Estilo de visualización O_{t}}$${\displaystyle \tau = (I_{t},O_{t})}$${\displaystyle \tau \in \Sigma}$${\displaystyle \tau \no \en \Sigma }$${\estilo de visualización \tau}$${\estilo de visualización \Sigma}$

Por la noción, es la función de comprobabilidad de la especificación . La existencia no debe simplemente afirmarse, debe probarse rigurosamente. Por lo tanto, obviamente sin consistencia algebraica, no se puede encontrar dicha función y, por lo tanto, la especificación deja de considerarse comprobable. ${\displaystyle 1_{\Sigma}}$${\estilo de visualización \Sigma}$

• Capacidad de prueba

• Robert V. Binder: Pruebas de sistemas orientados a objetos: modelos, patrones y herramientas, ISBN 0-201-80938-9 
• Stefan Jungmayr: Mejorar la capacidad de prueba de los sistemas orientados a objetos, ISBN 3-89825-781-9 
• Wanderlei Souza: Patrones abstractos de comprobabilidad, ISSN 1884-0760
• Boris Beizer: [1], Técnicas de prueba de software