1 Escriba un conjunto de datos para probar un programa relativamente simple. Cree un conjunto de datos de entrada para el programa - los cuales debe manejar correctamente, para obtener los datos requeridos. La descripción es la siguiente: El programa lee tres valores enteros de un diálogo de entrada. Los tres valores representan las longitudes de los lados de un triángulo. El programa muestra un mensaje que indica si el triángulo es escaleno, isósceles o equilátero. Realice el siguiente ejercicio Fuente: G. Myers

2 a.Triángulo escaleno: no hay dos lados son iguales. b.Triángulo isósceles: tiene dos lados iguales. c.Triángulo equilátero: tiene tres lados de igual longitud. Fuente: G. Myers

3 Por otra parte, los ángulos opuestos a los lados iguales en un triángulo isósceles también son iguales (se deduce también que los lados opuestos a los ángulos iguales en un triángulo, son iguales), y en todos los ángulos de un triángulo equilátero son iguales. Fuente: G. Myers

4 Evalúe su conjunto de datos, respondiendo a las siguientes preguntas. Anótese un punto por cada "sí" como respuesta. 1.¿Tiene usted un conjunto de números que representa un triángulo escaleno válida? (Tenga en cuenta que los conjuntos tales como 1,2,3 y 2,5,10 no justifican una respuesta "sí", porque no existe un triángulo que tiene estas dimensiones.) 2.¿Tiene usted un conjunto de números que representa un triángulo equilátero válida? 3.¿Tiene usted un conjunto de números que representa un triángulo isósceles válida? (Tenga en cuenta que un conjunto de números que representa 2,2,4 no se cuenta porque no es un triángulo válido.) 4.¿Tiene por lo menos tres conjunto de números que representan triángulos isósceles válidos, que ya ha probado las tres permutaciones de dos lados iguales (como, 3,3,4; 3,4,3, y 4,3,3)? 5.¿Tiene usted un caso de prueba en la que un lado tiene un valor de cero? Fuente: G. Myers

5 6.¿Tiene usted un conjunto de números en la que un lado tiene un valor negativo ? 7.¿Tiene usted un conjunto de números con tres números enteros mayores que cero tal que la suma de dos de los números es igual a la tercera ? ( Es decir, si el programa dijo que 1,2,3 representa un triángulo escaleno, que contendría un error) 8.¿Tiene por lo menos tres conjunto de números en la categoría 7 de tal manera que usted ha intentado todas las tres permutaciones que la longitud de un lado es igual a la suma de las longitudes de los otros dos lados ( por ejemplo, 1,2,3 ; 1,3,2, y 3,1,2 ) ? 9.¿Tiene usted un conjunto de números con tres números enteros mayores que cero tal que la suma de dos de los números es menor que el tercero (como 1,2,4 o 12,15,30 ) ? Fuente: G. Myers

6 10.¿Tiene por lo menos tres conjunto de números en la categoría 9 de tal manera que usted ha intentado todas las tres permutaciones (por ejemplo, 1,2,4 ; 1,4,2 y 4,1,2 ) ? 11.¿Tiene usted un conjunto de números en el que todos los lados son iguales a cero ( 0,0,0)? 12.¿Tiene por lo menos un conjunto de números de la especificación de valores no enteros (como 2.5,3.5,5.5 ) ? 13.¿Tiene por lo menos un conjunto de números que especifica el número incorrecto de valores ( dos en lugar de tres números enteros, por ejemplo) ? 14.Para cada conjunto de números ha especificado el resultado que se espera del programa, además de los valores de entrada ? Fuente: G. Myers

7 Un conjunto de números que satisfaga las condiciones anteriores no garantiza que todos los errores posibles serían encontrados. Las preguntas 1 a 13 representan los errores que en realidad se han producido en las diferentes versiones de este programa, una prueba adecuada de este programa debe exponer al menos estos errores. Consideren lo siguiente: Con base en las estadísticas, los programadores profesionales altamente cualificados puntúan, en promedio, sólo el 7,8 de un máximo de 14. Si usted ha logrado un puntaje mayor, felicitaciones, de lo contrario hay que profundizar en las pruebas. Fuente: G. Myers

8 La prueba de incluso un programa trivial como el anterior no es una tarea fácil. Por ejemplo, considere la dificultad de probar un sistema 100000-sentencia de control del tráfico aéreo, un compilador, o incluso un programa de nóminas mundano. Las pruebas también se dificultan con los lenguajes orientados a objetos como Java y C + +. Por ejemplo, los casos de prueba para aplicaciones creadas con estos lenguajes deben analizar los errores asociados con la creación de instancias de objetos y gestión de memoria. Fuente: G. Myers

