AUDITORIA DE SISTEMAS

REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR

ALDEA UNIVERSITARIA “SEVERIANO RODRÍGUEZ HERNÁNDEZ”

MISIÓN SUCRE

MARACAIBO EDO. ZULIA

Módulo II

Auditoría y Mantenimiento de Sistemas

Realizado por:

INCIARTE Mildred. C.I. 9.752.029

Sistemas 005

Prof. Ing. Dixon Troconis

04/05/2014

AUDITORIA Y MANTENIMIENTO DE SISTEMAS

Módulo II

1.- Prueba de Aceptación.

Una prueba de aceptación es un escenario de utilización del sistema y el comportamiento que de él se espera, visto desde la perspectiva del cliente, usuario o sistema externo que interactúa con el programa. A continuación se provee una definición más completa. Tiene como propósito demostrar al cliente el cumplimiento de un requisito del software”.

Para eliminar la influencia de conflictos de intereses, y para que sea lo más objetiva posible, la prueba de aceptación nunca debería ser responsabilidad de los ingenieros de software que han desarrollado el producto.

Para la preparación, la ejecución y la evaluación de la prueba de aceptación ni siquiera hacen falta conocimientos informáticos. Sin embargo, un conocimiento amplio de métodos y técnicas de prueba y de la gestión de la calidad en general facilitan esta labor.

La persona adecuada (o el equipo adecuado) para llevar a cabo la prueba de aceptación dispone de estos conocimientos y además es capaz de interpretar los requerimientos especificados por los futuros usuarios del sistema de software en cuestión.

2.- Prueba de Caja Blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente.

Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

Pruebas de flujo de control

Pruebas de flujo de datos

Pruebas de bifurcación (branch testing)

Pruebas de caminos básicos

Para esta prueba se consideran tres importantes puntos:

Conocer el desarrollo interno del programa, determinante en el análisis de coherencia y consistencia del código.

Considerar las reglas predefinidas por cada algoritmo.

Comparar el desarrollo del programa en su código con la documentación pertinente.

3.- Prueba de Caja Negra

Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba.

Estas pruebas se denominan de varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas por datos…los sinónimos son muchos y muy variados.

Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo, charter o sección específica de un software, es decir, es una manera de encontrar casos específicos en ese modulo que atiendan a su especificación.

Las pruebas de caja negra se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior.

Éstas, principalmente, se centran en módulos o charters de interfaz de usuario (pantalla, ficheros, canales de comunicación…)

...