El documento describe diferentes técnicas de pruebas de software, incluyendo pruebas estáticas, funcionales (caja negra) y estructurales (caja blanca). También discute la predicción de errores y los conceptos asociados con la calidad del software. Las revisiones ayudan a encontrar defectos temprano, mientras que el análisis estático puede encontrar fallas sin ejecutar el código. Las pruebas de caja negra se basan en los requisitos funcionales, y las pruebas de caja blanca se enfocan en la estruct

1. Metodología de Pruebas de Software
TECNICAS ESTATICAS Y EL PROCESO DE PRUEBAS
Técnicas estáticas no ejecuta código
Las revisiones se realizan con el objeto de mejorar
la calidad del producto
• Ventajas.
• Costos más bajos y un potencial de ahorro
relativamente alto.
• Defectos en la documentación son detectados y
corregidos temprano.
• Los documentos de alta calidad mejoran el proceso
de desarrollo.
• Mejora el índice de comunicación / intercambio de
conocimiento (•Know-how•)
• Desventajas.
• Se podrían presentar situaciones de tensión en el
caso de enfrentamientos directos con
el autor.
• Los expertos involucrados en las revisiones deben
adquirir conocimientos específicos
del producto, es necesario una buena preparación.
• Inversión considerable de tiempo (del 10% - 15% del
presupuesto total)
• Moderador y participantes influyen directamente en
la calidad de la revisión.
Fases de un revisión
• Fase de planificación
Organización de la revisión, selección de los
miembros de la revisión.
• Preparación de la organización e inicio (KICK-OFF•).
Distribución de los objetivos de la revisión e
información adicional.
• Preparación individual.
Los evaluadores inspeccionarán los objetos,
comentan los elementos en caso de necesidad
de aclaraciones.
• Reunión de revisión.
Reunión de los miembros de la revisión, los
evaluadores presentan sus resultados.
• Seguimiento (•follow up•)
• El resultado de la revisión es distribuido al
responsable de la revisión
estableciendo:
Objeto sujeto a pruebas, participantes y roles.
Recomendaciones realizadas por los evaluadores.
Roles y responsabilidades
• Director • Responsable • Jefe de proyecto
Inicia la revisión, decide respecto de los
participantes y asigna recursos.
• Moderador
Dirige la reunión / discusión, hace de mediador
, concluye resultados.
• Autor.
Expone su trabajo a la crítica, lleva a cabo
los cambios recomendados.
• Evaluador (también: Inspector o revisor)
Reunión de los miembros de la revisión, los

2. evaluadores presentan sus resultados.
• Escriba (también escribano)
Documenta todos los asuntos, problemas y putos
que hubieran sido identificados.
Tipos de revisiones
-Inspección
-•Walktrrough•
-Revisión técnica
-Revisión informales
Resumen
• Análisis estático
• Con el uso de las herramientas para la realización
de análisis estático (compiladores,
analizadores) el código del programa puede ser objeto
de inspección sin ser ejecutado
• Con el uso de las herramientas se puede realizar el
análisis estático de un programa
con un esfuerzo menor que el necesario para una
inspección.
• Resultado del análisis:
• El diagrama de flujo de control presenta el flujo
del programa y permite la detección de
•ramas muertas• y código inalcanzable.
• Las anomalías en los datos se detectan utilizando
el análisis del flujo de datos.
• Las métricas pueden ser utilizadas par evaluar la
complejidad estructural conduciendo a
una estimación del esfuerzo en pruebas a esperar.
Resumen: Puntos clave
• Las revisiones ayudan a encontrar defectos en el
desarrollo y la documentación de
prueba, se debe aplicar temprano.
• Los tipos de examen: informal, tutorial,
técnico / revisión por pares, la inspección.
• El análisis estático puede encontrar las fallas
y dar información sobre el código sin ejecutarlo
¿ QUE ES UNA TECNICA DE PRUEBA?
El proceso de desarrollo de pruebas que se describe
en esta sección puede
llevarse a cabo de varias maneras:
• desde muy informal, con poca o ninguna documentación
• hasta muy formal.
PRUEBAS DE CAJA BLANCA Y CAJA NEGRA
Tres tipos de técnica sistemática
• Estática (no ejecución)
• examen de la documentación, los listados de
código fuente?, etc
• Funcional (Caja Negra)
• funcionalidad basada en el comportamiento de
software
• Estructural (Caja Blanca)
• basado en la estructura de software
PRUEBAS DE CAJA NEGRA