9 Las pruebas de software son una tarea técnica, que implica algunas consideraciones importantes de la economía y la psicología humana. a.En un mundo ideal, seria agradable probar todas las permutaciones posibles de un programa. En la mayoría de casos, sin embargo, esto simplemente no es posible. b.Incluso un programa aparentemente simple puede tener cientos o miles de posibles combinaciones de entrada y salida. La creación de casos de prueba para todas estas posibilidades es poco práctico. c.Una revisión completa de una aplicación compleja tomaría demasiado tiempo y requieren demasiados recursos humanos para ser económicamente viable. Además, el tester de software tiene la actitud adecuada para probar con éxito una aplicación de software. En algunos casos, la actitud del tester puede ser más importante que el propio proceso real. Fuente: G. Myers

10 LA PSICOLOGÍA DE LA PRUEBA Una de las principales causas de la mala prueba del programa es el hecho de que la mayoría de los programadores comienzan con una definición falsa de la palabra. Se podría decir: Fuente: G. Myers La Prueba es: a.El proceso de demostrar que los errores no están presentes. b.Demostrar que un programa realiza las funciones previstas correctamente. c.El proceso de establecer la confianza de que un programa hace lo que se supone que debe hacer.

11 Estas definiciones son erradas. Cuando se prueba un programa, se desea añadir valor al mismo. El aumento del valor, añadido a través de pruebas, significa elevar la calidad y fiabilidad del programa. El aumento de la fiabilidad del programa significa encontrar y eliminar errores. Por lo tanto, no pruebe un programa para demostrar que funciona, sino que en su lugar empiece con la suposición de que el programa contiene errores (una suposición válida para casi cualquier programa) y luego pruebe el programa para encontrar la mayor cantidad de errores posible. Por lo tanto, una definición más apropiada es la siguiente: La prueba es el proceso de ejecución de un programa con la intención de encontrar errores. Fuente: G. Myers

12 Los seres humanos tienden a ser altamente orientado a los objetivos, y el establecimiento de la meta adecuada tiene un efecto psicológico importante. Si nuestro objetivo es demostrar que un programa no tiene errores, entonces subconscientemente nos dirigimos hacia este objetivo, es decir, se tiende a seleccionar los datos de prueba que tiene una baja probabilidad de causar que el programa falle. Por otro lado, si nuestro objetivo es demostrar que un programa tiene errores, nuestros datos de prueba tendrán una mayor probabilidad de encontrar errores. Fuente: G. Myers

13 Se supone que la prueba es un proceso destructivo, incluso un proceso sádico, lo que explica por qué la mayoría de las personas les resulta difícil construir pruebas. Eso puede ir en contra de nuestro objetivos, pues la mayoría de nosotros tenemos una visión constructiva en lugar de una destructiva. La mayoría de las personas se inclinan hacia la construcción que hacia la destrucción de los objetos. La definición también tiene implicaciones sobre cómo los casos de prueba (datos de prueba) deben ser diseñados y quién debe y quién no debe poner a prueba un programa dado. Fuente: G. Myers

14 a.La mayoría de los directores de proyectos denominan una “prueba exitosa” a aquella que no encontró una error, b.Mientras que una prueba que descubre un nuevo error es denominada “Insatisfactoria”. ERROR !!!!! Fuente: G. Myers Otra manera de reforzar la definición apropiada de las pruebas es analizar el uso de las palabras “éxito" y “fracasos”, en particular, su utilización por los administradores de proyectos categorizando los resultados de casos de prueba: “Insatisfactoria”.

15 “Sin éxito” denota algo indeseable o decepcionante ?????. Una prueba bien construida y ejecutada en una pieza de software tiene éxito cuando encuentra errores que pueden ser corregidos. Y esa misma prueba también es exitosa cuando finalmente establece que no hay más errores que se encuentran. La prueba insatisfactoria es aquella que no examina apropiadamente el software. Fuente: G. Myers

16 En la mayoría de los casos, una prueba que no detecta ningún error probablemente sería considerada infructuosa, ya que el concepto de un programa sin errores es básicamente irreal. Un caso de prueba que encuentra un nuevo error no puede considerarse un fracaso, sino que ha demostrado ser una valiosa inversión. Un caso de prueba insatisfactorio es aquel que causa que el programa produzca resultados correctos sin encontrar ningún error. Fuente: G. Myers

