unidad 3.1 prueba de sistemas

13 de abr de 2023 Sergio Sánchez Rios

Ingeniería de SoftwareUnidad III

Pruebas del Sistema

Sergio Sánchez Rios.

Ingeniero en Informática – Licenciado en Informática


Principio de la Prueba de Sistema

“Asegurar que el sistema hace lo que el cliente quiere que haga”.


Proceso de la Prueba de Sistema

Prueba

de Función

Prueba

de Desempeño

Prueba

de Aceptación

Prueba

de Instalación

Requerimientos Funcionales del

Sistema

Requerimientos No Funcionales

Especificaciones de

requerimientos del cliente

Ambiente del Usuario

Sistema

Funcionando

Software

Verificado y Validado

Sistema

Aceptado

SISTEMA

EN USO

Módulos

Integrados



Objetivo del proceso: Prueba funcional: verifica que el sistema integrado

realiza las funciones especificadas en las especificación de requerimientos.

Prueba de rendimiento o perfomance: luego de que se convencen que las funciones trabajan de acuerdo con la especificación, se realiza está prueba. Está prueba compara el rendimiento de los componentes integrados con los requerimientos no funcionales.

Hasta este punto, el sistema opera de la manera en que los diseñadores piensan. Se le denomina “Sistema Verificado”, es la interpretación de la especificación de requerimientos por parte de los diseñadores.



Luego si se comprueba satisfactoriamente que el sistema que se ha construido cumple los requerimientos, se tiene un “Sistema Validado” , es decir, se ha verificado el cumplimiento de los requerimientos.

Prueba de Aceptación: asegura a los clientes que el sistema que pidieron es el sistema que se construyo para ellos. A veces se ejecutan en el ambiente real, pero a menudo se realiza en una instalación del desarrollador.

Prueba de Instalación: se realiza (en el caso de que la prueba de aceptación no sea realizada en el lugar del cliente) para permitir que los usuarios ensayen las funciones del sistema y documenten todos los problemas adicionales surgidos de la puesta del sistema en el sitio real.


Prueba de Función

Ignora la estructura del sistema y se centra en la funcionalidad (se basa en los requerimientos funcionales).

El enfoque de aquí en adelante es más caja negra que caja blanca.


Prueba de FunciónPropósitos y Roles

Cada función puede asociarse con aquellos componentes del sistema que la conforman. Para algunas funciones, las partes pueden comprender el sistema entero.

El conjunto de acciones asociadas con una función se llama un hilo (thread), de manera que está prueba sule denominarse “prueba de hilo”.

Lógicamente, debe ser más fácil encontrar la causa de un problema en un conjunto pequeño de componentes que en uno grande. Por lo tanto, la facilidad de probar pasa por seleccionar cuidadosamente el orden en que se prueban las funciones.



Las pruebas de función eficaces deben tener una alta probabilidad de descubrir una falla. Para la prueba de función se aplican los mismas pautas que se utilizan para la comprobación unitaria:

Tener una alta probabilidad de descubrir un defecto. Utilizar un equipo de prueba independiente de los

diseñadores y programadores. Conocer acciones esperadas y rendimientos. Probar entradas validas como no validas. Jamás hacer modificaciones al sistema para hacerlo más

fácil de probar. Tener definido un criterio de finalización o detección.



Para pruebas de función, se prueban a razón de una función por vez, las pruebas de función pueden empezar antes de que se construya el sistema completo.

Las pruebas de función comparan el rendimiento real del sistema en sus requerimientos, de manera que los casos de prueba se desarrollan a partir de la especificación de requerimientos.

Ejemplo: Un sistema procesador de texto puede probarse examinando la manera en que el sistema maneja:

• Creación de Documentos.• Modificación de Documentos.• Eliminación de Documentos.



Ejemplo:

Dentro de cada categoría se prueban las funciones. Por ejemplo para la modificación de documentos:

Agregar Caracteres. Agregar palabras. Agregar párrafos. Anulación de Caracteres. Anulación de Palabras. Anulación de Párrafos. Cambio de Caracteres. Cambio de tamaño de tipo. Cambio de formato de Parrafo.


Prueba de Rendimiento

Cuando se tiene certeza que el sistema realiza las funciones exigidas por los requerimientos, el esfuerzo de prueba se vuelca a la manera en que se realizan esas funciones. Acá se ocupan los requerimientos no funcionales.


Prueba de RendimientoPropósitos y Roles

El rendimiento real del sistema se contrasta con los objetivos de rendimiento establecidos por el cliente, según esta en los requerimientos no funcionales.

La prueba de rendimiento es diseñada y gestionada por el equipo de prueba, y los resultados se entregan al cliente.

Debido a que la prueba de rendimiento normalmente involucra el hardware tanto como el software, los ingenieros de hardware pueden ser parte del equipo de prueba.


Prueba de RendimientoTipos de Prueba

Los tipos de prueba quedan determinados por los tipos de requerimientos no funcionales especificados:

• Prueba de Estrés: evalúan el sistema cuando está sometido a exigencias por encima de sus limites durante un corto plazo de tiempo. Ej.: Prueba de sistema con todos los dispositivos conectados funcionando a la vez.

