INTRODUCCIÓN A LAS PRUEBAS DE SOFTWARE · •ISO 9126-4: Métricas de uso. (Software en Producción) 2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA . ESTÁNDARES

INTRODUCCIÓN A

LAS PRUEBAS DE

SOFTWARE

750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE

INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

UNIVERSIDAD DEL VALLE

SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

CONTENIDO

• Crisis en el Desarrollo de Software

• Estándares Internacionales de Calidad

• Generación 1 (ISO 9126 – ISO 14598)

• Generación 2 (SQuaRE 25000)

• Conceptos Generales de Pruebas

• Tipos de Pruebas

• Pruebas de Software en el Ciclo de Vida de Desarrollo de SW

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA

• ¿Por qué toma tanto tiempo desarrollar software?

• ¿Por qué es tan elevado su costo?

• ¿Por qué no se puede entregar programas libres de errores?

• ¿Por qué es tan costoso su mantenimiento?

• ¿Por qué resulta tan difícil constatar el progreso del desarrollo

de software?

• ¿La calidad se mide o se construye?

La crisis del software aparece en la segunda era de la evolución

de los sistemas informáticos (alrededor de 1968).

Las actividades de mantenimiento del software (corrección de

fallas, modificación por cambios de requerimientos de usuarios,

y adaptación a nuevos dispositivos) y el costo en dicho

mantenimiento comenzó a absorber recursos en una medida

alarmante.

LA LLAMADA “CRISIS DEL SOFTWARE”


1970’s - Crisis del software

• Exceso en la capacidad para desarrollar software grande y

complejo, con la tecnología existente.

• Costo de las actividades de mantenimiento del software

superior a los costos de nuevos desarrollos.

• Inicio el descenso en los costos del hardware.

• Aumento de proyectos que fallaron a causa del software.

Soluciones

• Mejores lenguajes de programación (PL/1, APL, Jovial)

• Lenguajes formales para especificar requerimientos

• Lenguajes estructurales y multitareas.

LA CRISIS DEL SOFTWARE


1985

• Crecimiento de la Industria del Software a $ USD 300 MM

• Reconocimiento de la Ingeniería de Software como una

disciplina de la Ingeniería.

• Los costos del hardware continúan disminuyendo.

• Surgen las herramientas CASE y lenguajes de

modelamiento:

• Implementación de un proceso específico de desarrollo

• Representar gráficamente los diseños del software

• Fácil de mantener, validar y entender.

Soluciones

• Muchas compañías se dieron cuenta que necesitaban

realizar mejoras significativas en su proceso de desarrollo.

LA CRISIS DEL SOFTWARE


ESTÁNDARES INTERNACIONALES DE CALIDAD DE

SOFTWARE

Norma ISO 9126 - Definiciones

ISO 9126 es un estándar internacional para la evaluación de un producto de software.

Proyecto supervisado por el grupo SQuaRE, ISO 25000:2005, el cuál sigue los mismos conceptos.

Producto de Software:

Son los ejecutables, código fuente, descripciones de arquitectura, descripciones de requerimientos, etc.

Usuario de Software:

Son los operadores (con algún rol o perspectiva de usuario) y programadores (usuarios de componentes como son bibliotecas software)



SOFTWARE

Norma ISO 9126 - Definiciones

ISO 9126 distingue entre fallo y no conformidad.

Un fallo

Es el incumplimiento de los requisitos previos. (Requisitos del Cliente)

No conformidad

Es el incumplimiento de los requisitos especificados. (Requerimientos

definidos en fase de Análisis)

Una distinción similar es la que se establece entre validación y verificación.

Verificación ¿Estamos construyendo el producto correctamente?

¿Son las actividades que aseguran la implementación correcta de una función?

Validación ¿Estamos construyendo el producto correcto?

¿Son las actividades que aseguran que el software construido corresponde con los

requerimientos?



SOFTWARE

Norma ISO 9126 - Origen

Hereda conceptos de McCall 1977: Define 3 tipos características de

calidad:

Factores (especificar): visión externa del software, cómo es visto por los

usuarios.

Criterios (construir): visión interna del software, cómo es visto por el

desarrollador.

Métricas (controlar): Se definen y se usan para proveer una escala y método

para la medida.



SOFTWARE

Norma ISO 9126 - estructura

El estándar está dividido en cuatro capítulos:

