estrategias de pruebas de software

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:”


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.



-

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


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)

estrategias de pruebas de software

Education