Fundamentos de las Pruebas de Software. Proceso y técnicas de desarrollo de las pruebas de software

[pic 1]

ESCUELA DE INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE II

[pic 2]

Autor:

• Bautista Apaéstegui John Cristian

Tema:

Fundamentos de las Pruebas de Software.

Proceso y técnicas de desarrollo de las pruebas de software.

AÑO 2014

PRESENTACIÓN

El software está en todo lugar. Se podría decir que está presente en todos los aspectos y momentos de la vida de las personas o mejor dicho en casi todos. Algunas veces el software es obvio, otras veces no. Cuando estamos en un banco o estamos utilizando un cajero automático, podemos observar el funcionamiento de los sistemas de software. Si bien es fácil de olvidar el software cuando funciona, también es fácil para la mayoría de nosotros de recordar nuestras experiencias acerca del software que no funcionó. Una serie de dificultades pueden suceder a varias personas cuando un software contiene defectos.

Para ello se hacen necesarias las pruebas de software, para poder verificar la calidad del software y permitir que éste salga al mercado si errores.

En muchos casos, las pruebas tienen uno o más de los siguientes objetivos generales: Las pruebas podrían ser llevadas a cabo para encontrar defectos y luego proporcionar a los programadores la información que ellos necesitan para corregir estos defectos. Los programadores no resuelven todos los defectos usualmente, pero nuestra información debería ayudarles a corregir al menos los defectos más importantes. Así mismo las pruebas podrían ser llevadas a cabo para prevenir defectos. De cualquier manera las pruebas de software se hacen muy necesarias, casi obligatorias si es que se quiere adquirir calidad y eficiencia en los productos, y que una vez que estos salgan al mercado cubran las necesidades para las que fueron hechos.

En fin a lo largo de este informe se estudiarán los fundamentos de las pruebas de software así como el proceso y las técnicas de desarrollo de las mismas.

ÍNDICE

OBJETIVOS:        3

I.        FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE        4

Generalidades de las Pruebas de Software        4

Siete Principios del Proceso de Pruebas        5

Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos        5

Principio 2: El testing en forma exhaustiva es imposible        5

Principio 3: Probar en fases tempranas        5

Principio 4: Agrupamiento de los defectos        6

Principio 5: Paradoja “del pesticida”        6

Principio 6: Las pruebas son dependientes del contexto        6

Principio 7: Falacia de la ausencia de errores        6

Técnicas de Diseño de Pruebas        6

a)        Técnicas de pruebas dinámicas:        6

b)        Técnicas de control estáticas:        8

II.        PROCESO Y TÉCNICAS DE DESARROLLO DE LAS PRUEBAS DEL SOFTWARE        10

Proceso de Desarrollo de Pruebas del Software        10

1) Técnicas de la Caja Negra        10

2) Técnicas de la Caja Blanca        11

Técnicas basadas en la experiencia        17

Selección de las técnicas de pruebas        17

Comparación de técnicas de pruebas del software        19

III.        TENDENCIAS FUTURAS        20

CONCLUSIONES        22

REFERENCIAS        23

FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE. PROCESO Y TÉCNICAS DE DESARROLLO DE LAS PRUEBAS DE SOFTWARE

OBJETIVOS:

• Conocer para que sirven las pruebas de software y cómo estás ayudan en el desarrollo de la calidad del software.

• Determinar cuál es proceso y las técnicas para implementar las pruebas de software en el ámbito real.

• Resaltar la importancia de la prevención de errores en el software.

• Resaltar la importancia de la corrección adecuada de errores en el software mediante las técnicas de prueba del software.

1. FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE

Las pruebas de software (testing en inglés) son los procesos que permiten verificar y revelar la calidad de un producto software antes de su puesta en  marcha. Básicamente, es una fase en el desarrollo de software que consiste en  probar las aplicaciones construidas. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las  especificaciones iniciales del sistema.

Como parte del proceso de validación y verificación, se debería tomar decisiones  sobre quién debería ser responsable de las diferentes etapas de las pruebas.  Dichas etapas de pruebas se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de Software. [pic 3]

Generalidades de las Pruebas de Software

• Error: Es una acción humana que produce un resultado incorrecto.
• Defecto: Un desperfecto que puede causar que el componente o el sistema falle al realizar su función requerida, por ejemplo, una sentencia incorrecta o una definición incorrecta de los datos. Si es encontrado un defecto durante la ejecución, pude causar una falla del componente o sistema.
• Fallo: Desviación del componente o el sistema de su prevista entrega, servicio o resultado.

• Planes: Es la descripción de los alcances, métodos, los recursos y el cronograma de las actividades previstas. Se identifican entre otros ítems de pruebas, las características que tienen que ser probadas, las tareas de prueba, quien hará cada tarea, el grado de independencia del probador, el entorno de pruebas, las técnicas de diseño de pruebas y los criterios de entrada y salida que serán utilizados, y las razones para su elección, y algunos riesgos que requieren planes de contingencia. Es un registro del proceso de planificación de pruebas.

Siete Principios del Proceso de Pruebas

Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos

El testing puede mostrar la presencia de defectos pero no puede probar que no hay defectos.

El testing reduce la probabilidad de que defectos no descubiertos permanezcan en el software. Aunque no se encuentren defectos, esto no es prueba de que no los haya.

Principio 2: El testing en forma exhaustiva es imposible

El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones. Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.

Y eso si no tenemos en cuenta la prueba de requisitos no funcionales, como el rendimiento de un sistema ante una exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios malintencionados. Todo esto hace necesaria una estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos de calidad y de proyecto.

Principio 3: Probar en fases tempranas

Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente. En demasiadas ocasiones existe una confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando existe) se reduce a estas. Se confía en que todos los componentes que no se probaron con una estrategia de pruebas unitarias y de integración se puedan entender bien a unos días del hito de entrega (cuando corregir un bug ya es demasiado caro, en lo que se denomina una prueba de integración “big-bang”). Curiosamente estas malas prácticas se realizan para ahorrar costes, y finalmente el coste de la no calidad cambia las tornas: siempre se acaba pagando en unos costes de mantenimiento excesivos.

Principio 4: Agrupamiento de los defectos

Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo.

Conclusión: si encuentras un bug en un componente, es muy probable que haya más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.

...