ii - iii - istqb ctfl

Luis Mercadal & Asociados

Curso Oficial de ISTQB Certified Tester Foundation Level

- Probador de Software Certificado de Nivel Fundamentos -

Pruebas a través del Ciclo de Vida del Software + Técnicas Estáticas



www.luismercadal.com.ar | [email protected] 2

Capítulo II - Pruebas a través del Ciclo de Vida de l Software

Contenido Capítulo II - Pruebas a través del ciclo de vida de l software

- II/01 Modelos de desarrollo de software

- II/02 Niveles de prueba

- II/03 Tipos de prueba

- II/04 Pruebas de mantenimiento

II/01 Modelos de desarrollo de software

Modelos de desarrollo de software

- El proceso de pruebas no existe aislado

- Las actividades de prueba están relacionadas con las actividades de desarrollo de software

- Diferentes modelos de ciclo de vida de desarrollo necesitan diferentes enfoques de prueba

- Un modelo involucra principalmente el orden en el cual las actividades son llevadas a cabo, y las guías para hacer la transición entre etapas

- Modelos de ciclo de vida del software

- Modelo en Cascada (Modelo Lineal Secuencial ) - Modelo V (Modelo en V ) - Modelo Iterativo-Incremental

- Modelo en Cascada (Modelo Lineal Secuencial )

- El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida

- Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma

puramente secuencial




- Modelo V (Modelo en V )

- El modelo V se desarrolló para terminar con algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional

- Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que

las pruebas no se introducían hasta el final del proyecto

- Modelo Iterativo-Incremental

- El desarrollo iterativo-incremental es el proceso de establecer requerimientos, diseñar, construir y probar un sistema en una serie de cortos ciclos de desarrollo

- Prototipos, Desarrollo Rápido de Aplicaciones (Rapid Application Development, RAD),

Proceso Unificado de Racional (Rational Unified Process, RUP), Modelos de Desarrollo Ágil (SCRUM)

Modelo V

- Desarrollo y pruebas son dos ramas iguales

- Cada nivel de desarrollo tiene su correspondiente nivel de pruebas

- Los productos de trabajo generados por los desarrolladores y analistas de negocio durante el desarrollo son las bases de las pruebas en uno o más niveles.




- Las pruebas (rama derecha) son diseñadas en paralel o al desarrollo del software (rama

izquierda)

- Las pruebas necesitan empezarse lo más pronto posible y tienen lugar a través de todo el ciclo de vida

- Las pruebas no son sólo una actividad basada en la ejecución

- Rama de desarrollo del software (rama izquierda )

- Definición de Requisitos - Especificaciones de requisitos

- Diseño Funcional del Sistema

- Especificaciones funcionales de los requisitos

- Diseño Técnico del Sistema

- Definición de arquitectura / interfaces

- Diseños de alto nivel

- Especificación de Componentes - Estructura de los componentes

- Diseños detallados

- Programación

- Creación de código ejecutable

- Rama de pruebas del software (rama derecha )

- Pruebas de Aceptación

- Pruebas formales de los requisitos del cliente

- Pruebas de Sistema

- Sistema integrado, especificaciones

- Pruebas de Integración

- Interfaces de componentes

- Pruebas de Componente - Funcionalidad del componente




Verificación y Validación (V & V)

- Verificación

- Verificar - comprobar la evidencia, substanciar

- Comprobación de la conformidad con los requisitos establecidos

- ¿Se está construyendo el producto software de la manera correcta?

- ¿Hemos sumado 1 más 1 correctamente?

- Validación

- Validar - dar prueba de la aportación de valor

- Comprobación de la idoneidad para el uso esperado

- ¿Se está construyendo el producto software correcto?

- ¿El objetivo era sumar 1 más 1 o deberíamos haber restado? Verificación

- Cada nivel de desarrollo se verifica respecto de los contenidos del nivel que le precede

