Integración continua de aplicación de IBM z/OS: Parte 2. Pruebas continuas en todos los niveles

La integración continua mejora la calidad del software al aplicar continuamente un proceso de control de calidad. Se ha convertido en una práctica importante de desarrollo de software ágil. Este artículo describe cómo son utilizados los conceptos de integración en correlación de desarrollo distribuido con el dominio de IBM System z. El primer artículo de esta serie de dos partes fue sobre cómo utilizar Rational Team Concert para automatizar compilaciones y la implementación de aplicaciones de sistema principal. Este artículo describe cómo añadir pruebas de unidad, pruebas de interfaz y pruebas de IU al proceso de integración continua.

Zhang Hong Chen, Enterprise Modernization Solution Architect, IBM

Tony (Chen Zhang Hong) es Ingeniero de software superior dentro de la organización Rational Enterprise Modernization de IBM. Es el líder de desarrollo de la integración continua para el software de system z de IBM, es el responsable de su creación y validación.



Rosalind Radcliffe, Enterprise Modernization Solution Architect, IBM

Rosalind RadcliffeRosalind Radcliffe es una Ingeniera destacada de IBM dentro de la organización Rational Enterprise Modernization. Es la arquitecta de la solución Enterprise Modernization, responsable de los productos Collaborative Lifecycle Management de los system z y Power Systems de IBM. Esto incluye el soporte de Rational Team Concert para las actividades del sistema principal, y el soporte necesario dentro de IDE para proveer un desarrollo completo y un entorno de prueba. Antes de Rational, estaba en el departamento de software Tivoli, responsable de la estrategia de administración SOA de IBM. Rosalind es encargada de NC TEC, afiliada de Academy of Technology de IBM en Carolina del Norte, donde también es miembro y creadora principal.



05-02-2013

Retroalimentación de calidad continua

El poder de la integración continua viene de la retroalimentación inmediata para el equipo sobre la calidad del sistema que está siendo desplegado. El nivel de validación es el proceso de compilación automatizado, el cual puede atrapar problemas básicos de calidad tales como errores de compilación y no coincidencias de interfaz. Cuando una compilación es exitosa, las pruebas pueden ser ejecutadas en el archivo ejecutable o en la aplicación desplegada.


Aplicaciones de sistema principal modernizadas

Con el paso de los años, muchos talleres de sistema principal han modernizado sus interfaces de usuario de las aplicaciones con tecnología Web 2.0 o móvil para mejorar las IUs e incrementar el acceso. La lógica empresarial ejecutándose en el sistema principal pudo haberse convertido en servicios que pueden ser utilizados fácilmente por la aplicación frontal. La Figura 1 muestra la configuración de una aplicación de sistema principal modernizada.

Figura 1. Aplicación de sistema principal modernizada
modernized mainframe application configuration

Niveles de pruebas

Como ilustra la Figura 2, las pruebas pueden ser realizadas en todos los niveles con herramientas apropiadas.

Figura 2. Niveles de pruebas
Rational software by type of test

Pruebas de unidad

Las pruebas de unidad son normalmente grabadas y ejecutadas por desarrolladores de software para garantizar que el código cumpla con su diseño y se comporte como se pretende. Las pruebas de unidad frecuentemente prueban los artefactos más pequeños que pueden ser probados en el lenguaje de programación (por ejemplo, un método en la clase de Java). Las pruebas de unidad utilizan tecnologías tales como objetos simulados para aislar las pruebas del sistema más grande de forma que las pruebas puedan ser ejecutadas sin tener que integrar el sistema completo.

La infraestructura de pruebas de la unidad zUnit es una adaptación de la infraestructura de JUnit para grabar código para ejecutar pruebas de unidad repetibles y autoverificables. Las ideas e infraestructura desarrolladas en JUnit para pruebas de unidad de código orientado al objeto han sido adaptadas para probar código de Enterprise COBOL y PL/I. La infraestructura de prueba de zUnit, el ejecutor y el soporte de herramientas están disponibles con Rational Developer para Systems z a partir de la Versión 8.5.

Pruebas de interfaz

Los sistemas complejos están normalmente compuestos de múltiples componentes, los cuales proporcionan funciones de aplicación mediante interfaces o APIs. Por ejemplo, un componente de cuenta de banco proporciona un servicio web para abrir una cuenta que pueda ser utilizada por múltiples aplicaciones frontales.

Las pruebas de API o pruebas de interfaz son para probar los componentes con base en la especificación. Las especificaciones son normalmente compiladas con base en protocolos estándar, tales como SOAP, XML, JMS y MQ.