• ISO 9126-1: Métricas del proceso

• ISO 9126-3: Métricas internas (Software sin Ejecución)

• ISO 9126-2: Métricas externas (Software Ejecución)

• ISO 9126-4: Métricas de uso. (Software en Producción)



SOFTWARE

Norma ISO 9126 - 1 Modelo de Calidad

.



SOFTWARE


- Calidad del producto asociado a las diferentes fases del proceso de

desarrollo de software –



SOFTWARE


La estructura del modelo de calidad contempla tres niveles

• Característica

• Subcaracterística

• Atributo

El atributo es una entidad la cual puede ser verificada o medida en

el producto software. Los atributos no están definidos en el

estándar, ya que varían entre diferentes productos software (Tipo

de producto – plataforma de desarrollo – Modelo de desarrollo de

Software)



SOFTWARE

Norma ISO 9126 – 1 Modelo Calidad



SOFTWARE


Funcionalidad

La capacidad del producto de software para proporcionar las

funciones que satisfacen los requerimientos explícitos e implícitos

cuando el software se utiliza bajo condiciones especificas.

Adecuación: Capacidad del producto software para proporcionar

un conjunto apropiado de funciones para tareas y objetivos de

usuario especificados.

Exactitud: Capacidad del producto software para proporcionar los

resultados o efectos correctos o acordados, con el grado

necesario de precisión.



SOFTWARE


Interoperabilidad: Capacidad del producto software para

interactuar con uno o más sistemas especificados

Seguridad de acceso: Capacidad del producto software para

proteger información y datos de manera que las personas o

sistemas no autorizados no puedan leerlos o modificarlos, al

tiempo que no se deniega el acceso a las personas o sistemas

autorizados.

Cumplimiento funcional



SOFTWARE


Fiabilidad

La capacidad del producto de software para mantener un nivel

especificado de desempeño cuando está siendo utilizado bajo

condiciones especificas.

Madurez: Capacidad del producto software para evitar fallar

como resultado de fallos en el software.

Tolerancia a fallos: Capacidad del software para mantener un

nivel especificado de prestaciones en caso de fallos software o

de infringir sus interfaces especificados.



SOFTWARE


Capacidad de recuperación: Capacidad del producto software

para reestablecer un nivel de prestaciones especificado y de

recuperar los datos directamente afectados en caso de fallo.

Cumplimiento de la fiabilidad



SOFTWARE


Usabilidad

La capacidad del producto de software de ser entendido,

aprendido, utilizado y atractivo al usuario, cuando está siendo

utilizado bajo condiciones especificas.

Capacidad para ser entendido : Capacidad del producto

software que permite al usuario entender si el software es

adecuado y cómo puede ser usado para unas tareas o

condiciones de uso particulares.

Capacidad para ser aprendido : Capacidad del producto

software que permite al usuario aprender sobre su aplicación.



SOFTWARE


Capacidad para ser operado: Capacidad del producto software

que permite al usuario operarlo y controlarlo.

Capacidad de atracción: Capacidad del producto software para

ser atractivo al usuario.

Cumplimiento de la usabilidad



SOFTWARE


Eficiencia

La capacidad del producto de software para proporcionar el

desempeño apropiado, coherente a la cantidad de recursos

usados, bajo condiciones indicadas.

Comportamiento temporal: Capacidad del producto software para

proporcionar tiempos de respuesta, tiempos de proceso y

potencia apropiados, bajo condiciones determinadas.

Utilización de recursos: Capacidad del producto software para

usar las cantidades y tipos de recursos adecuados cuando el

software lleva a cabo su función bajo condiciones determinadas.

Cumplimiento de la eficiencia



SOFTWARE


Mantenibilidad

La capacidad del producto de software para ser modificado. Las

modificaciones pueden incluir correcciones, mejoras o adaptación

al software por cambios en el ambiente, o en requisitos y/o en las

especificaciones funcionales.

Capacidad para ser analizado: Es la capacidad del producto

software para serle diagnosticadas deficiencias o causas de los

fallos en el software, o para identificar las partes que han de ser

modificadas.

Capacidad para ser cambiado: Capacidad del producto software

que permite que una determinada modificación sea

implementada.



SOFTWARE


Estabilidad: Capacidad del producto software para evitar efectos

inesperados debidos a modificaciones del software.

Capacidad para ser probado: Capacidad del producto software