- El papel de la verificación implica comprobar que el software está de acuerdo con su especificación. Debería comprobarse que satisface sus requisitos funcionales y no funcionales




Validación - La validación se refiere a la corrección de cada nivel de desarrollo

- La validación tiene como objetivo asegurar que el sistema satisface las expectativas del cliente

- No solo comprobar que el sistema satisface su especificación sino que además demostrar que el software hace lo que el cliente espera que haga

Modelos Iterativos e Incrementales Características

- Cada iteración contribuye con una característica adicional del sistema a desarrollar - Cada iteración puede ser probada por separado

- Las pruebas de regresión y la automatización de pruebas son elementos/ factores de gran relevancia

- En cada iteración, la verificación (relación con el nivel precedente) y la validación (grado de corrección del producto dentro del nivel actual) se pueden efectuar por separado




Desarrollo Ágil SCRUM - Proceso ágil que se puede usar para gestionar y controlar desarrollos complejos de software y

productos usando prácticas iterativas e incrementales.

- Se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.

- Un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita)

- Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

- Responsabilidades

- Cliente (Product Owner)

- Facilitador (ScrumMaster)

- Equipo (Team) Desarrollo de Software Guiado por Pruebas / Test Driven Development (TDD)

- Técnica de desarrollo de software que usa iteraciones de desarrollo cortas basadas en casos de prueba escritos previamente que definen las mejoras deseadas o nuevas funcionalidades

- Ciclo de desarrollo guiado por pruebas

• Añadir una prueba

• Ejecutar las pruebas y comprobar que la última que se ha añadido falla • Escribir algo de código, realizar cambios en la imp lementación

• Ejecutar las pruebas automatizadas y ver que tienen éxito • Refactorizar el código para mejorar su diseño Repetir el ciclo con una nueva prueba

Realizar un conjunto de pruebas unitarias que cubran todos los casos descritos en los requerimientos. Una correcta aplicación de la etapa de refactorización hace que el código sea mas legible, optimo y fácil de mantener




Herramientas para automatizar las pruebas unitarias

- NUnit

- MbUnit

- xUnit.net

- csUnit

- JUnit

- JsUnit

- ASPUnit Si se aplica mal o a medias el TDD pueden surgir los siguientes problemas: - Generar pruebas mal diseñadas que no sirvan para determinar si los objetos tienen el

comportamiento esperado

- La calidad de la prueba depende del conocimiento del desarrollador - Se puede invertir mucho tiempo en hacer pruebas y dejar corta la fase de construcción

(codificación) - Diseñar pruebas poco representativas que no cumplan con una cobertura de código y que en algún

momento dejen de usarse

- Invertir mucho tiempo en hacer las pruebas y no darles mantenimiento, lo cual representa un gasto inútil de tiempo

Características de buenas pruebas en todo modelo

* Para cada actividad de desarrollo existe una actividad de prueba correspondiente

* Cada nivel de prueba tiene objetivos de prueba específicos para dicho nivel

* Los procesos de análisis y diseño de las pruebas para un nivel de prueba dado deben iniciarse durante la actividad de desarrollo correspondiente

* Los probadores deben iniciar su participación en la revisión de los documentos en cuanto haya borradores disponibles en el ciclo de vida de desarrollo

* Los niveles de prueba pueden combinarse o reorganizarse en función de la naturaleza del proyecto o de la arquitectura del sistema




II/02 Niveles de prueba

Pruebas de Componente

- Objetivo � Encontrar defectos y verificar el funcionamiento de un componente

- Un componente es la menor parte testeable de una aplicación

- Posible de ser probado de manera separada

- Probados para determinar si están aptos para su uso

- Pruebas de Módulo

- Pruebas de Clase

- Pruebas de Unidad o Unitarias

- Pruebas de Desarrollador

- Bases de prueba

- Especificaciones de requisitos de componentes

- Diseño detallado

- Código

- Objetos de prueba típicos

