1. Proceso de desarrollo de pruebas
1.1. El desarrollo o la especificación de las pruebas que deben ser ejecutadas pueden llevarse a cabo en una secuencia sistemática de fases.
1.1.1. Cronología de las pruebas
1.1.1.1. Análisis de riesgos de calidad Identifica y evalúa los riesgos asociados a la calidad del software.
1.1.1.2. Diseño de pruebas de alto nivel etapa en la que se planifican las pruebas que se llevarán a cabo para validar y verificar el correcto funcionamiento de un software. Se crea en paralelo con el diseño del sistema
1.1.1.3. Diseño de pruebas de bajo nivel Se planifican las pruebas que se llevarán a cabo para validar y verificar el correcto funcionamiento de componentes o módulos individuales del software
1.1.2. Técnicas para analizar los riesgos de calidad
1.1.2.1. Informal Empezar con las categorías de riesgos de calidad clásicas
1.1.2.2. ISO9126 Empezar con las seis principales características de calidad.
1.1.2.3. Análisis del modo de falla y efecto Empezar con categorías, características o subsistemas.
2. Categorías de las técnicas de diseños de pruebas
2.1. Pruebas basadas en la especificación
2.1.1. Ejemplos de pruebas basadas en la especificación incluyen: 1 Partición de equivalencia y análisis de valores limite 2 Diagramas de transición de estados 3 Tablas de decisión.
2.2. Pruebas basadas en la estructura
2.2.1. Ejemplos de pruebas basadas en la estructura incluyen: 1Cobertura de sentencias 2 Coberturas de ramas o decisión.
3. Técnicas basadas en la especificación
3.1. Tablas de decisión
3.1.1. Para diseñar pruebas utilizando tablas de decisión, se deben seguir los siguientes pasos: Identificar las condiciones que se evalúan para tomar la decisión. Identificar las posibles acciones que el sistema puede tomar en función de las condiciones evaluadas. Definir las reglas lógicas que relacionan las condiciones y las acciones. Crear una tabla de decisión que represente todas las combinaciones posibles de entradas y resultados esperados. Diseñar casos de prueba que cubran todas las combinaciones de la tabla de decisión.
3.2. Diagramas de trancisión
3.2.1. Para diseñar pruebas utilizando diagramas de transición de estados, se deben seguir los siguientes pasos: Identificar los estados en los que puede estar el sistema. Identificar los eventos o acciones que causan una transición entre estados. Definir las condiciones que deben ser verdaderas para que una transición se produzca. Crear un diagrama de transición de estados que represente todos los posibles estados del sistema y las transiciones entre ellos. Diseñar casos de prueba que cubran todas las transiciones posibles y las condiciones que las activan.
4. Técnicas basadas en la estructura
4.1. La complejidad ciclomática se define como el número de caminos independientes que existen en un grafo de control de flujo del programa. El grafo de control de flujo representa la estructura de control de un programa de software en términos de nodos y aristas.
4.1.1. La complejidad ciclomática se puede calcular utilizando la fórmula: M = E - N + 2P
4.1.1.1. Donde: M es la complejidad ciclomática. E es el número de aristas en el grafo de control de flujo. N es el número de nodos en el grafo de control de flujo. P es el número de componentes conectados en el grafo de control de flujo.
5. Técnicas basadas en la experiencia
5.1. Lista de comprobación
5.1.1. Es tal vez lo más simple de las guías, en la cual se incluirán descripciones cortas de las áreas de dos a cinco palabras, las características de calidad y los rasgos para probar.
5.2. Taxonomía
5.2.1. Es una guía más complicada. Una taxonomía es una jerarquía de defectos clasificada por tipo, subtipo, y así sucesivamente. Luego intentará de encontrar defectos que son descubiertos en la taxonomía.
5.3. Lista de ataques
5.3.1. En la lista de ataques, no tiene solamente defectos metas que está buscando, sino también procedimientos de pruebas de alto nivel para descubrir esos defectos. Los ejemplos más famosos de esta técnica son los de James Whittaker’s How to Break Software and How to Break Software Security.