INSTITUTO UNIVERSATARIO DE TECNOLOGIA JUAN PABLO PEREZ ALFONSO IUTEPAL

Profesora: Yelmin Prez. Seccin: 1551 AUTOR: Arias Jos Otaiza Lus

Puerto Cabello, de Marzo del 2012.

Prueba de Software:
En ingls testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementacin, calidad, o usabilidad de un programa de ordenador o videojuego. Bsicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniera de software. As se ejecuta un programa y mediante tcnicas experimentales se trata de descubrir que errores tiene. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Tipos de Pruebas: 1. Prueba Unitaria: es una forma de probar el correcto funcionamiento de un mdulo de
cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione correctamente por separado.

2. Pruebas Funcionales: Es una prueba basada en la ejecucin, revisin y

retroalimentacin de las funcionalidades previamente diseadas para el software. Las pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informtico.

3. Prueba de Integracin: 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.

4. Prueba de Validacin: En la ingeniera de software son el proceso de revisin que el

sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que tambin utiliza tcnicas tales como evaluaciones, inspecciones, y tutoriales. La validacin es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quera.

5. Prueba Caja Blanca: Las pruebas de caja blanca (tambin conocidas como pruebas de
caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseo est fuertemente ligado al cdigo fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecucin del programa y cerciorarse de que se devuelven los valores de salida adecuados.

6. Prueba Caja Negra: En teora de sistemas y fsica, se denomina caja negra a aquel
elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesar su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que tambin podran ser cajas negras) entendiendo qu es lo que hace, pero sin dar importancia a cmo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

7. Prueba de regresin: Se denominan Pruebas de regresin a cualquier tipo de pruebas

de software que intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicacin que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Ejemplo de una Prueba de Software:

Prueba de caja negra: en este tipos de pruebas se suelen utilizar varios tipos de mtodos y modelados como por ejemplo estos:
Mtodos de prueba basados en grafos: en este mtodo se debe entender los objetos (objetos de datos, objetos de programa tales como mdulos o colecciones de sentencias del lenguaje de programacin) que se modelan en el software y las relaciones que conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas. En este mtodo: 1. Se crea un grafo de objetos importantes y sus relaciones. 2. Se disea una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores. Modelado del flujo de transaccin: Los nodos representan los pasos de alguna transaccin (por ejemplo, los pasos necesarios para una reserva en una lnea area usando un servicio en lnea), y los enlaces representan las conexiones lgicas entre los pasos (por ejemplo, vuelo.informacin.entrada es seguida de validacin /disponibilidad.procesamiento). Modelado de estado finito: Los nodos representan diferentes estados del software observables por el usuario (por ejemplo, cada una de las pantallas que aparecen cuando un telefonista coge una peticin por telfono), y los enlaces representan las transiciones que ocurren para moverse de estado a estado (por ejemplo, peticininformacin se verifica durante inventario-disponibilidad-bsqueda y es seguido por cliente-factura-informacin-entrada).

Instrumentos para la aplicacin de una auditoria:

Los instrumentos para la recoleccin y evaluacin de informacin son:

Observacin Directa:
Con esta sencilla tcnica se observar todo lo relacionado con los sistemas, con el propsito de percibir, examinar o analizar lo relacionado con los eventos que se presentan en el desarrollo de las actividades de un sistema, de la operacin de la computadora o el desempeo de cualquiera de las actividades que le permitirn evaluar el cumplimiento de las operaciones del sistema. Esta tcnica se aplicar durante el desarrollo de toda la auditora.

Cuestionario:

Se utilizar el cuestionario evaluar los conocimientos tericos que poseen los usuarios en cuanto a computacin bsica y de Hardware. El cuestionario contendr el mismo formato de preguntas para las tres reas que se estn evaluando.

Entrevista al personal:
Existen aspectos que no se logran determinar con un cuestionario o con la observacin directa por lo que se recurrir a las entrevistas a los usuarios del sistema para obtener mayor informacin. La entrevista se utilizar para evaluar los Procesos que se realizan en cada rea auditada.

Gua de observacin
Consiste en la aplicacin de 40 preguntas, que tienen como finalidad determinar hasta qu nivel los procedimientos y la metodologa de trabajo que se aplican son correctos, estn en concordancia con los estndares y parmetros de calidad, si estos han sido implementados, y si se realizan acciones encaminadas a la superacin y supervisin de los auditores, consultores y supervisores que se relacionan con la actividad de auditora en las dependencias del Ministerio de Auditoria y Control. (Ver Anexo # 2) De conjunto con este instrumento se aplica la entrevista para esclarecer detalles que no se tratan con toda la amplitud necesaria en la Gua.