17 Considere la analogía de una persona que visita un médico a causa de una sensación general de malestar. Si el médico ejecuta algunas pruebas de laboratorio que no determinan el problema, no llamamos a las pruebas de laboratorio “exitosas”. Estas pruebas fueron infructuosas pues le constaron al paciente que, aun sigue enfermo, y puede cuestionar la capacidad del médico para identificar enfermedades. Sin embargo, si una prueba de laboratorio determina que el paciente tiene una úlcera péptica, la prueba es satisfactoria porque el médico puede comenzar el tratamiento adecuado. Por lo tanto, la profesión médica parece utilizar estas palabras en el sentido propio. La analogía es que debemos pensar en el programa, al comenzar la prueba, como si fuera nuestro paciente enfermo. Fuente: G. Myers

18 SEGUNDO PROBLEMA PSICOLÓGICO Fuente: G. Myers Un segundo problema con la definición de que “la prueba es el proceso de demostrar que los errores no están presentes" es que tal objetivo es imposible de alcanzar para casi todos los programas, incluso programas triviales. Los estudios psicológicos demuestran que las personas funcionan pobremente cuando realizan una tarea que saben que es posible o imposible.

19 Por ejemplo: Si se le pidió que resolviera el crucigrama del periódico en 15 minutos, probablemente observe poco, o ningún, progreso después de 10 minutos, porque la mayoría de nosotros estaría resignado al hecho de que la tarea parece imposible. Por otro lado, si se le pide una solución en cuatro horas, sin embargo, se podría razonablemente esperar ver más progresos en los primeros 10 minutos. La definición de prueba del programa como el proceso de descubrimiento de errores en un programa hace que sea una tarea factible, superando de este modo este problema psicológico. Fuente: G. Myers SEGUNDO PROBLEMA PSICOLÓGICO

20 Un tercer problema con la definición de que "la prueba es el procedimiento para demostrar que un programa hace lo que se supone hacer" es que los programas que hacen lo que se supone deben hacer todavía pueden contener errores. Es decir, un error esta presente si un programa hace lo que se supone que debe hacer, y de igual forma, los errores también están presentes si un programa hace lo que no se supone que debe hacer. Fuente: G. Myers TERCER PROBLEMA PSICOLÓGICO

21 Considere el programa del triángulo. Incluso si se pudiera demostrar que el programa correctamente distingue entre escaleno, isósceles y equiláteros, el programa todavía tendría errores si hace algo que no se supone que deba hacer (como la representación de 1,2,3 como un triángulo escaleno o decir que 0,0,0 representa un triángulo equilátero). Somos más propensos a descubrir la última clase de errores si vemos las pruebas de software como el proceso de encontrar errores mas que si lo vemos como el proceso de mostrar que un programa hace lo que se supone que debe hacer. Fuente: G. Myers TERCER PROBLEMA PSICOLÓGICO

22 Considere la posibilidad de que alguien se le acerque con la afirmación de que "mi programa es perfecto" (libre de errores). La mejor manera de establecer una cierta confianza en esta afirmación es tratar de refutarla, es decir, para tratar de encontrar imperfecciones en lugar de confirmar que el programa funciona correctamente con algún conjunto de datos de entrada. Fuente: G. Myers

23 LA ECONOMÍA DE LA PRUEBA Fuente: G. Myers Dada esta definición de las pruebas del programa, un paso adecuado es la determinación de si es posible poner a prueba un programa para encontrar todos sus errores. Esta respuesta es negativa, incluso para programas triviales. En general, no es práctico, a menudo imposible, encontrar todos los errores en un programa. Este problema fundamental tendrá consecuencias para la economía de la prueba, dados los supuestos que el tester tendrá que hacer sobre el programa y la forma en que los casos de prueba se diseñan.

24 Fuente: G. Myers

25 Principio 1: Una parte necesaria de un caso de prueba es una definición de la salida o resultado esperado. Este principio es uno de los errores más frecuentes en las pruebas del programa (se basa en la psicología humana). Si el resultado esperado de un caso de prueba no se ha predefinido, lo más probable es que un resultado plausible, pero errónea, se interprete como un resultado correcto a causa del fenómeno de "el ojo que ve lo que quiere ver." Fuente: G. Myers

26 Principio 1: Una parte necesaria de un caso de prueba es una definición de la salida o resultado esperado. En otras palabras, a pesar de la definición adecuada de la prueba, todavía hay un deseo subconsciente para ver el resultado correcto. Una manera de contrarrestar esto es realizar un examen detallado de todas las salidas que se esperan como resultados del programa. Por lo tanto, un caso de prueba debe constar de dos componentes: 1. Una descripción de los datos de entrada al programa. 2. Una descripción precisa de la salida correcta del programa para ese conjunto de datos de entrada. Fuente: G. Myers