3. • No se basan en conocimiento del diseño o del código
interno. Las pruebas se
basan solo en los requisitos y su funcionalidad. Solo
se conocen las entradas
válidas y los resultados esperados.
• Facilita la separación de funciones entre •tester•
y desarrollador.
• Facilita, desde fases iniciales, la planificación
de las pruebas.
• Más eficiente en grandes piezas de código.
• Las pruebas se realizan •casi• desde el punto de
vista del usuario.
• Ayuda a identificar problemas en las especificaciones
y a detectar y evitar errores
antes.
• Están limitadas por las posibilidades •ocultas• del
código.
• Repetición •inconscientemente• de pruebas.
• Importancia de cobertura de los requisitos.
• Mayor dificultad en la identificación del origen del
problema, por tanto mayor
tiempo en depuración y corrección.
PRUEBAS DE CAJA BLANCA
• Se basan en conocimiento de la lógica interna del
código de la aplicación.
• Las pruebas se basan en cobertura de sentencias de
código, condiciones, ramas de
código y caminos.
• Las pruebas no se pueden comenzar a diseñar hasta
que no está el código.
• El código debe ser fácilmente legible.
• Apoyarse en herramientas de monitorización para
encontrar los puntos de mayor uso de
CPU.
• Ayuda a conseguir buenos y eficientes juegos de
datos para las pruebas.
• Probar intensivamente los parámetros de entrada a
las funciones.
• Mayor claridad a la hora de reportar los defectos,
por tanto mayor rapidez
en la corrección.
• Ayuda a eliminar líneas de código •extra•.
• Pruebas Unitarias, Análisis estático y dinámica,
Cobertura de sentencias, Cobertura de
ramas, Pruebas de seguridad.
Caja Negra versus caja blanca
Caja Negra.
En todos los niveles, pero mas dominante en los
niveles de pruebas
Caja blanca
utilizada predominantemente a niveles más bajos para
complementar caja negra
PREDICCION DE ERRORES
Técnicas de prueba No sistemáticas •
basadas e la experiencia
• Predicción de errores (•error guessing•) en practica
• Lista de comprobación de errores.
• Enumerar posibles errores.
• Factores ponderados dependientes del riesgo y

4. probabilidad de ocurrencia.
• Diseño de caso de prueba
• Creación de casos de prueba dirigidos a producir
los errores de la lista.
• Asignar prioridades a los casos de prueba
considerando al valor de su riesgo.
• Actualizar la lista de errores durante las pruebas
• Procedimiento iterativo
• Es útil una colección estructurada de experiencia
cuando se repite el procedimiento en
futuros proyectos.
Resumen
• Las técnicas basadas en la experiencia complementan
las técnicas sistemáticas para
determinar casos de prueba.
• Las técnicas basadas en la experiencia dependen en
gran medida de la habilidad
individual del probador.
• La predicción de errores y las pruebas exploratorias
son dos de las técnicas mas
ampliamente utilizadas de pruebas basadas en la
experiencia.
Conceptos asociados a Calidad
-Aseguramiento de la Calidad del Software
-Control de Calidad
-Defecto o Fallo
-Error
Calidad del producto:
? correctitud usabilidad ? mantenibilidad
? confiabilidad ? rendimiento? disponibilidad
robustez ? performance ? amigabilidad
Reusabilidad ? portabilidad ? etc.
Calidad del proceso:
? El proceso debe estar definido, documentado y debe
ser practicado y medido
Criterios de Calidad
Es necesario establecer criterios para medir y evaluar
la calidad del producto y del proceso.
Funciones y Actividades de SQA
Plan de Calidad:Sección Gestión,Documentación.
Estándares, Prácticas y Convenciones
Revisiones y Auditorias,Pruebas
Métodos y Herramientas
Estándares de Calidad
ISO 9000:
Proceso de Mejora Continuo: CMM y CMMI
VISTAS DE LA CALIDAD
TRASCENDENTAL (calidad = excelencia innata)
BASADA EN USUARIO (adecuación al propósito)
BASADA EN FABRICANTE (conformidad con requisitos)

5. BASADA EN PRODUCTO (económica)
BASADA EN VALOR (precio asequible)
Calidad:
Característica o atributo de algo [Diccionario]
Capacidad de un conjunto de características inherentes
a un producto, sistema o proceso para satisfacer
requerimientos [ISO 9000:2000]
Grado en el cual un sistema, componente o proceso
satisface los requerimientos especificados y las
expectativas o necesidades del cliente o usuario
Calidad de software: concordancia del producto con:
los requerimientos funcionales y no funcionales
explícitamente establecidos por los clientes o usuarios
los estándares de desarrollo explícitamente
documentados
las características implícitas que se espera de
todo software
Totalidad de características de un producto o servicio
que le confieren su aptitud para satisfacer unas
necesidades expresadas o implicitas
CMM y CMMI

6. BASADA EN PRODUCTO (económica)
BASADA EN VALOR (precio asequible)
Calidad:
Característica o atributo de algo [Diccionario]
Capacidad de un conjunto de características inherentes
a un producto, sistema o proceso para satisfacer
requerimientos [ISO 9000:2000]
Grado en el cual un sistema, componente o proceso
satisface los requerimientos especificados y las
expectativas o necesidades del cliente o usuario
Calidad de software: concordancia del producto con:
los requerimientos funcionales y no funcionales
explícitamente establecidos por los clientes o usuarios
los estándares de desarrollo explícitamente
documentados
las características implícitas que se espera de
todo software
Totalidad de características de un producto o servicio
que le confieren su aptitud para satisfacer unas
necesidades expresadas o implicitas
CMM y CMMI