seminario de verificaciÓn & validaciÓn y pruebas
Post on 13-Feb-2017
233 Views
Preview:
TRANSCRIPT
© GMV, 2009 Property of GMV
All rights reserved
SEMINARIO DE VERIFICACIÓN & VALIDACIÓN Y PRUEBAS UNITARIAS
GMV – DEPARTAMENTO OSV
Ana Isabel Rodriguez aiodriguez@gmv.com
Facultad de Informática Mayo 2009
www.gmv.com
© 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
© GMV, 2009 Property of GMV
All rights reserved
PROCESOS DE VERIFICACIÓN
© GMVPágina 4Máster de Ingeniería de SW
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
© GMVPágina 6Máster de Ingeniería de SW
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
© GMVPágina 8Máster de Ingeniería de SW
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
© GMVPágina 11Máster de Ingeniería de SW
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.
© GMVPágina 12Máster de Ingeniería de SW
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.
© GMVPágina 13Máster de Ingeniería de SW
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
© GMVPágina 14Máster de Ingeniería de SW
PROCESOS RAMS Y PROCESO V&V
© GMVPágina 15Máster de Ingeniería de SW
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
© GMVPágina 16Máster de Ingeniería de SW
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
© GMVPágina 17Máster de Ingeniería de SW
V&V INDEPENDIENTE
© GMVPágina 18Máster de Ingeniería de SW
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
© GMVPágina 19Máster de Ingeniería de SW
ESTÁNDARES Y NORMAS
SENTINEL 3 OLCI Electronic Unit: ICM SW
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
© GMV, 2009 Property of GMV
All rights reserved
PRUEBAS UNITARIAS
© GMVPágina 21Máster de Ingeniería de SW
OBJETIVOS
SENTINEL 3 OLCI Electronic Unit: ICM SW
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.)
© GMVPágina 22Máster de Ingeniería de SW
PROCESO DE PRUEBAS UNITARIAS
SENTINEL 3 OLCI Electronic Unit: ICM SW
© GMVPágina 23Máster de Ingeniería de SW
TÉCNICAS DE PRUEBAS
SENTINEL 3 OLCI Electronic Unit: ICM SW
© GMVPágina 24Máster de Ingeniería de SW
PRUEBAS DE REGRESIÓN
SENTINEL 3 OLCI Electronic Unit: ICM SW
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
Máster de Ingeniería de SWPágina 25
© 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)
Máster de Ingeniería de SWPágina 26
© 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
Máster de Ingeniería de SWPágina 27
© 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
Máster de Ingeniería de SWPágina 28
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
Máster de Ingeniería de SWPágina 29
© 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.
Máster de Ingeniería de SWPágina 30
© 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
Máster de Ingeniería de SWPágina 33
© GMV
ENTORNO DE EJECUCIÓN DE PRUEBAS
Máster de Ingeniería de SWPágina 34
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
Máster de Ingeniería de SWPágina 35
© 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
Máster de Ingeniería de SWPágina 36
© GMV
ANÁLISIS DINÁMICO
Máster de Ingeniería de SWPágina 37
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.
© GMV, 2009 Property of GMV
All rights reserved
Gracias.
Ana Isabel Rodríguez
Jefe de Proyecto y Consultor
Software
Email: airodriguez@gmv.com
www.gmv.com
top related