2013A TPSW IntroduccionPruebasDeSoftware PDF

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

LA LLAMADA “CRISIS DEL SOFTWARE”
• ¿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 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.

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




BIBLIOGRAFÍA
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
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

2013A TPSW IntroduccionPruebasDeSoftware PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2013A TPSW IntroduccionPruebasDeSoftware PDF

Загружено:

Авторское право:

Доступные форматы

INTRODUCCIÓN A

750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE

• Crisis en el Desarrollo de Software

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

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

Las actividades de mantenimiento del software (corrección de

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

1970’s - Crisis del software

• Exceso en la capacidad para desarrollar software grande y

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

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

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

Norma ISO 9126 - Definiciones

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

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

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

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

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

Norma ISO 9126 - estructura

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

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

Norma ISO 9126 - 1 Modelo de Calidad

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

Norma ISO 9126 - 1 Modelo de Calidad

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

Norma ISO 9126 - 1 Modelo de Calidad

La estructura del modelo de calidad contempla tres niveles

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

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

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

Adecuación: Capacidad del producto software para proporcionar

Exactitud: Capacidad del producto software para proporcionar los

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

Norma ISO 9126 – 1 Modelo Calidad

Interoperabilidad: Capacidad del producto software para

Seguridad de acceso: Capacidad del producto software para

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

Norma ISO 9126 – 1 Modelo Calidad

Madurez: Capacidad del producto software para evitar fallar

Tolerancia a fallos: Capacidad del software para mantener un

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

Norma ISO 9126 – 1 Modelo Calidad

Capacidad de recuperación: Capacidad del producto software

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

Norma ISO 9126 – 1 Modelo Calidad

Capacidad para ser entendido : Capacidad del producto

Capacidad para ser aprendido : Capacidad del producto

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

Norma ISO 9126 – 1 Modelo Calidad

Capacidad para ser operado: Capacidad del producto software

Capacidad de atracción: Capacidad del producto software para

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

Comportamiento temporal: Capacidad del producto software para

Utilización de recursos: Capacidad del producto software para

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

Capacidad para ser analizado: Es la capacidad del producto

Capacidad para ser cambiado: Capacidad del producto software

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

Norma ISO 9126 – 1 Modelo Calidad

Estabilidad: Capacidad del producto software para evitar efectos

Capacidad para ser probado: Capacidad del producto software

Cumplimiento de la mantenibilidad: Capacidad del producto

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