Una métrica para la prueba del software - gplsi

Una métrica para la capacidad de prueba del software
Y. Wang †, J. Trujillo ‡ y M. Palomar ‡
†System Engineering Faculty, Southampton Institute
Southampton SQ16 OYN, UK
Email: [email protected]
‡Depto. de Lenguajes y Sistemas Informáticos. Escuela Politécnica Superior.
Universidad de Alicante, Apto. Correos 99. E-03080 Alicante. España.
Email: {trujillo,mpalomar}@dlsi.ua.es
RESUMEN:
La ingeniería de software convencional trata el diseño y prueba del software como fases
relativamente separadas y actividades independientes. Esto origina problemas como
mayor complejidad en la producción de software, poca fiabilidad de la fase de prueba y
un alto coste de la misma. Para solucionar estos problemas, un nuevo modelo de medida
para la capacidad de prueba del software es presentado y, una métrica para la capacidad
de prueba del sotfware (STM1) es desarrollada para dirigir y mejorar la prueba del
software. Utilizando esta métrica, el software, que es más comprobable, diagnosticable,
depurable y realizable puede ser desarrollado y mantenido formal y rigurosamente. Es
útil simplificar la prueba del software para que el costo de la prueba y mantenimiento
del mismo pueda ser reducido.
Palabras clave: ingeniería del software, diseño del software, prueba del software,
software comprobable, métricas del software.
1. Introducción
En la ingeniería del software convencional, el diseño y prueba del software son fases
relativamente separadas y actividades independientes. Esto puede originar problemas
como mayor complejidad en la producción de software y poca fiabilidad de la prueba
del mismo, conduciendo esta situación a un alto coste de la prueba del software [1,2].
Como consecuencia, muchos autores han defendido la idea de que el software no puede
1
ser comprobado en su totalidad, especialmente cuando un exhaustivo método de la caja
blanca es esperado.
Así que, es importante asegurar que los requerimientos de prueba podrían influenciar el
diseño e implementación del software si se espera que el programa final sea totalmente
comprobable. El diseño de la capacidad de prueba del software [3,5] es una
terminología que emergió en los 80 para la prueba del VLSI. Actualmente se entiende
también como un requerimiento esencial para la prueba de software de gran escala
debido al continuo crecimiento de la complejidad y coste en la prueba del software.
Este artículo propone un modelo de medida para la capacidad de prueba de módulos de
un programa, y a su vez lo extiende a la prueba de todo el sistema software. Una métrica
para la capacidad de prueba del software (STM) es desarrollada para establecer una
evaluación cuantitativa y una valoración estándar para fomentar la programación
comprobable [1]. Adoptando la STM y el método de programación comprobable, los
procesos subsecuentes de generación e implementación de la prueba pueden ser
simplificados substancialmente. La STM puede ser usada para valorar cuantitativamente
la capacidad de prueba del software, y dirigir el diseño del software comprobable y la
nueva generación de compiladores de prueba.
2. Definición básica de la capacidad de prueba del software
Antes de la definición del software comprobable es necesario introducir el concepto de
Estructuras de Control Básicas (BCSs2) [6,7] dentro del software.
Definición 1: Las BCSs del software son aquellas sentencias fundamentales que
controlan el flujo del programa, tales como las de condición, iteración y secuencia.
Las BCSs soportadas comúnmente por la mayoría de los lenguajes de alto nivel son las
siguientes:
1
2
STM: Software Testability Metric
BCSs: Basic Control Structures
2
BCSs ::= if-then
| if-then-else
| case
| while-do
| repeat-until
| for-do
| sequencial-statement
(1)
Basado en esta definición de BCSs, el software comprobable puede ser definido como
sigue.
Definición 2: El software comprobable es un programa en el que los mecanismos de
prueba construidos [1,2] que pueden ser activados independientemente durante la
prueba son adoptados en todas las BCSs en el programa.
Convencionalmente, el software diseñado o no es totalmente comprobable o es muy
costoso el probarlo en su totalidad [8,9]. Un ejemplo de un modulo es mostrado en la
figura 1. Se trata de una concatenación simple de las estructuras de control básicas ifthen-else, case e if-then-else. Dicho módulo no es totalmente comprobable ya que hay al
menos un camino h que no puede ser cubierto cuando X es previamente forzado a ser
falso en el caso de prueba.
Generalmente, la situación podría ser peor, como por ejemplo cuando las variables
Booleanas en las BCSs son caminos sensibles o mutuamente dependientes. Por ejemplo,
X en BCS3 es un camino sensible ya que depende de los caminos realmente ejecutados
anteriores a él; y el control de la expresión en BCS3, exp= X  Y, es mutuamente
dependiente tanto de X como de Y.
3
a
X
[BCS1 : If-then-else]
b
V F c
P
[BCS2 : Case-p]
d
e …
f
g
X Y
[BCS3 : If-then-else]
h
V
F i
j
Figura 1. Grafo del flujo de un módulo de programa.
Por estas razones necesitamos encontrar una nueva aproximación para la programación
comprobable y un entorno métrico para la valoración cuantitativa de la capacidad de
prueba del software.
3. Capacidad de prueba del software a nivel de módulo
El diseño de la prueba del software comprende tanto simulaciones como respuestas. Por
lo tanto, la prueba del software puede ser determinada desde dos aspectos controlabilidad de la prueba (TC3) y la observabilidad de la prueba (TO4).
3
4
TC: Test Controlability
TO: Test Observability
4
3.1. Controlabilidad de la prueba (TC)
Definición 3: La controlabilidad de la prueba TC se define como la capacidad para
asignar independientemente las variables Booleanas o expresiones (vi) en cada BCS
dentro de un módulo software.
El significado físico de TC es la habilidad para forzar a un módulo a ejecutar cualquiera
de los caminos esperados en modo de prueba asignando las variables de control (vi)
dentro del modulo probado. TC puede ser determinado mediante la siguiente fórmula:
TC
1 n
 CBCSi
