Tarea ingsof

120 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
120
En SlideShare
0
De insertados
0
Número de insertados
1
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Tarea ingsof

  1. 1. Alumno: David Cortez Alban Materia: Business Intelligence Resumen del capítulo 8 Las pruebas de Software En las pruebas de software se deben mostrar, que hace el software y lo que debería hacer y sobretodo encontrar defectos antes de ponerlo en uso. Cuando se prueba el software, este se ejecutara usando datos imaginarios. Se hacen Comparaciones de los resultados obtenidos de la prueba para hallar errores, anomalías e información acerca de los atributos no funcionales del sistema. Pueden revelar la existencia de errores. Son parte de una verificación general y de un proceso de validación. Objetivos de las Pruebas de Software Demostrar tanto al desarrollador y cliente que el software cumple sus requerimientos. Determinar las situaciones en las que el comportamiento del software es incorrecto, no cumple con las especificaciones o no es el esperado. Diferencias entre la Verificación y Validación. Verificación: Tiene como meta verificar que el software cumpla con todos los requerimientos funcionales y no funcionales. Validación: Tiene como meta asegurar que el software cumpla con las expectativas del cliente. Esto va a demostrar que el software, hará lo que el cliente espera que haga. El objetivo de estos procesos es verificar que el sistema este apto para su propósito (es decir que cumpla con sus metas y especificaciones) Estos procesos dependen del propósito del sistema, requerimientos del usuario y el marketing. Inspecciones de Software Está enfocado en el código fuente, como en cualquier representación del software, tales como sus requerimientos o el modelo de diseño, los cuales serán inspeccionados. La inspección de software nos presenta 3 puntos importantes, los cuales son: 1. Mientras se ejecuta una prueba, errores pueden cubrir otros errores: Cuando un error da salidas que no son esperadas, no se puede tener certeza de que estas salidas pertenezcan a errores nuevos o a errores anteriores. Ya que la inspección
  2. 2. es un proceso estático, es decir que no cambia, no se debe preocuparse si interactúan los errores entre ellos. 2. Las versiones incompletas (prototipos) del sistema pueden ser revisadas sin cargos adicionales. Si un programa está incompleto, se deben desarrollar pruebas especializadas para probar las partes que están disponibles. 3. Una inspección también podrá revisar otros atributos del programa, tales como mantenimiento, portabilidad y que se ajuste al estándar requerido. Niveles de Pruebas: Pruebas de desarrollo, es en donde un sistema será inspeccionado durante el desarrollo para de esta manera encontrar errores y defectos. Pruebas de Lanzamiento, es en donde un equipo encargado de probar dicho sistema, realizaran pruebas en una versión completa del sistema antes de su lanzamiento a los usuarios finales. Pruebas de usuario, es en donde los usuarios prueban el sistema ya listo, en su entorno de trabajo. Pruebas de desarrollo Es estas se incluyen, todas las actividades de pruebas que realiza el equipo que está desarrollando el sistema, estas se dividen en 3: 1. Pruebas de Unidad, donde las clases de objetos o unidades individuales de programa son probadas. Su objetivo está en probar la funcionalidad tanto de los objetos y métodos. 2. Pruebas de Componentes, es en donde muchas unidades son integradas para crear los componentes compuestos. Su objetivo es probar interfaces de los componentes. 3. Prueba de Sistema, es en donde algunos o todos de los componentes del sistema son integrados y el software es probado en su totalidad. Se interesa por las interacciones de los componentes. Las Pruebas de Unidad Es el proceso, en el cual se prueban componentes individuales, es decir se realizan pruebas de defectos. Las unidades (también llamados componentes individuales) pueden ser: Métodos o Funciones individuales dentro de un objeto. Clases de objetos con varios atributos y métodos Componentes compuestos con interfaces definidas que serán usadas para el acceso a sus funcionalidades.
  3. 3. Elección de pruebas de casos de unidad En esta parte, las pruebas son costosas, así que hay que determinar los casos más importantes, lo cual significa 2 cosas: 1. Los casos a probar tendrán que demostrar, cuando serán usados y como deberían de ser usados, los componentes que se prueban realizan lo que deben de hacer. 2. Si existen defectos en los componentes, estos tendrán que ser demostrados por las pruebas de casos. Somerville ha identificado 2 estrategias posibles para realizar la elección correcta de casos para su prueba, los cuales son: Pruebas de partición, en las cuales se deben identificar que los grupos de entradas poseen características similares y tendrán que ser procesadas de la misma manera. Pruebas basadas en secuencias, es en donde se prueban las guías, para determinar los casos para su prueba. Las guías muestran los errores de los programadores que por lo general surgen al momento de desarrollar componentes. Pruebas de Partición Datos de entrada y resultados de salida usualmente van a ir en clases diferentes en donde todos los miembros de una clase estarán relacionados. Cada una de las clases son una partición equivalente, en donde el programa se comporta de manera equivalente para cada uno de los miembros de la clase. Pruebas de casos tendrán que ser elegidas por cada partición. Pruebas basadas en secuencias Pruebas de software en secuencia quiere decir que tiene un solo valor Se usaran secuencias de diferentes tamaños para pruebas diferentes Se debe dividir las pruebas, de manera que el primero, segundo y último de los elementos de las secuencias sean accesados. Pruebas de Componentes Los componentes de Software generalmente son compuestos ya que están formados de muchos objetos. Se puede accesar a la funcionalidad de estos objetos mediante el uso de las interfaces definidas de los componentes. La prueba de componentes compuestos se debe de enfocar en mostrar como las interfaces de estos, se comportan de acuerdo a sus requerimientos. El objetivo principal es detectar faltas ocasionadas por errores de interfaces.
  4. 4. Tipos de Interfaces Interfaz de Parametros: Datos enviados de un método o procedimiento al otro. Interfaces de memoria compartida: Es esta los bloques de memoria, son compartidos entre procedimientos o funciones. Interfaces de Procedimiento: Subsistemas que tienen procedimientos establecidos para ser llamados por otros subsistemas. Interfaces de Mensaje: Son subsistemas que requieren servicios de otros subsistemas Errores de interface. Sucede cuando uno de los componentes llama a otro y este arroja un error en el uso de su interface. El componente que hace la llamada y el que es llamado operan a velocidades muy diferentes. Pruebas de Sistema Sirven para probar un sistema mientras este es desarrollado, en este caso se tendrá que integrar componentes para de esta manera crear una versión del software y luego probarlo. Como objetivo tiene probar las interacciones entre los componentes, que estos sean compatibles y que interactúen de forma correcta. Cuando se prueba el sistema, los componentes que hayan sido desarrollados de forma separada se pueden integrar, así como también los componentes desarrollados por otros equipos de desarrolladores. Las pruebas del sistema son un proceso colectivo, no individual. Los casos de uso usados para identificar las interacciones del sistema podrán ser usados como base para la prueba del sistema. Desarrollo Test Driven Este tipo de pruebas, deben de ser escritas antes de generar el código y el aprobado de la prueba es fundamental para el desarrollo. El código es desarrollado de forma incremental junto con la prueba. Tes Driven fue creado como parte de las metodologías agiles. Para este tipo de pruebas, primero se identifica la función que es solicitada y luego se escribe una prueba para esa función. Una vez hecho lo primero, se hace la prueba junto con las otras ya hechas. Luego se implementa la función y se hace la prueba una vez más. Cuando todas las pruebas han sido culminadas, se vuelve hacer todo nuevamente con una nueva función.
  5. 5. Los beneficios del desarrollo enfocado a pruebas. Cobertura del Código: Cada uno de los segmentos de código que se escribe, posee por lo menos una prueba asociada. Prueba en retroceso: Esta es desarrollada de manera incremental en base a como el programa sea desarrollado. Corrección de Errores simplificado: Cuando una de las prueba falla, deberá determinarse donde está el problema. Documentación del Sistema: Las pruebas son una forma de documentar, ya que en cierta forma describen lo que el código debe de hacer. Uno de los beneficios más esenciales en el desarrollo enfocado a pruebas, es que reduce en gran parte los costos de pruebas en retroceso. Las pruebas en retroceso, tienen que correr las pruebas que hayan sido anteriormente ejecutadas antes de los cambios que se hayan realizado al sistema. Las Pruebas de Lanzamiento Este es el proceso de probar un lanzamiento del sistema que va a ser usado por los usuarios. El objetivo principal es convencer al usuario final que el sistema ya esta listo para su uso. Las Pruebas de lanzamiento tienen que demostrar que el sistema rinde y cumple con sus funciones. También es considerada una forma de prueba del sistema. Generalmente los equipos que no han sido parte del equipo de desarrollo se encargaran de este tipo de pruebas. El equipo de desarrollo es responsable por hacer pruebas del sistema para encontrar errores y corregirlos. Pruebas basadas en requerimientos En este tipo de pruebas, se tiene que examinar cada uno de los requerimientos y hacer una prueba o algunas pruebas a cada uno de ellos. Pruebas basadas en Escenarios. Se realizan en un escenario, en el cual el sistema se pondrá en uso. Los Escenarios o ejemplos deben de ser reales y los sistemas reales tendrían que estar relacionados con los ejemplos. Pruebas de Rendimiento. En este tipo de pruebas se va cargando al sistema de poco a poco, con peso hasta que el rendimiento del sistema no sea optimo. Por lo general se intenta sobrecargar el sistema para probar su comportamiento ante fallos. Pruebas de Usuario En estas pruebas, los usuarios y/o clientes proveen indicaciones del sistema. Este tipo de prueba es muy esencial, en algunos casos ya que desde el punto de vista de los usuarios
  6. 6. tienen un mayor efecto tanto en la confianza, rendimiento, usabilidad y robustez del sistema. Tipos de Prueba de Usuario Pruebas Alpha: Para este tipo de pruebas, los usuarios del software trabajan en conjunto con el equipo de desarrollo en el mismo lugar para probar el sistema. Pruebas Beta: Un lanzamiento del software que está disponible para los usuarios y los cuales probaran y comunicaran los problemas que descubren a los desarrolladores del sistema. Prueba de aceptamiento: Los clientes prueban un sistema y deciden si el sistema apto o no para ser aceptado como un producto final para su uso. Por lo general son usadas en sistemas con especificaciones puntuales.

×