Capítulo No.3 ISTQB Técnica Estáticas

Probador Certificado – Nivel Básico
III. Técnicas estáticas

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

- III/01 Técnicas estáticas y el proceso de prueba
- III/02 Proceso de revisiones
- III/03 Análisis estático con herramientas

Contenido


01. Técnicas estáticas y el proceso de prueba
Enfoque básico
- Las técnicas de prueba estáticas comprenden varios métodos que no ejecutan el
componente o sistema objeto de la prueba
- Las pruebas estáticas incluyen:
- Revisiones (“reviews”) (actividad manual)
- Análisis estático (“static analysis”) (actividad basada en herramientas)
- Las técnicas estáticas complementan los métodos dinámicos
- Las pruebas estáticas detectan causas de fallos (defectos) en lugar de fallos
- Los conceptos también son analizados, no sólo el código ejecutable.
- Los defectos/desviaciones son detectados en una fase temprana, antes de que sean
implementadas en el código
- Las pruebas estáticas pueden descubrir defectos no detectables en 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
- Las revisiones se utilizan para verificar la correcta transición de una fase a la siguiente, según está
definido en la rama izquierda del modelo-V
- La detección temprana de errores ahorra costes
- En el transcurso de las revisiones se podrían detectar los siguientes defectos:
- Defectos en las especificaciones
- Defectos en el diseño y arquitectura Definición de
del software Requisitos
- Defectos en las especificaciones Diseño Funcional del

de interfaces Sistema
- Mantenibilidad insuficiente
Diseño Técnico del
- Desviaciones con respecto a estándares Sistema
acordados (por ejemplo guías de

Especificación de
programación) Componentes
VERIFICACIÓN
DESARROLLO Programación
E INTEGRACIÓN

Ventajas y desventajas de las revisiones

- Ventajas
- Costes más bajos y 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 (“know-how”)
- 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

Contenido

- III/02 Proceso de revisión

02. Proceso de revisión
Actividades de una revisión formal (1)

- Planificación
- Definición de los criterios de la revisión (listas de comprobación, tipo de revisión)
- Selección del personal (revisores, moderador, …)
- Asignación de roles y tiempo en el calendario del proyecto (quien hace qué)
- Definición de los criterios de entrada y salida para revisiones formales

- Seleccionar qué partes de los documentos serán revisadas (dependiendo de la importancia o
complejidad)
- Inicio o lanzamiento (“kick-off”)

- Distribución de documentos (a los revisores)
- Explicación de los objetivos, proceso y documentos (listas de comprobación)
- Comprobación de los criterios de entrada (para revisiones más formales)



- Preparación individual
- Los revisores inspeccionan los objetos, identifican elementos que requieren aclaración
- Identificación de defectos potenciales, preguntas y comentarios
- Reunión de revisión
- Reunión de los miembros de la revisión, los revisores presentan sus resultados
- Discusión o registro, con resultados documentados
- Identificación de defectos, presentación de recomendaciones respecto del tratamiento de los
defecto, toma de decisiones respecto de los defectos
- Examen/Evaluación/Registro
- Durante cualquier reunión física/seguimiento de comunicaciones electrónicas del grupo
- Reconstrucción (“rework”)
- El autor corrige cualquier defecto identificado por los inspectores
- Registro de estado actualizado de defectos


- Seguimiento (“follow up”)
- Comprobación de que los defectos han sido tratados/recogida de métricas
- Decisión de mantener una segunda reunión de revisión si fuera necesario
- Comprobación de los criterios de salida (revisiones formales) para dar el visto bueno

Roles y responsabilidades (1)