n i 1
(2)
Donde C BCS i es la controlabilidad individual de cada BCS en el módulo y n el número
total de BCSs en el módulo. Toma el valor 1 ó 0 dependiendo de si la BCS es
independientemente asignable o no.
El dominio de TC es [0,1]. Un módulo con TC=1 significa que es totalmente
controlable; TC=0 es no controlable. De cualquier otra forma 0 < TC < 1 implica que
es parcialmente controlable.
Ejemplo 1: En la figura 1, la BCS3 determinada mediante X  Y es no controlable
porque X puede tomar el valor de falso. La BCS2 es también no controlable ya que la
variable de control P es sensible a los caminos b ó c anteriores a él. En estos casos, la
controlabilidad total del módulo mostrado en la figura 1 puede ser calculado de acuerdo
con la fórmula 2 como sigue:
TC = 1/3 * (BCS1 + BCS2 + BCS3 )
= 1/3 * (1 + 0 + 0)
= 1/3
5
3.2 Observabilidad de la prueba (TO)
Definición 4: La observabilidad de la prueba TO de un módulo es la capacidad para
indicar los valores de la variables dentro de los caminos sensibles en el caso de prueba
actual.
TO tiene el mismo dominio que TC. TO=1 ó TO=0 representan una total y no total
observabilidad respectivamente de un módulo software. Como la observabilidad total es
más fácil de implementar insertando un instrumento de prueba en el código como las
sentencias write or print, a partir de ahora asumiremos TO  1.
3.3 Capacidad de prueba de un módulo (MTA5) software
Es intuitivo que cuanto mayor sea el índice tanto de TC como de TO, mayor será la
capacidad de prueba de un módulo. Así que, basándonos en las definiciones de TC y TO
podemos definir a continuación la capacidad de prueba de un modulo (MTA) de
software.
Definición 5: La capacidad de prueba de un módulo MTA es un producto de su
controlabilidad (TC) y observabilidad (TO) de la prueba. Esto es,
MTA =  (TC, TO)
= TC * TO
(3)
La fórmula 3 indica que MTA = 1 si tanto TC como TO valen 1; MTA = 0 si cualquiera
de ellos vale 0. De forma más general:
0  MTA  1
(4)
para 0  TC  1 y 0  TO  1.
Si consideramos que TO  1 y la expresión TC de la fórmula 2, la fórmula 3 puede ser
simplificada como:
5
MTA: Module Test Ability
6
MTA = TC * 1
1 n
=  C BCSi
n i 1
(5)
Ejemplo 2: Aplicando la fórmula 5 para dirigir la prueba del módulo dado en la figura
1, su MTA puede ser determinado como sigue
1 n
MTA =  C BCSi
n i 1
= 1/3 * (BCS1 + BCS2 + BCS3 )
= 1/3 * (1 + 0 + 0)
= 1/3
Es obvio que la MTA del módulo de la figura 1 es mucho más baja que 1 para una
prueba completa esperada. Métodos para mejorar la capacidad de prueba del módulo
basados en el resultado de una valoración cuantitativa pueden ser encontrados en [1,2].
4. Capacidad de prueba del software a nivel de sistema
La capacidad de prueba de un sistema software depende directamente de la capacidad de
prueba de los módulos contenidos en él. Así que la definición de la capacidad de prueba
del sistema (STA6) de software puede ser obtenida a partir de las MTAs del software.
Definición 6: La STA del software se define como una media estadística de las
capacidades de prueba de todos los módulos que dicho software contiene.
Asumiendo que los TOs en todos los módulos valen 1, la definición de STA puede ser
expresada como
MTA =
6
STA: Software Test Ability
7
1 m
 MTA j
m j 1
=
=
1 m
 TC
