seminario de verificaciÓn & validaciÓn y pruebas

© GMV, 2009 Property of GMV

All rights reserved

SEMINARIO DE VERIFICACIÓN & VALIDACIÓN Y PRUEBAS UNITARIAS

GMV – DEPARTAMENTO OSV

Ana Isabel Rodriguez [email protected]

Facultad de Informática Mayo 2009

www.gmv.com

mailto:[email protected]

© GMVPágina 2Máster de Ingeniería de SW

CONTENIDOS

Procesos de Verificación

1. Procesos de Ingeniería Software

2. Actividades en Verificación y Validación

3. Relaciones con procesos RAMS

4. Verificación y Validación Independiente

5. Procesos de Verificación

Prubas unitarias

1. Fase de pruebas unitarias

2. Análisis estático y dinámico


All rights reserved

PROCESOS DE VERIFICACIÓN


ISO/IEC 12207- PROCESOS CICLO DE VIDASupporting

Quality assurance

Verification

Validation

Joint review

Audit

Product evaluation

Usability

Documentation

Configuration management

Problem resolution management

Change request management

SUPPORTING

Management

Organisational alignment

Organisational management

Project management

Quality management

Risk management

Measurement

Process Improvement

Process establishment

Process assessment

Process improvement

Resource and Infrastructure

Human resource management

Training

Knowledge management

Infrastructure

ORGANISATIONAL

Engineering

Requirements elicitation

System requirements analysis

System architectural design

Software requirements analysis

Software design

Software construction

Software integration

Software testing

Software installation

System integration

System testing

System and software maintenance

Acquisition

Acquisition preparation

Supplier selection

Contract agreement

Supplier monitoring

Customer acceptance

Supply

Supplier tendering

Product release

Product acceptance support

PRIMARY

Operation

Operational use

Customer support

Reuso

Asset Management

Reuse progam management

Domain Engineering

© GMV

16% 53% 31%

27% 33% 40%

26% 46% 28%

28% 49% 23%

0% 20% 40% 60% 80% 100%

1994

1996

1998

2000

Histórico de proyectos (1994-2000)

Éxito

Finalizados

Fracaso

Página 5Máster de Ingeniería de SW

¿POR QUÉ?

El informe CHAOS de Standish Groupexaminó hasta 30.000 proyectos en EEUU desde 1994

demuestra que las mejoras en la gestión del proceso y el cumplimiento de estándares y buenas prácticas aumenta el índice de proyectos finalizados con éxito.

Detección y corrección temprana de errores es vital, reduce costes y tiempo

El coste de corregir un error software se multiplica según se progresa en su desarrollo.

45% - 50% de los defectos tienen su origen en la fase de requisitos.

Pru

eb

as

Có

dig

o

Dis

eñ

o

Re

qu

isito

s

Pruebas

Diseño

05

101520253035404550

Coste

relativo para

correcciones

Tipo de defecto

Coste relativo en corrección de errores por fase


CICLO DE VIDA SOFTWARE

V&V

Proceso de desarrollo que emplea métodos rigurosos para evaluar la corrección y calidad del producto a lo largo de todo su ciclo de vida.

© GMV

VERIFICACIÓN

Verificación: ¿ Estamos fabricando correctamente el Software ?

Es el proceso de determinar si los productos resultantes de una fase del Ciclo de Vida Software (CVS) cumplen los requisitos establecidos en la fase anterior

El producto resultante es completo, consistente y correcto para comenzar la siguiente fase

Máster de Ingeniería de SW Página 7


VERIFICACIÓN EN CICLO DE VIDA PROYECTOS

© GMV

VALIDACIÓN

Validación: ¿ Estamos fabricando el Software correcto?

Es el proceso de prueba del software para asegurar que cumple su especificación.

Este proceso asegura que el software fabricado se comporta como se espera y de acuerdo a las expectativas del cliente.

Definición ANSI/IEEE Validación:

'the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements'.

Máster de Ingeniería de SW Página 9

© GMV

ACTIVIDADES DE VERIFICACIÓN

Technical reviews, walkthroughs and software inspections

checking that software requirements are traceable to user requirements;

checking that design components are traceable to software Requirements;

unit testing;

integration testing;

system testing;

acceptance testing;

audit.

Máster de Ingeniería de SWPágina 10


V&V PREVENCIÓN Y ELIMINACIÓN DE FALLOS

FAULT ERROR FAILURE FAULTactivation propagation causation

Fault: defect (either hardware or software) within a system or user procedure.

