Prueba de entornos especializados, arquitectura y aplicaciones del software

Introducción

La prueba del software (SW) nos ayuda a descubrir los errores que se cometieron de manera imprevista al momento de realizar el diseño y construcción del software, por lo tanto la estrategia de prueba del software (EPSW) es una guía que describe los pasos que se seguirán al momento de realizar la prueba, una vez que planeado y realizados dichos pasos, en cuanto esfuerzo, tiempo y recursos se requieran, conllevarán a varios elementos tales como: 1) planificación de la prueba, 2) diseño de casos de prueba, 3) ejecución de la prueba, 4) recolección y 5) evaluación de los resultados.

Por tal razón un conjunto de pruebas son actividades que se orientan para la comprobación de los aspectos de un sistema del software o ya sea una parte del mismo. Estas pruebas son definidas a partir de las funciones y características del sistema considerando las pruebas de caja blanca y caja negra. Toda prueba de entorno especializado en las arquitecturas y aplicaciones del software, así como las estrategias de las pruebas del software son importantes ya que con las mismas obtenemos los resultados que esperamos con los diferentes procesos, métodos y clases que podemos diferenciar en cada prueba con el fin de demostrarle al usuario un buen trabajo que satisfaga las necesidades que desea. (Testing, 2015)

(Aralelij, 2009) A medida que la prueba del software se ha hecho más complejo ha crecido también la necesidad de soques de pruebas especializados los métodos de prueba de caja blanca y caja negra son aplicables a todos los entornos, arquitecturas y aplicaciones, pero a veces se necesitan directrices y enfoques únicos para las pruebas estas secciones prueban directrices de entornos, arquitectura y aplicaciones especializadas que se pueden encontrar los ingenieros del software.

Pruebas de terse y graficas de usuarios

(Mancilla, 2009)Presentan interesantes desafíos para los ingenieros del software debido a los componentes reutilizables provistos como partes de los entornos de desarrollo, la creación de la interfaz de usuario se ha convertido en menos costosos en tiempos y más exactas, al mismo tiempo la complejidad de estas ha aumentado originando más dificultad en el diseño y ejecución de prueba, dado que las modernas pruebas tienen la misma apariencia y filosofía, se puede obtener una serie de pruebas estándar los grafos de estado de modelado finito puede ser utilizado para realizar pruebas que vayan dirigidas sobre datos específicos y programas objeto que sean relevantes para el gran número de permutaciones asociadas con las operaciones, sería necesario probar y utilizar las herramientas automáticas.

Estrategia de pruebas del software

Verificación: conjunto de tareas que nos garantiza que el software nos está implementando correctamente una función específica, es decir cuando verificamos el software estamos viendo si este funciona correctamente, evaluándolo modulo a modulo en un programa convencional verificando si está cumpliendo su función, "¿construimos el producto correctamente?".

Validación: conjunto de tarea que nos aseguran que el software que se construye sigue los requerimientos del cliente, es decir cuando ya tenemos nuestro producto terminado esta validado si cumple y satisface lo necesario para el cliente, "¿construimos el producto correcto?".

Visión general de la estrategia del software

Ilustración 1

Por otra parte, las EPSW pasa a ser deducido por una serie de pruebas en las que podemos describir las siguientes:

• Prueba de unidad: enfocado en cada unidad, por decir componente, clase u objeto del software.

• Prueba de integración: se enfoca al diseño y construcción de la arquitectura del software.

• Prueba de validación: requerimientos que validan la construcción del software.

• Prueba del sistema: punto en el que se prueba el software con otros elementos en un todo.

EPSW convencional

Prueba de unidad

El controlador lleva una serie de módulos que tiene que probar, cada caso de prueba se acopla a un numero de resultados esperados en si comprobando que un módulo no es un programa independiente. En esta prueba definiremos dos conceptos en las cuales mencionamos:

-software controlador: ase llamada a ese modulo verificando que cada prueba de unidad consiste en la verificación de la interfaz, estructuras de datos locales, rutas independientes y rutas de manejo de error del software funcionan adecuadamente obteniendo así los resultados que buscamos.

-software representante (stub): cuando tenemos dentro de un módulo una llamada una función a un método, en lugar de llamar a ese método y entrar en otro modulo lo que asemos es representarlo por un stub que es un módulo que por lo general no hace nada, pero puede por decir invocar una rutina de imprimir por pantalla que sea llamado a él o que devuelva un valor que previamente hemos conocido, por ejemplo, un módulo que calcule la función el numero PI en lugar de entrar y computar lo que directamente hará es devolver el valor PI por tanto el modulo se va probando su integridad sin delegar en otros.

Prueba de integración

Son los módulos que se van a ir integrando uno a uno obteniendo así varios enfoques, uno de estos enfoques que tenemos es:

Descendente se integra al moverse hacia abajo a través de la jerarquía de control.

Recorrido primero en profundidad

