Secuencia y salto de código lineal ( LCSAJ ), en sentido amplio, es un método de análisis de software que se utiliza para identificar unidades estructurales en el código sometido a prueba. Su uso principal es el análisis de software dinámico para ayudar a responder la pregunta "¿Cuántas pruebas son suficientes?". [1] El análisis de software dinámico se utiliza para medir la calidad y eficacia de los datos de prueba de software, donde la cuantificación se realiza en términos de unidades estructurales del código bajo prueba. Cuando se utiliza para cuantificar las unidades estructurales ejercidas por un conjunto dado de datos de prueba, el análisis dinámico también se conoce como análisis de cobertura estructural .
En un sentido más estricto, un LCSAJ es una región lineal bien definida del código de un programa. Cuando se usa en este sentido, LCSAJ también se llama JJ-path , que significa ruta de salto a salto.
Historia
El método de análisis LCSAJ fue ideado por el profesor Michael Hennell para realizar evaluaciones de calidad en las bibliotecas matemáticas de las que dependía su investigación en física nuclear en la Universidad de Liverpool . [2] [3] El profesor Hennell fundó más tarde la empresa Liverpool Data Research Associates (LDRA) para comercializar el banco de pruebas de software producido para este trabajo, lo que resultó en el producto LDRA Testbed .
Introducido en 1976, el LCSAJ [4] ahora también se conoce como la ruta de salto a salto (ruta JJ). [5] También se ha llamado Contribución de Liverpool a acrónimos y chistes tontos. [ cita requerida ]
Definición y características de LCSAJ como región de código
Un LCSAJ es un fragmento de ruta de código de software que consta de una secuencia de código (una secuencia de código lineal) seguida de un salto de flujo de control y consta de los tres elementos siguientes: [6]
- el inicio de la secuencia lineal de sentencias ejecutables
- el final de la secuencia lineal
- la línea objetivo a la que se transfiere el flujo de control al final de la secuencia lineal.
A diferencia de los bloques básicos (máximos) , los LCSAJ pueden superponerse entre sí porque puede ocurrir un salto (fuera) en el medio de un LCSAJ, mientras que no está permitido en el medio de un bloque básico. En particular, los saltos condicionales generan LCSAJ superpuestos: uno que llega hasta donde la condición se evalúa como falsa y otro que termina en el salto cuando la condición se evalúa como verdadera (el ejemplo que se da más adelante en este artículo ilustra tal ocurrencia). Por lo tanto, cada bloque básico es un LCSAJ, pero un LCSAJ puede constar de más de un bloque básico. Según una monografía de 1986, los LCSAJ eran típicamente cuatro veces más grandes que los bloques básicos. [7]
La definición formal de LCSAJ se puede dar en términos de bloques básicos de la siguiente manera: [8]
una secuencia de uno o más bloques básicos numerados consecutivamente, p , ( p +1), ..., q , de una unidad de código, seguido de un salto de flujo de control fuera del código [unidad] o hacia un bloque básico numerado r , donde r ≠ ( q +1), y p = 1 o existe un salto de flujo de control para bloquear p desde algún otro bloque de la unidad. (Un bloque básico al que se puede realizar un salto de flujo de control de este tipo se denomina objetivo del salto [LCSAJ]).
Según el libro de texto de Jorgensen de 2013, fuera de la literatura de Gran Bretaña e ISTQB , la misma noción se llama DD-path . [9] [ dudoso ]
Tasa de efectividad de la prueba
Las métricas de análisis de cobertura se utilizan para medir cuántas pruebas se han logrado. La métrica más básica es la proporción de declaraciones ejecutadas, Tasa de efectividad de la prueba 1 (TER1): [10]
También se pueden generar métricas de cobertura de mayor nivel, en particular: [11]
Estas métricas satisfacen una jerarquía pura, por lo que cuando se ha alcanzado TER3 = 100%, se sigue que también se han logrado TER2 = 100% y TER1 = 100%.
Tanto las métricas TER1 como TER2 estaban en uso a principios de la década de 1970 y la tercera data de finales de la década de 1970. El requisito para lograr TER1 = 100% fue el nivel originalmente seleccionado para la norma de aviónica DO-178 hasta que fue complementado por el requisito adicional MCDC ( condición modificada / cobertura de decisión ) en 1992. [12] Se han aplicado niveles más altos TER3 = 100% obligatorio para muchos otros proyectos, incluidos el aeroespacial, la telefonía y la banca. [ cita requerida ] Un problema práctico de usar TER3 es que muchos LCSAJ nunca se pueden ejecutar debido a las condiciones conflictivas que contienen.
Ejemplo
Considere el siguiente código C:
#include #include #include #define MAXCOLUMNS 26#define MAXROW 20#define MAXCOUNT 90#definir ITERACIONES 750int main ( vacío ){ int count = 0 , totales [ MAXCOLUMNS ], val = 0 ; memset ( totales , 0 , MAXCOLUMNS * sizeof ( int )); cuenta = 0 ; while ( cuenta < ITERACIONES ) { val = abs ( rand ()) % MAXCOLUMNS ; totales [ val ] + = 1 ; si ( totales [ val ] > MAXCOUNT ) { totales [ val ] = MAXCOUNT ; } contar ++ ; } return ( 0 );}
De este código, la siguiente es una lista completa de los triples LCSAJ para este código
Número LCSAJ | Línea de salida | Línea de meta | Saltar a la línea |
---|---|---|---|
1 | 10 | 17 | 28 |
2 | 10 | 21 | 25 |
3 | 10 | 26 | 17 |
4 | 17 | 17 | 28 |
5 | 17 | 21 | 25 |
6 | 17 | 26 | 17 |
7 | 25 | 26 | 17 |
8 | 28 | 28 | −1 |
En este ejemplo se puede ver que el bloque básico identificado por un triple LCSAJ puede abarcar un punto de decisión, reflejando las condiciones que deben estar en su lugar para que se ejecute el LCSAJ. Por ejemplo, LCSAJ 2 para el ejemplo anterior incluye la while
declaración donde la condición se (count < ITERATIONS)
evalúa como verdadera.
Cada línea de código tiene asociada una 'densidad' LCSAJ; la línea 17, por ejemplo, aparece dentro de 6 LCSAJ únicos, es decir, tiene una densidad LCSAJ de 6. Esto es útil al evaluar la capacidad de mantenimiento del código; Si se va a cambiar una línea de código, la densidad es indicativa de cuántos LCSAJ se verán afectados por ese cambio.
Se alcanzaría un nivel de cobertura de TER3 = 100% cuando los datos de prueba utilizados provoquen la ejecución de cada uno de estos LCSAJ al menos una vez.
Referencias
- ^ MAHennell, D.Hedley y MRWoodward, "Cuantificación de la eficacia de la prueba de los programas Algol 68", Actas de la conferencia Strathclyde ALGOL 68 1977, págs. 36 - 41, ISSN 0362-1340
- ^ MA Hennell, un banco de pruebas experimental para software numérico. {I}. {Fortran} , The Computer Journal 21 (4): 333--336, @nov, 1978
- ^ MA Hennell y D. Hedley, un banco de pruebas experimental para software numérico. {II}. {ALGOL 68} , The Computer Journal 22 (1): 53--56, @feb, 1979
- ^ MA Hennell, MRWoodward y D.Hedley, "Sobre el análisis del programa", Cartas de procesamiento de información, 5 (5), págs. 136 - 140, 1976
- ^ MR Woodward, MA Hennell, "Sobre la relación entre dos criterios de cobertura de flujo de control: todas las rutas JJ y MCDC", Tecnología de la información y el software 48 (2006) pp. 433-440
- ^ MAHennell, D.Hedley e IJRiddell, "Evaluación de una clase de herramientas de software", Actas de la 7ma Conferencia Internacional sobre Ingeniería de Software de marzo de 1984, págs. 266 - 277. ISSN 0270-5257
- ^ Martyn A. Ould y Charles Unwin, ed. (1986). Pruebas en desarrollo de software . Prensa de la Universidad de Cambridge. pag. 102. ISBN 978-0-521-33786-1.
- ^ Groenda, Henning (2013). Certificación de especificaciones de rendimiento de componentes de software . KIT Publicaciones científicas. págs. 198-200. ISBN 978-3-7315-0080-3. citando de Yates, DF (2009). "Inclusión, subsunción, rutas JJ y pruebas de ruta estructurada: una reparación". Pruebas, verificación y confiabilidad de software . 19 (3): 199–213. doi : 10.1002 / stvr.400 .
- ^ Paul C. Jorgensen (2013). Pruebas de software: el enfoque de un artesano, cuarta edición . Prensa CRC. pag. 136. ISBN 978-1-4665-6068-0.
- ^ JRBrown, "Aplicación práctica de herramientas de software automatizadas", Informe TRW No. TRW-SS-72-05, presentado en WESCON, 1972
- ^ MRWoodward, D.Hedley y MAHennell, "Experiencia con análisis de rutas y pruebas de programas", Transacciones de IEEE sobre ingeniería de software, vol. 6, núm. 3, págs.278 - 286, mayo de 1980
- ^ Consideraciones de software en la certificación de equipos y sistemas aerotransportados-RTCA / DO-178B, RTCA Inc., Washington DC, diciembre de 1992