SEGUNDA WEB CONFERENCIA

EVALUACION DE SOFTWARE
GEOVANNI CATALAN
TUTOR
 Conceptos fundamentales

 Error (error): Una equivocación humana

 Defecto (defect, fault, «bug»): «Se produce cuando una persona
comete un error.
Fallo (failure): «La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas dentro de los
requisitos de rendimiento especificados»
 Prueba de Caja Negra.
En programación, se denomina cajas negra a un tipo de pruebas de software que se
realiza sobre las entradas y salidas del software.
Caracteristicas
Consideran la función específica para la cuál fue creado el producto (lo que hace).
Se centra en los requisitos funcionales del Software

Las pruebas se llevan a cabo sobre la interfaz del sistema.

Reduce el número de casos de prueba mediante la elección de condiciones de entrada
y salida válidas y no válidas que ejercitan toda la funcionalidad del sistema.
No es necesario conocer la lógica del programa, únicamente la Funcionalidad que debe
realizar.
 Prueba de Caja Negra.

Intenta encontrar errores de las siguientes categorías:

• Funciones Incorrectas o Ausentes.
• Errores de Interfaz.
http://www.guiadigital.gob.cl/articulo/pruebas-de-interfaces-y-contenidos.html
• Errores en estructuras de datos o acceso a bases de datos externas.
• Errores de rendimiento.
https://platzi.com/blog/pruebas-esenciales-para-evaluar-el-rendimiento-de-software/
• Errores de inicialización y terminación.
 Prueba de Caja Negra.
Técnicas de pruebas de caja negra.

• Partición Equivalente (clases equivalencia).

• Análisis de valores límite.
• Métodos de prueba basados en grafos.
 Prueba de Caja Negra.
Método clase de equivalencia
Una partición equivalente es una técnica de prueba de Caja Negra que divide el dominio de
entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las
clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un
conjunto de estados válidos o inválidos para condiciones de entrada.
Regularmente, una condición de entrada es un valor numérico específico, un rango de valores,
un conjunto de valores relacionados o una condición lógica.
 Prueba de Caja Negra.
Método clase de equivalencia
Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices:
Si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por
debajo, en y por encima del rango.

Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del
rango.

Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o
fuera de él.

Si una entrada es booleana, hay 2 clases: si o no.

Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de
las clases.
 Prueba de Caja Negra.
Método clase de equivalencia
Criterios de identificación de las clases de equivalencias
 prueba de Caja Negra.
Método clase de equivalencia
Pasos para identificar clases de equivalencia.
1. Identificación de las condiciones de entrada del programa.
2. Identificar las clases de equivalencia:
a) Datos válidos.
b) Datos no válidos.
 Prueba de Caja Negra.
Método clase de equivalencia

Pasos para identificar casos de prueba.

1. Asignar un número único para cada clase de equivalencia.

2. Escribir casos de pruebas para todas las clases válidas.
3. Escribir casos de pruebas para todas las clases no válidas.
 Ejemplo de clases de equivalencia
Aplicación bancaria en la que el operador
debe proporcionar un código, un nombre
y una operación.
Condición de
Clases Válidas Clases Inválidas
Entrada
Código de Área 2) Código < 200.
# de 3 dígitos que no 1) 200≤ código ≤ 999 3) Código > 999.
empieza con 0 ni 1: 4) No es número.
Nombre 6) Menos de 6
Para identificar la 5) Seis caracteres. caracteres.
operación 7) Más de 6 caracteres.
8) “Cheque”
Orden 9) “Depósito” 12) Ninguna orden
Una de las Siguientes 10) “Pago factura” válida
11)“Retiro de fondos”
 Prueba de Caja Negra.
Método de análisis de valores limite

Se basa en la evidencia experimental de que los errores

suelen aparecer con mayor probabilidad en los extremos de
los campos de entrada.

Un análisis de las condiciones límites de las clases de

