structural testing tutorial what is structural testing
Este completo tutorial de pruebas estructurales explica qué son las pruebas estructurales, sus tipos, qué son las pruebas de flujo de control y el gráfico de flujo de control, los niveles de cobertura, etc.
Una búsqueda rápida en Google de algunos de los errores de software más costosos me dejó la mente dando vueltas: $ 500 mil millones. Sí, así de costoso puede resultar un error. Leer cualquier cosa relacionada con la pérdida de vidas en las industrias del transporte y la salud debido a un error de software también puede ser horrible.
Si bien los errores en el código no siempre son tan extremos cuando implican la pérdida de grandes cantidades de dinero y vidas, la única conclusión clave que estamos tratando de transmitir es que no se pueden pasar por alto las pruebas.
Cuando las pruebas se realizan con frecuencia en todo el SDLC, nos permite detectar errores que necesitarían mucho más tiempo para corregirlos después del envío del producto.
Lo importante son los tipos de pruebas de software que elegimos. Hay varios de estos, incluidas las pruebas funcionales, estructurales y basadas en cambios.
Este tutorial también explica los tipos de pruebas estructurales. Aprenda a realizar pruebas de mutación, pruebas basadas en cortes, pruebas de flujo de datos en detalle con ejemplos y explicaciones.
Lo que vas a aprender:
- ¿Por qué son importantes las pruebas de software?
- ¿Qué son las pruebas estructurales?
- Tipos de pruebas estructurales
- Ventajas y desventajas de las pruebas estructurales
- Mejores prácticas de pruebas estructurales
- Conclusión
¿Por qué son importantes las pruebas de software?
Además de ahorrar dinero y evitar desastres como los casos mencionados anteriormente, existen varias otras razones para justificar la importancia de las pruebas.
A continuación se enumeran algunas razones:
# 1) Para garantizar que se cumplan los requisitos estipulados antes de comenzar a construir un proyecto. Las partes interesadas (por ejemplo, desarrolladores y clientes) deben estar de acuerdo con todos los aspectos de la solución / producto / software que se requieren para construir un proyecto.
Las pruebas implican verificar si se cumplen los requisitos del software. El desarrollador o la empresa involucrada en la construcción de la solución también obtienen una buena reputación por diseñar una solución de tan alta calidad que se ejecuta mediante código eclat.
# 2) Verifica que la función del código esté funcionando según lo previsto. Las pruebas también implican la verificación de la funcionalidad del software y, en caso de avería, se debe solucionar durante las primeras fases de SDLC (ciclo de vida de desarrollo de software).
# 3) Comprueba el rendimiento: por ejemplo, para identificar el tiempo total transcurrido mientras se ejecuta el código. Si usamos varios Para bucles en nuestro código, tomará mucho tiempo obtener el resultado deseado e incluso puede agotarse el tiempo de espera a veces.
# 4) Ayuda a lograr una mejor experiencia de usuario. Los usuarios no disfrutarán usando software que funcione mal, tenga errores o sea 'demasiado lento'. Es probable que los usuarios se impacienten y abandonen el uso del software. Las pruebas nos brindan una mejor oportunidad para garantizar que los usuarios puedan usar nuestros productos fácilmente.
# 5) Comprueba la escalabilidad. Un desarrollador debe apuntar a crear software que se pueda escalar.
# 6) Busca vulnerabilidades en el código. Las pruebas nos brindan la oportunidad de buscar vulnerabilidades de seguridad, Por ejemplo, código que puede comprometer PII (Información de identificación personal) que es de alta prioridad para el GDPR.
En este artículo, nos centraremos en un tipo de prueba, es decir, Ensayos estructurales . Como sugiere el nombre, tiene que ver con la estructura del código. Esto es diferente de lo que mencionamos anteriormente, que las pruebas ayudan a determinar aspectos como el rendimiento, la funcionalidad y la seguridad del código.
Pruebas estructurales frente a otros tipos de pruebas
Hay muchos tipos de pruebas de software. sin embargo, el DETENER (Junta Internacional de Cualificaciones de Pruebas de Software), define 4 tipos principales de pruebas de software, a saber
- Funcional
- No funcional
- Estructural
- Basado en cambios
Las diferencias se pueden explicar a continuación:
Pruebas funcionales: Esto implica verificar la funcionalidad del software con los requisitos estipulados. Los datos de prueba se utilizan como entrada. También comprobamos que el resultado dado sea el esperado.
Pruebas no funcionales : Esto implica un proceso de prueba para analizar qué tan bien funciona el software, por ejemplo, la cantidad de usuarios que puede manejar simultáneamente.
Ensayos estructurales: Este tipo de prueba se basa en la estructura del código. Por ejemplo, Si un código está destinado a calcular el promedio de números pares en una matriz, entonces las pruebas basadas en la estructura estarían interesadas en los 'pasos que conducen al cálculo del promedio', en lugar de si el resultado final es un valor numérico correcto.
Supongamos que tenemos que comprobar si hemos definido el código que diferencia los números pares de los impares. Podemos tener una declaración condicional aquí, como, si un elemento de la matriz es divisible por dos sin un resto, si (arr (i)% 2 === 0) entonces el número se puede decir como un número par.
Las pruebas estructurales las llevan a cabo las mismas personas que escriben el código cuando lo entienden mejor.
Pruebas basadas en cambios : Esto implica probar los efectos de realizar cambios en el código y luego asegurarse de que los cambios realizados se hayan implementado. También asegura que los cambios en el código no lo rompan.
Qué no son las pruebas estructurales
Hemos mencionado anteriormente que las pruebas basadas en estructura se refieren a la estructura del código. Tenga en cuenta que aquí tratamos con el código real. No verificamos los requisitos ni probamos las entradas con los resultados esperados. No nos preocupa la funcionalidad, la experiencia del usuario o incluso el rendimiento en este momento.
¿Qué son las pruebas estructurales?
Las pruebas basadas en estructura, por lo tanto, se pueden definir como un tipo de prueba de software que prueba la estructura del código y los flujos previstos. Por ejemplo, verificar el código real para aspectos como la implementación correcta de declaraciones condicionales, y si cada declaración en el código se ejecuta correctamente. También se conoce como prueba basada en estructura.
cual es el mejor convertidor de youtube
Para llevar a cabo este tipo de pruebas, necesitamos comprender a fondo el código. Esta es la razón por la que esta prueba la realizan generalmente los desarrolladores que escribieron el código como mejor lo entienden.
Cómo realizar pruebas estructurales
Para probar diferentes aspectos del código, primero debemos comprender los flujos de control.
Prueba de flujo de control
Esto deriva de pruebas de los flujos de control del código (el orden en el que se implementan las declaraciones, funciones y diferentes aspectos del código).
Proceso de prueba de flujo de control:
Gráfico de flujo de control
El proceso de control de flujo comienza creando una representación visual de diferentes secciones del código que nos ayuda a definir los caminos que se pueden seguir durante la ejecución.
Estas representaciones visuales se conocen como gráficos de flujo de control (CFG) y tienen varios componentes como nodos, bordes, rutas, uniones y puntos de decisión. El gráfico se puede crear de forma manual o automática, donde se utiliza software para extraer el gráfico del código fuente.
Veamos estos componentes a continuación:
# 1) Bloque de proceso
Esta parte se utiliza para representar una sección de código que se ejecuta secuencialmente. Esto significa que se ejecuta de la misma manera cada vez, y no hay decisiones o 'ramificaciones' que se deban tomar. Se compone de nodos con una ruta de entrada y salida.
Ejemplo de un bloque de proceso:
(imagen fuente )
El bloque de proceso no es una parte esencial del flujo de control y, como resultado, solo debe probarse una vez.
# 2) Puntos de decisión
Estos son algunos componentes clave en el flujo de control del código. Dentro de estos nodos, se toman decisiones. Esto generalmente se hace mediante comparación y el flujo de control cambia, dependiendo de la decisión. Esta parte del CFG se compone de un nodo con al menos 2 salidas.
La decisión tomada aquí podría ser declaraciones condicionales como declaraciones if-else (que tienen dos salidas posibles) y declaraciones case (que pueden tener más de dos salidas).
(imagen fuente )
En el diagrama anterior, hay un punto de decisión (del condicional 'edad = 18') seguido de las opciones 'sí' o 'no'.
# 3) Puntos de unión
En el diagrama anterior, podemos identificar fácilmente los puntos de unión en cuanto a dónde se unen los puntos de decisión. Los puntos de unión pueden tener muchas vías de entrada pero solo una vía de salida.
Mejores prácticas de gráficos de flujo de control:
Hay algunas cosas a tener en cuenta al construir gráficos de flujo de control:
- Intente tanto como sea posible para mantener el CFG simple. Podemos hacer esto combinando partes que pueden considerarse 'menos significativas', por ejemplo, bloques de proceso.
- Asegúrese de que en los puntos de decisión solo se tome una decisión. En CFG más complejos, hay 'consecuencias' que vienen después de que se toma la decisión. En nuestro ejemplo anterior, también podríamos agregar que si una persona tiene 18 años o más, entonces es elegible y debe pagar un boleto. Si no es así, la entrada es gratuita. La decisión 'más' debe 'omitir' algunos nodos, y todos esos pasos deben mostrarse en nuestro CFG.
Una vez que hemos definido nuestro CFG, ahora es el momento de pasar al siguiente paso en el proceso de prueba de flujo de control, es decir, definir hasta qué punto vamos a probar el código.
Definición de cuánto probar:
¿Qué parte del código fuente debe probarse? ¿Deberíamos probar todos los caminos posibles? Intentar cubrir todos los caminos en nuestras pruebas es prácticamente imposible. Necesitamos encontrar un término medio para determinar cuántas pruebas podemos hacer.
Si decimos que nuestro objetivo es probar el 50% de nuestro código, entonces esto podría significar que definiremos todas las declaraciones de código ejecutable y apuntaremos a probar al menos la mitad de ellas. Sin embargo, la pregunta que surge aquí es '¿entonces necesitamos definir todas las posibles rutas ejecutables?'
De nuevo, esto puede ser prácticamente imposible. Un mejor enfoque podría apuntar a probar el 50% de las rutas que podemos identificar en cada sección del código.
Hay diferentes niveles de cobertura, a saber, cobertura de declaración, rama y ruta. Los veremos brevemente más adelante.
Creando casos de prueba:
El siguiente paso es crear los casos de prueba que usaremos. Los casos de prueba en las pruebas basadas en estructura se basan en los siguientes factores:
- Las declaraciones ejecutables.
- Las 'decisiones' que deben tomarse.
- Los posibles caminos que se pueden seguir.
- Las condiciones que deben cumplirse (pueden ser múltiples o booleanas).
Los factores anteriores nos dan una idea de los tipos de casos de prueba que necesitamos crear. También podemos utilizar una herramienta de generación de pruebas estructurales. Si nuestro código está en el lenguaje de programación C, podemos usar PathCrawler para generar código de prueba. Otra herramienta que podemos utilizar es fMBT.
Ejecutando los casos de prueba:
Aquí, podemos ejecutar las pruebas. Podemos ingresar entrada o datos para verificar cómo lo ejecuta el código, y luego verificar si obtenemos los resultados esperados. Por ejemplo, ingrese una matriz en una llamada de función para observar los resultados que obtenemos después de recorrerla, o para verificar si los puntos de decisión están tomando las decisiones correctas.
Analizando los resultados:
En esta parte, todo lo que hacemos es verificar si obtenemos los resultados correctos después de la ejecución. Por ejemplo, si ingresamos una matriz donde todos los valores están por encima de 18, entonces deberíamos tener todos los puntos de decisión que resulten en 'elegibles'.
Supuestos de flujo de control
Es importante señalar que para llevar a cabo las pruebas de flujo de control, se hacen algunas suposiciones. Éstos incluyen:
- Los únicos errores presentes son los que pueden afectar el flujo de control.
- Todas las variables, funciones y elementos están definidos con precisión.
Niveles de cobertura en los flujos de control
Como mencionamos anteriormente, existen diferentes niveles de cobertura en las pruebas de flujo de control.
Veámoslos brevemente.
# 1) Cobertura de la declaración
En las pruebas estructurales, las declaraciones de código ejecutable juegan un papel vital cuando se trata de decidir los métodos de diseño de las pruebas.
Nuestro objetivo es lograr una cobertura del 100%, lo que significa que cada declaración ejecutable se ha probado al menos una vez. Cuanto mayor sea la cobertura, menor será la probabilidad de que se pierdan los errores y los errores.
Es necesario utilizar casos de prueba aquí. Los datos que buscamos son para asegurarnos de que cada declaración ejecutable en un bloque de código se ejecute al menos una vez.
# 2) Cobertura de sucursales
Este nivel de cobertura implica probar los puntos en las sucursales de CFG (donde se toman las decisiones). Los resultados son booleanos. Incluso si se usa una instrucción de cambio y hay varios resultados, en esencia, cada bloque de caso es una comparación de un par de valores.
Al igual que con la cobertura de estados de cuenta, debemos apuntar a una cobertura de sucursales del 100%. Para lograr esto, necesitamos probar cada resultado en cada nivel de decisión al menos una vez. Dado que estamos tratando con resultados booleanos, deberíamos apuntar a ejecutar al menos 2 pruebas por sección de código.
# 3) Cobertura de ruta
Este nivel de cobertura es más completo en comparación con la cobertura de decisiones y declaraciones. El objetivo aquí es 'descubrir' todos los caminos posibles y probarlos al menos una vez. Esto puede llevar mucho tiempo. Sin embargo, puede ayudar a descubrir errores o errores en nuestro código, o incluso aspectos que necesitamos definir, por ejemplo, entrada del usuario.
Tipos de pruebas estructurales
(imagen fuente )
Prueba de mutación
La prueba de mutación es una técnica de prueba basada en fallas en la que se prueban varias variaciones de una aplicación de software con el conjunto de datos de prueba.
>> Consulte este tutorial para ver en profundidad Prueba de mutación.
Pruebas basadas en cortes
La prueba basada en cortes (SBT) se puede definir como una técnica de prueba de software que se basa en rodajas - partes ejecutables del programa o grupos de declaraciones que afectan a algunos valores en puntos particulares de interés del programa, por ejemplo, partes donde se definen las variables o la salida de un grupo de declaraciones.
Cómo hacer rebanar
Ejemplo de rebanado en SBT: Código para imprimir números pares e impares (Python)
|_+_| 
Hay dos formas de ver un sector: Siguiendo la ruta de una variable de interés o la parte del código que afecta la salida.
En nuestro ejemplo, si miramos la salida de números impares, podemos rastrear la parte del código que nos lleva a esta salida.
En los criterios de corte dados por Mark Weiser (quien introdujo SBT), un corte se define usando esta fórmula: S (v, n) , dónde, v se refiere a la variable en cuestión ( por ejemplo, donde se define una variable), y norte es la declaración de interés por ejemplo, donde se da la salida), y S representa la rebanada.
En el ejemplo anterior, para obtener el segmento, partimos de nuestra salida en la línea 10, que se convierte en nuestro norte . Nuestra variable es dónde .
Entonces, nuestro criterio de corte es:
|_+_|Nuestra preocupación son las declaraciones que nos llevan a la salida.
Estos son:
10,9,8,4,3,1
Entonces, nuestro segmento en este código es:
|_+_|
Tipos de pruebas basadas en cortes
Hay dos tipos de SBT: estático y dinámico.
# 1) Prueba dinámica basada en cortes
El ejemplo de SBT explicado anteriormente donde observamos las declaraciones que afectan la impresión de los números impares es SBT dinámico. Nuestra preocupación es muy específica. Nos enfocamos solo en lo que afecta directamente a la salida particular.
Ejecutamos el código y usamos datos de prueba para asegurarnos de que funcione como se supone. Podríamos aumentar el rango a rango (1,50), por ejemplo, para ver si todavía genera solo números impares. Dynamic SBT también se conoce como prueba de validación.
# 2) EstáticoPruebas basadas en cortes
A diferencia de Dynamic SBT, las pruebas estáticas se centran en una variable en particular. Si pensamos en nuestra salida en el ejemplo anterior como dónde , podemos rastrear el corte que lo afecta como 10,9,8,7,6,5,4,3,2,1
¡Es básicamente todo el bloque de código! Aquí verificamos que el código sea correcto en cuanto a sintaxis y requisitos, y no lo ejecutamos. El SBT estático también se conoce como prueba de verificación.
Es importante señalar que SBT dinámico es 'más pequeño' en comparación con su contraparte estática. También es más específico.
Mejores prácticas / pautas de pruebas basadas en cortes
Los criterios de corte deben ser determinados por:
- Declaraciones donde los valores se definen o asignan valor, así como valor reasignado.
- Declaraciones donde se reciben valores de fuera del programa, por ejemplo, a través de la entrada del usuario.
- Declaraciones que imprimen salida / devuelven salida.
- La última declaración del programa, por ejemplo, una llamada a función que puede definir valores o proporcionar valores a argumentos
Las ventajas de las pruebas basadas en cortes incluyen:
- Dado que en SBT solo trabajamos con áreas de interés específicas, facilita la generación de conjuntos de pruebas de manera efectiva.
- La ruta está definida por dependencias dentro del código, lo cual es mejor que usar cobertura de ruta.
- Con SBT, es más fácil encontrar errores en el código fuente.
Las desventajas de las pruebas basadas en cortes incluyen:
- Si usamos pruebas dinámicas cuando probamos una base de código grande, necesitaremos muchos recursos computacionales.
- Si usamos pruebas estáticas, podríamos perdernos errores.
Prueba de flujo de datos
Las pruebas de flujo de datos se pueden definir como una técnica de prueba de software que se basa en valores de datos y su uso en un programa. Verifica que los valores de los datos se hayan utilizado correctamente y que generen los resultados correctos. Las pruebas de flujo de datos ayudan a rastrear las dependencias entre los valores de los datos en una ruta de ejecución particular.
Anomalías del flujo de datos
Las anomalías en el flujo de datos son simplemente errores en un programa de software. Se clasifican en los tipos 1, 2 y 3 respectivamente.
Profundicemos en ellos a continuación:
Tipo 1: Se define una variable y se le asigna un valor dos veces.
Código de ejemplo: Python
|_+_| 
Lst_1 está definido y se le asignan dos valores diferentes. El primer valor simplemente se ignora. Las anomalías de tipo 1 no hacen que el programa falle.
Tipo 2: El valor de una variable se usa o se hace referencia a ella antes de definirla.
Código de ejemplo: Python
|_+_| 
El ciclo anterior no tiene valores para iterar. Las anomalías de tipo 2 hacen que el programa falle.
Tipo 3: A Se genera un valor de datos, pero nunca se utiliza.
Código de ejemplo: Python
|_+_| 
La variable lst_2 no se ha hecho referencia. Las anomalías de tipo 3 pueden no provocar fallos en el programa.
Proceso de prueba de flujo de datos
Para definir las dependencias entre los valores de los datos, necesitamos definir las diferentes rutas que se pueden seguir en un programa. Para hacer esto de manera efectiva, necesitamos tomar prestado de otro tipo de prueba estructural conocido como prueba de flujo de control .
Paso 1) Dibujar un gráfico de flujo de control
Necesitamos dibujar un diagrama de flujo de control, que es una representación gráfica de las rutas que podríamos seguir en nuestro programa.
Código de ejemplo: Python
|_+_| 
En el ejemplo de código anterior, un miembro debería obtener un descuento si invita a un visitante.
Gráfico de flujo de control (CFG):
Paso 2) Explore la definición y el uso de variables y valores de datos.
Una variable en un programa se define o se utiliza. En CFG, tenemos variables en cada nodo. Cada nodo recibe un nombre según el tipo de variable que alberga. Si una variable se define en un nodo en particular, crea un nodo de definición. Si se usa una variable en un nodo, crea un nodo de uso.
Si consideramos el costo variable en CFG, estos son los nodos de definición y uso:
| Nodo | Escribe | Código |
|---|---|---|
| 1 | Definición de nodo | costo = 20 |
| 5 | Nodo de uso | factura = costo -1 |
| 7 | Nodo de uso | factura = costo |
Paso 3) Defina rutas de uso de definiciones.
Hay dos tipos de rutas de uso de definiciones: du senderos y dc senderos. Las rutas du son rutas de definición que comienzan con un nodo de definición y terminan con un nodo de uso. Este es el caso de la ruta en referencia al costo variable anterior.
Un ejemplo de una ruta de CC, una ruta de decisión clara, es la ruta con respecto a la variable de factura como se muestra a continuación:
| Nodo | Escribe | Código |
|---|---|---|
| 5 | Definición de nodo | factura = costo -1 |
| 7 | Definición de nodo | factura = costo |
| 8 | Nodo de uso | imprimir (factura) |
La ruta dc tiene más de un nodo de definición aunque todavía termina en un nodo de uso.
Paso 4) Cree la suite de pruebas.
Esto está agregando entrada. Tenga en cuenta que necesitamos tener un conjunto de pruebas diferente para cada variable. La suite de pruebas nos ayudará a identificar anomalías en el flujo de datos.
Tipos de pruebas de flujo de datos
Hay dos tipos - Estático y dinámico .
Estático significa que revisamos el código y CFG para identificar anomalías en los datos, sin ejecutarlo. Dinámico significa que realmente identificamos las rutas específicas y luego creamos conjuntos de pruebas para probarlas en un intento por 'detectar' anomalías que pueden haber pasado por alto durante las pruebas estáticas.
Ventajas y desventajas de las pruebas de flujo de datos:
- Las pruebas de flujo de datos son ideales para identificar anomalías en el flujo de datos, lo que las convierte en un método de prueba estructural muy eficaz.
- Su desventaja es que es necesario estar bien versado en el lenguaje utilizado para escribir el código para utilizar las pruebas de flujo de datos. También lleva mucho tiempo.
Ventajas y desventajas de las pruebas estructurales
Busquemos ahora las razones por las que las pruebas estructurales son un gran enfoque y exploremos también algunas de sus desventajas.
Ventajas:
- Permite pruebas de código exhaustivas, lo que resulta en errores mínimos. Las pruebas basadas en estructuras dan espacio para que el software se pruebe a fondo. Los diferentes niveles de cobertura, declaración por declaración, cada punto de decisión y ruta, apuntan a lograr una cobertura del 100%, lo que reduce en gran medida las posibilidades de que los errores pasen desapercibidos.
- La capacidad de automatizar . Hay varias herramientas que podemos utilizar para automatizar las pruebas. Esto nos ayudará a lograr la máxima cobertura de código y en un tiempo más corto en comparación con hacer las pruebas manualmente.
- Da como resultado un código de mayor calidad . Los desarrolladores tienen la oportunidad de estudiar la estructura y la implementación del código y corregir cualquier error, así como mejorar estos aspectos. Nos permite tener en cuenta la gran estructura a medida que escribimos las siguientes partes del código o implementamos las funciones restantes.
- Se puede hacer a través de cada fase del SDLC. - Las pruebas estructurales se pueden realizar en cada fase del SDLC sin esperar a que el desarrollo se complete al 100%. Esto facilita la identificación de errores en la fase inicial y, por lo tanto, ahorra mucho tiempo en comparación con las pruebas una vez finalizado el desarrollo.
- Ayuda a deshacerse del código muerto . Esto puede verse como un código 'adicional' o innecesario, por ejemplo, código que calculará un resultado pero nunca lo usará en ninguno de los siguientes cálculos.
- Eficiencia - Dado que los desarrolladores que escriben el código son los mismos que lo prueban, no es necesario involucrar a otras personas como QA.
Desventajas:
- Los desarrolladores que realizan pruebas basadas en estructuras deben tener un conocimiento profundo del lenguaje . Otros desarrolladores y QA que no estén bien versados en el idioma no pueden ayudar con las pruebas.
- Puede resultar bastante caro en términos de tiempo y dinero . Se requiere mucho tiempo y recursos para realizar pruebas de manera eficiente.
- Provoca retrasos en la entrega de funciones . Esto se debe a que los desarrolladores se ven obligados a dejar de crear software para realizar pruebas.
- La escala es un problema, especialmente cuando se trata de grandes aplicaciones . Una aplicación grande equivale a un número excesivamente alto de rutas por cubrir. Alcanzar una cobertura del 100% se vuelve imposible.
- Puede haber casos y rutas perdidas , por ejemplo, en un caso en el que las características no estén completamente desarrolladas o aún no se hayan desarrollado. Esto significa que debe combinarse con otros tipos de pruebas como, pruebas de requisitos (donde verificamos las características especificadas que debían construirse).
Mejores prácticas de pruebas estructurales
Algunos de los factores que requieren atención al realizar pruebas basadas en estructuras son los siguientes:
- Etiquetar y nombrar claramente las pruebas . Si alguien más necesita ejecutar las pruebas, debe poder ubicarlas fácilmente.
- Antes de mejorar el código, es decir, refactorizarlo y optimizarlo para su uso en diferentes entornos, asegúrese de que su estructura y flujo sean ideales.
- Ejecutar pruebas por separado . De esta forma, es fácil identificar errores y corregirlos. Por otro lado, es menos probable que pasemos por alto errores o rutas como resultado de superposiciones en secciones de código, bloques o rutas.
- Genere pruebas antes de realizar cambios . Se requiere que las pruebas se ejecuten como se esperaba. De esta manera, si algo se rompe, es fácil rastrear y solucionar el problema.
- Mantenga las pruebas para cada sección o bloque de código por separado . De esta forma, si hay cambios en el futuro, no necesitamos cambiar muchas pruebas.
- Corrija errores antes de continuar con las pruebas . Si identificamos algún error, es mejor que lo solucionemos antes de proceder a probar la siguiente sección o bloque de código.
- Nunca omita las pruebas estructurales con la suposición de que un control de calidad 'seguirá realizando pruebas de todos modos'. Incluso si los errores pueden parecer insignificantes al principio, acumulativamente, pueden resultar en un código defectuoso que nunca podrá lograr su propósito previsto.
Preguntas frecuentes sobre pruebas basadas en estructuras
Aquí exploraremos las preguntas más frecuentes cuando se trata de pruebas basadas en estructuras.
P # 1) ¿Cuál es la diferencia entre las pruebas funcionales y las pruebas estructurales?
Responder: La prueba funcional es un tipo de prueba de software que se basa en los requisitos estipulados en las SRS (Especificaciones de requisitos de software). Por lo general, se hace en un intento por encontrar disparidades entre las especificaciones del SRS y cómo funciona el código. Las pruebas estructurales se basan en la estructura interna del código y su implementación. Se requiere una comprensión profunda del código.
P # 2) ¿Cuáles son los tipos de pruebas estructurales?
Responder a la los tipos incluyen:
- Prueba de flujo de datos
- Prueba de mutación
- Prueba de flujo de control
- Pruebas basadas en cortes
P # 3) ¿Qué es un ejemplo de prueba estructural?
Respuesta: Aquí hay un ejemplo que muestra la cobertura del estado de cuenta:
|_+_|La cantidad de cobertura que obtenemos depende de los datos de prueba que proporcionamos como entrada (si cumple con las condiciones de suma> 0).
P # 4) ¿Cuál es la diferencia entre las pruebas de flujo de datos y las pruebas de flujo de control?
Responder: Tanto las pruebas de flujo de datos como las pruebas de flujo de control utilizan gráficos de flujo de control. La única diferencia es que en las pruebas de flujo de control, nos centramos en las rutas generadas a partir del código, mientras que en las pruebas de flujo de datos, nos centramos en los valores de los datos, su definición y uso dentro de las rutas identificadas dentro de un programa.
P # 5) ¿Para qué se utilizan las pruebas de flujo de datos?
Responder: Las pruebas de flujo de datos son ideales para identificar anomalías en el uso de valores de datos dentro de las rutas en un gráfico de flujo de control. por ejemplo, una variable a la que se le ha asignado valor dos veces, una variable que se ha definido y no se ha utilizado, o una variable que se ha utilizado o referenciado y no se ha definido.
P # 6) ¿Cuál es la diferencia entre cortar y cortar en cubitos en las pruebas de software?
Responder: Cortar significa centrarse en declaraciones particulares de interés en un programa e ignorar el resto. Cortar en cubos es cuando identificamos un segmento que tiene una entrada incorrecta y luego lo cortamos aún más para rastrear el comportamiento correcto.
P # 7) ¿Cuál es la diferencia entre las pruebas de mutación y la cobertura del código?
Responder: En las pruebas de mutación, consideramos el número de mutantes muertos como porcentaje del total de mutantes. La cobertura de código es simplemente la cantidad de código que se ha probado en un programa.
Conclusión
En este tutorial, analizamos las pruebas estructurales en profundidad: qué es, qué no es, cómo hacerlo, tipos de cobertura, ventajas y desventajas, mejores prácticas e incluso algunas preguntas frecuentes sobre este tipo de prueba de software.
Todavía hay mucho más que podemos aprender sobre las pruebas basadas en estructuras. En futuros tutoriales, exploraremos la cobertura de código (declaración, decisión, rama y ruta), tipos de pruebas estructurales (mutación, flujo de datos y basado en cortes) e incluso las herramientas que podemos usar para automatizar estos procesos de prueba.
Es importante tener en cuenta que no existe ningún tipo o enfoque de prueba de software que sea 100% eficiente. Siempre es recomendable combinar diferentes tipos y enfoques de prueba.
Por ejemplo, Las pruebas estructurales se complementan en gran medida con las pruebas de requisitos, ya que puede haber características que no se hayan desarrollado en el momento en que se estaban llevando a cabo las pruebas basadas en estructuras.
Las técnicas de prueba estructural se basan en los errores que cometen los programadores humanos al escribir código. La suposición es que el programador es un experto y sabe lo que está codificando, pero se equivoca de vez en cuando.
Los diferentes tipos de pruebas estructurales que hemos analizado: las pruebas de mutación, las pruebas basadas en cortes y las pruebas de flujo de datos pueden atribuirse a errores como el uso del operador incorrecto (prueba de mutación) o hacer referencia a una variable antes de usarla (prueba de flujo de datos) .
Lectura recomendada
- Tutorial de pruebas destructivas y no destructivas
- Pruebas funcionales versus pruebas no funcionales
- ¿Qué es la técnica de prueba basada en defectos?
- Tutorial de prueba de remojo: ¿Qué es la prueba de remojo?
- Tutorial de pruebas SOA: metodología de prueba para un modelo de arquitectura SOA
- Pruebas de carga con los tutoriales de HP LoadRunner
- ¿Qué es la prueba gamma? La etapa de prueba final
- Tutorial de pruebas de DevOps: ¿Cómo afectará DevOps a las pruebas de control de calidad?
- ¿Qué son las pruebas de conformidad (pruebas de conformidad)?