m j 1 j
m
1
C
m
n
j 1
nj
j 1 i 1
BCS ji
(6)
j
Donde m es el número de módulos en el software, y nj es el número de BCS en el
módulo j.
La fórmula 6 indica que si todos los CBCS ji = 1 para 1  j  m y 1  i  nj, o TCj = 1 o
MTA j = 1 para 1  j  m , entonces se obtiene que la capacidad de prueba del sistema es
STA = 1 y el software es totalmente comprobable. De otro modo, la capacidad de prueba
del software necesita ser mejorada mediante los métodos de programación
comprobables desarrollados en [1,2].
5. Una métrica para la capacidad de prueba del software
Una vez obtenidos los modelos de medidas MTA y STA en las secciones 3 y 4
respectivamente, alcanzamos el siguiente teorema de la métrica de la capacidad de
prueba del software.
Teorema 1. Para un software dado, se dice que dicho software es comprobable si y sólo
si :
a ) Su STA = 1; o
b ) Todos los MTAj = 1 para j = 1, 2, …, m; o
c ) Todos los CBCS ji = 1, 1  j  m , 1  i  nj
se satisfacen en el software. 
8
El teorema indica que la mejor aproximación para implementar un software
comprobable es incrementar el valor de TCs o C BCS s en cada uno de los módulos
software para poder así alcanzar una capacidad de prueba total a nivel de módulo y,
consecuentemente a nivel de sistema.
El teorema1, así como las fórmulas 5 y 6, forman el STM. El STM muestra que la
capacidad de prueba del software puede ser cuantitativamente medido en términos de
MTA y STA, o mediante los parámetros de STM de TCs, TO y C BCS s a nivel de módulo y
sistema.
6. Conclusiones
La prueba del software tradicional se centra en la generación de pruebas para el software
existente [9,11]. El diseño del software comprobable centra su atención en el diseño de
la capacidad de prueba y en la necesidad de construir mecanismos de prueba para el
software durante el código o la compilación [1,2]. Este artículo ha examinado la
naturaleza de la capacidad de prueba del software y la aproximación requerida para
medirlo cuantitativamente. Las capacidades de prueba del software a nivel de módulo
(MTA) y a nivel de sistema (STA) son modeladas en términos de controlabilidad (TC) y
observabilidad (TO) del software, y la métrica de la capacidad de prueba del software
STM es desarrollada sistemáticamente.
La STM puede ser aplicada no sólo para valorar la capacidad de prueba del software,
sino también para mejorarla. Este artículo pone énfasis en la primera, más información
sobre cómo mejorar la capacidad de prueba del software puede ser encontrada en [2]. La
valoración de los parámetros de STM, tales como TC, TO, C BCS s , MTA y STA, se
obtiene a partir de TC y TO mediante al análisis de los factores de camino sensible y
dependencia mutua en las BCSs.
Basado en el entorno de STM y en el método de programación comprobable, la prueba
del software puede ser llevada a cabo sobre la calidad de la prueba de la caja blanca y en
9
el coste de la prueba de la caja negra. Experimentos prácticos iniciales [1] han mostrado
que la métrica puede ser introducida en los procesos y metodologías existentes del
desarrollo del software, tales como el ciclo de vida, prototipación y metodologías
orientadas a objetos. La STM es útil para simplificar el trabajo del diseño de la prueba y
para reducir el coste de dicha prueba y del mantenimiento del software.
Agradecimientos
A los autores les gustaría agradecer a C.A.R. Hoare por su ayuda y comentarios.
Deseamos agradecer a nuestros compañeros G. Stapples, G. King, M. Ross y I. Court
por sus útiles sugerencias.
Bibliografía
[1] Wang, Y. [1995] On the Design of Testable Software, Research Report of Oxford
University Computing Laboratory, OUCL-WANG-95-002.
[2] Wang, Y., King G., Ross, M., Staples, G. and Court, I. [1996] On a Method to
Develop Testable Software, Proceedings of IEEE European Testing Workshop (IEEE
ETW’96), Montpellier, France, pp. 176-180.
[3] Smith, K. [1983] Scan-Path Logic Integrated on Chip Tests Data Array, Electronics
International, Vol. 56, No. 15, pp. 85-86.
[4] Hess, R.D. [1982] Testability Analysis: An Alternative to Structured Design for
Testability, VLSI Design, Vol. March/April, pp. 22-27.
[5] Wang, Y. [1988] Testability Theory and Its Application in the Design of Digital
Switching Systems, Journal of Telecommunication Switching, Vol. 17, pp. 30-36.
[6] McCabe, T. [1976] A Software Complexity Measure, IEEE Trans. Software
Engineering, Vol. 2, No. 6, pp. 308-320.
[7] McCabe, T. [1983] Structured Testing, IEEE Computer Society Press.
[8] Tai, K. C. [1989] What to Do Beyond Branch Testing, ACM Software Engineering
Notes, Vol. 14, No. 2, pp-58-61.
[9] Pressman, R.S. [1992] Software Engineering: A Practitioner´s Approach (3rd ed.),
McGraw-Hill International Editions, pp. 595-630
10
[10] Beizer, B [1990] Software Testing Techniques (2nd de.), Van Nostrand Reinhold,
pp. 1-14
[11] Beixer, B. [1984] Software System Testing and Quality Assurance, Van Nostrand
Reinhold, pp. 37-90
11