- Jefe de proyecto (“manager”)
- Inicia la revisión, decide con respecto a los participantes
- Asigna tiempo en el calendario del proyecto
- Determina si se han alcanzado los objetivos de la revisión
- Moderador (“moderator”)
- Dirige la reunión/la discusión, hace de mediador, concluye resultados
- Planificación de la revisión/ejecución de la revisión / seguimiento posterior
- Sobre quien recae la responsabilidad del éxito de la revisión
- Autor (“author”)
- Redactor o responsable jefe del objeto de la revisión
- Expone su trabajo a la crítica, lleva a cabo los cambios recomendados


- Revisor ("reviewer") [también inspectores (“inspectors”) o comprobadores (“checkers”)]
- Individuos con un bagaje técnico o de negocio específicos
- Detecta defectos, desviaciones, áreas problemáticas, etc.
- Ellos representan diferentes perspectivas y roles en el proceso de revisión
- Deberían tomar parte en cualquier reunión de revisión
- Escriba (“scribe”)
- Documenta todos los asuntos, problemas y puntos que hubieran sido identificados
- Los protocolos serán preparados de forma conjunta con un proyector tal vez en el caso de
revisiones importantes. Posteriormente se contará con un protocolo verificado


Las revisiones observan los productos software o productos resultado del trabajo desde
distintos puntos de vista. Las listas de comprobación pueden hacer las revisiones más
eficientes. Una lista de comprobación con los problemas típicos puede ayudar a descubrir
anomalías no detectadas previamente


- Lista de comprobación (“checklist”) – Ejemplo
(depende del objeto de revisión)
- Identificar la audiencia objetivo
- Crear un logo para el software
- Crear un sitio Web para promocionar el software
- Definir requisitos mínimos del sistema
- Optimizar el sitio Web para motores de búsqueda (SEO)
- Configurar el Orden de las Páginas en el sitio Web
- Crear una lista de beneficios clave (“key benefits list”)
- Los términos son correctos y únicos
- Los requisitos están completos y son únicos
- Los comentarios están “hablando” y en el lenguaje esperado
- Todas las variables del código comienzan con una “V”
- Todas las constantes del código serán nombradas en Mayúsculas
- Las interfaces son consistentes y con las mismas métricas
- …

Tipos de revisiones (IEEE 1028) (1)

- El proceso básico de una revisión – como se esquematiza aquí – se aplica a las
siguientes variantes:
A. Inspección(“inspection”)
B. Revisión guiada (“walkthrough”)
C. Revisión técnica(“technical review”)
D. Revisión informal (“informal review”)
- Estas variaciones difieren en algunos aspectos de la práctica de básica esbozada



- Una diferencia adicional de las revisiones se presenta dependiendo de la naturaleza del
objeto de la revisión: producto o proceso
- Proceso de desarrollo SW o proceso del proyecto
- CMMi, ISO/IEC 15504, TPI son términos relacionados con la mejora del proceso
- También denominada revisión de gestión (“management review”), estas revisiones no
interfieren directamente en el proceso de prueba, no forman parte de este curso
- Documentos/productos del proceso de desarrollo
- Estas son las revisiones tratadas en el presente curso


- A. Inspección: características relevantes
- Los revisores inspeccionan al objeto sujeto a revisión haciendo uso de listas de comprobación y
métricas (por ejemplo, problemas por página)
- Un moderador capacitado (formación específica) e independiente dirige la revisión
- La viabilidad de la revisión del objeto es valorada de forma previa a la revisión
- Criterios de entrada y salida especificados (previamente) para la aceptación del producto
software
- Proceso formal basado en reglas y listas de comprobación para las actividades de preparación,
ejecución, documentación y seguimiento
- Normalmente realizada/ejecutada como una evaluación entre pares
- Preparación previa a la reunión
- Informe de inspección incluyendo la lista de hallazgos (“findings”)


- A. Inspección: ventajas y desventajas
- Sesiones formales y organizadas con roles claramente definidos
- Requiere actividades intensivas de preparación y seguimiento
- Son necesarios el moderador y el escriba
- Propósito principal: detección de defectos utilizando un método estructurado