- Componentes / clases / unidades / módulos

- Programas

- Conversión de datos / migración de programas

- Módulos de base de datos




Arnés de Pruebas (Test Harness )

- La ejecución de pruebas de componente requiere frecuentemente controladores (drivers) y stubs

- Un arnés de Pruebas es un entorno de pruebas constituido por controladores y stubs necesarios para llevar a cabo una prueba

- Un controlador sustituye a un componente que asume el control y/ o la invocación a un componente o sistema

- Crea las entradas (Inputs) necesarias para el componente a probar y después lo invoca

- Un stub sustituye a un componente llamado

- Funciona como suplente del componente subordinado y proporciona el comportamiento mínimo requerido para ese componente

Pruebas de Integración

- Prueban interfaces entre componentes, e interacciones con distintas partes de un mismo sistema

- Bases de prueba

- Diseño del software y del sistema

- Arquitectura

- Flujos de trabajo (workflows)

- Casos de uso


- Subsistemas

- Implementación de base de datos

- Infraestructura

- Interfaces

- Configuración de sistema y de datos




- Estrategias de Integración

- Ad hoc

- Incremental

- Ascendente (Bottom-Up )

- Descendente (Top-Down )

- Big Bang

- Ad hoc

- Objetivo

- Los módulos se conectan de la misma manera que se producen

- Están listos para ser integrados

- Ventajas

- Posibilidad de ganancias de tiempo

- No se espera por el componente concreto que debe ser integrado

- Desventajas

- Se necesitan controladores (drivers) y stubs para las pruebas

- Ascendente (Bottom-Up )

- Objetivo

- Los componentes de nivel más bajo se integran primero y, a continuación, se utilizan para facilitar la integración de componentes de nivel superior.

- El proceso se repite hasta que se integra el componente de la parte superior de la jerarquía

- Ventajas

- No hay necesidad de stubs

- No se pierde tiempo esperando que todos los módulos estén desarrollados




- Desventajas

- Módulos críticos, en el nivel superior, que controlan el flujo de la aplicación se prueban al último y pueden ser propensos a defectos.

- Se puede utilizar solo para sistema de construcción jerárquica

- Son necesarios controladores para reemplazar módulos que están arriba en la jerarquía

- Descendente (Top-Down )

- Objetivo

- Los componentes en la parte superior de la jerarquía de componentes son integrados en primer lugar, mientras que los componentes de nivel inferior son simulados por stubs

- Los componentes probados, a continuación, se utilizan para integrar los componentes de nivel inferior

- El proceso se repite hasta que se integran los componentes de nivel más bajo

- Ventajas

- No hay necesidad de controladores

- No se pierde tiempo esperando que todos los módulos estén desarrollados

- Posibilidad de presentar al usuario un temprano prototipo

- Desventajas

- Se puede utilizar solo para sistema de construcción jerárquica

- Son necesarios varios stubs para reemplazar módulos que están abajo en la jerarquía

- Big Bang

- Objetivo

- Los módulos se integran cuando todos están listos.

- Todos los módulos se integran a la vez.

- Ventajas

- No se necesitan ni controladores ni stubs

- Todos los módulos están listos




- Desventajas

- La localización de defectos es dificultosa, y consume mucho tiempo

- Es para sistemas pequeños

Pruebas de Sistema

- Bases de prueba

- Especificación de requisitos

- Casos de uso y procesos de negocio

- Especificaciones funcionales

- Informes de análisis de riesgos


- Manuales de sistema, usuario y operaciones

- Configuración del sistema

- Datos de configuración

- Se controlan escenarios completos de extremo a extremo, y la manera en que un usuario/ cliente podría usar el sistema

- Comprobar el cumplimiento de requisitos (funcionales y no funcionales) especificados

- El alcance está definido en el Plan Maestro de Pruebas o en Plan de Pruebas de Nivel