que permite que el software modificado sea validado.

Cumplimiento de la mantenibilidad: Capacidad del producto

software para adherirse a normas o convenciones relacionadas

con la mantenibilidad..



SOFTWARE


Portabilidad

La capacidad del producto de software para ser transferido de un

ambiente a otro.

Adaptabilidad: Capacidad del producto software para ser

adaptado a diferentes entornos especificados, sin aplicar acciones

o mecanismos distintos de aquellos proporcionados para este

propósito por el propio software considerado.

Instalabilidad: Capacidad del producto software para ser instalado

en un entorno especificado.

Coexistencia: Capacidad del producto software para coexistir con

otro software independiente, en un entorno común, compartiendo

recursos comunes.



SOFTWARE


Capacidad para reemplazar: Capacidad del producto software

para ser usado en lugar de otro producto software, para el

mismo propósito, en el mismo entorno.

Cumplimiento de la portabilidad: Capacidad del producto

software para adherirse a normas o convenciones relacionadas

con la portabilidad.



SOFTWARE

Norma ISO 9126-1 Modelo de Calidad



SOFTWARE

Norma ISO 9126 – 1 Calidad en Uso

Se mide mediante los resultados de usar el software en dicho

entorno, más que por propiedades del software en si.

Característica de mayor relevancia: usabilidad

-capacidad para ser entendido

- capacidad para ser aprendido

- capacidad para ser operado

- capacidad de atracción y cumplimiento.



SOFTWARE


Efectividad

La capacidad del producto software para permitir a los usuarios

alcanzar objetivos especificados con exactitud y completitud, en su

contexto de uso.

Productividad

La capacidad del producto software para permitir a los usuarios gastar

una cantidad adecuada de recursos. (el tiempo para completar la tarea,

el esfuerzo del usuario, materiales, o el coste financiero del uso)



SOFTWARE


Seguridad física

La capacidad del producto software para alcanzar niveles aceptables

del riesgo de hacer daño a personas, al negocio, al software, a las

propiedades o al ambiente.

Satisfacción

La capacidad del producto software para satisfacer a los usuarios en su

contexto. (Interacción con el producto)



SOFTWARE

Norma ISO 9126- 2 Métricas Externas

% Cobertura Funcionalidad

• Tiempo de análisis de fallos

• Éxitos al encontrar causas de fallo

• Confiabilidad de la funcionalidad



SOFTWARE

Norma ISO 9126- 2 Métricas Internas

%Completitud de la implementación Funcional

%Suficiencia de las Pruebas

% Funcionalidades Evidentes para el usuario

%Tiempo de Respuesta Promedio

%Trazabilidad de cambios



SOFTWARE

Norma ISO 9126- 4 Métricas de Calidad de Uso

Effectiveness metrics

% Efectividad de Tareas

% Tareas Completas

Frecuencia de Errores

Productivity metrics

Tiempo promedio de tareas

Eficiencia de tareas (Nro Tareas / Tiempo)

Costo de Productividad (Tareas/ Total costo)

% Tiempo Productivo

% Eficiencia Relativa (Uso sistema vs Experto)



SOFTWARE

Norma ISO 9126- 4 Métricas de Calidad de Uso

Safety metrics

% Seguridad de Software: (Usuarios reportan incidentes en Producción Vs Total Usuarios)

% Afectación Software: (Usuarios afectados por incidentes en Producción Vs Total Usuarios)

Daño Económico

Satisfaccion metrics

Escala de Satisfacción

Uso del Software



SOFTWARE

Norma ISO/IEC 14598

Presenta una visión general de los procesos de evaluación del

producto software y proporciona directrices y requisitos para la

evaluación.

ISO/lEC 14598-2 e ISO/lEC 14598-6 son relativas a la gestión y

soporte de la evaluación a nivel corporativo.

ISO/lEC 14598-3, ISO/lEC 14598-4 e ISO/IEC 14598-5 proporcionan

requisitos y directrices para la evaluación a nivel de proyecto.



SOFTWARE

Norma ISO/IEC 14598 - Alcance

Presenta una visión general de los procesos de evaluación del

producto software y proporciona directrices y requisitos para la

evaluación.

ISO/lEC 14598-2 e ISO/lEC 14598-6 son relativas a la gestión y

soporte de la evaluación a nivel corporativo.

