Integração contínua de aplicativo do IBM z/OS: Parte 2. Teste contínuo em todos os níveis

A integração contínua melhora a qualidade do software ao aplicar um processo de controle de qualidade continuamente. Tornou-se uma prática importante do desenvolvimento de software agile. Este artigo descreve o mapeamento de conceitos de integração contínua para o domínio do IBM System z. O primeiro artigo desta série de duas partes tratou do uso do Rational Team Concert para automatizar o desenvolvimento e implementação de aplicativos de mainframe. Este artigo descreve como incluir testes de unidade, testes de interface e testes de UI ao processo de integração contínua.

Zhang Hong Chen, Enterprise Modernization Solution Architect, IBM

Zhang Hong ChenTony (Chen Zhang Hong) é Senior Software Engineer na organização IBM Rational Enterprise Modernization. É líder de desenvolvimento de integração contínua para o software IBM System z, responsável por criação e validação.



Rosalind Radcliffe, Enterprise Modernization Solution Architect, IBM

Author photoRosalind Radcliffe é IBM Distinguished Engineer na organização Rational Enterprise Modernization. Ela é Enterprise Modernization Solution Architect responsável por produtos Collaborative Lifecycle Management para IBM System z e Power Systems. Isso inclui o suporte de Rational Team Concert para atividades padrão de desenvolvimento em mainframe, além do suporte necessário em IDEs para oferecer um ambiente completo de desenvolvimento e teste. Antes de Rational, ela esteve na divisão de software Tivoli, responsável pela estratégia de gerenciamento de SOA da IBM. Rosalind é chefe do NC TEC, North Carolina IBM Academy of Technology Affiliate, membro da IBM Academy of Technology e Master Inventor.



30/Nov/2012

Feedback de qualidade contínua

A eficiência da integração contínua vem do feedback imediato para a equipe sobre a qualidade do sistema que está sendo desenvolvido. O primeiro nível de validação é o processo de desenvolvimento automatizado, que pode detectar problemas básicos de qualidade, como erros de compilação e incompatibilidades de interface. Quando um desenvolvimento tem sucesso, podem ser realizados testes no arquivo executável ou no aplicativo implementado.


Aplicativos de mainframe modernizados

Ao longo dos anos, muitas oficinas de mainframe modernizaram as interfaces com o usuário de seus aplicativos com tecnologia remota ou web 2.0, para melhorar as UIs e aumentar o acesso. A lógica de negócios em execução no mainframe pode ter sido transformada em serviços que podem ser usados facilmente pelo aplicativo de frontend. A Figura 1 mostra a configuração de um aplicativo de mainframe modernizado.

Figura 1. Aplicativo de mainframe modernizado
Aplicativo de mainframe modernizado

Níveis de teste

Como mostra a Figura 2, testes podem ser realizados em todos os níveis com ferramentas apropriadas.

Figura 2. Níveis de teste
Níveis de teste

Testes de unidade

Testes de unidade são geralmente escritos e executados por desenvolvedores de software para garantir que o código esteja de acordo com o design e tenha o comportamento planejado. Os testes de unidade geralmente testam os menores artefatos testáveis na linguagem de programação (por exemplo, um método em uma classe Java). Eles usam tecnologias como objetos simulados para isolar os testes do sistema, de modo que eles possam ser executados sem precisar integrar todo o sistema.

A estrutura de teste de unidade zUnit é uma adaptação da estrutura JUnit para criar código para executar testes de unidade repetidos e verificação própria. As ideias e a estrutura desenvolvida em JUnit para realizar teste de unidade em código orientado a objetos foram adaptadas pelo zUnit para testar código Enterprise COBOL e PL/I. Rational Developer para Systems z oferece suporte para a estrutura, executor e ferramenta de teste do zUnit a partir da Versão 8.5.

Testes de interface

Sistemas complexos são geralmente compostos por vários componentes, que fornecem funções de aplicativo através de interfaces ou APIs. Por exemplo, um componente de conta bancária oferece um serviço da web para abertura de conta, que pode ser usado por vários aplicativos de frontend.

Os testes de API ou de interface destinam-se a testar os componentes com base na especificação. As especificações são geralmente construídas com base em protocolos padrão, como SOAP, XML, JMS e MQ.