IBM® Rational® Integration Tester, basado en tecnología de Green Hat, fue creado para atender los problemas inherentes en los sistemas de pruebas a nivel de la interfaz. Tiene un intervalo extenso de posibilidades empresariales estándar y soporta más de 70 protocolos.

Pruebas de GUI

La pruebas de GUI verifican un sistema en ejecución mediante las interfaces de usuario en la forma en que los usuarios finales utilizarían el sistema. Un probador normalmente realiza pruebas de GUI. Muchas de las pruebas de GUI pueden ser automatizadas con herramientas, tales como Rational Functional Tester.

Rational Functional Tester soporta pruebas de GUI para aplicaciones Java, Web, Web 2.0 y Microsoft Visual Studio .NET Windows Forms. También soporta las pruebas de automatización para aplicaciones de IBM® zSeries® e iSeries® , que utilizan terminales 3270 y 5250.

Las siguientes secciones muestran cómo automatizar estas pruebas e incluirlas en el proceso de integración continua.


Automatice pruebas de zUnit

Puede ejecutar pruebas de zUnit al llamar la API Test Runner como muestra la Figura 3.

Figura 3. Infraestructura de prueba de zUnit
zUnit test framework

Puede llamar a Test Runner desde JCL, desde un shell de comandos de TSO o desde un shell de comandos de IBM® z/OS® UNIX System Services. Para automatizar la ejecución de zUnit en integración continua, utilice el dispositivo de ejecución de script de la compilación empresarial de Rational Team Concert. Existen múltiples lugares en los que puede insertar un script personalizado. La Figura 4 muestra un ejemplo de utilizar una Línea de Comandos Postcompilación de una compilación de dependencia para ejecutar pruebas de zUnit.

Figura 4. Ejecutar zUnit desde una línea de comandos de postcompilación
Configuration page for Post-Build Command Line

Los comandos en la Figura 4 graban resultados de prueba en el archivo JKERS001.azures en el sistema de archivos de USS. Puede abrir el archivo resultante en Rational Developer para System z. También es posible publicar los resultados en el resultado de compilación de integración continua utilizando la tarea junitResultPublisher de Apache Ant en Rational Team Concert.

Consejo:
Los resultados de prueba de zUnit no son compatibles con los formatos esperados por la tarea junitResultPublisher, pero con un XSL simple para hacer la transformación, puede ser utilizado. El script de Ant a continuación muestra cómo convertir el resultado y publicarlo en el resultado de compilación de integración continua. Vea Resources para conocer dónde puede descargar el XSL.

Listado 1. Script para convertir los resultados y publicarlos en el resultado de compilación de CI
<target description="Publish zunit test results" name="publish_zunit">
<xslt in="${zunit.result}" out="${transfomresult}" style="${zunit2junit.xsl}" />
<junitResultPublisher buildResultUUID="${buildResultUUID}" 
    repositoryAddress="${repositoryAddress}" userId="${userId}" 
    passwordFile="${passwordFile}" filePath="${transfomresult}" 
    componentName="Mortgage" verbose="true" mayFailPattern="pattern1" 
    failOnError="false" />
</target>

El mayFailPattern permite control si las fallas de prueba causan que falle toda la compilación. Muchos proyectos que hemos visto permiten las fallas de pruebas de unidad en su integración continua. La Figura 5 muestra el resultado de prueba de zUnit después de que es publicado en el resultado de compilación de integración continua.

Figura 5. resultados de prueba de zUnit publicados en el resultado de compilación
Failure detail section shows code

Automatice las pruebas de interfaz

Las pruebas de interfaz automatizadas creadas en IBM® Rational® Integration Tester pueden ser exportadas a Rational® Quality Manager. Después de ser exportadas, puede gestionar la ejecución de pruebas y suites mediante el entorno de gestión de pruebas centralizadas de Rational Quality Manager.

Configure la compilación y la integración

Para ejecutar pruebas automáticamente para una compilación, las integraciones deben ser configuradas para utilizar IBM® Rational Team Concert™ como un proveedor de compilación y para sincronizar la información de compilación con Rational Quality Manager. La Figura 6 muestra la configuración.

Figura 6. Configurar Rational Team Concert como el proveedor de compilación
Project dashboard, Manage Project Properties view

El intervalo predeterminado para sincronización de compilación es 500 segundos. En la Figura 7, el intervalo es cambiado a 60 segundos para ejecutar las pruebas con mayor prontitud.

Figura 7. Configurar la integración de la compilación
Build integration framework details

Planifique las pruebas automatizadas

La siguiente etapa es crear una planificación de ejecución en Rational Quality Manager.

