1. TÉCNICAS DE PRUEBAS
1.1. PRUEBAS ESTÁTICAS
1.1.1. Pueden referirse a la revisión de la documentación, ya que no hace alusión a la ejecución del código. Así mismo permiten detectar causas, que posea algún defecto dentro de la prueba.
1.1.2. El análisis estático, es otro ítem importante dentro de estas pruebas, ya que, contribuyen la detección tempranas de anomalías compuestas en el diseño o el código.
1.1.3. La revisión en las pruebas estáticas, consideran la corrección de desviaciones de estándares, defectos de diseño, interfaz y requisitos, posibilitando la reducción de costos y tiempo.
1.1.3.1. Revisión Informal
1.1.3.1.1. Es una revisión que por lo general no esta documentada careciendo de instrucciones inscritas´y es una revisión que se lleva acabo por el líder técnico.
1.1.3.2. Revisión Guiada
1.1.3.2.1. Presenta dos tipos de características, Formal e Informal y su función es encontrar deficiencias, concluyendo con un entendimiento común.
1.1.3.3. Revisión Inspeccionada
1.1.3.3.1. Es una revisión rigurosa y formal, donde se destaca y registra defectos del producto, tanto en estándares como en especificaciones. Es ta revisión involucra a un Revisor que esta determinado a identificar anomalías, el Escriba que realiza actas y puede sugerir mejoras, y el Moderador que intercede con los distintos puntos de vistas.
1.1.3.4. Revisión Tecnica
1.1.3.4.1. Es una actividad de debates por grupos, el cual se enfoca en lograr un consenso, acerca del método técnico, alternativas, decisiones, que se deban tomar.
1.1.3.5. Revisión Walkthought
1.1.3.5.1. Es una revisión conducida únicamente por miembros del grupo de desarrollo, que tiene como fin examinar una parte especifica del producto.
1.2. PRUEBAS DINÁMICAS
1.2.1. Son pruebas que implican la ejecución del software, componente o sistema. Comúnmente es donde recae la mayoría de pruebas.
1.2.1.1. UNIDAD
1.2.1.1.1. Aplicado a unidades individuales o a grupos relacionado con hardware y software
1.2.1.2. SISTEMA
1.2.1.2.1. Se realiza la prueba a todo un sistema completo e integrado, para evaluar los requisitos especificados y su conformidad.
1.2.1.3. INTEGRACIÓN
1.2.1.3.1. Se prueba la interacción entre el software y hardware, y así mismo se evalúa la combinación entre los ellos.
1.2.1.4. ACEPTACIÓN
1.2.1.4.1. Es una prueba que determina si el sistema responde a los criterios de aceptación, de forma que el cliente determine su aceptación.
1.2.1.5. REGRESIÓN
1.2.1.5.1. A partir de modificaciones realizadas, las pruebas de regresión originan una reejecución selectiva, ya sea de un componente o todo el sistema, para verificar que no se presenten anomalías y si los requerimientos establecidos, todavía se cumplen.
2. PRUEBAS UNITARIAS
2.1. CAJA BLANCA
2.1.1. Se dispone de código fuente y se intenta analizar tantos fragmentos como sean posibles. En a priori se puede pensar que tan viable es la verificación de la totalidad de caminos alternativos del código, pero realmente esto no es posible. Pero si es posible al menos verificar los camino independientes.
2.2. PRUEBAS DE FLUJO DE DATOS
2.2.1. Es un método complejo, el cual requiere que cada variable y segmento sean verificables desde su trayectoria de control, hasta su ejecución final.
2.3. PRUEBAS DE BIFURCACIÓN
2.3.1. Satisface los criterios de cobertura, que requiere cada punto de decisión. Es decir, define si algún bucle esta correctamente implementado y si esa condición es la mejor opción, o debería ser cambiada.
2.4. PRUEBAS DE CAMINOS BÁSICOS
2.4.1. Es una prueba que determina los conjuntos de pasos base del programa. Con esta prueba se intenta garantizar, que se prueben todos los caminos de ejecución del programa, al menos una vez.
2.4.1.1. Grafo de flujo
2.4.1.1.1. Es una representación de los caminos que puede tomar un programa durante su ejecución. Posee tres características importantes, uno de ellos son los NODOS: representan una o mas instrucciones, dos ARISTAS: interpretan el flujo de control y tres REGIONES: son áreas acotadas por los nodos y las aristas.
2.4.1.2. Programa independiente
2.4.1.2.1. El programa independiente, es cualquier comienzo de una nueva condición en el programa o una nueva linea de instrucciones.
2.4.1.3. Complejidad ciclomática
2.4.1.3.1. Permite definir el número de caminos independientes del camino básico de un sistema y posibilita saber el número de pruebas a realizar.
2.4.1.4. Cobertura de Sentencias
2.4.1.4.1. Se efectúa con los casos de prueba, cada sentencia e instrucción al menos una vez.
2.4.1.5. Cobertura de decisiones
2.4.1.5.1. Se debe dar, que para cada condición al menos tenga un resultado verdadero y otro falso.
2.4.1.6. Criterio de condición múltiple
2.4.1.6.1. Si se tiene decisiones multicondicionales se descomponen en decisiones unicondicionales, ejecutando todas las combinaciones posibles de resultados, EJEMPLO: las decisión multicondicional x>y && x>z y la decisión unicondicional z >y.
2.5. PRUEBAS DE FLUJO DE CONTROL
2.5.1. Se analizan todos lo bucles y sentencias en un programa de combinaciones especificadas.
3. COMPORTAMIENTO O PRUEBAS DE CAJA NEGRA
3.1. PARTICIÓN DE EQUIVALENCIAS
3.1.1. Es una prueba que posee la porción del dominio de una entrada o una salida, la cual se asume que el comportamiento de un componente dentro del sistema, respecto a su especificación, sean el mismo. Existe dos pasos en la partición de pruebas, el primero es IDENTIFICAR LAS EQUIVALENCIAS, que identifica 2 tipos de clases, invalidas y validas. Y el segundo es la DEFINICIÓN DE LOS CASOS DE PRUEBA, que se forma a partir de un dato de entrada y salida.
3.2. ANÁLISIS DE VALORES LIMITES
3.2.1. Los valores limites, son aquellos que se hayan en las margenes de las clases de equivalencias, con los datos de entradas y salidas. Por tanto, es una técnica que ayuda a seleccionar, los casos de pruebas que encamine a los valores limites. De igual manera, es una técnica que reduce los números de pruebas que se deben crear y ejecutar.
3.3. PRUEBAS DE TRANSICIÓN DE ESTADOS
3.3.1. Esta técnica se basa en el comportamiento dependiente del tiempo de un sistema. De manera que es una prueba que evidencia los procederes de transición de estados, analizando los cambios de estados, validos e inválidos.
3.4. TABLAS DE DECISIÓN
3.5. PRUEBAS DE CASO DE USO
3.5.1. Una prueba de caso de uso, detalla a fondo un sistema incluyendo, todas funciones que experimenta el programa al ejecutarse. Este tipo de prueba, debe cubrir todo tipo de datos de entrada y salida, cada clase de defecto, su comportamiento y la integridad de los elementos de diseño.
4. PRUEBAS DE ACEPTACIÓN
4.1. PRUEBAS ALFA
4.1.1. Pueden ejecutarse por usuarios o clientes potenciales, en lugar de los desarrolladores del sistema. Normalmente de efectúa de forma interna en las pruebas de aceptación.
4.2. PRUEBAS BETA
4.2.1. Se puede ejecutar cuando existe una avanzada versión, total o parcial del sistema disponible para usuarios o testers. Se puede utilizar deliberadamente, con el objetivo de reportar errores si es el caso.