IBM® Rational® Integration Tester, desenvolvido com tecnologia Green Hat, foi criado para lidar com os problemas inerentes ao teste de sistemas no nível de interface. Possui um amplo conjunto de recursos corporativos padrão e suporte para mais de 70 protocolos.

Testes de GUI

Testes de GUI verificam um sistema em execução através das interfaces com o usuário, da forma como um usuário final usaria o sistema. Um testador geralmente realiza testes de GUI. Muitos dos testes de GUI podem ser automatizados com ferramentas, como Rational Functional Tester.

Rational Functional Tester oferece suporte para teste de GUI em aplicativos Java, web, web 2.0 e Microsoft Visual Studio .NET Windows Forms. Também oferece suporte para teste de automação em aplicativos de IBM® zSeries® e iSeries®, que usam terminais 3270 e 5250.

As seções a seguir mostram como automatizar esses testes e incluí-los no processo de integração contínua.


Automatizar testes de zUnit

Para executar testes do zUnit, é possível chamar a API Test Runner, como mostra a Figura 3.

Figura 3. Estrutura de teste zUnit
Estrutura de teste zUnit

É possível chamar Test Runner a partir de JCL, de um shell de comando TSO ou de um shell de comando IBM® z/OS® UNIX System Services. Para automatizar a execução de zUnit em integração contínua, use o recurso de execução de script do desenvolvimento corporativo do Rational Team Concert. Há vários lugares para inserir um script customizado. A Figura 4 mostra um exemplo da execução de Linha de Comando Pós-desenvolvimento de um desenvolvimento de dependência para executar testes do zUnit.

Figura 4. Execute zUnit a partir da linha de comando pós-desenvolvimento
Execute zUnit a partir da linha de comando pós-desenvolvimento

Os comandos na Figura 4 gravam resultados de teste no arquivo JKERS001.azures no sistema de arquivos USS. O arquivo resultante pode ser aberto no Rational Developer para System z. Também é possível publicar os resultados no resultado do desenvolvimento de integração contínua, usando para isso a tarefa junitResultPublisher do Apache Ant no Rational Team Concert.

Dica:
Os resultados de teste do zUnit não são compatíveis com os formatos que a tarefa junitResultPublisher espera, mas, com um simples XSL para fazer a transformação, ela pode ser usada. O script Ant a seguir mostra como converter o resultado e publicá-lo no resultado do desenvolvimento de integração contínua. Consulte Recursos para saber onde fazer o download do XSL.

Listagem 1. Script para converter os resultados e publicá-los no resultado de desenvolvimento 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>

O mayFailPattern permite controlar se uma falha do teste faz com que o desenvolvimento inteiro falhe ou não. Muitos projetos que vimos permitem que testes de unidade falhem na integração contínua. A Figura 5 mostra o resultado do teste do zUnit após ser publicado no resultado de desenvolvimento de integração contínua.

Figura 5. Resultados de teste do zUnit publicados no resultado de desenvolvimento
Resultados de teste do zUnit publicados no resultado de desenvolvimento

Automatizar testes de interface

Os testes de interface automatizados criados no IBM® Rational® Integration Tester podem ser exportados para o Rational® Quality Manager. Após a exportação, é possível gerenciar a execução dos testes e conjuntos através do ambiente de gerenciamento de testes centralizado do Rational Quality Manager.

Configurar o desenvolvimento e a integração

Para executar testes automaticamente para um desenvolvimento, é necessário configurar construções para usar IBM® Rational Team Concert™ como provedor de desenvolvimento e sincronizar as informações de desenvolvimento com o Rational Quality Manager. A Figura 6 mostra a configuração.

Figura 6. Configure Rational Team Concert como provedor de desenvolvimento
Configure Rational Team Concert como provedor de desenvolvimento

O intervalo padrão para a sincronização de desenvolvimento é de 500 segundos. Na Figura 7, o intervalo é alterado para 60 segundos, para executar os testes mais rapidamente.

Figura 7. Configure a integração de desenvolvimento
Configure a integração de desenvolvimento

Planeje os testes automatizados

A próxima etapa é criar um planejamento de execução no Rational Quality Manager.