- La calidad del software es observada desde el punto de vista del usuario

- Implementación completa y correcta de los requisitos

- Las características de la calidad de los datos son la base para las pruebas

- El ambiente de pruebas debería coincidir con el ambiente real

- ¡ No se realizan pruebas en el entorno real !




Pruebas de Aceptación

- Determinar si los requerimientos especificados fueron o no cumplidos

- El objetivo es proporcionar la confianza de que el sistema entregado cumple con los requisitos de negocio

- Bases de prueba

- Requisitos de usuario y de sistema

- Casos de uso y procesos de negocio

- Informes de análisis de riesgo


- Procesos de negocio en sistemas completamente integrados

- Procesos de operaciones y mantenimiento

- Procedimientos de usuario

- Formularios e informes

- Datos de configuración Aceptación Contractual y de Regulación

- ¿El software satisface todos los requisitos contractuales?

- Con la aceptación formal se cumplen hitos legales

- comienzo de fase de garantía, hitos de abono (pago), acuerdos de mantenimiento, etc.

- Criterios de aceptación verificables definidos en el momento del acuerdo contractual constituyen una garantía para ambas partes

- Las pruebas de aceptación deben tener en cuenta normas y reglamentos gubernamentales, legales, industriales y de otro tipo

Pruebas de Aceptación de Usuario

- El cliente selecciona casos de prueba para las pruebas de aceptación

- Las pruebas se realizan utilizando el entorno del cliente

- El entorno del cliente puede producir nuevos fallos




Pruebas de Aceptación Operativa

- Requiere que el software sea adecuado para su uso en un entorno de producción

- Integración del software en la infraestructura TI del cliente

- Copias de seguridad / restauración de sistemas, reinicio, instalación, capacidad de ser desinstalado, recuperación en caso de desastres, etc.

- Gestión de usuarios, interacción con ficheros y estructuras de directorios en uso

- Compatibilidad con otros sistemas

- Tareas de mantenimiento

- Tareas de carga y migración de datos

- Con frecuencia, las pruebas de aceptación operativa son realizadas por el administrador de sistemas del cliente

Pruebas Alfa

- Pruebas realizadas por equipos de prueba independientes, clientes potenciales o interesados, en instalaciones propias de desarrollo

- Se realizan principalmente para software de distribución masiva (Commercial Off-The-Shelf software, COTS) como una forma de pruebas de aceptación interna antes de mover el software para pruebas beta

Pruebas Beta

- Se realizan después de las pruebas alfa, como pruebas de aceptación externa de software de distribución masiva, para adquirir retroalimentación del mercado

- Pruebas realizadas por usuarios / clientes actuales o potenciales en una instalación externa, sin la actuación de desarrollo

- Se llevan a cabo en un ambiente no controlado por desarrollo

- Se prueba si el software satisface las necesidades de negocio u operacionales de los cliente y usuarios finales




II/03 Tipos de prueba

Tipos de Prueba

- Un tipo de prueba se centra en un objetivo de prueba en particular

- Prueba de una función a ser realizada por el software

- Una característica de calidad no funcional

- La estructura o arquitectura del software o sistema

- Pruebas de confirmación y de regresión

- Distintos tipos de prueba se aplican durante los distintos niveles de prueba

- Tipos de prueba

Pruebas funcionales Pruebas no funcionales Pruebas estructurales Pruebas asociadas al cambio

Pruebas funcionales

- Objetivo

- Probar la función / verificar los requisitos funcionales

- La funcionalidad puede ser vinculada a los datos de entrada y salida de un objeto de prueba

- Los métodos de caja negra se utilizan en el diseño de casos de prueba relevantes

- Las pruebas funcionales se pueden llevar a cabo en todos los niveles de prueba

- Pruebas de seguridad

- Tipo de prueba funcional que aborda amenazas externas

- Ataques maliciosos podrían dañar programas o datos




Pruebas no funcionales

- Objetivo

