La Auditoría de Software

Document Sample
La Auditoría de Software Powered By Docstoc
					IUTEPAL PTO CABELLO

AUDITORIA DE SISTEMA II
LUIS PEREZ C.I. 19.196.610
        La Auditoría de Software
• La Auditoría de Software es un término general
  que se refiere a la investigación y al proceso de
  entrevistas que determina cómo se adquiere,
  distribuye y usa el software en la organización.
• Conducir la auditoría es una de las partes más
  críticas de un Programa de Administración de
  Software, porque la auditoría ayuda a la
  organización 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 físicos 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
  implementación, calidad, o usabilidad de un programa
  de ordenador o videojuego. Básicamente 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 Ingeniería de software. Así se ejecuta un programa y
  mediante técnicas 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 investigación más que
  seguir un procedimiento al pie de la letra. Una
  definición de "testing" es: proceso de evaluación
  de un producto desde un punto de vista crítico,
  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 reacción.
• Por supuesto, nunca se debe testear el software en un
  entorno de producción. Es necesario testear los nuevos
  programas en un entorno de pruebas separado
  físicamente del de producción. Para crear un entorno
  de pruebas en una máquina independiente de la
  máquina de producción es necesario crear las mismas
  condiciones que en la máquina de producción. Existen
  a tal efecto varias herramientas vendidas por los
  mismos fabricantes de hardware (IBM, Sun, HP etc.).
  Esas utilidades reproducen automáticamente las bases
  de datos para simular un entorno de producción.
                       Tipos de pruebas

•   Pruebas unitarias
•   Pruebas funcionales
•   Pruebas de Integración
•   Pruebas de validación
•   Pruebas de sistema
•   Caja blanca (sistemas)
•   Caja negra (sistemas)
•   Pruebas de aceptación
•   Pruebas de regresión
•   Pruebas de carga
•   Pruebas de prestaciones
•   Pruebas de recorrido
•   Pruebas de mutación
•   Pruebas concurrentes
            Pruebas unitarias
• 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.
          Pruebas funcionales
• Una prueba funcional es una prueba basada
  en la ejecución, revisión y retroalimentación
  de las funcionalidades
  previamente diseñadas para el software. La
  pruebas funcionales se hacen mediante el
  diseño de modelos de prueba que buscan
  evaluar cada una de las opciones con las que
  cuenta el paquete informático.
          Pruebas de Integración
• Pruebas integrales 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.
           Pruebas de validación
• Las pruebas de validación en la ingeniería de
  software son el proceso de revisión 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 también utiliza técnicas tales como evaluaciones,
  inspecciones, y tutoriales. La validación es el proceso
  de comprobar lo que se ha especificado es lo que
  el usuario realmente quería.
• 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 volúmenes de datos)
  (umbral límite de los recursos) Sobrecarga (funcionamiento en el
 Disponibilidad de datos (cuando se produce una recuperación ante
fallos) Facilidad de uso (usabilidad) de desarranque, actualización de
              Operación e instalación (operaciones software)
     Entorno (interacciones con otros sistemas) y comunicaciones
               Seguridad (control de acceso e intrusiones)
                Caja blanca (sistemas)
•   En programación, se denomina cajas blancas a un tipo de pruebas de software que
    se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja
    negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja
    blanca están dirigidas a las funciones internas. Entre las técnicas usadas se
    encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos
    los posibles caminos de ejecución), pruebas sobre las expresiones lógico-
    aritméticas, pruebas de camino de datos (definición-uso de variables),
    comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego
    para las iteraciones máximas, máximas menos uno y más uno).
•   Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo
    concreto, para luego realizar las de caja negra sobre varios subsistemas
    (integración).
•   En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a
    los métodos de la clase, pero según varias opiniones, ese esfuerzo debería
    dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que
    los métodos de una clase suelen ser menos complejos que los de una función de
    programación 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 también podrían ser cajas negras)
  entendiendo qué es lo que hace, pero sin dar
  importancia a cómo 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 aceptación
• Estas pruebas las realiza el cliente. Son básicamente
  pruebas funcionales, sobre el sistema completo, y
  buscan una cobertura de la especificación de requisitos
  y del manual del usuario. Estas pruebas no se realizan
  durante el desarrollo, pues sería impresentable al
  cliente; sino que se realizan sobre el
  producto terminado e integrado o pudiera ser una
  versión del producto o una iteración funcionad pactada
  previamente con el cliente.
• La experiencia muestra que aún después del más
  cuidadoso proceso de pruebas por parte del
  desarrollador, quedan una serie de errores que sólo
  aparecen cuando el cliente comienza a usarlo.
              Pruebas de regresión
• Se denominan Pruebas de regresión 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 aplicación 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 prácticas no adecuadas
  de control de versiones, falta de consideración acerca del ámbito o
  contexto de producción final y extensibilidad del error que fue
  corregido (fragilidad de la corrección), o simplemente una
  consecuencia del rediseño de la aplicación.
              Pruebas de carga
• son las pruebas que se realizan, desde una
  perspectiva, para determinar lo rápido que realiza
  una tarea un sistema en condiciones particulares
  de trabajo. También 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 ingeniería de pruebas, una
  práctica informática que se esfuerza por mejorar
  el rendimiento, englobándose en el diseño y la
  arquitectura de un sistema, antes incluso del
  esfuerzo inicial de la codificación.
       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 día, cada vez más
  necesarias: los tiempos de respuesta por encima
  de lo aceptable, la excesiva variabilidad de los
  mismos en función 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 categorías: predecibles e impredecibles
             Pruebas de recorrido
• Nunca se puede asegurar que una aplicación funcionará
  correctamente siempre, pues es inviable económicamente realizar
  pruebas de todos los componentes individuales y de todos los
  componentes como conjunto.
• Las pruebas deben ser diseñadas para descubrir fallos y no para
  demostrar que el software funciona. Siendo más razonable diseñar
  pruebas de aquellas partes en donde la probabilidad de fallo es
  mayor.
• Las pruebas deben ser diseñadas 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 enseñan, no van a ser tan ingenuos de
  hacer que falle.
         Pruebas de mutación
• Esta prueba esta basada en la introducción
  deliberada de diferentes códigos externos al
  programa (bugs) para reexaminar si estos
  bugs pueden ser detectados. Requiere gran
  disponibilidad de recursos de computación.
         Pruebas concurrentes
• Esto viene al caso de que comúnmente uno
  define los escenarios de Performance o de
  pruebas de Carga de la manera: “La aplicación
  debe soportar un máximo de 250 usuarios
  concurrentes” poniendo implícitamente la
  cantidad e usuarios concurrentes como
  parámetro de entrada para las pruebas.
Dispositivo de prueba de software
• Esto se consigue mediante el uso de un
  dispositivo especial de prueba(test Fixture),
  cuyas terminales de contacto( pogo-pins )
  coinciden con los puntos de conexión de la
  tarjeta de circuito impreso que están en el
  lado de las pistas.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:4/25/2013
language:Unknown
pages:22