• Prueba de Volumen: se ocupan del manejo de grandes cantidades de datos en el sistema. Ej.: Se ve si las estructuras de datos poseen el tamaño máximo para almacenar los datos esperados. Además, se prueba que cuando se sobre pase el máximo el sistema funcione de buena forma.

• Pruebas de Configuración: analiza las diferentes configuraciones del software y del hardware especificadas en los requerimientos.



• Prueba de Compatibilidad: son necesarias cuando un sistema tiene interfaces con otros sistemas. Se trata de determinar si las funciones de la interfaz se realizan según los requerimientos.

• Pruebas de Regresión: son las requeridas cuando el sistema que se está probando va a reemplazar un sistema existente. Está prueba garantiza que el rendimiento de nuevo sistema es mejor o tal vez similar al del actual sistema.

• Pruebas de Seguridad: garantizan que se satisfacen los requerimientos de seguridad. Se prueban características del sistema relacionadas con la disponibilidad, integridad, confiabilidad de los datos y servicios.

• Pruebas de Temporización: evalúan los requerimientos que se ocupan de aspectos temporales, tiempo para responder a un usuario, o el tiempo para realizar una función.



• Prueba de Medio Ambiente: contempla la habilidad del sistema de funcionar donde se le instala. La prueba garantiza el rendimiento apropiado del sistema bajo condiciones ambientales.

• Prueba de Calidad: evalúan la confiabilidad del sistema, facilidad de mantenimiento y disponibilidad.

• Prueba de Recuperación: se ocupa de la respuesta a la presencia de defectos o a la perdida de datos, energía, dispositivos o servicios.

• Prueba de Mantenimiento: se ocupa de la necesidad de herramientas de diagnóstico para ayudar a encontrar la fuente de los problemas. Se verifica que las ayudas existan y que funcionen correctamente.

• Prueba de la Documentación: asegura que se han escrito los documentos requeridos.

• Prueba de Factores Humanos: investigan requerimientos concernientes a las interfaz del usuario del sistema.



Algunas de estas pruebas son mucho más fáciles de administrar que las pruebas de función.

Para la realización y justificación de una de estas pruebas el requerimiento debe ser explicito y detallado.


Prueba de Aceptación

Con las pruebas de función y rendimiento, se tiene la convicción de que el sistema satisface todos los requerimientos especificados durante la fases iniciales de desarrollo de software.

El próximo paso es preguntar a clientes y usuarios si están de acuerdo con el producto.


Prueba de AceptaciónPropósitos y Roles

Hasta ahora, son los diseñadores quienes han diseñado los casos de prueba y administrado todas las pruebas. Ahora es el cliente quien conduce la prueba y define los casos a ser probados.

Aquellos empleados del cliente que estuvieron involucrados en la definición de los requerimientos desempeñan un rol importante en la prueba de aceptación, dado que comprenden qué tipo de sistema había pensado adquirir el cliente.


Prueba de AceptaciónTipos de Prueba

Prueba de Referencia (bench-mark)

El cliente prepara un juego de casos de prueba que representan condiciones típicas bajo las que el sistema operará cuando realmente este instalado.

El cliente evalúa el rendimiento del sistema para cada caso de prueba.

Estas pruebas normalmente se realizan cuando un cliente tiene requerimientos especiales.



Prueba Piloto

Se instala el sistema en una base experimental. Los usuarios ensayan el sistema como si se tratara de una instalación permanente.

Esta prueba cuenta con el trabajo diario del sistema para probar todas las funciones.

Esta prueba es mucho menos formal y estructurada que una prueba de referencia.



Prueba Piloto

A veces, los desarrolladores prueban un sistema desde adentro, con los usuarios, la propia organización o compañía antes de liberar el sistema al cliente; es decir se “pilotea” el sistema antes que el cliente ejecute realmente la prueba piloto.

Esta prueba interna se denomina “Prueba Alfa”, la prueba piloto del cliente es una “Prueba Beta”. Este enfoque es común cuando se trata de sistemas que se liberan a una amplia variedad de clientes.

Ej.: Una nueva versión de un sistema operativo.



Prueba en Paralelo

Cuando un nuevo sistema esta remplazando a uno existente o es parte de un desarrollo escalonado, puede usar esta prueba en paralelo.

Los usuarios se van acostumbrando gradualmente al sistema nuevo pero continúan utilizando el antiguo para duplicar las salidas obtenidas por el nuevo. Esta transición gradual les permite a los usuarios comparar y contrastar el nuevo sistema con el anterior.


Prueba de AceptaciónResultado de las Pruebas

La prueba de aceptación es la oportunidad del cliente para verificar que lo que quería es lo que se ha construido. Entonces, si el cliente está satisfecho, el sistema se acepta según lo establecido en el contrato.


Prueba de Instalación

La ronda final de prueba implica instalar el sistema en los puestos determinados por el usuario. Si la prueba de aceptación se ha realizado en el sitio, pueden no necesitarse las pruebas de instalación.

Cuando el cliente está satisfecho con los resultados, la prueba se considera completa y se hace la entrega formal del sistema.


Bibliografía

Guía del Tópico:

Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000.Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.

Solo referencial:

Ingeniería de Software: Un enfoque práctico - Roger S. Pressman - Mc Graw Hill – 2002.

unidad 3.1 prueba de sistemas

Documents