Control de Lectura # 3. Pruebas del software

Transcripción

1 Universidad Don Bosco Facultad de Ingeniería Escuela de Ingeniería en Computación Ingeniería de Software Control de Lectura # 3 Pruebas del software Docente: Milton Narváez. Grupo: 01T Presentado por: José Jorge Hernández Carrillo Luis Stanley Jovel Portal Gustavo Adolfo Sánchez Moreno HC JP SM San Salvador 26 de octubre de 2014

2 Índice Marco conceptual... 1 Resumen... 2 La prueba de componentes:... 2 La prueba de sistema:... 2 Pruebas de integración Pruebas orientadas a objetos... 4 Mapa Conceptual... 5 Conclusiones Fuentes de consulta.... 7

3 Marco conceptual A medida se avance en la construcción del software a crear, el desarrollo debe de ser más meticuloso y poder observar problemas e inconvenientes que a futuro se logre presentar. Es por eso que durante el diseño e implementación del software se tiene que tener varias consideraciones, y cumplir con los requisitos fundamentales que satisfagan las expectativas y peticiones de los clientes. Las pruebas de software es un conjunto de herramientas, técnicas y métodos que hacen a la excelencia del desempeño de un programa, brindándole la calidad de software que se busca así como también la mejor publicidad que una empresa dedicada a la producción de software pueda tener. Las técnicas para encontrar problemas en un programa son extensamente variadas y van desde el uso del ingenio por parte del personal de prueba hasta herramientas automatizadas que ayudan a aliviar el costo de tiempo que conlleva el realizar esta actividad. Las pruebas de software involucra las operación del sistemas bajo condiciones controlados y evaluando resultados. Las pruebas pueden intencionalmente esforzar al programa y producir errores en la respuesta para determinar si los sucesos ocurren cuando no tendrían que generarse o cuando los hechos no suceden al realizar una petición especificada. La mayoría de las grandes organizaciones asumen la responsabilidad del control de calidad y prueba de software a tal medida que en la producción se incluyen desarrolladores de sistema así como un grupo dedicado a la prueba de software, dichos grupos trabajando en conjunto cumpliendo el control de calidad y la prueba de software logrando una tarea exitosa. 1 P á g i n a

4 Resumen Las fases fundamentales de las pruebas de software son: Pruebas de componente Pruebas de integración Fases de pruebas La prueba de componentes: También denominadas pruebas de unidad, consiste en comprobar componentes individuales del sistema en busca de defectos (pruebas de defectos). Los componentes que se pueden probar son: 1. Funciones individuales, son el tipo más simple de componente. 2. Clases de objetos. 3. Componentes compuestos. Cuando un componente del sistema es complejo y está compuesto por varios subsistemas es cuando resultan útiles las pruebas de interfaces. Las pruebas de defecto tienen como objetivo principal descubrir los defectos del sistema y verificar si el comportamiento de este es correcto o presenta respuestas erróneas. Las pruebas de defecto se relacionan de gran magnitud con la eliminación de cualquier tipo de comportamiento indeseado, como la duplicación de datos, tiempos de espera demasiados largos, cálculos innecesarios o equivocados. Por lo tanto las pruebas de defecto son las que consisten en encontrar y dar a conocer las fallas que se están generando dentro del sistema, brindando una ayuda extra al desarrollador, ya que a partir de la información que estas pruebas indiquen, se podrán corregir los defectos que posea el sistema. La prueba de sistema: Debemos tomar en cuenta que dependiendo de la magnitud del sistema a desarrollar por ejemplo si es un sistema grande o sistemas más pequeños como los desarrollados por script o reutilización usan modelos de procesos de pruebas que se ajustan mejor a estos sistemas, sin embargo para la mayoría de sistemas complejos existen dos fases de prueba de sistema. Pruebas de integración, realizada por el equipo de pruebas junto al código fuente. Pruebas de entregas, pruebas realizadas por los usuarios finales. 2 P á g i n a