ISO/lEC 14598-3, ISO/lEC 14598-4 e ISO/IEC 14598-5 proporcionan

requisitos y directrices para la evaluación a nivel de proyecto.



SOFTWARE

Norma ISO/IEC 14598 - Estructura

Proceso de Evaluación en tres situaciones:

• Desarrollo (mejora) (ISO/lEC 14598-3);

• Adquisición (ISO/lEC 14598-4);

• Evaluación independiente (incluyendo evaluación por tercera parte)

(ISO/lEC 14598-5).



SOFTWARE

Norma ISO/IEC 14598 - Estructura



SOFTWARE

Norma ISO/IEC 14598 - Modelo General de Evaluación



SOFTWARE

Norma ISO 9126

SQuaRE (Software Product Quality Requirements and Evaluation) Revision de la ISO/IEC 9126-1:2001

Unifica los conceptos de ISO 9126 – ISO 15288 (Fases del ciclo de vida de desarrollo del producto Sw)

• ISO/IEC 2500n: División de dirección de calidad.

• ISO/IEC 2501n: División del modelo de calidad.

• ISO/IEC 2502n: División de medida de calidad.

• ISO/IEC 2503n: División de requisitos de calidad.

• ISO/IEC 2504n: División de evaluación de calidad.



SOFTWARE

Norma ISO SQuaRE – Modelo 15288



SOFTWARE

Norma ISO SQuaRE - Estructura



SOFTWARE

Norma ISO SQuaRE - Estructura


CONCEPTOS GENERALES DE PRUEBAS

¿Qué son las Pruebas?

“Las pruebas muestran la presencia de errores pero nunca la ausencia de ellos”

“El proceso de operar un sistema o un componente bajo condiciones especificadas, observando o registrando los resultados, y de hacer una evaluación de un cierto aspecto del sistema o del componente.”

IEEE Estándar Glossary of Software Enginerineering Terminology





Ideas Generales - Pruebas

La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos)

El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito de una prueba)

El descubrimiento de un defecto significa un éxito para la Mejora de la Calidad del producto de Software.

Todos los errores deben ser registrados y tenidos en cuenta para su corrección.



Objetivos de las Pruebas de Software - Producto

Detectar defectos antes de que el producto sea instalado en el cliente o usuario final.

Garantizar la aceptación de los productos por parte de los clientes o usuarios finales.

Asegurar que el producto (Sistema) este listo para ser utilizado desde el punto desde las diferentes características de calidad definidas.

Mejoramiento en la satisfacción de clientes o usuarios finales.



Objetivos de las pruebas – Equipo de desarrollo

Disminución del reproceso de corrección de defectos

Apropiación de la cultura de calidad por parte del equipo humano

Medición y control del producto durante la etapa de desarrollo de

software.

Análisis de causas de defectos para apoyar la mejora de procesos de

desarrollo de software.



Pruebas Estáticas – La evaluación del software no implica

su ejecución. Se evalúan los productos intermedios de

trabajo.

Pruebas Dinámicas - La evaluación del software implica su

ejecución. Se evalúa el producto de software o un componente

funcionalmente operable.


TIPOS DE PRUEBAS DE SOFTWARE

Pruebas Estáticas de Software:

Revisión de Requerimientos

Revisión de Diseño

Inspección de Código

Revisión de Reléase



Los Tipos de Pruebas se pueden visualizar desde dos enfoques:

Estrategia (momento en el que se realiza) – Niveles Prueba

• Pruebas Unidad • Pruebas Integración • Pruebas Sistemas • Pruebas Regresión • Pruebas Alpha & Beta • Pruebas Aceptación

El objetivo

• Pruebas funcionales • Pruebas Seguridad • Pruebas Desempeño (Carga) • Pruebas Resistencia (Stress) • Pruebas Volumen • Pruebas Concurrencia


Niveles de Pruebas




Pruebas Unidad - Pretenden probar que los fragmentos individuales (unidades) que forman el sistema cumplen las especificaciones y tienen el comportamiento esperado. Cumplimiento del objetivo de un componente de software (Método-Clase)

Pruebas Integración – Módulos o componentes funcionan integrados.

Los datos enviados de un módulo o componente se reciben de manera consistente en el otro.

Pruebas Proceso – Tiene como objetivo determinar el estado de las funcionalidades independientes de un sistema. (Pueden ser modulos o componentes funcionales)