- Probar las características del producto

- ¿De qué forma el software lleva a cabo sus funciones?

- Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad, Portabilidad

- Las pruebas no funcionales se pueden llevar a cabo en todos los niveles

- Pruebas no funcionales típicas:

- Pruebas de rendimiento, de carga, de volumen, de estrés

- Prueba de fiabilidad y robustez

- Pruebas de usabilidad, de configuración

- Prueba de rendimiento

- Rapidez con la cual un sistema ejecuta una determinada función

- Prueba de carga

- Sistema bajo carga (carga mínima, más usuarios / transacciones)

- Prueba de volumen

- Procesamiento de grandes cantidades de datos / ficheros

- Prueba de estrés

- Reacción a la sobrecarga / recuperación tras el retorno a un carga normal

- Prueba de robustez

- Reacción a entradas erróneas o datos no especificados

- Reacción a fallos hardware / recuperación ante situaciones de desastre




- Pruebas de cumplimiento

- Cumplir normas y reglamentos (interno / externo)

- Pruebas de usabilidad

- Estructurado, comprensible, fácil de aprender por parte del usuario

- Otros aspectos no funcionales de calidad

- Portabilidad

- Mantenibilidad

- Fiabilidad (tolerancia a fallas)

Pruebas estructurales

- Objetivo

- Probar la estructura, la arquitectura software

- Enfoque de prueba de caja blanca

- La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba

- Las pruebas estructurales son posibles en todos los niveles de pruebas

- La cobertura del código se realiza de forma conjunta a las pruebas de componente y de integración mediante el uso de herramientas

- El diseño de pruebas estructurales se finaliza tras haber sido diseñadas las pruebas funcionales, con el propósito de obtener un alto grado de cobertura




Pruebas asociadas al cambio

- Objetivo

- Probar después de cambios

- Después de que un objeto de pruebas o el ambiente de su sistema ha sido objeto de modificación

- Criterios para la selección de casos de prueba de regresión:

- Casos de prueba de prioridad alta

- Probar solamente la funcionalidad estándar, saltarse casos y variaciones especiales

- Probar solamente la configuración utilizada con mayor frecuencia

- Probar solamente subsistemas / zonas seleccionadas del objeto de pruebas

II/04 Pruebas de mantenimiento

Pruebas posteriores a la aceptación del producto

- El cliente ha aprobado el producto y es puesto en producción

- El ciclo de desarrollo inicial, incluidas las pruebas asociadas, ha sido completado

- El mismo software se encuentra al comienzo del ciclo de vida:

- Será utilizado por muchos años, será ampliado

- Es muy probable que aún contenga defectos, por lo tanto será modificado y corregido

- Necesitará adaptarse a nuevas condiciones y deberá integrarse a nuevos entornos

- Necesitará cambiar o extender los datos de configuración

- Será retirado, se extraerá del entorno de producción ¡Cualquier nueva versión del producto, cada nueva ac tualización y cada cambio del software requiere pruebas adicionales !




- El mantenimiento de software cubre dos campos diferenciados:

- Mantenimiento tal como: corrección de errores o implementación de “hot-fixes” , que han sido parte de la versión inicial del software

- Distribuciones de software planificados: adaptaciones como resultado una modificación / cambio del entorno o nuevos requisitos del cliente

- Alcance de las pruebas de mantenimiento:

- “Hot-fixes ” y la corrección de defectos requieren la repetición de pruebas

- La ampliación de la funcionalidad requiere nuevos casos de prueba

- La migración a otra plataforma requiere pruebas operativas

- Adicionalmente, son necesarias pruebas de regresión intensivas

- El alcance de las pruebas depende del impacto del cambio

- El análisis de impacto se utiliza para determinar las áreas afectadas con el objeto de decidir la cantidad de pruebas de regresión

- Pueden ocurrir problemas si la documentación del software antiguo falta o es incompleta

- Retirada del software

