Unidad 5: Implementación

5.1 Implementación.

5.2 Entradas para pruebas.

5.3 Plan de pruebas (estrategia de prueba, ambientes, test team, atacar y asegurar

regresión).

5.4 Ejecución de tipos generales de pruebas.

5.5 Caja negra y caja blanca.

5.6 Otros tipos de test.

5.7 GUI, Funcionalidad, Performance, entre otros.

5.7.1 Documentación (técnica y de usuario).

5.7.2 Seguridad.

5.7.3 Diseño de las pruebas.

1.1 Implementación.

Desarrollar un plan de implementación del proyecto Después del diseño detallado del proyecto, el paso siguiente es elaborar un plan de implementación del mismo. Idealmente, el plan de implementación debe incorporar todos los aspectos de la implementación del proyecto, incluyendo las estrategias descritas para lograr sus resultados. El proceso de elaboración de un plan de implementación de un proyecto es esencialmente el mismo que el de un proyecto de desarrollo.

1.2  Entradas para pruebas.

Clase de equivalencia

Un conjunto de datos de entrada que definen estados válidos y no válidos del sistema.

•         Clase válida: genera un valor esperado –Clase no válida: genera un valor inesperado Se obtienen a partir de las condiciones de entrada descritas en las especificaciones.

•         Cada caso debe contemplar el máximo número de clases de equivalencia válidas.

•         Generar suficientes casos para cubrir todas las clases.

•         Generar un caso de prueba por cada clase de equivalencia no válida que haya sido identificada

5.3 Plan de pruebas (estrategia de prueba, ambientes, test team, atacar y asegurar

regresión).

´        Estrategias de prueba del software

´        Proporcionan un plano o guía para el desarrollador del software, para la organización de control de calidad y para el cliente.

´        Es una guía que describe los pasos a llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir. Por lo tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de los casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes.

Pruebas

Para llevar a cabo un caso de prueba es necesario definir las precondiciones y post condiciones, identificar unos valores de entrada, y conocer el comportamiento que debería tener el sistema ante dichos valores.

Durante el proceso de pruebas es importante cubrir los siguientes objetivos:

´        Establecer la participación de los roles implicados.

´        Definir el alcance, momento y características de las diferentes pruebas a realizar.

´        Definir los contenidos de los manuales de usuario y de administración.

´        Establecer los requisitos necesarios para la aceptación del producto antes de su promoción a la siguiente fase del ciclo de vida de desarrollo.

´        Definir el ciclo de vida de gestión de un caso de prueba.

´        Presentar técnicas y estrategias aplicables en la elaboración y ejecución de las ´ pruebas del software.

Un enfoque estratégico para la prueba del software Generalmente se proporciona una plantilla para la prueba con las siguientes características generales:

´        La prueba comienza en el nivel de módulo y trabaja "hacia fuera", hacia la integración de todo el sistema basado en computadora. Se usa el enfoque “bottom-up”.

´        En diferentes momentos se utilizarán diferentes técnicas de prueba

´        La prueba la lleva a cabo el que desarrolla el software y (para grandes proyectos) un grupo de prueba independiente.

´        La prueba y la depuración son actividades diferentes, pero la depuración se puede incluir en cualquier estrategia de prueba.

Etapas de un plan de pruebas a. especificar los objetivos de las pruebas. b. determinar con precisión los criterios a seguir en su realización. c. Integrar al personal y los elementos necesarios para el desarrollo de las pruebas. d. Aplicación de la prueba o pruebas según los criterios seleccionados. e. evaluación de los resultados y consideraciones para llevar a cabo una nueva serie de pruebas.

ASPECTOS A TENER EN CUENTA EN LA APLICACIÓN DE UNA PRUEBA

´        Operatividad. Cuanto mejor funcione el software, más eficientemente se puede probar. Ningún error debe bloquear la ejecución de las pruebas.

´        Observabilidad. Lo que ves es lo que pruebas. Un resultado incorrecto se identifica fácilmente.

´        Controlabilidad. Cuánto mejor podamos controlar el software más se puede automatizar y optimizar. Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.

Capacidad de descomposición. Controlando el ámbito de las pruebas podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. Los módulos de software se pueden probar independientemente.

