Técnicas de prueba de software

Las técnicas de prueba de software son las formas empleadas para probar la aplicación bajo prueba contra los requisitos funcionales o no funcionales recopilados del negocio. Cada técnica de prueba ayuda a encontrar un tipo específico de defecto . Por ejemplo, es posible que las técnicas que pueden encontrar defectos estructurales no puedan encontrar los defectos en el flujo comercial de un extremo a otro. Por lo tanto, se aplican múltiples técnicas de prueba en un proyecto de prueba para concluirlo con una calidad aceptable. 

Principios de prueba

A continuación se presentan los principios de las pruebas de software:

1. Todas las pruebas deben cumplir con los requisitos del cliente.
2. Para que nuestro software las pruebas deben ser realizadas por un tercero
3. Las pruebas exhaustivas no son posibles. Como necesitamos la cantidad óptima de pruebas en función de la evaluación de riesgos de la aplicación.
4. Toda la prueba a realizar debe ser planificada antes de implementarla
5. Sigue la regla de Pareto (regla 80/20) que establece que el 80% de los errores provienen del 20% de los componentes del programa.
6. Comience a probar con piezas pequeñas y extiéndalo a piezas grandes.

Tipos de técnicas de prueba de software

Hay dos categorías principales de técnicas de prueba de software:

1. Las técnicas de prueba estática son técnicas de prueba que se utilizan para encontrar defectos en la aplicación bajo prueba sinejecutando el código. Las pruebas estáticas se realizan para evitar errores en una etapa temprana del ciclo de desarrollo y, por lo tanto, reducir el costo de corregirlos.
2. Las técnicas de prueba dinámica son técnicas de prueba que se utilizan para probar el comportamiento dinámico de la aplicación bajo prueba, es decir, mediante la ejecución del código base. El objetivo principal de las pruebas dinámicas es probar la aplicación con entradas dinámicas, algunas de las cuales pueden permitirse según los requisitos (pruebas positivas) y otras no (pruebas negativas).

Cada técnica de prueba tiene otros tipos, como se muestra en el siguiente diagrama. Cada uno de ellos se explicará en detalle con ejemplos a continuación.

Técnicas de prueba estática

Como se explicó anteriormente, las técnicas de pruebas estáticas son técnicas de prueba que no requieren la ejecución de un código base. Las técnicas de prueba estática se dividen en dos categorías principales:

1. Revisiones : pueden variar desde revisiones por pares puramente informales entre dos desarrolladores/probadores sobre los artefactos (código/casos de prueba/datos de prueba) hasta inspecciones totalmente formales dirigidas por moderadores que pueden ser internos/externos a la organización.
   1. Revisiones por pares : las revisiones informales generalmente se llevan a cabo sin ninguna configuración formal. Es entre pares. Por ejemplo, dos desarrolladores/evaluadores revisan los artefactos de cada uno, como código/casos de prueba.
   2. Recorridos : Recorrido es una categoría en la que el autor del trabajo (código o caso de prueba o documento en revisión) recorre lo que ha hecho y la lógica detrás de esto para las partes interesadas para lograr un entendimiento común o con la intención de recibir comentarios.
   3. Revisión técnica : Es una reunión de revisión que se enfoca únicamente en los aspectos técnicos del documento bajo revisión para lograr un consenso. Tiene menos o ningún enfoque en la identificación de defectos basados ​​en documentación de referencia. Se requieren expertos técnicos como arquitectos/jefes de diseño para realizar la revisión. Puede variar de informal a completamente formal.
   4. Inspección : La inspección es la categoría más formal de revisiones. Antes de la inspección, el documento bajo revisión se prepara minuciosamente antes de ir a una inspección. Los defectos que se identifican en la reunión de inspección se registran en la herramienta de gestión de defectos y se les da seguimiento hasta el cierre. Se evita la discusión sobre los defectos y se utiliza una fase de discusión separada para las discusiones, lo que hace que las Inspecciones sean una forma muy efectiva de revisión.
2. Análisis estático : el análisis estático es un examen de requisito/código o diseño con el objetivo de identificar defectos que pueden o no causar fallas. Por ejemplo, revisar el código para los siguientes estándares. No seguir un estándar es un defecto que puede o no causar una falla. Hay muchas herramientas para el análisis estático que los desarrolladores utilizan principalmente antes o durante las pruebas de componentes o de integración. Incluso Compiler es una herramienta de análisis estático, ya que señala el uso incorrecto de la sintaxis y no ejecuta el código per se. Hay varios aspectos en la estructura del código: flujo de datos, flujo de control y estructura de datos.
   1. Flujo de datos : significa cómo se sigue el rastro de datos en un programa determinado: cómo se accede a los datos y cómo se modifican según las instrucciones del programa. Mediante el análisis de flujo de datos, puede identificar defectos como una definición de variable que nunca se usó.
   2. Flujo de control : es la estructura de cómo se ejecutan las instrucciones del programa, es decir, condiciones, iteraciones o bucles. El análisis de flujo de control ayuda a identificar defectos como el código muerto, es decir, un código que nunca se usa bajo ninguna condición.
   3. Estructura de datos : se refiere a la organización de datos independientemente del código. La complejidad de las estructuras de datos se suma a la complejidad del código. Por lo tanto, proporciona información sobre cómo probar el flujo de control y el flujo de datos en un código determinado.

Técnicas de prueba dinámica

Las técnicas dinámicas se subdividen en tres categorías:

1. Pruebas basadas en la estructura:

Estas también se llaman técnicas de caja blanca . Las técnicas de prueba basadas en la estructura se centran en cómo funciona la estructura del código y se prueban en consecuencia. Para comprender las técnicas basadas en estructuras, primero debemos comprender el concepto de cobertura de código. 