- Las pruebas tras la retirada del software pueden incluir:

- Pruebas de migración de datos

- Verificación del archivo de datos y programas

- Pruebas en paralelo de sistemas nuevo y su antecedente




Capítulo III - Técnicas Estáticas

Contenido Capítulo III - Técnicas estáticas

- III/01 Técnicas estáticas y el proceso de pruebas

- III/02 Proceso de revisiones

- III/03 Análisis estático con herramientas

III/01 Técnicas estáticas y el proceso de pruebas

Técnicas estáticas

- No se ejecuta el código

- Manuales - Revisiones

- Automatizadas - Análisis Estático

- Las técnicas estáticas complementan los métodos dinámicos

- Las pruebas estáticas detectan causas de fallas (defectos) en lugar de fallas

- Los conceptos también son analizados, no sólo el código ejecutable

- Los defectos / desviaciones son detectados en una fase temprana

- Las pruebas estáticas pueden descubrir defectos que no son detectables en las pruebas dinámicas

- Documentos de alta calidad conducen a productos de alta calidad

- Incluso si una especificación revisada no contiene ningún defecto, la interpretación de la especificación y creación del diseño pueden ser defectuosas




Objetivos de las revisiones

- Las revisiones se realizan con el objeto mejorar la calidad del producto

- Defectos típicos:

- Desviaciones de los estándares

- Defectos de requisito

- Defectos de diseño

- Mantenibilidad insuficiente

- Especificaciones de interface incorrectos Ventajas y desventajas de las revisiones

- Ventajas

- Costos más bajos y un alto potencial de ahorro

- Los defectos en la documentación son detectados y corregidos de forma temprana

- Los documentos de alta calidad mejoran el proceso de desarrollo

- Mejora el índice de comunicación / intercambio de conocimiento

- Desventajas

- Se podrían presentar situaciones de tensión en el caso de enfrentamientos directos con el autor

- Los expertos involucrados en las revisiones deben adquirir conocimientos específicos del producto, es necesaria una buena preparación

- Inversión considerable de tiempo (del 10% - 15% del presupuesto total)

- Moderador y participantes influyen directamente en la calidad de la revisión




III/02 Proceso de revisiones

Revisiones Informales y Formales

- Informales

- Ocurren espontáneamente entre pares

- Los revisores no tienen necesariamente ninguna responsabilidad, y no tienen que producir un informe de la revisión

- Formales

- Son cuidadosamente planificadas

- Los revisores son responsables por su participación, y se genera un informe de la revisión que contiene elementos de acción

Actividades de una Revisión Formal

* Planificación

* Definir los criterios de la revisión

* Seleccionar el personal

* Asignar los roles

* Definir los criterios de entrada y de salida

* Seleccionar las partes del documento a revisar

* Controlar los criterios de entrada

* Inicio (Kick-off )

* Distribuir documentos

* Explicar los objetivos, procesos y documentos a los participantes

* Preparación individual

* Revisar los documentos antes de la reunión de revisión

* Anotar potenciales defectos, preguntas y comentarios




* Reunión de revisión

* Discutir o registrar, con resultados documentados o minutas

* Anotar defectos, dar recomendaciones sobre el manejo de los defectos, realizar decisiones sobre los defectos

* Examinar, evaluar y registrar los temas durante reuniones físicas o realizar el seguimiento de comunicaciones electrónicas de grupo

* Corrección del trabajo (Rework )

* Corregir los defectos encontrados

* Registrar el estado actualizado de los defectos

* Seguimiento (Follow-up )

* Comprobar que los defectos han sido tratados

* Recopilar métricas

* Comprobar los criterios de salida

Roles y Responsabilidades

* Roles de una Revisión Formal típica

- Jefe de Proyecto (Manager, Gerente )

• Decide sobre la ejecución de las revisiones

• Asigna tiempo en el calendario del proyecto