Pruebas Regresión – Asegurar que cualquier no conformidad encontrada en el sistema ha sido corregida y que ninguna de las funcionalidades liberadas previamente ha fallado como resultado de las correcciones.

Pruebas Sistemas – Los procesos soportados por la aplicación se cumplen completamente, es decir, los procesos fluyen desde su inicio hasta el final. Reutilización de Instrumentos de prueba.

Pruebas de Aceptación – Realizadas con los clientes y define su aceptación del software.¿Quién define el nivel de la prueba de aceptación?

• ¿Quién plantea y escribe los instrumentos de pruebas?

• ¿Quién ejecuta las pruebas?

• ¿Cuál es el criterio de éxito / falla para la prueba de aceptación?



Pruebas Alpha y Beta - Son pruebas de Sistemas que se realizan integrando al grupo de testers un conjunto de potenciales usuarios de la aplicación. Estos usuarios Conscientes de que el producto no ha sido liberado usan su experiencia para advertir sobre potenciales fallas de la aplicación. La diferencia fundamental entre estas pruebas radica en la ubicación del equipo de pruebas; Alpha son las pruebas que se realizan internamente en la casa de software y Beta las que se realizan externamente en el cliente.





Pruebas de Seguridad - La prueba de seguridad intenta verificar que los

mecanismos de protección incorporados en el sistema lo protegerán, de

hecho, de accesos impropios. Durante la prueba de seguridad, el

responsable de la prueba desempeñe el papel de un individuo que desea

entrar al sistema.

Pruebas Rendimiento

• Carga de Información

• Volumen de Datos

• Concurrencia (Funcionalidades o Usuarios)

• Stress


PRUEBAS EN EL CICLO DE DESARROLLO DE SOFTWARE

Pruebas en el Proceso de desarrollo de Software











Engineering models and software quality models: an example and a discussion –

Paolo Salvaneschi, Ugo Piazzalunga. May 2008

ISO/IEC SQuaRE. The second generation of standards for software product

quality, Witold Suryn, Alain Abran. Department of Electrical Engineering, École de

Technologie Supérieure.

ISO/IEC 9126 Information technology - Software Product Evaluation- Quality

characteristics and guidelines for their use.

ISO/lEC 2382-1:1993, Tecnología de la información. Vocabulario. Parte 1:

Términos fundamentales.

ISO 8402:1994,Gestión de la calidad y aseguramiento de la calidad. Vocabulario.

ISO/lEC 9126-1:2001, Tecnología de la Información. Calidad del producto

software. Parte 1: Modelo de calidad. ISO/lEC 12207:1995 - Tecnología de la

información. Procesos de ciclo de vida del software.

BIBLIOGRAFÍA


http://portal.acm.org/citation.cfm?id=1370731.1370741&coll=ACM&dl=ACM&CFID=74474488&CFTOKEN=75666455

http://portal.acm.org/author_page.cfm?id=81100396819&coll=ACM&dl=ACM&CFID=75821306&CFTOKEN=11963871





ISO/IEC 9126: Software Engineering - Product quality. To be published in

2003

ISO/IEC 14598: Information Technology – Software product evaluation. 1999-

2001

Krause P., Freimut B., Suryn W., “New Directions in Measurement for Software

Quality Control.” Proceedings of STEP2002, Computer Society Press, 2003

Suryn W., Abran A., Bourque P., Laporte C., “Software Product Quality

Measurement and Evaluation: An integrated life cycle quality model using TL9000

and ISO/IEC 9126.” Submitted to JISBD 2003 - VIII Jornadas de Ingeniería del

Software y Bases de Datos 12-14 November 2003, Alicante, Spain

Bevan N., Bohomolni I., “Incorporating user quality requirements in the software

development process,” In: Proceedings of 4th International Software Quality

Week Europe, Brussels, pages 1192-1204, 2000.

BIBLIOGRAFÍA


Vliet, H., Software Engineering, Principles and Practice, Second Edition.

John Wiley & Sons, 2002

Pfleeger S.L. “Software Engineering, Theory and Practice” Second Edition,

Prentice Hall 2001

BIBLIOGRAFÍA


Documents

INTRODUCCIÓN A LAS PRUEBAS DE SOFTWARE · •ISO 9126-4: Métricas de uso. (Software en Producción) 2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA . ESTÁNDARES