Error: detected deviation from requirements specification.

Failure: software component inability to perform a required function (either loss of function or malfunctions)

CAUSAS DE FALLOS

SW requirements are incorrect, incomplete or ambiguous, e.g. unhandled states or unhandled environmental conditions, non-conformance in the software or deficiencies in the code (they cause software faults)

SW requirements have not been implemented, validated and verified properly.

SW has not been tested enough or has been tested inadequately.

Software Defects.

Software is used incorrectly.

Poor design or implementation.

rare events can lead to uncontrolled states.


PROCESOS GESTIÓN DE FALLOS

Fault prevention techniques can be used in any engineering or development activities to prevent faults.

Fault tolerance techniques are direct mechanisms to be implemented in the design and the code in order to tolerate faults.

To verify that tolerance techniques are being used as designed for, fault removal techniques are needed : detected deviation from requirements specification.


PROCESOS RAMS Y PROCESOS DE DESARROLLO

Análisis de dependencia (RAMS) se implementa como un proceso independiente o integrados en el proceso de desarrollo

Requisitos RAMS impactan las actividades V&V


PROCESOS RAMS Y PROCESO V&V


V&V INDEPENDIENTE

La independencia es una característica reconocida como altamente positiva en muchas áreas de la sociedad

– Por ejemplo poderes legislativo, ejecutivo y legislativo; comités médicos, jurados, etc.

Independencia añade a la V&V importantes ventajas:

– Separación de intereses

Se evitan conflictos de intereses internos en una organización. Una organización independiente garantiza que requisitos importantes no sean ignorados en el proceso de toma de decisiones

– Diferentes puntos de vista

Una segunda opinión siempre es interesante para eliminar ambigüedades u omisiones

– Efectividad y productividad

Las actividades de V&V son llevadas a cabo por personal experto, con competencias específicas en el área de V&V


TIPOS DE INDEPENDENCIA

Clásica V&VI - Incluye técnica, financiera y de gestión

– Un organización o empresa independiente de los suministradores del software lleva a cabo actividades de verificación y validación de la

especificación, diseño y código del producto

Interna V&VI – Independencia técnica

– Las actividades son realizadas por personal de la misma organización, formando parte del mismo equipo de proyecto y sin participar en el proceso de desarrollo: especificación, diseño y código

Modificada V&VI - Independencia técnica y financiera

– Las actividades de V&V se realizan como proyecto independiente con su propio presupuesto

• La independencia no es muro infranqueable entre el equipo de desarrollo y equipo de V&V, fomentamos un entorno de participación y aprendizaje hacia un objetivo común, conseguir el éxito del proyecto


V&V INDEPENDIENTE


V&V INDEPENDIENTE – METEOSAT MSG

SENTINEL 3 OLCI Electronic Unit: ICM SW

108 35

20 34

128 69

0% 20% 40% 60% 80% 100%

Éxito

Fallidas

Total

Procedimientos deanálisis

Pruebas ejecutadas

www.esa.intMSG-Enero/2006

http://www.esa.int/


ESTÁNDARES Y NORMAS


Referencias a normas y estándares relacionados con VV

IEEE Standard for Software Verification and Validation. IEEE Std 1012-1998

SPICE (Software Process Capability Determination)

– Comité internacional de estándares de ingeniería de software ISO/ICE JTC 1/SC 7

– Proporciona una plataforma para evaluación de los procesos software

– ISO/IEC TR 15504-1:1998(E), Information Technology - Software Life Cycle Processes

SPiCE for SPACE (S4S) Assessment Model. Cómo implementar la evaluación y mejora de procesos. Incluye nuevos procesos de soporte o support, e incluye V&VI

ESA Guide for Independent Software Verification and Validation. Issue 2 Jan. 2009


All rights reserved

PRUEBAS UNITARIAS


OBJETIVOS


Las pruebas unitarias verifican que los subsistemas y componentes software funcionan aislados correctamente: se ejecuta satisfactoriamente la función que se le ha asignado, el flujo de control es correcto dentro del módulo y los datos se calculan con la precisión y en el tiempo requerido.

Se complementan con

― Análisis estáticos (reglas de codificación y programa de métricas)

― Análisis de cobertura para comprobar que efectivamente se ejecutan las áreas deseadas del SUT (SW Under Test)

― Ánalisis de prestaciones para estudiar el consumo de recursos (CPU, memoria, etc.)


PROCESO DE PRUEBAS UNITARIAS



TÉCNICAS DE PRUEBAS