• Determina si se han cumplido los objetivos de la revisión

- Moderador

• Lidera la revisión del o de los documentos

• Planifica la revisión, ejecuta la reunión, y realiza el seguimiento posterior

• Puede mediar entre los varios puntos de vista

• Sobre quien recae la responsabilidad del éxito de la revisión




- Autor

• Redactor o principal responsable de los documentos a ser revisados

• Expone su trabajo a la crítica, lleva a cabo los cambios recomendados

- Revisores (Inspectores, Comprobadores, Chequeadores )

• Personas con un bagaje técnico o de negocio específico

• Después de la preparación necesaria, identifican y describen los descubrimientos (por ejemplo, defectos) en el producto bajo revisión

• Deben ser elegidos para representar diferentes perspectivas y roles en el proceso de revisión

• Deben tomar parte en cualquier reunión de revisión

- Escriba (Redactor, Registrador )

• Documenta todos los asuntos, problemas y puntos abiertos que fueron identificados durante la reunión

Tipos de Revisiones 1. Revisión Informal (Informal Review )

2. Revisión Guiada (Walkthrough ) 3. Revisión Técnica (Technical Review ) 4. Inspección (Inspection ) • IEEE STD 1028-2008 - IEEE Standard for Software Reviews and Audits




1. Revisión Informal

- Ningún proceso formal

- Programación por pares

- Líder técnico revisando diseños y código

- Los resultados pueden ser documentados

- Su utilidad varia dependiendo de los revisores

- Propósito principal: Forma económica de obtener algún beneficio 2. Revisión Guiada

- Reunión liderada por el autor

- Escenarios, ensayos generales, participación de grupo de pares

- Sesiones abiertas

- Preparación pre-reunión de los revisores (Opcional)

- Preparación de reporte de revisión (Opcional)

- Escriba(Opcional)

- De muy informal a formal

- Propósitos principales: Aprender, Comprender, Encontrar defectos 3. Revisión Técnica

- Proceso de detección de defectos documentado y definido que incluye pares y expertos

- Puede ser realizada como una revisión entre pares sin la participación de la gestión

- Idealmente conducida por un moderador entrenado

- Preparación pre-reunión de los revisores

- Uso de listas de comprobación (Opcional)

- Preparación de un reporte de revisión

- De muy informal a formal

- Propósitos principales: Discutir Tomar decisiones Evalu ar alternativas Encon trar defectos Soluc ionar problemas técnicos y comprobar conformidad




4. Inspección

- Liderada por un moderador entrenado

- Usualmente conducida como un examen entre pares

- Roles definidos

- Incluye recopilación de métricas

- Proceso formal basado en reglas y listas de comprob ación

- Criterios de entrada y de salida para la aceptación del software

- Preparación pre-reunión

- Reporte de inspección incluyendo lista de descubrimientos

- Proceso formal de seguimiento

- Mejora de proceso y lector (Opcional)

- Propósito principal: Encontrar defectos

Factores de éxito de una revisión

- Cada revisión tiene un claro objetivo predefinido

- Están involucradas las personas adecuadas para los objetivos de la revisión

- Los probadores son revisores valorados que contribuyen a la revisión y también aprenden sobre el producto

- Los defectos encontrados son bienvenidos y expresad os objetivamente

- Los problemas de las personas y los aspectos psicológicos son tratados

- La revisión es conducida en una atmósfera de confia nza

- Se aplican las técnicas de revisión adecuadas

- Listas de comprobación o roles son usados para aumentar la identificación de defectos

- Se brinda entrenamiento en técnicas de revisión

- La gestión da soporte a un buen proceso de revisión

- Existe un énfasis en el aprendizaje y en la mejora del proceso




III/03 Análisis estático con herramientas

Análisis Estático

- Analizar un objeto de prueba sin ejecutar el objeto de prueba

- Todos los objetos de prueba deben tener una estructura formal

- Principalmente cuando se utilizan herramientas de pruebas

