Pruebas De Software

ESTE ES DE UN TRABAJO

PRUEBA DE SOFTWARE

La prueba de software es un conjunto de actividades y a su vez un componente del proceso de verificación y validación, cuyo objetivo es detectar errores, permitiendo así la introducción de un proceso de retroalimentación que nos lleve al desarrollo de un producto de calidad.

El proceso de someter a prueba al software SISWIT fue de mucha importancia porque permitió descubrir errores para la parte de la navegabilidad, el desempeño, la capacidad y la seguridad de la aplicación desarrollada. Esto se logró a lo largo de todo el proceso de ingeniería.

5.2 PRUEBAS DE CONTENIDO

Los errores en el contenido de la aplicación pueden ser tan triviales como errores tipográficos menores o tan significativos como información incorrecta, organización impropia o violación de las leyes de propiedad intelectual. Las pruebas de contenido intentan descubrir estos problemas antes de que el usuario las encuentre.

Las pruebas de contenido tienen tres objetivos importantes:

1. Descubrir errores sintácticos, por ejemplo errores tipográficos, equívocos gramaticales.

2. Descubrir errores semánticos, es decir errores en la precisión de la información o que esta sea incompleta.

3. Hallar errores en la organización o estructura del contenido que se presenta al usuario final.

5.3 PRUEBAS FUNCIONALES

También llamadas prueba de nivel de componentes, se enfocan sobre un conjunto de pruebas que intentan descubrir errores en la función de la aplicación. Cada función de la aplicación es un módulo de software (implementando en algún lenguaje de programación) y se puede probar empleando las técnicas de caja negra.

Las pruebas de caja negra, también denominadas, pruebas de comportamiento se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.

Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones,) Este comentario no obsta para que sean útiles en cualquier módulo del sistema.

Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea.

Existen varios tipos de métodos de diseño de casos de prueba, pero uno de lo más utilizados es la técnica llamada prueba de error forzado para producir casos de prueba que deliberadamente conducen a la aplicación Wap y Web hacia una condición de error. El propósito es descubrir los errores que ocurren durante el manejo de los errores como por ejemplo: mensajes de errores incorrectos o inexistentes, falla de la aplicación como consecuencia del error, salida errónea producida por entrada errónea, efectos colaterales relacionados con el procesamiento del componente.

5.4 PRUEBA UNITARIA

Una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

• Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa.

• Completas: deben cubrir la mayor cantidad de código.

• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.

• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.

• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

5.5 PRUEBAS DE INTEGRACIÓN

La pruebas integral o pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

5.6 PRUEBAS DE DESEMPEÑO

Las Pruebas de desempeño se aplican para descubrir problemas que se presentan debido a la falta de recursos en el lado del servidor, ancho de banda inapropiado, capacidades inadecuadas de base de dato defectuosa, así como también conflictos de hardware y software que puedan conducir a un pobre desempeño

...