PRUEBAS DE SOFTWARE "TESTING"

PRUEBAS DE SOFTWARE


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.

Las pruebas de software también conocidas como “testing” 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.

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.

La importancia de la detección oportuna

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barata es su corrección.

El proceso de prueba es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.

TIPOS DE PRUEBAS


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.

Las pruebas de validación empiezan tras la culminación de las pruebas de integración, cuándo se han ejercitado los componentes individuales.se han terminado de ensamblar el software como paquete y se ha descubierto y corregido los errores de interfaz

Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?

Enfoques a la verificación

• Dinámica de verificación, también conocido como ensayos o experimentación.

• Estática de verificación, también conocido como análisis.

Tipos

• Pruebas de aceptación: desarrolladas por el cliente.

• Pruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).

• Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores

Características

Comprobar que se satisfacen los requisitos:

• Se usan la mismas técnicas, pero con otro objetivo.

• No hay programas de prueba, sino sólo el código final de la aplicación.

• Se prueba el programa completo.

• Uno o varios casos de prueba por cada requisito o caso de uso especificado.

• Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).

• Pruebas alfa (desarrolladores) y beta (usuarios).

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 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. Las 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.

Las pruebas funcionales están desarrolladas bajo la perspectiva del usuario, confirmando que el sistema hace lo que los usuarios esperan que haga. Un error funcional en su aplicación puede tener consecuencias catastróficas, desde la pérdida de credibilidad de sus clientes, hasta grandes pérdidas económicas.

Los consultores de pruebas funcionales de Testhouse tienen amplia experiencia en multitud de mercados a nivel global, adaptándose a todo tipo de metodologías de desarrollo y habiendo realizado pruebas funcionales en aplicaciones críticas de empresas líderes en el sector de finanzas, telecomunicaciones y media, entre otros.

PRUEBAS DE RECORRIDO

Incluye indagación y observación del flujo de transacciones dentro de procesos representativos desde el punto en que las transacciones son iniciadas hasta el punto en el que son reportadas en el mayor general. Recorremos los controles que hemos identificado para determinar que han sido diseñados e implantados eficazmente. El recorrido incluye el examen de los flujos de la documentación e información desde una perspectiva tanto manual como automatizada. Su objetivo es confirmar nuestra comprensión del flujo de las transacciones representativas, la exactitud de la información que hemos obtenido acerca de los controles preventivos y/o de detección relevantes sobre el flujo de transacciones, si los controles han sido diseñados eficazmente para prevenir o detectar y corregir aseveraciones equívocas materiales en forma oportuna, si lo los controles han sido implantados y la idoneidad de nuestra documentación.

PRUEBA UNITARIA

En programación, 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.

Característica

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

• Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua

• Completas: deben cubrir la mayor cantidad de código.

• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.

• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.

• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

Ventajas

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas:

1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.

2. Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.

3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.

4. Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.

5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones

Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.
CAJA BLANCA

Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas también son llamadas pruebas modulares ya que nos permiten determinar si un módulo del programa está listo y correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras está desarrollando el módulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar, se debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de manera sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, si los módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos de probar y al encontrar algún error será más difícil ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista de pruebas podrá recomendar que un módulo muy complejo sea separado en 2 o 3 módulos más sencillos.

Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar familiarizado en el uso de herramientas de depuración y pruebas, así mismo deben conocer el lenguaje de programación en el que se está desarrollando la aplicación, en la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientas para cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboración de casos de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas unitarias son: Junit, La Suite de Mercury, CPPUnit etc.

El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfaces, o flujo de datos entre componentes.

No es un requisito indispensable la culminación de todos los módulos del sistema para iniciar las pruebas, generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas metodologías consideran oportuno iniciar la etapa de pruebas unitarias poco después del desarrollo.

En esta imagen se muestra lo que se considera una representación clásica de Software Testing White Box o pruebas de caja blanca, en este tipo de pruebas el cubo representaría un sistema en donde se pueden observar los diversos componentes que forman parte del mismo, cada uno de estos componentes debe ser probado en su totalidad (óvalos), y también sus interfaces o comunicaciones con los demás componentes (flechas), este tipo de pruebas también son llamadas pruebas de caja de cristal ya que este último término representa mejor el tipo de pruebas.