Tenemos una serie de módulos por decir, M1, M2, M3, M4, M5, M6, M7, M8 estos se van a ir integrando uno por uno en diferente ruta supongamos que del M1 hacia la izquierda se integrara con el M2, M5, M8 y luego al M6, en la ruta central M1 se integrara al M3 Y M7 y así ya a la ruta derecha el M1 con el M4.

Recorrido primero en anchura

Retomando el ejemplo nos enfocaremos en ir de nivel a nivel:

nivel de control: M2, M3 y M4

nivel:M5, M6 y M7

nivel:M8

Ascendente se probará distintos grupos del módulo del software donde los módulos se integrarán uno por uno, por ejemplo, tenemos tres grupos D1, D2, D3 lo que vamos a ser es ir acoplándolos unos a otros para ver que realmente funcionen bien y a esto los sustituiremos con sus respectivos módulos que tenemos en nuestro programa y así se probara el enfoque ascendente.

En las estrategias de pruebas del software encontramos dos tipos de pruebas las cuales son:

la prueba de caja blanca

(Luna, 2009) Filosofía de diseño de casos de prueba que usa la estructura de control descrita como parte del diseño a nivel de componentes para derivar casos de prueba.

Cuando usamos los métodos de prueba de caja blanca tenemos que verificar ciertas características como las siguientes:

-tenemos que garantizar que todas las rutas independientes que se encuentran dentro de cada módulo son revisadas al menos una vez.

-revisar todas las decisiones lógicas de sus lados verdaderos y falsos

-ejecutar todos los bucles en sus fronteras y dentro de sus fronteras operativas

-revisar estructuras de datos internas para garantizar su validez

Para ellos tenemos que definir lo que se conoce con el nombre de constructos estructurados en un gráfico de flujo.

Ilustración 2

Básicamente lo que tenemos que identificar cada una de las instrucciones que tiene nuestro modulo y podemos tener, esos nodos que aparecen cuando nos referimos a una secuencia, estructura o instrucciones que van ejecutándose en secuencia, pues son dos módulos acoplados con una flecha tal como mostramos en el grafico o cuando tenemos una estructura condicional como un ifs de helf hay vemos que tenemos un nodo pues ese nodo se bifurca en dos porque es parte del if la ejecución del if y luego la ejecución del helf y luego convergen los dos en un punto de ejecución del cual siguen las instrucciones de ejecución, luego tenemos otros constructo estructurados momo el mientras, hasta y caso el swich en este caso en programación C a todos los estructos estructurados se debe representar de esa manera para que por ejemplo, cuando tengamos un diagrama de flujo podamos identificar de donde parte un nodo, hasta donde se dirige o hasta donde los nodos se compartirán y así, por otra parte también el grafico de flujo este grafico es una representación equivalente y muy similar a lo que es el diagrama de flujo en los cuales los nodos se están agrupando unos más enunciados de procedimientos es decir instrucciones que se ejecutan en secuencial sin ningún tipo de salto las aristas que denomina el flujo de control por donde y cuáles son los caminos por donde pueden llevarse al momento de ejecutar los módulos y luego las regiones que son las áreas que son cortadas por las aristas que se ha visto previamente

Prueba de ruta básica

Ruta de programa independiente: conjunto de enunciados que cualquiera introduce ya sea una arista que no se haya recorrido antes de definir la ruta produciendo una nueva condición en el programa.

Conjunto básico: enunciados que garantizan la ejecución del programa al menos una vez, donde se ejecutaran sus lados verdaderos y falsos.

Dentro del conjunto básico encontramos

La complejidad ciclomática: tamaño del conjunto básico, para calcular la complejidad ciclomática sw necesitan tres puntos.

• 1) R: el número de regiones(R) del grafico de flujo

• 2) V(G)= E-N+2; E= número de aristas. N= número de nodos

• 3) V(G)=P+1; P es el número de nodos predicado del grafico de flujo G

¿Qué es un nodo predicado? Es cuando tenemos una convicción que produce dos caminos por lo minino.

la prueba de caja negra

se enfocan en los requisitos funcionales del software donde se derivan conjuntos de condiciones de entrada que revisan completamente las funcionalidades para un programa.

Por tanto, la prueba de caja negra se realiza normalmente en las últimas etapas de la prueba, es decir de la validación y la prueba del sistema

Se centran en los requisitos funcionales del software ósea la prueba de caja negra permite al ingeniero del software obtener conjuntos de condiciones de entradas que ejerciten completamente todos los requisitos funcionales de todo programa, la prueba de caja negra no es una alternativa a las técnicas de prueba de caja blanca más bien se trata de un enfoque complementario que trata de descubrir diferentes tipos de errores de caja blanca , la prueba de caja negra intentan encontrar errores de las siguientes categorías :

• Funciones incorrectas o ausentes

• Errores de interfaz

• Errores en estructuras de datos o accesos de bases de datos externas