- B. Revisión guiada (“walkthrough”): características relevantes
- Opcionalmente puede haber una preparación, por parte de los revisores, previa a la reunión
- Sesiones abiertas (“open-ended”)
- Pueden tomar la forma de escenarios (“scenarios”), ejecución simulada (“dry run”),
participación grupal de pares (“peer group participation”)
- La reunión es dirigida por el autor
- No es necesario un moderador distinto (el autor modera)
- A lo largo de la presentación por parte del autor los revisores tratan de detectar desviaciones
y/o áreas que representen un problema
- Ejemplos para el uso de revisiones guiadas:
- Revisión guiada de documentos
- Revisión guiada de un diseño preliminar de interfaz de usuario
- Revisión guiada de modelo de datos del proceso de negocio


- B. Revisión guiada (“walkthrough”): ventajas y desventajas
- Esfuerzo reducido en la preparación de la sesión de revisión, pero es una sesión de resultado
abierto
- Una sesión puede ser iniciada a través de notificaciones realizadas con poca antelación
- El autor tiene una gran influencia sobre el resultado: dado que él mismo modera la revisión, hay
un riesgo de dominación por su parte (puntos crítico no abordados en profundidad)
- Posibilidad limitada de control, dado que el autor también se encuentra a cargo de cualquier
actividad de seguimiento


- C. Revisión técnica (“technical review”): características relevantes
- La meta del examen es un aspecto técnico del objeto en revisión: ¿es apto para el uso?
- Son necesarios expertos, preferentemente externos con la participación opcional de miembros
responsables de la organización (“management”)
- Se puede ejecutar como una revisión entre pares (“peer review”) sin la participación de
responsables de la organización
- Liderada, idealmente, por un moderador entrenado / formado específicamente para la función,
no por el autor
- Preparación previa a la reunión por parte de los revisores
- Uso de listas de comprobación con el objeto de no olvidar cosas importantes


- C. Revisión técnica (“technical review”): características relevantes
- El panel de expertos presenta sus recomendaciones con carácter unánime
- Preparación de un informe de revisión que incluye la lista de hallazgos, el veredicto respecto del
cumplimiento de los requisitos por parte del producto
- La revisión técnica puede ser muy formal o informal, dependiendo de la importancia


- C. Revisión técnica (“technical review”): objetivo principales
- Discusión durante la revisión
- Tomar decisiones
- Evaluar alternativas
- Detectar defectos
- Resolver problemas técnicos
- Comprobar la conformidad (estándares, planes, especificaciones, normativa)


- D. Revisiones informales: características relevantes
- Es la forma de revisión más simple
- Frecuentemente iniciada por el autor
- Solamente estarán involucrados revisores (uno o más)
- No es necesaria ninguna reunión por separado
- Los resultados pueden ser registrados en forma de una lista de acción
- Normalmente se inicia / desarrolla con la solicitud de la revisión de un documento a un
compañero de trabajo


- D. Revisiones informales: ventajas y desventajas
- Fácil de ejecutar, incluso en los casos de notificaciones realizadas con poca antelación
- Rentable
- No requiere protocolo

Factores de éxito de una revisión (1)

- Las revisiones se deben desarrollar orientadas al logro de objetivos, es decir, las
desviaciones en el objeto revisado deben ser establecidas de forma imparcial
- El autor del objeto revisado deberá ser motivado de una forma positiva por la revisión
(“su documento será aún mejor” en lugar de “su documento es de baja calidad”)
- Uso sistemático de las técnicas y plantillas implantadas
- El uso de listas de comprobación mejorará la eficiencia de la revisión
- Para la ejecución apropiada de las revisiones será necesario un presupuesto apropiado
(10% al 15% del costo total del desarrollo)
- Hacer uso del efecto de las lecciones aprendidas, utilizar la retroalimentación para
implementar un proceso de mejora continua

Factores de éxito de una revisión (2)

