tsu informatica
Páginas: 14 (3317 palabras)
Publicado: 6 de marzo de 2014
Introducción
Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo. Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquierconflicto de intereses que aparezcan cuando se descubran errores. Autores como Beizer, describe eficientemente esta situación cuando plantea: Existe un mito que dice que si fuéramos realmente buenos programando, no habría errores que buscar. Si tan sólo fuéramos realmente capaces de concentrarnos, si todo el mundo empleara técnicas decodificación estructuradas, el diseño descendente, las tablas de decisión, si los programas se escribieran en un lenguaje apropiado, si tuviéramos siempre la solución más adecuada, entonces no habría errores. Así es el mito. Según el mito, existen errores porque somos malos en lo que hacemos, si somos malos en lo que hacemos, deberíamos sentirnos culpables por ello. Por tanto, las pruebas, con el diseño de casos de prueba, son un reconocimiento de nuestros fallos, lo queimplica una buena dosis de culpabilidad. Y lo tediosas que son las pruebas son un justo castigo a nuestros errores.
Técnicas de prueba:
*Principios: defectos vs. Fallas, clases equivalentes, pruebas de límites:
Objetivos de las Pruebas:
En un libro sobre las pruebas del software, Glen Myers establece varias normas quepueden servir acertadamente como objetivos de las pruebas:
I.-La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
II.-Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
III.- Una prueba tiene éxito si descubre un error no detectado hasta entonces.Los objetivos anteriores suponen un cambio dramático de punto de vista.
Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores. Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software.Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como untodo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos.
El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito de una prueba).• Mito: Un defecto implica que somos malos profesionales y que debemos sentirnos culpables. Todo el mundo comete errores.
El descubrimiento de un defecto significa un éxito para la mejora de la calidad.
• “No se puede garantizar ni probar que un sistema jamás falle, si no que sólo se puede demostrar que contiene faltas. No encontrar faltas no significa que la prueba haya sido exitosa. Sololo es si se han encontrado faltas.”
Principios de las Pruebas:
Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.
Pruebas del Software:
A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del...
Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo. Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquierconflicto de intereses que aparezcan cuando se descubran errores. Autores como Beizer, describe eficientemente esta situación cuando plantea: Existe un mito que dice que si fuéramos realmente buenos programando, no habría errores que buscar. Si tan sólo fuéramos realmente capaces de concentrarnos, si todo el mundo empleara técnicas decodificación estructuradas, el diseño descendente, las tablas de decisión, si los programas se escribieran en un lenguaje apropiado, si tuviéramos siempre la solución más adecuada, entonces no habría errores. Así es el mito. Según el mito, existen errores porque somos malos en lo que hacemos, si somos malos en lo que hacemos, deberíamos sentirnos culpables por ello. Por tanto, las pruebas, con el diseño de casos de prueba, son un reconocimiento de nuestros fallos, lo queimplica una buena dosis de culpabilidad. Y lo tediosas que son las pruebas son un justo castigo a nuestros errores.
Técnicas de prueba:
*Principios: defectos vs. Fallas, clases equivalentes, pruebas de límites:
Objetivos de las Pruebas:
En un libro sobre las pruebas del software, Glen Myers establece varias normas quepueden servir acertadamente como objetivos de las pruebas:
I.-La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
II.-Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
III.- Una prueba tiene éxito si descubre un error no detectado hasta entonces.Los objetivos anteriores suponen un cambio dramático de punto de vista.
Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores. Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software.Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como untodo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos.
El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito de una prueba).• Mito: Un defecto implica que somos malos profesionales y que debemos sentirnos culpables. Todo el mundo comete errores.
El descubrimiento de un defecto significa un éxito para la mejora de la calidad.
• “No se puede garantizar ni probar que un sistema jamás falle, si no que sólo se puede demostrar que contiene faltas. No encontrar faltas no significa que la prueba haya sido exitosa. Sololo es si se han encontrado faltas.”
Principios de las Pruebas:
Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.
Pruebas del Software:
A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del...
Leer documento completo
Regístrate para leer el documento completo.