PRUEBAS DE REGRESIÓN


Pruebas de regresión permite ejecutar automáticamente todos las pruebas necesarias para probar los módulos modificados, analizando los resultados de la ejecución de la prueba.

© GMV

PREUBAS UNITARIAS EN EL PROYECTO OLCI-ICMSW

Características del proyecto:

Lenguaje de programación Ada

Perfil Ravenscar

Arquitectura ERC32

Estas características implican:

Uso de herramientas diseñadas para Ada

Compilador y RTS sólo con funcionalidades Ravenscar

Uso de simulador de ERC32


© GMV

SENTINEL 3 OLCI ICM SW

OLCI Mission

– Visible light images of the oceans, coastal waters & land vegetation

– Continuation of the relevant mission of MERIS on ENVISAT (GMV OBSW)

Specification, design and development of onboard ICM SW (Instrument Control Module)

Based on latest generation TAS-I Laben standard NEWERC-32 Processor Module board (ERC-32 single chip TSC695F CPU).

1553-MIL-STD, SpaceWire and RS-422 links.

Object Oriented Methodology: UML using Together.

GNAT Pro for ERC-32 (Ada 95) with Ravenscar Profile (RCM)


© GMV

ENTRADAS A PRUEBAS UNITARIAS

Entradas a la fase de codificación y pruebas:

Diseño detallado HRT-UML

Plan de verificación y validación. Describe:

Herramientas a usar

Operaciones de verificación

Requisitos de cobertura de código (Análisis dinámico)

Reglas de codificación. Incluye:

Normas y operaciones del lenguaje Ada (Análisis Estático)

Manuales o guías de las herramientas usadas


© GMV

ACTIVIDADES DE PRUEBAS UNITARIAS

Actividades para cada uno de los paquetes Ada:

Análisis estático de código, proceso de métricas de acuerdo con el plan de calidad

Comprobaciones de reglas de programación

Implementación y ejecución de la prueba unitaria

Análisis dinámico del código


Reglas de codificación incluyen normas y operaciones del lenguaje Ada que se deben usar en la implementación

Experiencia de GMV en el uso del lenguaje Ada y de la implementación de sistemas de tiempo real

El objetivo es ayudar a generar un código de calidad que facilite su desarrollo y mantenimiento, evitando el uso de soluciones que puedan provocar problemas

© GMV

ANÁLISIS ESTÁTICO

Objetivo: comprobar si se cumplen las normas de programación y las métricas establecidas

Nº Máximo de anidamiento:

8 en software no crítico (Categoría C)

5 en software crítico (Categoría B)

Nº Máximo de complejidad ciclomática

15 en software no crítico (Categoría C)

12 en software crítico (Categoría B)

Nº Máximo de sentencias de un subprograma (max. 250)

Nº Máximo de sentencias en un fichero fuente (max. 1500)

Porcentaje mínimo de comentarios en cada fichero (min. 20%-max.200%)

Herramienta: AdaControl


© GMV

PROGRAMA DE MÉTRICAS

LOC (Lines of Code): nº total de líneas de código incluyendo comentarios.

eLOC (efective LOC): nº de líneas de código sin incluir comentarios, blancos o llaves de inicio de bloques (max. 200 lines).

lLoc (logical LOC): nº de líneas que contienen instrucciones de código y que terminan con un punto y coma.

Comment: nº de líneas que son comentarios.

Lines: nº total de líneas.

File Function Count: nº de funciones implementadas en cada fichero fuente.

Cyclo Complexity: Complejidad ciclomática.

Interface Complexity: medida de complejidad para las funciones que es el resultado de sumar el número de parámetros de entrada con el número de instrucciones de retorno internas de la función.


© GMV

ANÁLISIS ESTÁTICO: EJEMPLO

Máster de Ingeniería de SW

Página 31

Métricas de un fichero:

Function: hk_register_defaults_

Complexity Param 0 Return 1 Cyclo Vg 28 Total 29

LOC 408 eLOC 298 lLOC 110 Comment 1 Lines 411

~~ Total File Summary ~~

~~ File Functional Summary ~~

File Function Count ...: 1

Total Function LOC.....: 408 Total Function Pts LOC : 3.2

Total Function eLOC....: 298 Total Function Pts eLOC: 2.4

Total Function lLOC....: 110 Total Function Pts lLOC: 0.9

Total Function Params .: 0 Total Function Return .: 1

Total Cyclo Complexity : 28 Total Function Complex.: 29

Max Function LOC ......: 408 Average Function LOC ..: 408.00

