Testeabilidad

Atributos de Calidad
 Definición
 Es el grado en el cual un artefacto de software (sistema, modulo, clase, etc) soporta
testing en un contexto de test dado.
 Si la testeabilidad del arterfacto de software es alta, entonces encontrar defectos a
través del testing es más sencillo.

Consideraciones
 Se orienta, principalmente, a la posibilidad de realizar tests automatizados: unit tests,
integration tests, UI tests.
 Para que un artefacto de software sea testeable, debe ser posible:
 Controlar las entradas del componente, ejercitando su estado interno
 Observar las salidas
Escenarios
Tácticas
Tácticas

 El objetivo de un régimen de prueba es descubrir fallas. Esto requiere que

se proporcione la entrada al software que se está probando y que se
capture la salida.

La ejecución de los procedimientos de prueba requiere algún software

para proporcionar información al software que se está probando y
capturar la salida. Esto se llama arnés de prueba. Una pregunta que no
consideramos aquí es el diseño y la generación del arnés de prueba. En
algunos sistemas, esto lleva mucho tiempo y gastos.

Discutimos dos categorías de tácticas para la prueba: proporcionar

entrada y capturar salida, y monitoreo interno.
INPUT/OUTPUT

 Record/playback: se refiere tanto a la captura de información que cruza una interfaz como a su
uso como entrada en el arnés de prueba. La información que cruza una interfaz durante el
funcionamiento normal se guarda en algún repositorio y representa la salida de un componente
y la entrada a otro. El registro de esta información permite la entrada de prueba para uno de los
componentes que se generarán y la salida de prueba para guardar la comparación posterior.
 Separate interface from implementation: permite la sustitución de implementaciones para
diversos fines de prueba. Las implementaciones de stubbing permiten probar el resto del sistema
en ausencia del componente que se está stubbing. La sustitución de un componente
especializado permite que el componente que se reemplaza actúe como un arnés de prueba
para el resto del sistema.
 Specialize access routes/interfaces: Tener interfaces de prueba especializadas permite la
captura o especificación de valores variables para un componente a través de un arnés de
prueba, así como de forma independiente de su ejecución normal. Por ejemplo, los metadatos
podrían estar disponibles a través de una interfaz especializada que un arnés de prueba usaría
para conducir sus actividades. Las rutas e interfaces de acceso especializadas deben
mantenerse separadas de las rutas e interfaces de acceso para la funcionalidad requerida.
Tener una jerarquía de interfaces de prueba en la arquitectura significa que los casos de prueba
se pueden aplicar en cualquier nivel de la arquitectura y que la funcionalidad de prueba está
en su lugar para observar la respuesta.
INTERNAL MONITORING

 Built-in monitors: El componente puede mantener el estado, la carga de

rendimiento, la capacidad, la seguridad u otra información accesible a
través de una interfaz. Esta interfaz puede ser una interfaz permanente del
componente o puede introducirse temporalmente a través de una
técnica de instrumentación como programación orientada a aspectos o
macros de preprocesador.
 Una técnica común es registrar eventos cuando se han activado los
estados de monitoreo. Los estados de monitoreo en realidad pueden
aumentar el esfuerzo de prueba ya que las pruebas pueden tener que
repetirse con el monitoreo apagado. La mayor visibilidad de las
actividades del componente generalmente supera con creces el costo de
las pruebas adicionales.