- Las revisiones deben ser desarrolladas en un ambiente de confianza
- El resultado no será utilizado para evaluar a los participantes de la revisión
- Los probadores son revisores valorados que contribuyen con la revisión y también
aprenden sobre el producto de tal forma que les permite preparar pruebas de forma
temprana
- Involucrar a la gente adecuada en función de los objetivos de la revisión
- Hay un énfasis en el aprendizaje y en la mejora del proceso

Resumen
- En el transcurso de las pruebas estáticas no se ejecuta el objeto de prueba
- Las revisiones pueden tener lugar en fases tempranas del proceso de desarrollo, ellas
complementan/extienden los métodos de pruebas dinámicas
- Fases de una revisión:
- Planificación – reunión de lanzamiento o “Kick off” – preparación individual – reunión de
revisión – reconstrucción – seguimiento
- Roles y tareas para una revisión:
- Director – moderador – escriba – autor – evaluador/revisor
- Tipos de revisiones:
- Inspección (inspection) – revisión guiada (“walkthrough”) – revisión técnica (technical review”) –
revisión informal (“informal review”)

Contenido


03. Análisis estático con herramientas
Terminología y definiciones
- Análisis estático (Definición):
- Es aquella tarea que consiste en analizar un objeto de prueba {por ejemplo código fuente, script
(guión), requisito} sin ejecutar el objeto de prueba.
- Posibles aspectos a ser comprobados con análisis estático:

- Reglas y estándares de programación
- Diseño de un programa (análisis del flujo de control)
- Uso de datos (análisis del flujo de datos)
- Complejidad de la estructura de un programa
- métricas, por ejemplo número ciclomático

Aspectos generales (1)

- Todos los objetos de prueba deben tener una estructura formal
- Esto es especialmente importante cuando se utilizan herramientas de prueba
- Con mucha frecuencia no se generan documentos formalmente
- En la práctica, lenguajes de modelado, programación y de creación de scripts (“scripting
language”) cumplen con la regla, de la misma forma que algunos diagramas
- El análisis estático de un programa mediante el uso de herramientas se desarrolla con
un esfuerzo menor que el necesario en una inspección
- Por lo tanto, con mucha frecuencia, el análisis estático se ejecuta de forma previa a que tenga
lugar una revisión
- Para detectar lógica ausente o errónea (bucles potencialmente infinitos)
- Para detectar construcciones excesivamente complicadas, vulnerabilidades en el ámbito de la
seguridad interfaces inconsistentes, etc.


- El valor del análisis estático es la prevención de defectos:
- Para encontrar defectos tan pronto como sea posible antes de la ejecución de pruebas
- Para advertir sobre aspectos sospechosos del código
- Para detectar discrepancias en el diseño a través del cálculo de métricas como la medida de una
alta complejidad
- Estos defectos pueden no ser encontrados fácilmente con pruebas dinámicas
- Detectando inconsistencias y dependencias
- Para comprobar la mantenibilidad del código o diseño


- Herramientas que deben ser utilizadas: Compiladores y herramientas de análisis
(analizadores)
- Compilador
- Detecta errores sintácticos en el código fuente de un programa
- Crea datos de referencia del programa (por ejemplo lista de referencia cruzada, llamada
jerárquica, tabla de símbolos)
- Comprueba la consistencia entre los tipos de variables
- Detecta variables no declaradas y código inaccesible (código muerto)
- Analizador: trata aspectos adicionales tales como:
- Convenciones y estándares
- Métricas de complejidad
- Acoplamiento de objetos

Análisis del flujo de control (1)

- Propósito
- Detectar defectos causados por un desarrollo anómalo de código (ramas muertas, código
muerto, etc.)
- Método
- La estructura del código se representa como un
diagrama de control de flujo
- Grafo dirigido
- Los nodos representan sentencias o
secuencias de sentencias
- Las aristas representan la transferencia
del flujo de control, como en decisiones y bucles
- Construcción mediante herramientas