Lo importante en este tipo de pruebas es que se deben tener claros los siguientes aspectos:

• Los datos de entrada son conocidos por el Tester o Analista de Pruebas y estos deben ser preparados con minuciosidad, ya que el resultado de las pruebas dependen de estos.

• Se debe conocer que componentes interactúan en cada caso de prueba.

• Se debe conocer de antemano que resultados debe devolver el componente según los datos de entrada utilizados en la prueba.

• Finalmente se deben comparar los datos obtenidos en la prueba con los datos esperados, si son idénticos podemos decir que el modulo supero la prueba y empezamos con la siguiente.

Luego de tener una buena cantidad de módulos independientes probados y encontrados Conformes, el siguiente paso es integrarlos, las principales formas de integración que existen son:

• Integración Incremental.

• Integración no incremental.



Integración Incremental

Al realizar una integración incremental debemos combinar o unir el siguiente modelo que se debe probar con el conjunto de módulos ya probados. El número de módulos se incrementa progresivamente hasta formar el programa completo. Esto lo podemos realizar en dos formas.

• Integración Incremental Ascendente.

• Integración Incremental Descendente.





Integración incremental ascendente



En este tipo de integración se combinan los módulos de más bajo nivel en grupos que realizan alguna sub función específica.

Atreves de un driver (módulo impulsor) se simulan llamadas a los módulos, se introducen los datos de prueba y se recogen los resultados.

Cada grupo se prueba usando un driver (test integrador), y este luego es sustituido por los módulos de nivel superior en la jerarquía. En el último paso se prueba el programa completo con sus entradas y salidas reales.

Ejemplo: Para probar un sistema bancario, se debe empezar por los módulos que aplican lógica de negocio y que hacen cambios en la base de datos, una vez que cada uno de estos módulos funciona correctamente, se inicia las pruebas de niveles superiores, los cuales básicamente hacen llamadas a estos módulos de bajo nivel, esta segunda etapa normalmente es mucho más rápida.

Tal como se muestra en la siguiente figura, luego de probar los módulos de más bajo nivel, continuamos con los módulos del siguiente nivel, para esto debemos construir nuevos drivers o impulsores (B y C), que se aplicaran directamente a los módulos superiores (B y C) y estos a su vez se integrarán a los de más bajo nivel.



Este proceso se repite algunas veces hasta que se culmina por probar el sistema completo, en la figura 2 se muestra un nivel más de integración incremental ascendente.

VENTAJAS DE LA INTEGRACIÓN INCREMENTAL ASCENDENTE:



Las entradas para las pruebas son más fáciles de crear ya que los módulos inferiores suelen tener funciones más específicas.

Es más fácil la observación de los resultados de las pruebas, puesto que es en los módulos inferiores donde se elaboran.

Resuelve primero los errores de los módulos inferiores que son los que acostumbran tener el procesamiento más complejo, para luego nutrir de datos al resto del sistema.



DESVENTAJA DE LA INTEGRACIÓN INCREMENTAL ASCENDENTE:

Se requieren módulos impulsores, que deben escribirse especialmente y que no son necesariamente sencillos de codificar.

El sistema como entidad no existe hasta que se agregue el ultimo modulo.



La integración descendente:



Los módulos se incorporan iniciando del módulo de control principal (de mayor nivel) para luego ir incorporando los módulos subordinados progresivamente. No hay un procedimiento considerado óptimo para seleccionar el siguiente módulo a incorporar. La única regla es que el módulo incorporado tenga todos los módulos que lo invocan previamente probados.

En general no hay una secuencia óptima de integración. Debe estudiarse el problema concreto y de acuerdo a este, buscar el orden de integración más adecuado para la organización de las pruebas. No obstante, pueden considerarse las siguientes pautas:

• Si hay secciones críticas como ser un módulo complicado, se debe proyectar la secuencia de integración para incorporarlas lo antes posible.

