2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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
8. 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.
9. 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.
10. 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.
11. 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
12. 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)
13. 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).
14. 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.
15. 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.
16. 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.
17. 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.
18. 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
19. 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.
20. Pruebas de mutación Esta prueba esta basada en la introducción deliberadade diferentes códigos externos al programa (bugs) para reexaminar si estosbugs pueden ser detectados. Requiere gran disponibilidad de recursos decomputación.
21. 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.
22. 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.
