La secuencia de código lineal y salto ( LCSAJ ), en sentido amplio, es un método de análisis de software utilizado para identificar unidades estructurales en el código bajo prueba. Su uso principal es con 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, una LCSAJ es una región lineal bien definida del código de un programa. Cuando se utiliza en este sentido, a una LCSAJ también se la denomina JJ-path , que significa ruta de salto a salto.
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ó posteriormente la empresa Liverpool Data Research Associates (LDRA) para comercializar el banco de pruebas de software producido para este trabajo, lo que dio como resultado el producto LDRA Testbed .
Introducido en 1976, el LCSAJ [4] ahora también se conoce como el camino de salto a salto (JJ-path). [5] También se lo ha llamado la contribución de Liverpool a los acrónimos y chistes tontos. [ cita requerida ]
Un LCSAJ es un fragmento de ruta de código de software que consiste en 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]
A diferencia de los bloques básicos (máximos) , los LCSAJ pueden superponerse entre sí porque un salto (hacia fuera) puede ocurrir 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 se extiende 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). 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 una 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, seguida de un salto de flujo de control ya sea fuera de la [unidad] de código o hacia un bloque básico numerado r , donde r ≠ ( q +1), y ya sea p = 1 o existe un salto de flujo de control al bloque p desde algún otro bloque en la unidad. (Un bloque básico al cual se puede realizar dicho salto de flujo de control se denomina un objetivo del salto [LCSAJ].)
Según el libro de texto de Jorgensen de 2013, fuera de Gran Bretaña y de la literatura ISTQB , la misma noción se denomina DD-path . [9] [ dudoso – discutir ]
Las métricas de análisis de cobertura se utilizan para medir cuánto se ha realizado la prueba. La métrica más básica es la proporción de declaraciones ejecutadas, índice de efectividad de la prueba 1 (TER1): [10]
También se pueden generar métricas de cobertura de nivel superior, en particular: [11]
Estas métricas satisfacen una jerarquía pura, por la cual cuando se ha alcanzado TER3 = 100% se deduce que también se han alcanzado TER2 = 100% y TER1 = 100%.
Tanto la métrica TER1 como la TER2 se utilizaban a principios de los años 1970 y la tercera data de finales de los años 1970. El requisito para lograr TER1 = 100% fue el nivel seleccionado originalmente para el estándar de aviónica DO-178 hasta que se complementó con el requisito adicional MCDC ( cobertura de decisión/condición modificada ) en 1992. [12] Se han exigido niveles más altos TER3 = 100% para muchos otros proyectos, incluidos el aeroespacial, la telefonía y la banca. [ cita requerida ] Un problema práctico del uso de TER3 es que muchos LCSAJ nunca se pueden ejecutar debido a las condiciones conflictivas que contienen.
Considere el siguiente código C:
#incluir <stdlib.h> #include <cadena.h> #include <matemática.h> #define MAXCOLUMNAS 26#define MAXROW 20#define MAXCOUNT 90#define ITERACIONES 750int principal ( vacío ) { int count = 0 , totales [ MAXCOLUMNS ], val = 0 ; memset ( totales , 0 , MAXCOLUMNS * sizeof ( int )); conteo = 0 ; mientras ( count < ITERACIONES ) { val = abs ( rand ()) % MAXCOLUMNAS ; totales [ val ] += 1 ; si ( totales [ val ] > MAXCOUNT ) { totales [ val ] = MAXCOUNT ; } contar ++ ; } retorna ( 0 ); }En este ejemplo se puede observar que el bloque básico identificado por un triple LCSAJ puede abarcar un punto de decisión, lo que refleja las condiciones que deben cumplirse para que se ejecute el LCSAJ. Por ejemplo, LCSAJ 2 para el ejemplo anterior incluye la whiledeclaración donde la condición (count < ITERATIONS)se evalúa como verdadera.
Cada línea de código tiene una 'densidad' LCSAJ asociada a ella; la línea 17, por ejemplo, aparece dentro de 6 LCSAJ únicos, es decir, tiene una densidad LCSAJ de 6. Esto es útil para evaluar la capacidad de mantenimiento del código; si se debe 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.