• El orden de integración debe incorporar cuanto antes los módulos de entrada y salida.

Existen principalmente dos métodos para la incorporación de módulos:



1. Primero en profundidad: Primero se mueve verticalmente en la estructura del módulo.

2. Primero en anchura: primero se mueve horizontalmente en la estructura del módulo.



Etapas de la integración descendente:



- El módulo de mayor nivel hace de impulso y se escriben módulos ficticios simulando a los subordinados, que serán llamados por el módulo de control superior.

- Probar cada vez que se incorpora un módulo nuevo al conjunto ya engarzado.

- Al terminar cada prueba, sustituir un módulo ficticio subordinado por el real que remplazaba.

- Escribir los módulos ficticios subordinados que se necesiten para la prueba del nuevo módulo incorporado.



Ventajas de este método de integración:



Las fallas que puedan existir en los módulos inferiores se detecten en una etapa temprana.

Permite ver la estructura del sistema desde un principio, facilitando la elaboración de demostraciones de su funcionamiento.

Concuerda con definir primero las interfaces de los distintos subsistemas para después seguir con las funciones específicas de cada uno por separado.

Desventajas:

Requiere de mucho trabajo de desarrollo adicional, ya que se debe escribir un gran número de módulos ficticios subordinados.

Antes de incorporar los módulos de entrada y salida resulta difícil introducir los casos de prueba y obtener los resultados.

Los juegos de datos de prueba pueden resultar difíciles o imposibles de generar, puesto que generalmente los módulos de nivel inferior son los que proporcionan los detalles.

Induce a diferir la terminación de la prueba en ciertos casos.



Integración no incremental

Es muy sencilla y se recomienda para proyectos de poca envergadura, consiste en probar cada módulo por separado de manera similar a la integración incremental, pero una vez de terminar con los módulos independientes, se continúa probándolos todos juntos como un todo.

La única ventaja es que no se necesita ningún tipo de trabajo adicional, ni planificar al orden de integración, ni crear módulos impulsores, ni módulos ficticios subordinados.

Las desventajas son que no tiene noción de la comunicación hasta el final, en ningún momento se dispone de un producto (ni siquiera parcial) para mostrar o presentar, el hecho de presentar las pruebas de una vez hace que las sesiones de prueba sean más largas y tediosas, la cantidad de errores que arroja puede ser atemorizante, encontrar la causa de los errores puede resultar mucho más compleja y se corre el riesgo que a poco tiempo de la entrega, haya que volver sobre el diseño y la codificación de sistema.



• Automatización De Pruebas Unitarias

Contexto

Un proceso de desarrollo de software que necesita mejorar la calidad y reducir el número de defectos. El proyecto ya debe poseer Automatización de build y Control de versiones.

Problema

La calidad del software es una tarea de todo el equipo. Dejar la cuestión de la calidad del código apenas a cargo de un grupo de analistas de pruebas y de calidad es un riesgo. Aumentar la confianza de los programadores en relación a eventuales modificaciones en el código es esencial en Código Legado. Facilitar las pruebas de los programadores es fundamental, para que ellos puedan probar su código sólidamente y de esa forma no encuentren dificultades en probar siempre todo lo que producen.

Fuerzas

• El costo de detección y corrección de un defecto es mayor cuando ocurre en la etapa de homologación.

• Las partes complejas de un software acostumbran tener más defectos y tienden a ser recurrentes.

• La flexibilidad de modificar aumenta la complejidad. Siempre que un desarrollador trabaja con un código complejo, le lleva un tiempo para que él pueda entender nuevamente la solución.

• Corregir un defecto ocasionalmente causa problemas en otra parte del software.

Solución

Utilice una herramienta para la creación de la Prueba Unitaria automatizada, bien como herramientas que permitan la creación de "Mock Object" (Objeto Falso) que imiten la funcionalidad de objetos reales.

Siempre ejecute todas las pruebas unitarias automatizadas antes de hacer check-in de nuevos código en el repositorio de control de versiones.