Una planificación de ejecución contiene etapas que se ejecutan en forma secuencial al momento planificado o cuando son desencadenadas por una terminación de compilación. Cuando una compilación desencadena una planificación de ejecución, todos los resultados del caso de prueba y los resultados de la suite de prueba son asociados con el registro de compilación correspondiente. La Figura 8 muestra una planificación de ejecución que es desencadenada por la terminación de la compilación mortgage.ci y ejecuta la prueba de verificación, la suite de prueba BVT JKE Bank , la cual contiene dos casos de prueba.

Figura 8. Planificación de la ejecución
Details of the schedule and steps

Ahora la prueba de interfaz automatizada para una compilación está en su lugar. Siempre que una compilación de mortgage.ci sea completada, Rational Quality Manager desencadenará la planificación de ejecución que utiliza agentes de Rational Integration Tester para ejecutar las pruebas de interfaz. La Figura 9 muestra la vista Rational Quality Manager Build Records que lista los resultados de compilación con el estado de prueba de verificación de la compilación (BVT).

Figura 9. Resultados de compilación y estado de BVT
screen capture of details in table format

Clave para las abreviaciones en la Figura 10

RD&T: Rational Development and Testing Environment para System z
RFT: Rational Functional Tester
RIT: Rational Integration Tester
RQM: Rational Quality Manager
RTC: Rational Team Concert
Vea Resources para obtener enlaces a más información sobre cada producto.

La Figura 10 muestra cómo los productos son reunidos para hacer una BVT automatizada. Rational Development and Test Environment para System z, como el nombre implica, es un entorno gestionable de desarrollo y pruebas de IBM® System z® ejecutándose en máquinas x86. En la última sección de este artículo, explicamos cómo este entorno de Rational mejora las pruebas.

Figura 10. Arquitectura de BVT automatizada
Flow between the products for executing a test

Automatice las pruebas de GUI

Puede crear pruebas de GUI automatizadas al utilizar Rational Functional Tester. La herramienta proporciona una forma de Registro y Reproducción y una forma de programación para crear las pruebas de GUI para probar aplicaciones web, Web 2.0 y de escritorio. Las pruebas de Rational Functional Tester pueden ser importadas en Rational Quality Manager como scripts de prueba y asociadas con casos de prueba nuevos o existentes. Después de que las pruebas de GUI automatizadas estén en Rartional Quality Manager, puede utilizar el mismo método que usó para ejecutar pruebas de interfaz para ejecutar pruebas de GUI.

Las pruebas de GUI normalmente requieren más tiempo para ser ejecutadas que las pruebas de unidad o pruebas de interfaz. Esto no solo es porque las pruebas de GUI ejecutan toda la transacción, sino también porque simulan las acciones del usuario con conceptos tales como tiempo de reflexión. Una buena práctica para la integración continua es que la compilación debe ser rápida. Esto significa que la compilación y las pruebas se relacionaron para ser compiladas. Por lo tanto, necesita evaluar cuidadosamente si las pruebas de GUI deben ser parte de las pruebas de compilación para un proyecto y cuáles pruebas de GUI selecciona para ejecutar en cada compilación.


Entorno de pruebas de z/OS flexible

Las pruebas de z/OS frecuentemente tienen restricciones de recursos. La Figura 11 muestra una arquitectura de pruebas de z/OS típica con múltiples equipos y proyectos que comparten la misma base de datos y LPAR de pruebas. Este modelo de recursos compartidos crea conflictos, impide la innovación y hace más lenta la entrega del código. La coordinación de cambios ambientales y releases causa cuellos de botella, retrasos y sobrecarga adicional. Los datos de prueba compartidos son difíciles de gestionar y pueden llevar a realizar pruebas de más o a resultados de prueba incorrectos.

Figura 11. Arquitectura de pruebas de z/OS típica con recursos compartidos
Diagram that shows the flow

Con Rational Development and Test Environment para System z, cada equipo tiene su propio entorno de z/OS aislado y gestionable para desarrollo y pruebas, como se muestra en la Figura 12. Esto proporciona un entorno ideal para ejecutar compilaciones y pruebas continuas.

Figura 12. Arquitectura de pruebas de z/OS en Rational Development and Test Environment
Separate resources

Resumen

En este segundo y último artículo de esta serie de integración continua de z/OS, discutimos la arquitectura modernizada de la aplicación de sistema principal y las pruebas en distintos niveles. También mostramos cómo automatizar estas pruebas y ejecutarlas en el contexto de integración continua y cómo Rational Development and Test Environment para System z cambia la arquitectura de pruebas de z/OS al proporcionar un entorno de pruebas flexible.


Descargar

DescripciónNombretamaño
Sample filezunit2junit.zip1KB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=857182
ArticleTitle=Integración continua de aplicación de IBM z/OS: Parte 2. Pruebas continuas en todos los niveles
publish-date=02052013