La Cobertura de Código normalmente se realiza en Pruebas de Componentes e Integración . Establece qué código está cubierto por técnicas de pruebas estructurales del código total escrito. Un inconveniente de la cobertura de código es que no habla de código que no se ha escrito en absoluto (requisito perdido). Hay herramientas en el mercado que pueden ayudar a medir la cobertura de código. 

Hay varias formas de probar la cobertura del código:

1. Cobertura de declaraciones: Número de declaraciones de código ejercidas/Número total de declaraciones. Por ejemplo, si un segmento de código tiene 10 líneas y la prueba diseñada por usted cubre solo 5 de ellas, entonces podemos decir que la cobertura de declaración dada por la prueba es del 50%.

2. Cobertura de decisiones: Número de resultados de decisiones ejercidos/Número total de Decisiones. Por ejemplo, si un segmento de código tiene 4 decisiones (condiciones If) y su prueba ejecuta solo 1, entonces la cobertura de decisión es del 25%

3. Cobertura de condición condicional/múltiple: Tiene como objetivo identificar que cada resultado de cada condición lógica en un programa ha sido ejercido. 

2. Técnicas basadas en la experiencia:

Estas son técnicas para ejecutar actividades de prueba con la ayuda de la experiencia adquirida a lo largo de los años. La habilidad de dominio y los antecedentes son los principales contribuyentes a este tipo de prueba. Estas técnicas se utilizan principalmente para pruebas de UAT/usuario empresarial . Estos funcionan sobre técnicas estructuradas como las basadas en especificaciones y basadas en estructuras, y las complementa. Estos son los tipos de técnicas basadas en la experiencia:

1. Adivinación de errores : lo utiliza un probador que tiene muy buena experiencia en pruebas o con la aplicación bajo prueba y, por lo tanto, puede saber dónde un sistema podría tener una debilidad. No puede ser una técnica eficaz cuando se usa de forma independiente, pero es realmente útil cuando se usa junto con técnicas estructuradas.

2. Pruebas exploratorias : son pruebas prácticas en las que el objetivo es tener la máxima cobertura de ejecución con una planificación mínima. El diseño y la ejecución de la prueba se llevan a cabo en paralelo sin documentar los pasos del diseño de la prueba. El aspecto clave de este tipo de prueba es el aprendizaje del probador sobre las fortalezas y debilidades de una aplicación bajo prueba. Similar a la adivinación de errores, se usa junto con otras técnicas formales para ser útil.

3. Técnicas basadas en especificaciones:

Esto incluye tanto técnicas funcionales como no funcionales (es decir, características de calidad). Básicamente significa crear y ejecutar pruebas basadas en especificaciones funcionales o no funcionales del negocio. Su atención se centra en la identificación de los defectos correspondientes a las especificaciones dadas. Estos son los tipos de técnicas basadas en especificaciones:

1. Partición de equivalencia : generalmente se usa en conjunto y se puede aplicar a cualquier nivel de prueba. La idea es dividir el rango de entrada de datos en secciones válidas y no válidas, de modo que una partición se considere «equivalente». Una vez que tenemos las particiones identificadas, solo requiere que probemos con cualquier valor en una partición dada, asumiendo que todos los valores en la partición se comportarán de la misma manera. Por ejemplo, si el campo de entrada toma el valor entre 1 y 999, entonces los valores entre 1 y 999 producirán resultados similares, y NO necesitamos probar con cada valor para que la prueba se complete.

2. Análisis de valor límite (BVA) : este análisis prueba los límites del rango, tanto válido como no válido. En el ejemplo anterior, 0,1,999 y 1000 son límites que se pueden probar. El razonamiento detrás de este tipo de prueba es que, en la mayoría de los casos, los límites no se manejan correctamente en el código. 

3. Tablas de decisión : son una buena manera de probar la combinación de entradas. También se le llama tabla de Causa-Efecto . En lenguaje sencillo, se pueden estructurar las condiciones aplicables para el segmento de aplicación bajo prueba como una tabla e identificar los resultados contra cada uno de ellos para llegar a una prueba efectiva. 

1. Hay que tener en cuenta que no hay demasiadas combinaciones, por lo que la tabla se vuelve demasiado grande para ser efectiva.
2. Tome un ejemplo de una tarjeta de crédito que se emite si se cumplen tanto el puntaje de crédito como el límite de salario. Esto se puede ilustrar en la siguiente tabla de decisiones:

4. Pruebas basadas en casos de uso : esta técnica nos ayuda a identificar casos de prueba que ejecutan el sistema como un todo, como un usuario real (Actor) , transacción por transacción. Los casos de uso son una secuencia de pasos que describen la interacción entre el actor y el sistema. Siempre se definen en el lenguaje del Actor, no del sistema. Esta prueba es más efectiva para identificar los defectos de integración. El caso de uso también define las condiciones previas y posteriores del flujo del proceso. El ejemplo de un cajero automático se puede probar mediante un caso de uso:

5. Pruebas de transición de estado : se utiliza cuando una aplicación que se está probando o una parte de ella puede tratarse como FSM o máquina de estados finitos. Continuando con el ejemplo ATM simplificado anterior, podemos decir que el flujo ATM tiene estados finitos y, por lo tanto, puede probarse con la técnica de transición de estado. Hay 4 cosas básicas a considerar: 

1. Estados que un sistema puede lograr
2. Eventos que provocan el cambio de estado
3. La transición de un estado a otro
4. Resultados del cambio de estado

Se puede crear una tabla de pares de eventos de estado para derivar condiciones de prueba, tanto positivas como negativas.