Um planejamento de execução contém etapas que são executadas em sequência em um momento planejado, ou quando são acionadas pela conclusão de um desenvolvimento. Quando um desenvolvimento aciona um planejamento de execução, todos os resultados de caso de teste e de suíte de testes são associados ao registro de desenvolvimento correspondente. A Figura 8 mostra um planejamento de execução que é acionado pela conclusão do desenvolvimento mortgage.ci e executa o teste de verificação de construção, suíte de teste BVT JKE Bank, que contém dois casos de teste.

Figura 8. Planejamento de execução
Planejamento de execução

Agora o teste de interface automatizado para um desenvolvimento está pronto. Quando um desenvolvimento de mortgage.ci for concluído, Rational Quality Manager acionará o planejamento de execução que usa agentes do Rational Integration Tester para executar testes de interface. A Figura 9 mostra a visualização Build Records do Rational Quality Manager, que contém os resultados de desenvolvimento com status de build verification test (BVT).

Figura 9. Resultados de desenvolvimento e status de BVT
Resultados de desenvolvimento e status de BVT

Legenda para abreviações na 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
A seção Recursos contém links para mais informações sobre cada produto.

A Figura 10 mostra como os produtos são unidos para formar um BVT automatizado. Rational Development and Test Environment para System z, como o próprio nome indica, é um ambiente gerenciável de desenvolvimento e teste para IBM® System z® executando em máquinas x86. Na última seção deste artigo, explicamos como esse ambiente Rational melhora os testes.

Figura 10. Arquitetura BVT automatizada
Arquitetura BVT automatizada

Automatizar testes de GUI

É possível criar testes de GUI automatizados usando Rational Functional Tester. A ferramenta permite criar testes de GUI pelo método de registrar e reproduzir ou pelo método de programação, para testar aplicativos da web, web 2.0 e de desktop. Os testes do Rational Functional Tester podem ser importados para o Rational Quality Manager como scripts de teste e associados com casos de teste novos ou já existentes. Quando os testes de GUI automatizados estiverem no Rational Quality Manager, é possível executar os testes de GUI com o mesmo método usado para os testes de interface.

A execução dos testes de GUI geralmente demora mais que testes de unidade ou de interface. Isso acontece porque os testes de GUI executam toda a transação e também porque eles simulam ações do usuário com conceitos como tempo de pensamento. Uma melhor prática para a integração contínua determina que o desenvolvimento deve ser rápido. Isso significa tanto o desenvolvimento quanto os testes relacionados a ele. Portanto, é necessário avaliar cuidadosamente se os testes de GUI devem ser parte dos testes de desenvolvimento de um projeto e quais testes serão executados em cada desenvolvimento.


Ambiente de teste flexível do z/OS

Os testes do z/OS geralmente têm limites de recursos. A Figura 11 mostra uma arquitetura típica de teste do z/OS com mais de uma equipe e projeto compartilhando o mesmo LPAR e banco de dados de teste. Esse modelo de compartilhamento de recursos cria conflitos, impede a inovação e atrasa a entrega do código. A coordenação de alterações ambientais e releases causa gargalos, atrasos e sobrecarga adicional. Dados de teste compartilhados são difíceis de gerenciar e podem levar a testes excessivos ou a resultados incorretos.

Figure 11. Arquitetura de teste do z/OS típica, com recursos compartilhados
Figure 11. Arquitetura de teste do z/OS típica, com recursos compartilhados

Com o Rational Development and Test Environment para System z, cada equipe tem seu próprio ambiente isolado e gerenciável para z/OS para desenvolvimento e teste, como mostra a Figura 12. É um ambiente ideal para desenvolver e executar testes de forma contínua.

Figure 12. Arquitetura de teste do z/OS em um ambiente Rational Development and Test
Figure 12. Arquitetura de teste do z/OS em um ambiente Rational Development and Test

Resumo

Neste segundo e último artigo da série sobre integração contínua no z/OS, discutimos a arquitetura de aplicativo de mainframe modernizada e testes em diferentes níveis. Também mostramos como automatizar e executar esses testes no contexto de integração contínua e como o Rational Development and Test Environment para System z altera a arquitetura do z/OS ao proporcionar um ambiente de teste flexível.


Download

DescriçãoNomeTamanho
Sample filezunit2junit.zip1KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

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


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

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

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=848136
ArticleTitle=Integração contínua de aplicativo do IBM z/OS: Parte 2. Teste contínuo em todos os níveis
publish-date=11302012