Cuando un nuevo defecto es descubierto, lo primero que se hace es una prueba unitaria automatizada para probar el defecto. Luego el mismo es corregido. De este modo es más difícil que el defecto vuelva, ya que en el caso que un desarrollador cometa el mismo error nuevamente, la batería de pruebas unitarias automatizadas lo detectará.

Raciocinio

Las pruebas unitarias reducen el tiempo que gasta el equipo para identificar y corregir defectos (HUNT e THOMAS, 2004). Un conjunto de pruebas unitarias automatizadas también aumenta la confianza del equipo cuando necesita realizar cambios para inclusión de nuevas funcionalidades o la alteración de funcionalidades existentes.

La automatización de pruebas unitarias aumenta la calidad al facilitar la detección de defectos más rápido en el ciclo de desarrollo. El tiempo de vida de un software tiende a aumentar debido a la "red de seguridad" que da la batería de pruebas unitarias.

Contexto Resultante

El proyecto posee un conjunto de pruebas unitarias automatizadas que es ejecutada siempre que un desarrollador le desee.

El código de las pruebas unitarias generados por la Automatización De Pruebas Unitarias se deben almacenar como parte del proyecto junto con el código fuente del software en la herramienta de control de versiones. La automatización de bild debe tener tareas específicas para ejecutar todas las pruebas unitarias del proyecto. De este modo es posible ejecutar el conjunto de pruebas unitarias siempre que la integración continua sea ejercida.



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.

Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa.

Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la práctica habitual en programación extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software.

Tipos de regresión


Clasificación de ámbito

• Local - los cambios introducen nuevos errores.

• Desenmascarada - los cambios revelan errores previos.

• Remota - Los cambios vinculan algunas partes del programa (módulo) e introducen errores en ella.

Clasificación temporal

• Nueva característica - los cambios realizados con respecto a nuevas funcionalidades en la versión introducen errores en otras novedades en la misma versión del software.

• Característica preexistente - los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existente de previas versiones.

Como mitigar los riesgos

• Repetición completa y habitual de la batería de pruebas, manual o mediante automatización.

• Repetición parcial basada en trazabilidad y análisis de riesgos.

• Pruebas de cliente o usuario:

o Beta - distribución a clientes potenciales y actuales de versiones beta.

o Pilot - distribución a un subconjunto bien definido y localizado.

o Paralela - simultaneando uso de ambos sistemas.* Usar reléase mayores. Probar nuevas funciones a menudo cubre las funciones existentes. Cuantas más nuevas características haya en un reléase, habrá mayor nivel de pruebas de regresión "accidental".

• Parches de emergencia - estos parches se publican inmediatamente, y serán incluidos en reléase de mantenimiento futuras.

Usos

Las Pruebas de Regresión pueden usarse no solo para probar la corrección de un programa, sino a menudo usarse para rastrear la calidad de su salida. Por ejemplo en el diseño de un compilador, las pruebas de regresión deben rastrear el tamaño del código, tiempo de simulación, y el tiempo de compilación de las suites de prueba. Cuando quiera que aparezca un nuevo build, el proceso de regresión aparece.



Citas

• "También como consecuencia de la introducción de nuevos bugs, el mantenimiento del programa necesita más pruebas del sistema por sentencia escrita que cualquier otra programación. En teoría, después de cada corrección uno debe ejecutar el batch completo de casos de prueba antes de ejecutar contra el sistema, para asegurarse de que no ha sido dañado de forma oscura. En la práctica, tales pruebas de regresión deben aproximarse a esta idea teórica, y es muy costoso." -- Fred Brooks, The Mythical Man Month (p 122).

PRUEBAS DE PRESTACIONES



A veces es importante el tiempo de respuesta, u otros parámetros de gasto. Típicamente nos puede preocupar cuánto tiempo le lleva al sistema procesar tantos datos, o cuánta memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones, o ... Para todos estos parámetros suele ser importante conocer cómo evolucionan al variar la dimensión del problema (por ejemplo, al duplicarse el volumen de datos de entrada).