equivalencia aumenta la eficiencia de la prueba.

Condiciones límites: valores justo por encima y por debajo de

los márgenes de la clase de equivalencia.
 Ptueba de Caja Negra.
Método de análisis de valores limite
Las reglas para identificar las clases son:

1. Si una condición de entrada, especifica un rango que deben generar

casos para los extremos.
2. Si la condición de entrada, especifica un número finito y consecutivo de
valores, escribir casos para los números máximo, mínimo, uno más del
máximo y uno menos del mínimo de valores
 Técnica de Caja Negra.
Análisis de valores
limite

Las reglas para identificar las clases son:

Técnica de Caja Negra.
Análisis de valores limite

5 6 7 8 9 10 11 12 13 14 15
4 16
Tipos de prueba
CAJA BLANCA
En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza
sobre las funciones internas del software
 Tipos de pruebas
Pruebas de verificación: Se revisa si el resultado corresponde a la especificación del sistema,
es decir, si se esta construyendo el sistema de manera correcta.
¿Estamos construyendo el producto correctamente?
Se comprueba que el software cumple los requisitos funcionales y no funcionales de su especificación.

Pruebas de validación: se revisa si el resultado es realmente lo que el cliente quería.

Comprueba que el software cumple las expectativas que el cliente espera
1. Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema
es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o
requerimientos.
2. Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito,
mensurables para el producto. Las pruebas del sistema son una fase de pruebas de investigación, en la
que se asegura que cada componente unitario o módulo (identificado en las pruebas unitarias) interactúe
con otros componentes o módulos, tal como fue diseñado. Las pruebas de sistema tienen como objetivo
ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente,
verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen
y con el resto de sistemas de información con los que se comunica.
 Tipos de pruebas
http://www.slideshare.net/dajigar/presentacion-pruebas-presentation#btnNext
http://es.slideshare.net/aracelij/pruebas-de-software?related=3
 Plan de prueba
http://es.slideshare.net/choselin/plan-de-pruebas-15563690

http://www.guiadigital.gob.cl/articulo/desarrollo-de-un-plan-de-pruebas.html

http://www.slideshare.net/choselin/plan-de-pruebas-15563690?related=3
 PLAN DE
PRUEBA
Este documento tiene como finalidad entregar los pasos para la aplicación correcta de las estrategias y
pruebas necesarias en el sistema presente. Con el fin de verificar las funciones y procesos de los distintos
módulos del software, así como también encontrar los posibles fallos o errores que se presentan durante el
periodo de pruebas. Además validar si el sistema cumple con los requerimientos que contemplen el
funcionamiento total del mismo
Las fases en la que se realiza las pruebas son:
Planificación de la pruebas: Identificar los requerimientos para la pruebas. Desarrollar las estrategias de prueba
Identificar los recursos necesarios para realizar las pruebas. Generar el plan de pruebas.
Diseño de las pruebas: Desarrollo de las pruebas. Identificar y describir los casos de pruebas.
Implementación de las pruebas: Establecer el entorno de prueba. Desarrollar las clases de pruebas, los
componentes de pruebas y los datos de pruebas.
Ejecución de las pruebas: Ejecutar los casos de prueba. Evaluar la ejecución del proceso de prueba. Verificar los
Resultados. Investigar los resultados no esperados, registrar los defectos.
Evaluación de las Pruebas: Evaluar la cobertura de los casos de pruebas. Evaluar la cobertura de los códigos. Analizar
los defectos. Determinar si se han alcanzado los criterios de las pruebas. Crear los informes de evaluación de las
pruebas
 Lista de chequeo
checklists o Listas de Comprobación, mediante las cuales se pueden verificar de manera rápida los elementos
más importantes que debe cumplir un Sitio Web o software de aplicación ante determinados estándares o exigencias.

http://www.guiadigital.gob.cl/articulo/checklists
Matriz de prueba

Var ayuda enviada