Please enable JavaScript.
Coggle requires JavaScript to display documents.
Técnicas de verificación y validación de software - Coggle Diagram
Técnicas de verificación y validación de software
Metodos Estaticos
Implican procesos de revisión
Walkthroughs
Un participante narra la descripción del software y el grupo da comentarios (Revisión en grupos).
Ventajas: :check:
Colaborativo y formalidad de bajo nivel.
Fomento de la comunicación y detección temprana de errores.
Desventajas: :warning:
La calidad de revisión dependerá del presentador.
Cobertura de información limitada.
Fase de diseño y código en el CVDS.
Método de verificación. :construction:
Métodos de verificación en la verificación del Software
Code inspections
Método de verificación. :construction:
Se revisa el código fuente para detectar defectos, siguiendo un proceso estructurado
Ventajas: :check:
Garantiza estándares y consistencia.
Reducción de deuda técnica a largo plazo
Desventajas: :warning:
Dependencia de habilidades del revisor.
Resistencia del equipo de desarrollo (pensar que es una evaluación de competencias).
Fase de implementación en el CVDS.
Reviews
Evaluar la calidad y cumplimiento de los documentos de especificación, diseño y otros artefactos.
Ventajas: :check:
Consistencia en los artefactos.
Detecta el cumplimiento de los documentos de especificación con el equipo.
Desventajas: :warning:
Retroalimentación percibida como conflictos.
Limitación en la cobertura de revisión.
Método general de verificación :building_construction:
Fases antes de la implementación del CVDS.
Software Review - Software Engineering
Formal proofs
Asegurar que el software cumpla estrictamente con sus especificaciones utilizando métodos matemáticos.
Ventajas: :check: - Alta precisión de especificaciones.
Desventajas: :red_flag:
Complejidad y alto costo.
Limitado a sistemas pequeños.
Difícil de interpretar para no especialistas.
Prueba formal
Método de verificación :construction:
Fases de especificación (análisis) y diseño del CVDS.
Aplicable a todos los niveles
Metodos dinamicos
White box
Se enfoca en evaluar la estructura interna del código. Al realizar estas pruebas, el probador necesita tener conocimiento del código fuente, los algoritmos y la lógica implementada en el sistema
Cause-Effect Graphing
Es útil en escenarios donde existen múltiples condiciones de entrada que influyen en la salida, permitiendo identificar qué combinaciones de entradas podrían causar errores
Identifica las posibles relaciones entre las causas y los efectos en una función o módulo. Se utiliza para visualizar y analizar las combinaciones posibles de entradas que deberían producir salidas específicas.
:check:Ayuda a reducir el número de casos de prueba necesarios al enfocarse en los casos más relevantes y complejos.
:red_cross:Puede ser complicado y laborioso construir el gráfico de causa-efecto, especialmente en sistemas con muchas entradas y salidas.
:red_cross:Requiere un análisis detallado de las combinaciones de entradas, lo que puede hacer que el proceso sea lento y difícil de mantener.
:red_cross:No siempre garantiza una cobertura completa de todos los caminos en el código.
Decision-to-Decision Path Testing
En esta técnica se identifican y prueban todos los caminos de decisión a decisión (DD paths) en un flujo de control. Un DD path es el camino entre dos decisiones consecutivas en el código, es decir, de un punto donde se toma una decisión hasta el siguiente.
:check:Permite descubrir errores en la lógica de control del flujo del programa y asegurarse de que todas las decisiones se prueben en varios escenarios.
Permite descubrir errores en la lógica de control del flujo del programa y asegurarse de que todas las decisiones se prueben en varios escenarios.
:red_cross:Para programas con muchos caminos de decisión, el número de combinaciones posibles de caminos puede ser muy alto, lo que hace que esta técnica sea difícil de aplicar exhaustivamente.
:red_cross:Puede requerir una cantidad significativa de tiempo y recursos para analizar cada camino de decisión.
:red_cross:No es eficaz para encontrar errores que no están relacionados con las decisiones o el flujo de control del programa.
Data Flow Testing
Es útil para verificar la validez de las operaciones con variables en el código y detectar errores en el manejo de datos.
Enfocado en el seguimiento del flujo de datos a través del programa, Data Flow Testing examina cómo las variables se definen, usan y eliminan en diferentes partes del código. La técnica busca identificar problemas en el uso de variables, como la utilización de variables sin inicializar o variables nunca utilizadas.
:check:Ayuda a mejorar la calidad del código y a detectar errores que pueden pasar desapercibidos en otras pruebas, como problemas de inicialización de variables o posibles fugas de memoria.
:red_cross:La identificación y el seguimiento de todas las definiciones y usos de variables pueden ser complejos en programas grandes.
:red_cross:No considera la lógica del programa más allá del flujo de datos, por lo que otros errores estructurales o lógicos pueden no ser detectados.
:red_cross:Puede ser ineficaz para aplicaciones pequeñas o con estructuras de control simples, donde la gestión de variables no es tan compleja.
Heuristic Testing
Medir la usabilidad de un producto a través de reglas generales utilizadas por expertos.
Mira las 10 heurísticas para probar la usabilidad
Técnica de validación 🚧
Se encuentra en el apartado de testing y mantenimiento dentro del CVDS 📋
Recomendaciones
Utilizar pruebas de heurísticas a cada interfaz desarrollada para validar su usabilidad y diseño.
Recordar que solo son pruebas basadas en supuestos, no es necesario cumplir con cada una de ellas a raja tabla.
Si los usuarios tienen problema al usar tu interfaz realizar las pruebas de
heurísticas
es la mejor opción.
Desventajas: :warning:
Pueden terminar dando falsas alarmas - 43% de los problemas de las pruebas no fueron realmente problemas.
Ventajas: :check:
Resalta problemas de usabilidad en fases tempranas.
Relación costo-beneficio a comparación de otros métodos.
Relacionada a esta técnica se encuentra
Error guessing
Técnica de validación 🚧
Enfoque no estructurado de las pruebas de software (no formal)
Anticipar los defectos que podrían presentarse en algún componente o en el sistema sometido a prueba. Diseñar pruebas específicas para exponerlos (Chopra, 2016).
Se encuentra en el apartado de testing dentro del CVDS 📋
Recomendaciones:
Tener conocimiento en el entorno técnico en el que se desarrolla la aplicación.
Comprender el sistema que se está probando
Evaluar errores tanto en el código como en los requisitos, diseño, compilación, pruebas y uso.
Redactar los casos de prueba a base de una lista de errores en la app.
2 more items...
Interface Testing
Técnica de validación 🚧
Validar
la interrelación entre dos sistemas separados de una aplicación. Es decir, evaluar que la comunicación sea correcta entre dos partes a través de una interfaz.
Se encuentra en la fase del desarrollo, testing y
mantenimiento
en el CVDS 📋.
Recomendaciones:
Elegir la manera en la que probar con esta técnica: Top-Down o Bottom-Up testing.
Escribir buenos casos de prueba para validar las interfaces,
Documentar los test realizados con sus resultados para atacar el problema que surja de inmediato.
Validar en diferentes plataformas y dispositivos.
Desventajas:
:warning:
Se puede caer en el extremo (muuuy sencillo) si no se entiende bien la necesidad.
Inservible sin participación del usuario.
Ventajas:
:check:
Interfaces fáciles para un aprendizaje alto por parte de los usuarios.
Ayuda a comprender cómo actúa el usuario y qué espera que haga el sistema.
Satisfacción del cliente ya que la aplicación se ajusta a él.
Viene después de las
pruebas unitarias
.
Mira los tipos de pruebas de interfaz aquí
Black box or functional testing
Boundary Value Analysis
Detectar defectos en el software relacionados con la gestión de datos en los límites de sus rangos.
Ventajas
: :check:
Faciles de implementar.
Es posible automatizar las pruebas.
Desventajas: :warning:
No utiles para variables boleanas y logicas.
Supone que las variables son independientes.
Método de verificación. :construction:
Utiliza los valores de entrada cercanos a los limites:
{min, min+, nom, max–, max}.
Equivalence Class Partitioning
Reducir el número de pruebas seleccionando casos representativos, lo que permite evitar redundancias.
Desventajas: :warning:
Puede omitir casos
Es limitada para sistemas complejos.
Asume un comportamiento uniforme en cada clase.
Ventajas: :check:
Reduce casos de prueba
Mejora cobertura, simplifica el diseño .
Permite probar entradas válidas e inválidas.
Se dividen las entradas y salidas en clases de equivalencia, se elige un representante de cada clase y se prueba el programa con él.
Método de verificación. :construction:
Desicion Table Based Testing
Modelar y organizar lógicas complejas en situaciones donde múltiples condiciones pueden afectar las acciones a realizar.
Ventajas: :check:
Considera todas las combinaciones de condiciones.
Facilita la creación de nuevas tablas.
No requieren un orden específico.
Claridad en las acciones según condiciones.
Desventajas: :warning:
Dificultades con tablas grandes que requieren división.
Difíciles de manejar en sistemas complejos.
La eficacia depende de identificar correctamente condiciones y acciones.
Aplicaciones
Lógica If-Then-Else.
Relaciones Lógicas.
Cálculos: Procesos que involucran combinaciones de entradas.
Causa y Efecto: Análisis de cómo entradas afectan salidas.
Complejidad Ciclomática.
Método de verificación. :construction:
El código no es revisado
Cause-Effect Graphing Technique
Son casos de prueba que relacionan las condiciones de entrada (causas) con los resultados esperados (efectos)
Desventajas: :warning:
Puede volverse difícil de manejar si hay muchas condiciones y efectos.
Necesita un buen entendimiento del sistema para identificar correctamente las causas y efectos.
La calidad de los casos de prueba depende de la precisión en el grafo de causa-efecto.
Ventajas: :check:
Facilita la visualización de las relaciones entre entradas y salidas.
Ayuda a derivar test cases de manera estructurada.
Puede utilizarse para varios tipos de sistemas y condiciones.
Aplicaciones
Pruebas de Lógica: donde se deben evaluar múltiples condiciones.
Transformaciones de Estado: cambios de estado basados en entradas específicas.
Validación de Reglas de Negocio: en sistemas que dependen de reglas de negocio complejas para determinar acciones.
Método de verificación. :construction:
Autores:
Jorman Chuquer
Jean Cotera
Cristian Sangucho
Cristian Zambrano