´        Simplicidad. Cuanto menos haya que probar más rápidamente podemos probarlo.

´        Estabilidad. Cuánto menos cambios haya, menos interrupciones a las pruebas.

´        Facilidad de comprensión. Cuanta más información tengamos, mejores serán las pruebas.

´        Sistema de pruebas

´        Los cuatro componentes principales de un sistema de pruebas son:

´        Equipo de pruebas: los ingenieros de pruebas, técnicos de pruebas y el responsable de las pruebas, los cuales tienen habilidades, experiencia y trabajan para diseñar, implementar, y usar componentes de pruebas.

´        - Recursos de prueba: casos de prueba, datos de prueba, herramientas de pruebas,

´        y otro material de desarrollo.

´        Sistema de prueba

´        Procesos de prueba: condiciones informales, formales, no documentadas y documentadas en las que se realiza el trabajo de pruebas.

´        Entorno de pruebas: hardware, software, infraestructura de redes, oficina y laboratorio, y otros elementos que formen el lugar de trabajo.

5.5 Caja negra y caja blanca.

CAJA BLANCA: Tipos de pruebas de software que se realiza sobre las funciones internas de un módulo. «si queremos saber cómo funciona internamente un elemento de un sistema se utiliza el termino caja blanca.»

CAJA NEGRA: 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. «si queremos es estudiar la interacción de dicho modulo con los demás módulos del sistema se utiliza el termino caja negra»

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.

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

TECNICAS USADAS: 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ógicoaritmé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.

Pruebas de caja negra

CARACTERISTICAS:

´        (Pressman) se centran en los requisitos funcionales

´        Pruebas sobre la interfaz del software.

´        Enfocada en las entradas y salidas y no en el código fuente.

5.6 Otros tipos de test.

Pruebas (test): «una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto»

Caso de prueba (test case): «un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»

Defecto (defect, fault, «bug»): «un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa»

5.7 GUI, Funcionalidad, Performance, entre otros.

Interfaz de Usuario

La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, un equipo o una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo.

Es un programa informático que actúa de interfaz de usuario, utilizando un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz. Su principal uso, consiste en proporcionar un entorno visual sencillo para permitir la comunicación con el sistema operativo de una máquina o computador. GUI’s y Zooming user Interface

GUI's y Zooming user interface Los tipos de GUIs que se encuentran en juegos de computadora, y los GUIs avanzados basados en realidad virtual, se usan con frecuencia en tareas de investigación. La interfaz de enfoque del usuario o ZUI (Zooming User Interface), que es un adelanto lógico de las GUI, mezclando 3D con 2D. Podría expresarse como "2 dimensiones y media en objetos vectoriales de una dimensión".

Interfaz de usuario de Pantalla táctil

Los "GUIs de uso específico." Un ejemplo de un GUI de uso específico es la ahora familiar touchscreen o pantalla táctil (pantalla que al ser tocada efectúa los comandos del ratón en el software).

Interfaz natural de Usuario

 Las NUI naturales son aquellas en las que se interactúa con un sistema, aplicación, etc., sin utilizar dispositivos de entrada como ratón, teclado, lápiz óptico, etc. En lugar de éstos se utilizan las manos o las yemas de los dedos.

Pasos para el diseño de una interfaz

´        Principios de UCD

´        Análisis del modelo ISO 13407

´        Evaluación contextual

´        Crear a una persona

´        Manual de la página

´        Crear Prototipo de Baja fidelidad

Evaluación de usabilidad con el usuario:

´        Diseño contextual

´        Inspección de estándares

´        Evaluación con un prototipo de baja fidelidad

´        Cuestionarios de usabilidad del prototipo

´        Formato de tareas y de observación del usuario

´        Análisis de tareas usando KLM

Evaluación de usabilidad sin usuarios:

      Elaboración de Escenarios

      Aplicación de Heurísticas

      Paseo Cognitivo

      Comparación de resultados

      Evaluación con usuarios

      Presentación de la información

      Descripción de la página con las correcciones hechas

      Diseño Centrado en el Usuario

      Es una filosofía de diseño que tiene por objetivo la creación de productos que resuelvan necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso posible con el mínimo esfuerzo de su parte.