5 Pruebas de integración. Durante las pruebas de integración se comprueba que los diferentes componentes que formaran el sistema en verdad funcionan juntos, es decir que se comunican entre sí y transfieren los datos en el tiempo preciso, existen dos denominaciones en las pruebas de integración: Integración descendente: se desarrolla completamente el esqueleto del sistema y luego se añaden los componentes. Integración ascendente: primero se integran los componentes de infraestructura y luego los componentes funcionales. Es difícil localizar errores durante las pruebas de integración por lo que se recomienda realizar una aproximación incremental para probar el sistema mientras se integra, el orden en el que se integran los componentes está dirigido por las prioridades del cliente si el cliente está implicado directamente en el desarrollo, pero es recomendable integrar primero los componentes con las funciones más frecuentemente utilizadas. Observar en el ejemplo de integración incremental: Tengamos un sistemas formado por los componentes A, B C y D; y los conjuntos de prueba T1 hasta T5. Se integran los componentes A y B y se ejecutan las pruebas T1, T2 y T3. Si hay defectos se corrigen. A T1 T2 B T3 Secuencia de prueba 1 Se integra el componente C y se ejecuta el conjunto de pruebas T4 si hay errores se deben a la integración con el componente C, estos errores se corrigen. A T1 T2 B C T3 T4 Secuencia de prueba 2 3 P á g i n a

6 Se integra el componente D junto con la ejecución del conjunto de pruebas T5, si hay errores se deben a la integración del componente D, estos errores se corrigen. A B C D T1 T2 T3 T4 T5 Una vez se realizan la integración de los componentes, es necesario hacer pruebas de regresión, es decir que se deben ejecutar todas las pruebas para incrementos previos y si es necesario nuevas pruebas para verificar la funcionalidad del sistema. Pruebas orientadas a objetos Secuencia de prueba 3 Dentro una estructura de clases y objetos es mucho más complicado definir casos de pruebas, en este caso se debe diseñar pruebas que abarquen con la totalidad de la clase, utilizando todos sus atributos y métodos, además de verificar los diferentes estados que puede llegar a tener el objeto. Las pruebas orientadas a objetos deben contener: 1. Las pruebas aisladas de todas las operaciones asociadas con el objeto. 2. La asignación y consulta de todos los atributos asociados con el objeto. 3. Ejecutar el objeto en todos sus posibles estados. Esto significa que deben simularse todos los eventos que provocan un cambio de estado en el objeto. También se puede comprobar el funcionamiento del objeto en una sucesión de estados y funciones, para comprobar la integridad que hay entre sus métodos internos. Si se utiliza herencia es más complicado para comprobar su funcionamiento mediante pruebas. Se debe comprobar el funcionamiento de una función heredada así como el funcionamiento de una función sobre escrita para cada uno de los métodos que componen las clases que heredan de una superclase. 4 P á g i n a

7 Mapa Conceptual 5 P á g i n a

8 Conclusiones. El proceso de pruebas es crucial para garantizar la funcionalidad del sistema según como se definió en los requerimientos, son las pruebas las que ayudan a demostrar al desarrollador y al cliente que el software satisface dichos requerimientos. Sin embargo las pruebas no pueden demostrar que el software está libre de errores, las pruebas solo demuestran la presencia de errores, no su ausencia. El proceso de pruebas representa un costo significativo de recursos, tanto de tiempo como personal y equipo que al final se traducen en dinero, tal es la magnitud de este costo asociado que muchas veces los ingenieros de software pueden tomar la decisión de no realizar ningún tipo de prueba. Frente a esta situación Edsger Dijkstra sostiene que los procesos de pruebas de pruebas descubren defectos en el software en que el comportamiento de éste es incorrecto, no deseable o no cumple su especificación. Podemos concluir entonces que aunque el proceso de pruebas de software tenga un alto costo asociado es más caro lidiar con un sistema finalizado que no es funcional y que no cumple con los requerimientos previamente establecidos. 6 P á g i n a

9 Fuentes de consulta. Javier Zapata Sánchez. (enero 21, 2013). Pruebas de Software. Sitio web: 7 P á g i n a