• Errores de rendimiento

• Errores de iniciación y de terminación

A diferencia de la prueba de caja blanca que se lleva a cabo previamente al proceso de prueba, la prueba de caja negra tiende a aplicarse en fases posteriores de la prueba, ya que ignora intencionadamente la estructura de control centrada su control en el campo de la información.

Las pruebas se diseñan para las siguientes preguntas

¿Cómo se prueba la validez funcional?

¿Cómo se prueba el rendimiento y comportamiento del sistema?

¿Qué clase de entrada compondrán unos buenos casos de prueba?

¿Es el sistema particularmente sensible a ciertos valores de entrada?

¿De qué forma están aislados los límites de una clase de datos?

¿Qué volúmenes y niveles de datos tolerara el sistema?

¿Qué efectos sobre la operación del sistema tendrá combinaciones específicas de datos?

Estrategias de prueba para software de paradigma orientada a objeto

(Abellan, 2014)Para la prueba nos enfocamos de nuevo a lo que es la prueba de unidad ya que cada instancia de una clase empaqueta los atributos manipulándolos en las operaciones de estos datos donde las unidades de comprobación son más pequeñas ya no es posible probar una sola operación en aislamiento, sino más bien como parte de una clase.

Pero será equivalente la prueba de unidad en un paradigma imperativo como es el lenguaje C donde identificamos una serie de módulos con respecto a un paradigma orientada a objetos en el cual tenemos clases pues la respuesta es no realmente la definición de prueba de unidad de clases en programación orientadas a objetos es irnos a la unidad, es decir, a la clase no al método en la que vamos a ir probando cada uno de sus métodos, cada uno de sus atributos vemos si se modifican si no identificamos por ejemplo, vamos a ver distintas particiones en las cuales los vamos a identificar determinados atributos que modifican lo que es los conceptos de enlace u otros atributos que no sean modificados por una serie de métodos pues eso va enfocado a lo que es la prueba de unidad, aquí es probar método a método pues no tiene mucho sentido por el concepto de ligadura dinámica, también cuando tenemos una jerarquía de clases pues un determinado método en las clases, en las superclases pues podemos ir probándolos pero que pasa cuando tenemos una subclase de esa superclase ese mismo método que se hereda como realmente repercuta las pruebas de esa superclase porque la subclase también podemos ver que ese método por ligadura dinámica en el concepto de herencia vamos viendo que puede interactuar con otras series de atributos, con otras series de métodos, con otras llamadas a otras clases es que esta redefinido entonces no es trivial por tanto la prueba de unidad se debe reflejar sobre el concepto de clase de manera encapsulada no sobre métodos independientes.

Prueba de integración

Qué pasa con la prueba de integración aquí podemos por ejemplo hacer una prueba de integración ascendente y descendente como se podía ver en el paradigma imperativo o realmente no por el concepto de ligadura dinámica no está clara en cuál es la jerarquía de las estructuras de control jerárquico de una serie de clases que manda a otra, bueno dependiendo de la instanciación de determinados objetos pues la integración puede realizarse de manera simple, aquí tenemos dos enfoques en la prueba de integración:

• Prueba basada en hebra: es donde se identifica un conjunto de clases que realizan una determinada función.

• Prueba basada en uso: identifica desde ya lo que son las clases independientes que son llamadas a ellas no dependen de otras.

Pruebas de validación

Estas pruebas se basan o por decir comienzan tras la conclusión de las pruebas de integración, el software está completamente ensamblado como un paquete y los errores de interfaz son descubiertos y corregidos ya con esto desaparece la distinción entre software convencional y software orientado a objetos las pruebas se enfocan en las acciones visibles para el usuario y las salidas del sistema reconocibles por el usuario.

El proceso de depuración

Una depuración no es una prueba, pero es un proceso que ocurre cuando el software funciona correctamente dándonos pruebas exitosas del mismo, la depuración es el proceso que da como resultado la eliminación de error.

Bibliografía

Abellan, J. L. (21 de noviembre de 2014). ucam . Obtenido de http://www.ucam.edu/estudios/grados/i…

Aralelij. (13 de agosto de 2009). slideshare. Obtenido de https://es.slideshare.net/aracelij/pruebas-de-software

Luna, J. M. (03 de agosto de 2009). ingeniero de gestion . Obtenido de http://ingenierogestion.blogspot.com/2009/06/pruebas-de-caja-negra-y-caja-blanca.html

Mancilla, R. (04 de noviembre de 2009). slideshare.

Testing, P. (11 de febrero de 2015). Panel Testing – Centro de Excelencia. Obtenido de http://www.panel.es/blog/software-qa-cuales-son-los-tipos-de-pruebas-software/

Autor:

Xavier Sebastián Ávila Rodriguez.

Erika Cinthia Cevallos Pérez.

Estudiantes del Sexto Semestre de la Carrera de Ingeniería en Computación y Redes. Ecuador.