PRUEBAS DE VALIDACIÓN DE SOFTWARE
Álvarez, DavidGasperin, LucíaHerrera, JorgeRivas, EdixsonRodríguez, RonaldSeijas, Fanny
Examen que se hace para demostrar o comprobar
los conocimientos o aptitudes de alguien.
Acción y efecto de probar.Razón, argumento,
instrumento u otro medio con que se pretende
mostrar y hacer patente la verdad o falsedad de algo.Indicio, señal o
muestra que se da de algo.
Ensayo o experimento que se hace de algo, para saber cómo resultará en su forma
definitiva.
Análisis médico.
Muestra, cantidad pequeña de un alimento destinada a
examinar su calidad.
Prueba según el DICCIONARIO DE LA LENGUA ESPAÑOLA - Vigésima segunda edición
Según IEEE
DEFECTO
ERROR FALLA
Error Vs Defecto Vs Falla
Según Cem Kaner
¿Por qué probamos?
¿Qué estamos tratando de aprender?
Misión.
Estrategia.
¿Cómo organizam
os el trabajo para
alcanzar la misión? Resultados esperados
¿Cómo sabemos quepaso o fallo las pruebas?
¿Cuánto nos tomaría completar la
tarea de pruebas?
Imposible.
Dep
ende
.
¿Cuá
ntas
pru
ebas
son
sufic
ient
es?
Estrategias de Pruebas
Evaluación:Criterio para evaluar.
Testers: ¿Quién hace las pruebas?
Cubrimiento: ¿Qué estamos probando?
Riesgo: ¿Qué estamos probando?
Actividades: ¿Cómo probamos?
Estrategias de Pruebas
Pruebas sin Estrategias
MotivaciónLas pruebas son incómodasLa pruebas son aburridas“Estoy seguro de que lo he codificado bien”
Probar todo junto, al final – Big-BangFalla por todas partesMuy difícil diagnosticar las causas de los fallosMuy costoso de arreglarResultado productos finales defectuosos
Estrategias de Pruebas de Software Convencionales y Orientados a Objetos
Según Gonzáles, Javier. (2002), el aseguramiento de la calidad toma en cuenta todas aquellas acciones
planificadas y sistemáticas necesarias para proporcionar la confianza de que un producto o
servicio satisfaga los requisitos de calidad establecidos.
Algunos autores como Krutchen, Pressman, Pfleger, Cardoso y Sommerville afirman que el proceso de ejecución de Pruebas
debe ser considerado durante todo el ciclo de vida de un proyecto, para así obtener un
producto de alta calidad. Su éxito dependerá del seguimiento de una Estrategia de
Prueba adecuada.
“Propiciar la calidad en el Software”
Según Sommerville, Bosch, Dromey, Pressman entre otros, los requerimientos del software se clasifican en:
Requerimientos Funcionales (RF) y Requerimientos No Funcionales (RNF).
Requerimientos del Software
Proceso de desarrollo de Software
Requisitosdel usuario Sistema software
“Encontrar Errores”
Análisis
Diseño
Codificación
Integración
Mantenimiento
P. unidadesDoc. Diseño
Cod. Módulos
P. integración
Cód. Completo
P. validación
Doc. Requisitos
Actividades de Prueba de Software
“La estrategias de Prueba permiten identificar las Características de Calidad que deben ser evaluadas en un software:”
Estrategias de Pruebas de Software Convencionales y Orientados a Objetos
Convencional
Fiabilidad
Usabilidad
Eficiencia
Mantenibilidad
Portabilidad.
O.O.
Ortega, M. Pérez, M. & Rojas, T. (2003). Construction of a Sistemic Quality Model for Evaluating aSoftware Product. Software Quality Journal, 11, 219-242.
. Concepto deoperación
Análisis de riesgos
An.Riesgo.
Análisis de riesgos
Análisis de riesgos
-
PROGRESOA TRAVÉS
DE LAS ITERACIONES
DESARROLLAR, VERIFICARPRODUCTO DE SIGUIENTE NIVEL
-
Codificar
PLANIFICAR SIGUIENTEFASE
Simulaciones, modelos,pruebas comparativasPlan de
requerimientosPlan de ciclo
de vida
Plan dedesarrollo
Plan de integracióny prueba
REVISIÓN Proto-tipo 1
Prototipo 2Prototipo 3
Prototipooperativo
Requerimientosde software
Validación derequerimientos
Diseño delproducto
Diseño de validacióny verificación
Diseñodetallado
Prueba deunidad
Prueba deintegraciónPrueba de
aceptaciónExplotación
EVALUAR ALTERNATIVAS,IDENTIFICAR Y RESOLVER RIESGOS
DETERMINAR OBJETIVOS,ALTERNATIVAS YRESTRICCIONES
Barry Boehm:
divide en 4 sectores definición de objetivos,
restricciones del producto y proceso, plan de administración,...
evaluación y reducción de riesgos (por ejemplo, mejor definición de requerimientos mediante prototipos)
desarrollo y validación: elección de un modelo para el desarrollo
planificación: el proyecto se revisa y se decide si se continúa con el siguiente ciclo. si es así, se planifica la siguiente fase
Estrategias de Pruebas de Software Convencionales y Orientados a Objetos
Laboratorio de Investigación de Sistemas de Información (LISI)Departamento de Procesos y Sistemas, Universidad Simón Bolívar
Anna. C Grimán, María Pérez, Luis. E Mendoza
La formulación de la Estrategia de Prueba para Software aquí propuesta contempló cinco pasos:
Identificación de las Etapas del Proceso de Pruebas, Propuesta del Instrumento de Medición: Las Listas de Chequeo, El Diseño y Registro de Casos de Prueba, y Establecimiento de Pautas para Procesar los Resultados y Diseño Final de la EPSOO.
Identificación de las Etapas del Proceso de Pruebas:
Se inspiró en las Actividades Clásicas del Proceso de Desarrollo (ACPD), es decir: Análisis, Diseño e Implantación; ya que las mismas se encuentran actualmente presentes, a manera de disciplinas, en la mayoría de los procesos de desarrollo.
Técnicas de Pruebas con el RNF de FiabilidadSub Características Objetivo Técnicas que Aplican
Madurez. Evaluar la capacidad que tiene elsoftware para evitar fallas
Prueba Negativa: Hacer que el sistema falle intencionalmente para medir su capacidad de respuesta frente a un error.
Tolerancia aFallas
Verificar la capacidad del oftwarepara mantener un nivel de rendimiento específico ante unerror, es decir, la capacidad decontinuar procesando en caso defalla.
Prueba de Valores Límites: Evaluar valores frontera; es decir, los valores mínimo y máximo que la unidad puede aceptar.
Prueba Bajo Stress: Evaluar la habilidad del sistema para seguir operando apropiadamente ante bajos recursos o competencias para los recursos. Ejecutar el sistema de manera que demande recursos en cantidad, frecuencia o volúmenes anormales.
Prueba Negativa: Hacer que el sistema falle intencionalmente para medir su capacidad de continuar su ejecución a pesar de la falla.
Prueba de Volumen: Someter al software a una gran cantidad de datos para determinar si los límites alcanzados hacen que este falle.
Recuperabilidad Verificar que el proceso derecuperación del sistema restauraapropiadamente la base de datos,la aplicación y el sistema a unestado conocido o deseado
Prueba de Recuperación: Exponer al software a condiciones extremas y verificar que la recuperación se realiza correctamente.
Correctitud 1) Evaluar la capacidad decómputo.2) Comprobar la completitud delas formas estructurales y del
software como un todo.3) Evaluar la consistencia.
Prueba Estructural: Verificar que las formas estructurales de las clases sean completas.
Prueba de Ejecución: La capacidad de cómputo esperada se puede evaluar durante la ejecución del software en aquellos módulos en donde se apliquen cálculos.
Prueba de Carga: Probar diferentes cargas para evaluar la capacidad de cómputo.
Estructurado Que siga las reglas de Programación Estructurada.
Prueba Estructural: Esta técnica permite evaluar los valores de las variables, las constantes y los tipos de datos y si éstos son usados en el contexto en que se definieron.
Encapsulado. Verificar que sea encapsulado, Prueba Estructural: Esta técnica permite evaluar los valores de las variables, las constantes y los tipos de datos y si éstos son usados en el contexto en que se definieron.
Diseño y Registro de Casos de Prueba
Pautas para Procesar los Resultados
Instrumento de Medición
Prueba de ValidaciónSon el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido.
http://es.wikipedia.org/wiki/Pruebas:_de_validaci%C3%B3n
La validación es el proceso de comprobar lo que se ha especificado es lo que e usuario realmente quería.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales.
Utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales.
Como en otras etapas de la prueba, la validación permite descubrir errores, pero su enfoque está en el nivel de requisitos -sobre cosas que son necesarias para el usuario final.
Las expectativas razonables están definidas en la Especificación de Requisitos del Software, contenidas en una sección denominada Criterios de validación
(Presuman, Roger…5ta Edición Pag 316)
Revisión de la configuraciónLa intención de la revisión es asegurarse de que todos los elementos de la configuración del software se han desarrollado apropiadamente, a veces denominada auditoria.
Prueba de Validación
Condiciones en cada caso de prueba: Las características de funcionamiento o de
rendimiento están de acuerdo con las especificaciones
y son aceptables. Se descubre una desviación de las especificaciones
y se crea una lista de deficiencias.
Pruebas Alfa y BetaEs virtualmente imposible que un desarrollador de software pueda prever cómo utilizará el usuario realmente el programa.
Objetivo: Buscar discrepancia entre el software y sus objetivos originales (Requerimientos funcionales y no funcionales).Las Funciones del sistemas o del programa completo no son probadas en esta parte ya que implicaría una Redundancia con las Pruebas Funcionales.Procurar demostrar como el producto (software, sistema, aplicación) no resuelves sus objetivos o requerimientos planteados por los usuarios.
Principales tipos de Pruebas: Recuperación: Forza al fallo del software y verifica que la recuperación
se lleva a cabo apropiadamente. Usabilidad: Verifica el sistema por medio de las interacciones
realizadas por un grupo de usuarios.Rendimiento: Verifica el rendimiento del sistema (tiempo de
respuesta) para realizar una tarea en situaciones particulares . (Cargas, Estrés, Estabilidad, Picos)
Seguridad: Verifica que un usuario solo puede tener acceso a datos y funciones autorizadas.
Pruebas del Sistema
Elementos de una Prueba:
Interacciones entre el Sistema y la Prueba (Propósito) Valores de Prueba (Pasos de ejecución) Resultados Esperados.
Los dos primeros permiten realizar la prueba y el ultimo evaluar si la prueba se supero o no.
Fases de una Prueba: (Métodos y Herramientas)
Análisis y Diseños de pruebasCodificaciónEjecuciónAnálisis de Resultados
Pruebas del Sistema
Depuración del Software
Es el proceso de identificar la raíz de un error y corregirlo.
La prueba, es el proceso mediante el
cual se detecta inicialmente el error.
Obtención de salida incorrecta
Realización de operaciones fuera de lo normal
No finalización del programa (ciclos infinitos)
Caídas del programa
Definición:
Se manifiesta mediante inducción o deducción. Se llega a una «hipótesis de causa» y se usan los datos anteriores para probar o revocar la hipótesis.
Bradley describe el enfoque de la depuración de la siguiente forma:
Enfoque de la Depuración
Es probablemente la más común y menos eficiente a la hora de aislar la causa del error en el software. Se aplica cuando todo lo demás falla. Mediante una filosofía de «dejar que la computadora encuentre el error», se hacen volcados de memoria, trazas de ejecución y se cargan multitud de sentencias Mostrar en el programa.
Fuerza Bruta
Se puede usar con éxito para pequeños programas. Partiendo del lugar donde se descubre el síntoma, se recorre hacia atrás (manualmente) el código fuente hasta que se llega a la posición de error. A medida que aumenta el número de líneas del código, el número de posibles caminos de vuelta se hace difícilmente manejable.
Vuelta Atrás
Eliminación de Causas
Debes hallar un caso de prueba que produzca el error y debe ser lo más simple posible.
Estabiliza el error
Observar el comportamiento bajo condiciones controladas
Localiza la fuente del error
Errores de ProgramaciónErrores de Sintaxis
Corrige el error
Con el caso de prueba y otras hipótesis
Prueba la corrección
Verifica si existen otras partes del programa donde pusiese presentar el mismo error.
Busca errores similares
¿Qué hacer para corregir el error?
http://www.galeon.com/neoprogramadores/howdebug.htm, Charles Connell . Escrito por J. F. Díaz. Consultado el 01/05/2010..
Tips para corregir errores de Programación
Comprende el problema antes de corregirlo Comprende el programa, no sólo el problema Confirma la diagnosis del error
"Invertir tiempo y esfuerzo en el
problema de comprender por qué
existen los bugs es el primer paso para
escribir código libre de errores. El
segundo paso es entrar en acción e
instituir políticas que eliminen el
problema o ayuden a detectarlo.“
Steve Oualline, de su libro C Elements of
Style(Elementos de Estilo en C)
"El conocer la sintaxis de un lenguaje de programación no significa que se conozca cómo desarrollar un buen programa y un software de calidad."
Gustavo Rondina, de su artículo Ingeniería de Software
La depuración es la piedra angular de ser un programador... Un programador que no puede depurar efectivamente está ciego."Robert L. Read, de su ensayo Cómo ser un Programador. Un Resumen Corto, Comprensivo y
Personal
http://www.galeon.com/neoprogramadores/citas001.html
Citas Textuales
Los buenos programadores resuelven
problemas. Los mejores los evitan.“
César Becerra Santamaría (Versión aparentemente
pirateada de cierto documento sobre hackers)
Top Related