Análisis del flujo de control (2)

- Resultados
- Visión comprensible del conjunto del código del programa
- Las anomalías* pueden ser detectadas fácilmente, los defectos se hacen evidentes
- Bucles abandonados por saltos
- Ramas muertas
- Retornos múltiples
- El grafo de un flujo de control es una versión
simplificada de un diagrama de flujo
?
*Anomalía: una irregularidad o inconsistencia

Análisis del flujo de datos (1)

- Propósito
- Detección de anomalías en el flujo de datos con la asistencia de los diagramas de control de flujo
y conjeturas racionales respecto de las secuencias del flujo de datos
- Beneficios
- Detección fiable de anomalías en el flujo de datos
- Se puede detectar fácilmente la localización exacta de defectos
- Es un buen complemento para otros métodos de pruebas
- Desventajas
- Limitado a un rango reducido de tipos de defectos

Análisis del flujo de datos – Método

- Una variable x puede tener los siguientes estados a lo largo del la ejecución de un
programa:
- x se encuentra indefinida (u): no ha sido asignado valor alguno a la variable x
- x se encuentra definida (d): ha sido un valor asignado a la variable x (por ejemplo x = 1)
- x está referenciada (r): ha sido tomada una referencia, el valor de x no cambia (por ejemplo if
(x>0) o a=b+x).
- El flujo de datos de una variable puede ser expresado como una secuencia de estados:
d, u y r, por ejemplo → udrdrru
- Si una de estas secuencias contiene una sub-secuencia que no tiene sentido, entonces
se ha identificado una anomalía en el flujo de datos:
- ur - anomalía: un valor indefinido ha sido utilizado
- du - anomalía: un valor definido pasa a indefinido antes de ser leído
- dd - anomalía: un valor definido vuelve a ser definido antes de ser leído

Análisis del flujo de datos (3)

