pruebas y depuracion

Pruebas y Depuración

La confirmación de un sistema de software es un proceso continuo en cada etapa del ciclo de vida del software. La prueba de los programas sigue siendo la técnica de confirmación de sistemas mas utilizada, por lo que informe se centra en ese tema en su proceso asociado de depuración.

La prueba de los programas es parte del proceso de confirmación que suele realizarse durante la aplicación y también, en una forma distinta, cuando este ha terminado. La prueba consiste en ejercitar el programa utilizando datos similares a los datos reales que harán de ser ejecutados por el programa, observar los resultados y deducir la existencia de errores o insuficiencias del programa a partir de las anomalías de este resultado.

En ocasiones, se piensa que las pruebas y la depuración de programas son una misma cosa. Aunque están muy relacionadas, en realidad son procesos distintos. La prueba es el proceso de establecer la existencia de errores en el programa. Depuración es el proceso de localizar dónde se produjeron esos errores y corregir el código incorrecto.

Es muy importante comprender que la prueba nunca demuestra que un programa es correcto. Siempre es posible que existan errores aun después de la prueba mas completa. La prueba de programas sólo puede demostrar la presencia de errores en un programa, no su ausencia. De acuerdo con Myers, se considera prueba acertada aquella que establece la presencia de uno o más errores en el software objeto de la prueba. Obsérvese la diferencia con la definición normal de prueba acertada, que es una prueba que no descubre anomalías en el resultado.

La prueba de programas es un proceso destructivo. Se diseña para hacer que el comportamiento de un programa sea distinto del que intentaba su diseñador o aplicador. Como es una característica humana natural que un individuo tenga cierta afinidad con los objetos que ha construido, el programador responsable de la aplicación del sistema no es la persona mas apropiada para probar un programa. Psicológicamente, el programador no querrá “destruir” su creación, lo cual hará que, de manera consciente o inconsciente, elija pruebas que fallan, por lo que no serán adecuadas para demostrar la presencia de errores en el sistema.

Por otra parte, el conocimiento detallado de la estructura de un programa o sistema de programación puede ser muy útil para identificar los casos de prueba apropiados, y el aplicador del sistema tiene una parte importante de esto. La clave de una prueba de programa acertada es establecer un ambiente de trabajo donde los aplicadores del sistema y las personas implicadas en estas pruebas realicen una función complementaria. Esto debe incluir la premisa de administración de que los “errores” de los programas son inevitables dada la complejidad de los sistemas implicados y que los errores no son condenables. El proceso de prueba no se debe ver como una amenaza para los individuos que participan en la aplicación, pues eso haría que se sintieran poco inclinados a cooperar con los encargados de realizar las pruebas.

Aunque es una parte del proceso de confirmación total, la prueba es la única técnica utilizada en la mayoría de las organizaciones de programación para confirmar un programa. La inspección y confirmación de programas no son técnicas de confirmación de uso general. Lamentablemente, por si sola, la prueba no puede confirmar totalmente un programa, lo que da como resultado la proliferación de sistemas no confiables.

Además de las técnicas de pruebas de programas, en este informe también se analiza la función de las inspecciones de confirmación formalizadas en el proceso de confirmación de software. El diseño de casos de prueba se ilustra con un ejemplo y se describen los instrumentos de software que se pueden usar en el proceso de pruebas.