- Con el uso de herramientas, se requiere menos esfuerzo que en una revisión para revisar un programa

- Compiladores

- Analizadores Valor del análisis estático

- Detección temprana de defectos antes de la ejecución

- Detección temprana sobre aspectos sospechosos del código o diseño

- Identificación de defectos difícilmente encontrados por las pruebas dinámicas

- Detectar dependencias e inconsistencias en los modelos de software

- Mantenibilidad mejorada del código y del diseño

- Prevención de defectos, si las lecciones son aprendidas en el desarrollo Defectos típicos descubiertos por las herramientas

- Referencia a una variable con un valor indefinido

- Interfaces inconsistentes entre módulos y componentes

- Variables que no se usan o están declaradas en forma incorrecta

- Código inalcanzable (muerto)

- Lógica faltante y errónea (bucles potencialmente infinitos)

- Construcciones excesivamente complicadas

- Violaciones de estándares de programación

- Vulnerabilidades de seguridad

- Violaciones de sintaxis de código y de modelos de software




Las métricas

- Ciertos aspectos de la calidad de un programa pueden ser medidos utilizando métricas

- La complejidad estática de un programa puede ser medida

- Métricas diferentes tratan aspectos diferentes de la complejidad de programa

- Tamaño del programa (por ejemplo, líneas de código)

- Estructuras de control del programa (por ejemplo, número ciclomático)

- ¡Es difícil comparar dos métricas diferentes, inclus o cuando ambas abordan el mismo atributo del programa !

Las métricas - Número Ciclomático (CC)

- Número ciclomático v(G) - McCabe -

pneGv 2)( +−=

- Mide la complejidad estática de un programa basada en su grafo de flujo de control

- Testeabilidad y Mantenibilidad

- El número ciclomático se define de la siguiente forma:

- Número de aristas: e (edges)

- Número de nodos: n (nodes)

- Número de componentes conectados: p (normalmente es igual a 1)

- Hasta 10 es aceptable




pneGv 2)( +−=

- El gráfico de la derecha tiene:

- 1 partes independientes: p = 1

- 9 nodos: n = 9

- 10 aristas: e = 10

- Esto conduce al número ciclomático: v(G)= e – n + 2p v(G)= 3 IF P = T CARRY OUT THIS IF X = 10 CARRY OUT THE OTHER ELSE CARRY OUT THAT ENDIF ENDIF * Gráfico de Flujo de Control / Control Flow Graph (CFG)

- El CFG tiene 2 regiones, 4 nodos y 5 aristas.

- N° de Regiones + 1

- N° de Aristas - N° de Nodos + 2 CC = 3




Los gráficos de flujo de control no deben mostrar ninguna instrucción, pero para facilitar la comprensión, pueden mostrarse instrucciones, tal como se muestra en el gráfico de la derecha: 1 IF P = T 2 CARRY OUT THIS 3 IF X = 10 4 CARRY OUT THE OTHER ELSE 5 CARRY OUT THAT 6 ENDIF 7 ENDIF El CFG tiene 2 regiones, 7 nodos y 8 aristas. N° de Regiones + 1 N° de Aristas - N° de Nodos + 2 CC = 3

Número ciclomático

- El grafo de la derecha tiene:

- 1 partes independientes: p = 1

- 6 nodos: n = 6

- 7 aristas: e = 7

- Esto conduce al número ciclomático: v(G)= e – n + 2p v(G)= 3

- Número de Decisiones + 1




- Por ejemplo: IF A=1 AND B=1

- Método de McCabe = CC = CC1 => +1

- Método Extendido = CC2 = Complejidad Ciclomática Extendida = ECC => +2

- Operadores lógicos / booleanos => CC2 = CC1 + Booleanos

- CC3 = Complejidad Ciclomática sin Cases = Complejidad Ciclomática Modificada

ii - iii - istqb ctfl

Documents