27 Principio 2: Un programador debe evitar tratar de probar su propio programa. Cualquier programador sabe - o debería saber - que es una mala idea tratar de modificar o corregir su propio trabajo. Saben lo que se supone que el segmento quiere decir y pueden no reconocer cuando se diga lo contrario. Usted realmente no quiere encontrar errores en su propio trabajo. Fuente: G. Myers

28 Principio 2: Un programador debe evitar tratar de probar su propio programa. Otro problema surge con un cambio en el enfoque en un proyecto de software. Después de que un programador ha diseñado y un codificado de manera constructiva, es extremadamente difícil cambiar la visión para mirar programa con una óptica destructiva. Tenga en cuenta que este argumento no se aplica a la depuración (corrección errores conocidos ); la depuración se lleva a cabo de manera más eficiente con el programador original. Fuente: G. Myers

29 Principio 3: Un equipo de desarrollo no debe probar sus propios programas. Un grupo de programación es, en muchos sentidos, un grupo que vive con problemas psicológicos similares a los de los programadores individuales. Principio 4: Inspeccione minuciosamente los resultados de cada prueba. Es algo que a menudo se pasa por alto. Numerosos experimentos que muestran que muchas personas no lograron detectar ciertos errores, incluso cuando los síntomas de esos errores fueron claramente observable en los listados de salida. Fuente: G. Myers

30 Principio 5: Los casos de prueba deben ser escritos para las condiciones de entrada inválidas e inesperadas, así como para los que son válidas y se esperadas. Hay una tendencia natural al probar un programa, en concentrarse en las condiciones de entrada válidas y esperadas, descuidando las condiciones inválidas e inesperadas. Fuente: G. Myers

31 Principio 5: Los casos de prueba deben ser escritos para las condiciones de entrada inválidas e inesperadas, así como para los que son válidas y se esperadas. Por ejemplo, esta tendencia aparece con frecuencia en las pruebas del programa de triángulo: Pocas personas, por ejemplo, definen el conjunto de números 1,2,5 para asegurarse de que el programa no lo interprete erróneamente como un triángulo escaleno en lugar de un triángulo inválido. Además, muchos de los errores que se descubren en la producción de programas resultan cuando el programa se utiliza de alguna manera nueva o inesperada. Por lo tanto, los casos de prueba que representan condiciones de entrada inesperadas y no válidas parecen tener un mayor rendimiento de detección de errores que los casos de prueba para las condiciones de entrada válidas. Fuente: G. Myers

32 Principio 6: Examinar un programa para ver si no hace lo que se supone que debe hacer es sólo la mitad de la batalla la otra mitad es ver si el programa hace lo que no se supone que debe hacer. Los programas deben ser examinados para efectos secundarios no deseados. Fuente: G. Myers

33 Principio 7: Evite los casos de prueba de usar y desechar, a menos que el programa es realmente un programa de usar y desechar. Una práctica común es sentarse en una terminal e inventar casos de prueba sobre la marcha, y luego enviar estos casos de prueba a través del programa. El principal problema es que los casos de prueba son una inversión valiosa que, en este entorno, desaparecen después de la prueba se ha completado. Cada vez que el programa tiene que ser probado de nuevo, los casos de prueba se deben reinventar. Fuente: G. Myers

34 Principio 8: No planee un esfuerzo de pruebas bajo el supuesto tácito de que NO se encontraron errores. La definición de la prueba es el proceso de ejecución de un programa con la intención de encontrar errores. Fuente: G. Myers

35 Principio 9: La probabilidad de la existencia de más errores en una sección de un programa es proporcional al número de errores que ya se encuentra en esa sección. Si un programa se compone de dos módulos, clases, o subrutinas A y B; y cinco errores se han encontrado en el módulo A y sólo un error se ha encontrado en el módulo B; si el módulo A no ha sido sometido a un prueba más rigurosa, este principio dice que la probabilidad de que a más errores en el módulo A es mayor la probabilidad de que se encuentren más errores en el módulo B. Fuente: G. Myers

36 Principio 10: Las pruebas son una tarea extremadamente creativa e intelectualmente desafiante. Probablemente es cierto que la creatividad requerida en la prueba de un gran programa supera la creatividad necesaria en el diseño de ese programa. Es imposible probar un programa lo suficiente como para garantizar la ausencia de todos los errores. Fuente: G. Myers

37 Trabajo de Clase 1.Realice la lectura correspondiente 2.Define los siguientes parámetros: a.Lenguaje de trabajo b.Selección del IDE c.Selección de la metodología d.Identificación del líder del equipo de trabajo e.Definición de las estrategias de comunicación f.Definición de repositorios y versionamiento g.Definición de curvas de aprendizaje Fuente: G. Myers