Inicio | Artículos | Biografías | Cursos | Entrevistas | Frases | Libros | Diccionario | Presentaciones | Servicios | Videos | Mapa Web | Enlazar | Contactar | Acerca de


CURSO/TUTORIAL DE INGENIERÍA DEL SOFTWARE
Introducción
Introducción al Curso
Metodología de la Programación
Ingeniería del Software
Calidad del Software
Análisis
Análisis
Especificación de Requisitios Software (ERS)
Diseño
Diseño
Diseño Modular
¿Qué es un Algoritmo?
Pseudocódigo
Diagramas de Flujo (Ordinogramas)
Cualidades de un Algoritmo
Codificación
Codificación
Lenguajes de Programación
Compiladores e Intérpretes
Tipos de Errores
Fases de la puesta a punto de un Programa
Entornos Integrados de Desarrollo (EID)
Depuradores de Código
Pruebas
Pruebas
Mantenimiento
Mantenimiento
Documentación de un Programa
CarlosPes.comCurso de Ingeniería del Software > Pruebas

Pruebas

¿Qué tipo de pruebas se pueden hacer en ingenieria del software?

Una vez obtenido el código ejecutable de un programa depurado lo máximo posible, hay que comprobar, exhaustivamente, su funcionalidad. Para ello, se tiene que ejecutar tantas veces como se considere necesario, proporcionándole, cada vez, datos de entrada distintos, y comprobando si los datos de salida son siempre los esperados.

El código ejecutable de un programa es imposible que tenga
errores de sintaxis, ya que, estos habrán sido detectados por el compilador y corregidos por el programador. Por tanto, las pruebas a realizar se deben centrar en la búsqueda de errores de ejecución o de lógica.

Para estar totalmente seguros del buen funcionamiento de un programa se debería probar con todas las combinaciones posibles de entrada, cosa que suele ser imposible, ya que, éstas podrían ser infinitas. Así pues, las pruebas tienen que ser muy bien elegidas, intentando abarcar el mayor número de casos, y poniendo a prueba al programa en aspectos críticos.

Por ejemplo, el código ejecutable de un programa que sirva para calcular la suma dos números enteros cualesquiera, se puede probar con distintos datos de entrada aleatorios, tales como: 3 y 5, 10 y 20, 400 y 56, etc. (todos ellos positivos) sabiendo de antemano que los datos de salida deben ser: 8, 30 y 456, respectivamente. También se debería probar si funciona correctamente con números negativos, por ejemplo, con los números: -3 y -5, -10 y -20, etc. Otra prueba que se puede hacer es sumar números positivos con negativos: -3 y 5, 72 y -72, etc. Si todas las pruebas han salido bien, entonces se puede pensar que el programa funciona correctamente, aunque nunca se tendrá la certeza al cien por cien, ya que, no se han probado todos los casos.

Además, en todos los programas pueden darse situaciones inesperadas, es decir, situaciones no previstas por el
programador. En esos casos, el programa reaccionará de manera imprevisible. Por ejemplo: ¿qué ocurrirá si el usuario introduce dos letras en vez de dos números enteros?, ¿y si introduce dos números reales?, ¿qué ocurrirá si se introducen dos números enteros de diez cifras cada uno?, ¿y si son de treinta cifras cada uno?, etc.

En un programa tan simple como el de este ejemplo, las pruebas a realizar pueden llevar poco tiempo. Sin embargo, cuando se desarrolla una
aplicación grande, las pruebas pueden tardar semanas o incluso meses. Piense, por ejemplo, en la aplicación que controla el tráfico aéreo de un aeropuerto, en la que gestiona todos los semáforos de una gran ciudad o en la que supervisa el lanzamiento de un cohete, etc. En todos estos ejemplos, las pruebas no sólo se deben centrar en la comprobación del tratamiento de los datos, sino también en aspectos como: la adpatación de la aplicación al resto del sistema informático o la interacción del software con otras aplicaciones ya existentes. Una aplicación informática de tal envergadura puede estar formada por cientos o miles de programas, y todos ellos deben ser probados individual y conjuntamente. Antes de implantar un software de estas características, lo normal es hacer simulaciones con datos reales para verificar su buen funcionamiento.

Para corregir los errores de ejecución o de lógica encontrados en la fase de pruebas, casi siempre, por no decir siempre, hay que modificar el algoritmo y, en algunos casos, incluso hay que volver a analizar el problema, volviendo a pasar por todas las fases de desarrollo; de lo cual se deduce que, cuanto mejor se haga el análisis y el diseño de una aplicación, la probabilidad de encontrar errores en la fase de pruebas será menor.
Artículos Interesantes
Artículos de Desarrollo Web
Artículos de Informática
Artículos de Programación
Artículos de SEO
Cursos/Tutoriales de Informática
Curso/Tutorial de Algoritmos
Curso/Tutorial de Informática Básica
Curso/Tutorial de Ingeniería del Software
Curso/Tutorial de Lenguaje C
Curso/Tutorial de Marketing en Internet
Curso/Tutorial de Turbo Pascal
Curso/Tutorial de Representación de los Datos
Curso/Tutorial para Webmasters
Curso/Tutorial Web 2.0
Curso de SEO
Libros de Carlos Pes
36 Pasos Básicos para Desarrollar un Sitio Web
Empezar de Cero a Programar en Lenguaje C
Fundamentos del SEO
Libros Recomendados
Libros de Analítica Web
Libros de Desarrollo Web
Libros de Java
Libros de Lenguaje C
Libros de Marketing Online
Libros de Pascal (Turbo Pascal)
Libros de SEO
Libros de Visual Basic
Recursos de Informática
Diccionario de Informática
Ejercicios de Programación
Guías de uso de Software
Sintaxis de Lenguajes de Programación
Biografías
Entrevistas
Frases y Citas
Recursos Educativos
Presentaciones Educativas
Videos Educativos
Enlaces Web
Servicios
Desarrollo de Sitios Web
Diseño Web
Aplicaciones Web
Marketing Online
Formación y Conferencias
Consultoría
Acerca de Carlos Pes
Bibliotecas
Colaboradores
Contactar
Enlazar
Librerías
Perfiles en Internet
Mapa Web
Blog de Carlos Pes Blog de Carlos Pes
Google+ CarlosPes.Com en Google+
© 2006-2017 CarlosPes.com