Las Pruebas de Prestaciones tienen como objetivo fundamental:

"Demostrar que el sistema funciona de acuerdo a las especificaciones con tiempos de respuesta aceptables para el usuario mientras se están procesando los volúmenes de transacciones requeridos sobre una base de datos proporcional a la de producción."



Las Pruebas de Escalabilidad tienen como objetivo fundamental:

"Demostrar la capacidad de un sistema para proporcionar un servicio aceptable cuando la carga se incrementa o decrementa. Ejemplo: manejar cargas del sistema, bases de datos y redes tanto grandes como pequeñas."



El principal requisito para las pruebas de prestaciones y escalabilidad, es disponer de una infraestructura para poder ejecutar pruebas automáticas durante largos periodos de tiempo.



Esta infraestructura es un activo, aunque costoso, para cualquier organización por lo que hay que hacer el mayor uso posible del mismo.



HI Iberia Ingeniería y Proyectos ayuda a nuestros clientes a desarrollar una infraestructura que pueda ser utilizada para la realización de otras pruebas de prestaciones y escalabilidad con objetivos más amplios:

• Evaluar la capacidad de crecimiento del sistema.

• Evaluar la escalabilidad del sistema.

• Identificar puntos débiles en la infraestructura.

• Ajustar el sistema para optimizar el rendimiento.

• Verificar y Garantizar la robustez y fiabilidad del sistema.

• Detectar aspectos en el sistema que pueden ser irrelevantes para operaciones a pequeña escala pero que pueden llegar a ser vitales para el uso del sistema cuando este crece.

• Identificar cuellos de botella y puntos débiles en la arquitectura del sistema que podrían reducir la capacidad y prestaciones del sistema.

• Ajustar los parámetros de rendimiento del sistema mediante la repetición de pruebas de prestaciones.

Una infraestructura adecuadamente diseñada puede ser utilizada para asegurar estos objetivos como parte de la estrategia global de pruebas.



La metodología utilizada por HI Iberia Ingeniería y Proyectos para implementar la infraestructura de pruebas de prestaciones sigue las siguientes fases:

• Análisis del Sistema

• Especificación de los casos de Prueba

• Preparación

• Ejecución

• Tuning



PRUEBAS DE SISTEMA

Al final del desarrollo del software se incorpora otros elementos (hardware, personas, información) y se realiza una serie de pruebas de integración del sistema y de validación.

Estas pruebas están más allá del proceso del software y no las realizan únicamente los ingenieros del software. Sin embargo los pasos dados durante el diseño y la prueba mejoraran en gran medida la probabilidad de tener éxito y la integración del software del sistema mayor.



El software ya validado se integra con el resto del sistema donde algunos

Tipos de pruebas a considerar son:

Rendimiento: determinan los tiempos de respuesta, el espacio que ocupa el módulo en disco o en memoria, el flujo de datos que genera a través de un canal de comunicaciones, etc.



Resistencia: determinan hasta donde puede soportar el programa determinadas condiciones extremas.



Robustez: determinan la capacidad del programa para soportar entradas incorrectas.



Seguridad: se determinan los niveles de permiso de usuarios, las operaciones de

acceso al sistema y acceso a datos la prueba comprueba que los mecanismos de protección integrados en el sistema realmente lo protejan de irrupciones inapropiadas

Usabilidad: se determina la calidad de la experiencia de un usuario en la forma en la que éste interactúa con el sistema, se considera la facilidad de uso y el grado de

satisfacción del usuario.



• Instalación: se determinan las operaciones de arranque y actualización del software.



Desempeño: está diseñada para probar el desempeño del software en tiempo de ejecución en tiempo de contexto de un sistema integrado. La prueba de desempeño se aplica en todos los pasos del proceso de la prueba, incluso a nivel de la unidad, el desempeño de un módulo individual debe evaluarse mientras se realizan las pruebas





CAJA NEGRA (SISTEMAS)

En teoría de sistemas y física, 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

Cuando se construye software a la medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide y verifique todos 1os requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo del sistema.