Auditoria de SW

Auditora de Software
Ing. Freddy Toribio Huayta Meza

Ingeniera de Software
La Auditora de Software
La Auditora de Software es un trmino general que se refiere a la investigacin y al proceso de entrevistas que determina cmo se adquiere, distribuye y usa el software en la organizacin. Conducir la auditora es una de las partes ms crticas de un Programa de Administracin de Software, porque la auditora ayuda a la organizacin a tomar decisiones que optimicen sus activos de software.
Auditoria del hardware

la auditoria del entorno hardware vendr a verificar la seguridad no solamente en la operativa de los componentes materiales del ordenador, sino de todo lo relativo a los aspectos fsicos concernientes al departamento de procesos de datos.
Las pruebas de software

Las pruebas de software 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.
Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva requiere de un proceso de investigacin ms que seguir un procedimiento al pie de la letra. Una definicin de "testing" es: proceso de evaluacin de un producto desde un punto de vista crtico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reaccin.
Por supuesto, nunca se debe testear el software en un entorno de produccin. Es necesario testear los nuevos programas en un entorno de pruebas separado fsicamente del de produccin. Para crear un entorno de pruebas en una mquina independiente de la mquina de produccin es necesario crear las mismas condiciones que en la mquina de produccin. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware (IBM, Sun, HP etc.). Esas utilidades reproducen automticamente las bases de datos para simular un entorno de produccin.
Tipos de pruebas
Pruebas unitarias Pruebas funcionales Pruebas de Integracin Pruebas de validacin Pruebas de sistema Caja blanca (sistemas) Caja negra (sistemas) Pruebas de aceptacin Pruebas de regresin Pruebas de carga Pruebas de prestaciones Pruebas de recorrido Pruebas de mutacin Pruebas concurrentes
Pruebas unitarias
una 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. Luego, con las Pruebas de Integracin, se podr asegurar el correcto funcionamiento del sistema o subsistema en cuestin. La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo de forma que cada caso sea independiente del resto.
Pruebas funcionales
Una prueba funcional es una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamente diseadas para el software. La 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.
Pruebas de Integracin
Pruebas integrales o pruebas 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. Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos. Las pruebas de integracin (algunas veces llamadas integracin y testeo I&t) es la fase del testeo de software en la cual mdulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.
Pruebas de validacin
Las pruebas 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. Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales
Pruebas de sistema
se realizan las funciones especificadas Pruebas relacionadas con el rendimiento del sistema: Rendimiento (tiempos de respuesta adecuados) Volumen (funcionamiento con grandes volmenes de datos) (umbral lmite de los recursos) Sobrecarga (funcionamiento en el Disponibilidad de datos (cuando se produce una recuperacin ante fallos) Facilidad de uso (usabilidad) de desarranque, actualizacin de Operacin e instalacin (operaciones software) Entorno (interacciones con otros sistemas) y comunicaciones Seguridad (control de acceso e intrusiones)
Caja blanca (sistemas)

En programacin, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un mdulo. As como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del mdulo, las de caja blanca estn dirigidas a las funciones internas. Entre las tcnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecucin), pruebas sobre las expresiones lgico-aritmticas, pruebas de camino de datos (definicin-uso de variables), comprobacin de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones mximas, mximas menos uno y ms uno). Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un mdulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integracin). En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los mtodos de la clase, pero segn varias opiniones, ese esfuerzo debera dedicarse a otro tipo de pruebas ms especializadas (un argumento podra ser que los mtodos de una clase suelen ser menos complejos que los de una funcin de programacin estructurada).
Caja negra (sistemas)

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.
Pruebas de aceptacin
Estas pruebas las realiza el cliente. Son bsicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificacin de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sera impresentable al cliente; sino que se realizan sobre el producto terminado e integrado o pudiera ser una versin del producto o una iteracin funcionad pactada previamente con el cliente. La experiencia muestra que an despus del ms cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que slo aparecen cuando el cliente comienza a usarlo.
Pruebas 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. Este tipo de cambio puede ser debido a prcticas no adecuadas de control de versiones, falta de consideracin acerca del mbito o contexto de produccin final y extensibilidad del error que fue corregido (fragilidad de la correccin), o simplemente una consecuencia del rediseo de la aplicacin.
Pruebas de carga
son las pruebas que se realizan, desde una perspectiva, para determinar lo rpido que realiza una tarea un sistema en condiciones particulares de trabajo. Tambin puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. Las pruebas de rendimiento son un subconjunto de la ingeniera de pruebas, una prctica informtica que se esfuerza por mejorar el rendimiento, englobndose en el diseo y la arquitectura de un sistema, antes incluso del esfuerzo inicial de la codificacin.
Pruebas de prestaciones
Las pruebas de prestaciones, enmarcadas dentro de lo que se viene a llamar Calidad Operacional o Calidad de Servicio son, hoy en da, cada vez ms necesarias: los tiempos de respuesta por encima de lo aceptable, la excesiva variabilidad de los mismos en funcin de la carga del sistema y los problemas de fiabilidad o disponibilidad deben de considerarse errores tan graves como los de funcionalidad. Los problemas de rendimiento son provocados por causas que pueden clasificarse en dos categoras: predecibles e impredecibles
Pruebas de recorrido
Nunca se puede asegurar que una aplicacin funcionar correctamente siempre, pues es inviable econmicamente realizar pruebas de todos los componentes individuales y de todos los componentes como conjunto. Las pruebas deben ser diseadas para descubrir fallos y no para demostrar que el software funciona. Siendo ms razonable disear pruebas de aquellas partes en donde la probabilidad de fallo es mayor. Las pruebas deben ser diseadas por personas distintas a las personas que desarrollan el componente que se desea probar. De todos es bien sabido que conocemos los fallos de nuestros componentes y si el componente es ejecutado por las personas que lo desarrollan cuando lo ensean, no van a ser tan ingenuos de hacer que falle.
Pruebas de mutacin
Esta prueba esta basada en la introduccin deliberada de diferentes cdigos externos al programa (bugs) para reexaminar si estos bugs pueden ser detectados. Requiere gran disponibilidad de recursos de computacin.
Pruebas concurrentes
Esto viene al caso de que comnmente uno define los escenarios de Performance o de pruebas de Carga de la manera: La aplicacin debe soportar un mximo de 250 usuarios concurrentes poniendo implcitamente la cantidad e usuarios concurrentes como parmetro de entrada para las pruebas.

Auditoria de SW

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Auditoria de SW

Cargado por

Copyright:

Formatos disponibles

Auditora de Software

Ing. Freddy Toribio Huayta Meza

Auditoria del hardware

Las pruebas de software

Caja blanca (sistemas)

Caja negra (sistemas)

También podría gustarte