Max Function eLOC .....: 298 Average Function eLOC .: 298.00

Max Function lLOC .....: 110 Average Function lLOC .: 110.00

Max Function Parameters: 0 Avg Function Parameters: 0.00

Max Function Returns ..: 1 Avg Function Returns ..: 1.00

Max Interface Complex. : 1 Avg Interface Complex. : 1.00

Max Cyclomatic Complex.: 28 Avg Cyclomatic Complex.: 28.00

Max Total Complexity ..: 29 Avg Total Complexity ..: 29.00

© GMV

ANÁLISIS ESTÁTICO: EJEMPLO

Máster de Ingeniería de SW

Página 32

Métricas de un fichero:

~~ File Functional Summary ~~

File Function Count ...: 29

Total Function LOC.....: 183 Total Function Pts LOC : 2.7

Total Function eLOC....: 124 Total Function Pts eLOC: 2.2

Total Function lLOC....: 95 Total Function Pts lLOC: 1.2

Total Function Params .: 53 Total Function Return .: 29

Total Cyclo Complexity : 33 Total Function Complex.: 115

Max Function LOC ......: 15 Average Function LOC ..: 6.31

Max Function eLOC .....: 13 Average Function eLOC .: 4.28

Max Function lLOC .....: 10 Average Function lLOC .: 3.28

Max Function Parameters: 9 Avg Function Parameters: 1.83

Max Function Returns ..: 1 Avg Function Returns ..: 1.00

Max Interface Complex. : 10 Avg Interface Complex. : 2.83

Max Cyclomatic Complex.: 3 Avg Cyclomatic Complex.: 1.14

Max Total Complexity ..: 11 Avg Total Complexity ..: 3.97

________________________________________________________________________

End of File: X:\work\ilvc\metricas SW\src\pus\func_laser.c

En este caso la métrica que no se cumple es el número de parámetros

© GMV

COMPROBACIÓN REGLAS DE PROGRAMACIÓN

Objetivo: comprobar si se cumplen las reglas de programación contenidas en el documento reglas de codificación

Comprobación automático (40%) e inspección de código.

Herramientas:

AdaControl: normas de programación

GnatCheck: normas de programación específica

Gnat Pretty Printer: formato y sintáxis


© GMV

ENTORNO DE EJECUCIÓN DE PRUEBAS


LINUX

TSIM program

TSIM simulation thread

AdaTEST

Procedure

TSIM

SRAM

Test results data

base

APSW

under

test

RS422

test results standard output of

TSIM program

© GMV

IMPLEMENTACIÓN Y EJECUCIÓN

Entorno de pruebas:

AdaTest95 para generar pruebas (programa ejecutable y stubs)

TSIM (simulador de ERC32) para ejecutar pruebas

TSIM escribe el resultado en su salida estandar.

Cada prueba unitaria de AdaTest se divide en varios test cases.

Elegir valores significativos como parámetros de entrada (limítrofes, fuera de rango…)

Cada test case desarrolla las siguientes operaciones:

1. Inicialización de los valores globales

2. Configuración de los stubs a usar

3. Inicialización de los parámetros in e in-out

4. Ejecución de módulo bajo prueba

5. Comprobación de los valores out e in-out

6. Comprobación de los valores globales


© GMV

ANÁLISIS DINÁMICO

Objetivo: Verificación de requisitos de cobertura.

Los requisitos de cobertura (ESA) dependen de la criticidad del software:

Categoría C: 100% de instrucciones ejecutadas en cada prueba

Ejecución de instrucciones simples y al menos una rama de las complejas (100% statement coverage)

Ejemplo instrucción compleja: 100% cobertura si se ejecuta al menos una de sus ramas.

if Data = 1 then...

else...

end if


© GMV

ANÁLISIS DINÁMICO


Categoría B: 100% de decisiones ejecutadas en cada prueba (100% cobertura)

Decisiones booleanas: al menos una vez cada uno de los valores. (if, elif y exit when)

Decisiones de bucle: ejecución completa de una iteración y terminación normal del bucle. Ej. Terminación no esperada (50% cob.)

for I in 1..10 loop -- Exit expected in I = 10…exit when I = 9;…

end loop;

Otras decisiones: ejecución completa de cada una de las clausulas de instrucciones case y select. Ejemplo: 100% cobertura para Case statements

Herramienta: AdaTest con el módulo bajo prueba previamente instrumentalizado.

seminario de verificaciÓn & validaciÓn y pruebas

Documents