- Ejemplo de anomalía en flujo de datos
Para este ejemplo, los valores de El análisis del flujo de datos muestra: Este ejemplo puede ser fácilmente
dos variables son intercambiados a - La Variable Help se encuentra indefinida corregido:
través de una variable auxiliar, si no (undefined) cuando es referenciada
están ordenados por valor. (“referenced”:
anomalía-ur.
void MinMax (int Min, int
Max) - La variable Max se define (“defined”) dos void MinMax (int Min, int
{ veces sin ninguna referencia entre ambas Max)
int Help; definiciones: anomalía-dd. {
if (Min>Max) - El valor definido (“defined”) para la int Help;
{ variable Help se vuelve indefinido if (Min>Max)
Max =Help; (undefined) final del programa sin {
Max = Min; referencia: anomalía-du. Help =Max;
Help = Min; Max = Min;
} Min = Help;
End MinMax; }
End MinMax;

Las métricas y su cálculo

- Ciertos aspectos de la calidad de un programa pueden ser medidos utilizando métricas
- La métrica sólo tiene relevancia para el aspecto medido (considerado)
- La complejidad estática de un programa puede ser medida
- Actualmente hay aproximadamente 100 métricas diferentes disponibles
- Métricas diferentes tratan aspectos diferentes de la complejidad de programa
- Tamaño del programa (por ejemplo líneas de código (“Lines of Code - LOC”))
- Estructuras de control del programa (por ejemplo número ciclomático)
- Estructuras de control de datos (por ejemplo métrica de Halstead (“Halstead-Metric”)
- ¡Es difícil comparar dos métricas diferentes, incluso cuando ambas abordan el mismo
atributo del programa!

Las métricas y su significado (1)

Número ciclomático v(G)
- Métrica que mide la complejidad estática de un v(G) e  n  2p
programa basada en el grafo de su flujo de control
- Mide los caminos linealmente independientes del programa,
como un indicador de la testabilidad y la mantenibilidad
- El número ciclomático se define de la siguiente forma:
- Número de aristas: e
- Número de nodos: n
- Número de partes del programa independientes
inspeccionadas: p (normalmente 1)
- Valores hasta 10 son aceptables. Para valores
superiores el código debe ser reconstruido
(“reworked”)/mejorado (buena práctica, McCabe)


- Ejemplo III/3-2
- (Número ciclomático)
v(G) e  n  2p
- El grafo de la derecha tiene:
1
- 1 partes independientes: p = 1 1
- 14 nodos: n = 14 2
- 19 aristas: e = 19 2 3
3 4
4 6
5 7
- Esto conduce al número ciclomático: 1 5 76
12
8
8 9 11 13
9 10 10 16 11
15
v(G)= e – n + 2p 14 12
19
14 17
v(G)= 7 18 13


Número ciclomático (por McCabe) – significado
- El número ciclomático puede ser utilizado como un valor objetivo para revisiones de
código
- El número ciclomático también puede ser calculado como el número de decisiones
independientes más uno. Si las dos formas de cálculo aportan resultados diferentes se
puede deber a:
- Ramas superfluas
- Ramas faltantes
- El número ciclomático también aporta un índice del número de casos de prueba
necesarios (para alcanzar cobertura de decisión)

Resumen
- Análisis estático
- Con el uso de herramientas para la realización de análisis estático (compiladores, analizadores)
el código del programa puede ser objeto de inspección sin ser ejecutado
- Con el uso de herramientas se puede realizar el análisis estático de un programa con menor
esfuerzo que el necesario para una inspección
- Resultado del análisis

- El diagrama de flujo de control presenta el flujo del programa y permite la detección de “ramas
muertas” y código inalcanzable
- Las anomalías en los datos se detectan utilizando el análisis del flujo de datos
- Las métricas pueden ser utilizadas para evaluar la complejidad estructural conduciendo a una
estimación del esfuerzo esperado en pruebas

Capítulo No.3 ISTQB Técnica Estáticas

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Capítulo No.3 ISTQB Técnica Estáticas

Hochgeladen von

Copyright:

Verfügbare Formate

Probador Certificado – Nivel Básico

III. Técnicas estáticas

Capítulo III – Técnicas estáticas

III. Técnicas estáticas

Capítulo III – Técnicas estáticas

III. Técnicas estáticas

III. Técnicas estáticas

Objetivos de las revisiones

- Defectos en las especificaciones Diseño Funcional del

acordados (por ejemplo guías de

III. Técnicas estáticas

Ventajas y desventajas de las revisiones

III. Técnicas estáticas

Capítulo III – Técnicas estáticas

III. Técnicas estáticas

Actividades de una revisión formal (1)

- Definición de los criterios de entrada y salida para revisiones formales

- Inicio o lanzamiento (“kick-off”)

- Comprobación de los criterios de entrada (para revisiones más formales)

III. Técnicas estáticas

Actividades de una revisión formal (2)

III. Técnicas estáticas

Actividades de una revisión formal (3)

III. Técnicas estáticas

Roles y responsabilidades (1)

III. Técnicas estáticas

Roles y responsabilidades (2)

III. Técnicas estáticas

Roles y responsabilidades (3)

III. Técnicas estáticas

Roles y responsabilidades (3)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (1)

- Estas variaciones difieren en algunos aspectos de la práctica de básica esbozada

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (2)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (3)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (4)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (5)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (6)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (7)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (8)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (9)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (10)

III. Técnicas estáticas

Tipos de revisiones (IEEE 1028) (11)

III. Técnicas estáticas

Factores de éxito de una revisión (1)

III. Técnicas estáticas

Factores de éxito de una revisión (2)

III. Técnicas estáticas

III. Técnicas estáticas

Capítulo III – Técnicas estáticas

III. Técnicas estáticas

- Posibles aspectos a ser comprobados con análisis estático: