Geekly articles weekly

IBM System i (aka AS / 400) - Como fizemos testes automáticos de aplicativos em tela verde

Oi Meu nome é Anton Vorobyov, sou responsável no Alfa Bank pelo desenvolvimento de aplicativos para um sistema bancário centralizado.

Neste post, vou falar sobre o que são os aplicativos de tela verde, por que eles são necessários e como fizemos os autotestes para eles, escrevendo nossa própria solução para isso, o que nos permitiu acelerar os autotestes em 11 vezes.



A plataforma AS / 400 (Application System / 400) nasceu em 1988. O primeiro sistema operacional desta plataforma é o OS / 400, renomeado posteriormente para i5 / OS e ainda mais tarde para IBM i. Não faz muito tempo, ela comemorou seu trigésimo aniversário.

Mergulhando no mundo do desenvolvimento sob o sistema operacional IBM i, você entende que isso realmente não é "legado" no sentido clássico da palavra. Este é um ambiente diferente, completamente diferente, que é um pouco semelhante aos sistemas Windows ou Unix usuais. A principal tarefa deste sistema operacional é ser o mais produtivo possível no equipamento com o qual trabalha, e não ser conveniente para o usuário.

IMHO, esse sistema operacional pode deixá-lo louco por quão ineficazes as abordagens usuais para escrever código C ++ são ineficazes (até dezenas de vezes a perda de CPU), que alguns antipadrões demonstrados em livros didáticos são a melhor prática de código eficaz e a fonte com a data da escrita para 1978, além de montar sem problemas, também funciona como projetado! Tudo isso nos faz dar uma nova olhada nas abordagens modernas do desenvolvimento de software.

1. Introdução


A questão de melhorar a qualidade do software em desenvolvimento excita as mentes de cada equipe de desenvolvimento. Uma de nossas equipes de crédito, cuja tarefa é desenvolver e desenvolver a parte traseira do módulo para o sistema bancário automatizado da Misys Equation, também não passou por esse momento. A peculiaridade desse ABS é que:

  • as primeiras versões do ABS trabalharam sob o predecessor AS / 400 - a plataforma IBM System / 38 (apresentada em 1978) sob o CPF OS - "Control Program Facility";
  • Foi desenvolvido desde os anos 70 do século XX, e você pode encontrar um código escrito antes de seu nascimento (muitos códigos antigos);
  • os recursos do trabalho com o ABS devem-se à estreita integração com o IBM i e, devido à colossal compatibilidade com versões anteriores, parece que você está trabalhando como arqueólogo nas escavações da Grande Pirâmide.



IBM i (logotipo)

O desenvolvimento de aplicativos para esse ABS (opções ABS) é realizado de acordo com o padrão do Pacote Técnico do Misys ITP Integrator, que estipula que a opção deve consistir em um programa interativo para interação do terminal com o usuário final e implementar a API usando a interface instalada para execução em segundo plano .

Tais programas interativos desenvolvidos no sistema operacional IBM i são historicamente chamados de aplicativos de tela verde e são a única UI com a qual o usuário deste ABS interage.

O que é um aplicativo de tela verde?


A resposta simples é uma aplicação que se parece com isso:



Ou então :



Por que aplicativos de tela verde?


Historicamente, os únicos aplicativos interativos em execução nos sistemas de baixo e médio alcance da família AS / 400 e outros mainframes IBM que permitem solicitar qualquer entrada do usuário são aplicativos de tela verde. A instalação, administração, configuração e desenvolvimento no sistema operacional IBM i (e seus antecessores i5 / OS e AS400) foram realizadas (e ainda estão sendo realizadas em algum lugar) exclusivamente usando aplicativos de tela verde.

A imagem do aplicativo de tela verde tem dois tamanhos - caracteres 24x80 e 27x132 e 16 cores possíveis. Nessa escala, a maioria do trabalho de desenvolvedores e usuários deste sistema operacional é realizada.

Esses tamanhos de tela são o resultado da evolução de "estações de trabalho" conectadas aos progenitores do AS400 nos segmentos de gama baixa e média dos computadores comerciais IBM System / 32, System / 34, System / 36 e System / 38. Essas estações de trabalho eram chamadas de terminais e consistiam em uma tela em uma caixa de metal com um teclado e equipamento adicional na forma de uma caneta de luz. Inicialmente, apenas duas cores de tela eram suportadas - verde e verde brilhante, razão pela qual a frase estabelecida "aplicativo de tela verde" (aplicativo de tela verde na literatura inglesa) foi excluída. Na década de 1970, o número de cores suportadas aumentou para 16.


Estação de Display 5251 Modelo 11

As opções de terminal mais comuns foram 5251 Display Station Modelo 1 (960 caracteres na tela) e Modelo 11 (1920 caracteres na tela) com dimensões Largura / Profundidade / Altura iguais a 530/400/400 mm, respectivamente, e pesando 34 kg. A resolução da tela do Modelo 1 era 12x80, Modelo 11 - 24x80. O terminal foi conectado diretamente ao sistema host.

Os terminais 5251 Display Station Modelo 2 (960 caracteres na tela) e Modelo 12 (1920 caracteres na tela) com grandes dimensões e peso de 45 kg também eram bastante comuns. Eles se distinguem do Modelo 1 e do Modelo 11 pela possibilidade de "encaminhar" a conexão a montante através deles mesmos para a máquina host de clientes mais baratos na forma de terminais Modelo 1 (ou 11) com impressoras de mesa ou uma impressora de piso separada. Assim, os modelos 2 e 12 agiram como um hub, proxy da conexão com o host de dispositivos que exigem uma conexão direta com a máquina host e custam significativamente mais.

Os terminais da série 5252 Dual Display Station também parecerão incomuns para o leigo moderno.


Imagem promocional do folheto IBM System / 38 Equipment and Programs (5252 Dual Display Station)

O preço de um kit de terminal com uma impressora conectada a ele pode chegar a vários milhares de dólares.

Os terminais foram conectados através de um cabo biaxial à máquina host com uma topologia de barramento no modo half-duplex com uma velocidade de transmissão de até 1 Mbps. O número máximo de terminais suportados pelo twinaxial é de até 6 terminais, e o terminal mais remoto do host deve estar localizado a uma distância não superior a 1500 metros.

O número de cada terminal é definido durante sua instalação por três interruptores, para que um endereço exclusivo seja determinado dentro do barramento. Na presença de uma rede coaxial existente, é possível usar adaptadores de um cabo biaxial a um cabo coaxial e um conjunto apropriado de terminações de cabo para crimpagem. Com esse esquema, foi possível conectar apenas dois dispositivos no barramento com um comprimento máximo de segmento de até 30 metros. O número total de dispositivos conectados variou de uma dúzia a várias dezenas, dependendo do modelo.

Com o desenvolvimento de sistemas de desktop e redes de acesso, terminais volumosos foram substituídos por estações de trabalho, onde várias placas de expansão de empresas terceirizadas foram usadas como meio de acesso à máquina host, suportando conexão direta via twinaxial. Depois que a IBM desenvolveu a tecnologia Token Ring em 1984, surgiram soluções de software para acessar a máquina, inclusive por meio dessa interface.


Adaptador 5250 para barramento ISA (fabricante desconhecido)


Placas adaptadoras Blackbox 5250 (PC470C, PC471C, PC472C, PC473C, PC478C)

Emuladores para MS-DOS e MS Windows aparecem tanto da IBM como de terceiros, incluindo implementações de código aberto (por exemplo, tn5250j.sourceforge.net) Em meados dos anos 90, a pilha TCP / IP chega ao mundo intermediário de negócios de gama baixa e baixa. Para suportar o acesso ao host por meio do novo protocolo, a IBM está desenvolvendo emuladores de terminal da série 5250.

Para criar um protocolo host, a IBM está desenvolvendo
Extensões de protocolo Telnet (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), coletivamente chamadas de Telnet5250 (TN5250), que descreve o processo de recebimento e transmissão de fluxos Fluxos de dados 5250 (fluxos de dados 5250) sobre o protocolo Telnet padrão.


IBM Client Access / 400 para Windows 3.1 Installer

O que há de especial no IBM 5250?


Um recurso dos terminais IBM 5250 (e, consequentemente, do protocolo TN5250) é a orientação do bloco, em contraste com os terminais * nix usuais, orientados a símbolos . Isso significa que os fluxos de dados 5250 pelos quais o host se comunica com o terminal são transmitidos pelos blocos de dados, e um símbolo separado nele, sem o contexto do bloco transmitido, não faz sentido.

Por exemplo, a máquina host transmite ao terminal um bloco de dados que contém as informações estáticas exibidas na tela, juntamente com os atributos e coordenadas dos campos de entrada e uma indicação do deslocamento nesse bloco, onde gravar o resultado da entrada do usuário nos campos. Depois disso, a máquina host espera mensagens do terminal e não participa do processo de entrada do usuário.


Tela de login para o IBM i host RZKH.de (pub400.com)

Além disso, a tarefa do emulador de terminal é interpretar o bloco de dados da máquina e formar a tela de entrada para o usuário, onde ele tem a oportunidade de inserir qualquer informação nos campos permitidos. Além disso, as tarefas do emulador de terminal incluem uma reação às ações do usuário. As teclas F1-F24 (F13-F24 são simuladas via SHIFT + Fx), Enter, Home, End, PageUp, PageDn e algumas outras teclas especiais que não estão disponíveis nos teclados modernos são consideradas teclas do host. Isso significa que, pressionando essa tecla, um buffer de fluxo com informações dos campos de entrada e a posição do cursor na tela, previamente preenchida com o emulador de terminal, será enviada ao host para processamento.


Tentativa de logon do WIreshark 5250 Data Stream na tentativa de despejo em pub400.com

O host recebe o buffer, analisa-o e o resultado da entrada é transmitido ao programa que solicitou a reação do usuário para validação de dados adicionais e o aplicativo continua a funcionar, enquanto o aplicativo recebe o código da tecla host pressionada.

Por que o autoteste aqui


Pensamos em automatizar o teste manual de aplicativos de tela verde quando tivemos a necessidade de testar centenas de telas de um módulo desenvolvido, onde até oitenta verificações de negócios diferentes (validações) podiam ocorrer em uma tela.

A dor particular da equipe foi a ausência quase completa em 2017 de ferramentas de teste automático de tela verde, exceto a solução UIPath proprietária. Ainda hoje não existem muitas soluções semelhantes, o autor conhece o Automate da HelpSystems e a extensão JMeter para o BlazeMeter (ficarei feliz em saber sobre outros produtos similares).

A primeira pesquisa sobre o problema


O emulador padrão do terminal TN5250 instalado nos locais de trabalho no banco é o IBM Personal Communications para Windows 6.0 (PCOMM 6.0). Os colegas descobriram que este produto possui meios regulares de automatizar seu gerenciamento na forma de uma API diversa, a saber:

  1. Interface de Programa de Aplicativo de Linguagem de Alto Nível (HLLAPI);
  2. HLLAPI aprimorado;
  3. Windows HLLAPI
  4. HACL (Host Access Client Library).

As três primeiras interfaces são as mais antigas e são suportadas desde o DOS e as versões de 16 bits do Windows. O trabalho na interface EHLLAPI é implementado chamando uma única função de acordo com o seguinte protótipo:

long hllapi (LPWORD, LPSTR, LPWORD, LPWORD);

onde o primeiro parâmetro é um ponteiro para o número numérico da função que está sendo executada, os outros dois são seus argumentos sensíveis ao contexto da função que está sendo chamada e o último é o resultado da função. Ou seja, para solicitar o status de conexão 'A' (as sessões no emulador são numeradas com uma letra latina do intervalo de 'A' a 'Z'), você deve executar o seguinte código (retirado da documentação da IBM):

  #include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling }

O número de funções disponíveis para chamadas dessa maneira é de cerca de 60.

A interface WinHLLAPI expande levemente essa funcionalidade com várias funções adicionais que permitem registrar funções de retorno de chamada para chamadas assíncronas, a fim de notificar sobre eventos de estabelecimento de uma conexão com o host, desconexão do host, alteração de dados na tela do terminal etc.

A interface HACL (Host Access Client Library) parecia mais amigável, porque, ao contrário de chamar a "função do mesmo nome", foi fornecida uma variante da hierarquia de classes orientada a objetos que imitava completamente qualquer ação do usuário.


Hierarquia de classes da biblioteca de classes do emulador HACL (C ++)

Existem implementações HACL para C ++, Java, LotusScript e um servidor de automação COM para Windows (conveniente para Visual Basic e .NET).

Primeiro protótipo


Devido à enorme complexidade do protocolo de fluxo de dados 5250 e às informações extremamente escassas sobre seu dispositivo interno com links para literatura paga fechada da IBM, ficou óbvio que o desenvolvimento de seu próprio emulador é extremamente não trivial e demorado. A esse respeito, surgiu a idéia de usar uma camada de middleware que permitirá controlar o emulador de terminal dentro da funcionalidade mínima exigida, em particular “insira um valor no campo”, “compare parte da tela com o padrão” ou “pressione a tecla host F22”.

Os colegas que usaram interfaces HACL anteriormente alegaram (e uma pesquisa no StackOverflow confirmou) que o objeto COM apresentava problemas de estabilidade e poderia travar após a execução de um certo número de comandos. Somente reiniciar o processo do servidor de automação ajudou. Uma análise rápida da versão Java mostrou que o Wrapper é usado na interface C ++ por meio do JNI. Portanto, a escolha caiu na interface C ++. Os arquivos de cabeçalho e arquivos .lib correspondentes estavam disponíveis no diretório de instalação do Personal Communications para Windows.

O primeiro protótipo foi baseado no Qt5, onde foi possível executar o código JavaScript por meio do QtScript. No ambiente do script executável, um objeto foi registrado com um pequeno número de métodos que permitiam executar comandos no emulador de terminal como se estivessem sendo executados por uma pessoa (entrando em um campo, pressionando as teclas do host, aguardando a linha aparecer na tela). Demonstramos uma "demonstração" ao vivo, onde escrevemos um caso de usuário para iniciar um aplicativo de tela verde da ABS Equation com um teste da reação do aplicativo à entrada incorreta nos campos. A demonstração mostrou que o protótipo foi bem sucedido e que podemos seguir em frente.

A aparência de um vizinho


Juntamente com a demonstração do primeiro protótipo, colegas de outro departamento reuniram vários módulos Ruby + Pepino + Quick3270 + Ruby ( cheeze / te3270 ). A opção proposta usa um módulo Ruby que interage com o emulador de terminal DN32 Computing Quick3270 através de seus objetos COM especializados (incompatíveis com as interfaces HACL). Era uma solução completa para aplicativos de autoteste de tela verde no estilo BDD, com algumas etapas pré-descritas. No entanto, na solução proposta, ficamos alarmados com o seguinte:

  1. Usamos um emulador pago de terceiros, não da IBM (todos os emuladores funcionam de maneira um pouco diferente, mas precisamos verificar o trabalho nos padrões usados ​​no banco, o preço do erro é incrivelmente alto);
  2. As implementações das etapas do Cucumber para o Quick3270 usaram um grande número de inativos para aguardar uma resposta da máquina;
  3. Um desempenho muito ruim do Quick3270 por meio da interface de automação (trabalhar com HACL no protótipo por meio da interface C ++ parecia muito mais dinâmico).


Emulador de terminal Quick3270

Com base no protótipo, decidimos tentar implementar nosso próprio servidor de automação para conectar o Pepino ao Personal Communications para Windows e projetar as etapas para que o tempo de inatividade entre as ações na tela do emulador seja mínimo.

Digressão lírica . Apesar de existir um grande número de problemas técnicos em torno da IBM supostamente "legada", que, ao que parece, já deveria ter sido resolvida para sistemas de nível médio e corporativo, a relevância de adaptar e transferir soluções técnicas existentes é muito alta simplesmente por causa de sua ausência na plataforma. Freqüentemente, a ausência está conectada aos próprios recursos deste sistema operacional, que é fundamentalmente diferente do moderno * nix, Windows ou MacOS X, que requer otimização significativa do software para essa pilha.

Decisão própria


Como nossa própria solução, criamos um servidor de automação como um desenvolvimento do protótipo demonstrado anteriormente. Este servidor executa comandos para automatizar a interação dos consumidores através de um servidor RPC (Qt5 WebSocket). Ele interage com o Personal Communications para Windows, que faz parte da imagem corporativa do sistema operacional Windows, e permite:

  • iniciar / parar sessões de emulador de terminal;
  • Executar raspagem de tela Tela verde;
  • pesquise campos de entrada na tela;
  • controlar o cursor e simular pressionamentos de tecla (incluindo host);
  • e outros


Iniciar servidor de automação

No entanto, para todas as vantagens da API HACL, ela tem uma desvantagem - não sabe como trabalhar com o DB2 for i DBMS integrado ao sistema operacional e não permite a execução de comandos que são vitais para a construção de um ambiente simulado no qual um script de teste seria executado. Se o cliente DB2 para Ruby existir na IBM, o cliente para o comando remoto e o servidor de chamada de programa distribuído será apenas para Java na forma da biblioteca JTOpen : A versão de código aberto do IBM Toolbox for Java (também conhecido como jt400 ) Nós "espiamos" a solução para esse problema na própria IBM, analisando o comportamento de seus produtos com funcionalidade semelhante (em particular, Personal Communications para Windows Data Transfer, iSeries para PC / PC para iSeries Transfer, etc.). Acontece que esses produtos, por sua implementação, executam o IBM JRE 6 ou 8, dependendo da versão do aplicativo, e usam a biblioteca jt400.

Para o servidor de automação, decidimos fazer o mesmo. O JNI lança o IBM JVM, fornecido com o Personal Communications para Windows. Usando métodos especiais do wrapper, os comandos do servidor RPC provenientes de fora são executados por meio de proxy em chamadas para a funcionalidade necessária do jt400. Como o último também contém um driver JDBC para DB2, foi decidido usá-lo para acessar o DBMS no IBM i.

É importante observar que você não pode usar o Oracle JVM ao usar o HACL. Se você executar uma sessão de emulador de terminal, a tentativa de criar uma instância da máquina virtual falhará. Da mesma forma, se você executar a JVM do Oracle no espaço de endereço de um processo que interage com o HACL, o último trava sem explicação.

Com o tempo, a solução foi implementada em um número crescente de tarefas. Funcionou mais rápido que a solução com o Quick3270. A popularidade cresceu, assim como o número de autotestes. No entanto, durante a operação, surgiram dificuldades adicionais:

  1. Terminal ocasional congela;
  2. Incapacidade de trabalhar em uma posição de regressão devido ao emulador de terminal se recusar a iniciar se a área de trabalho do usuário sob a qual o emulador é iniciado estiver bloqueada ou sua sessão RDP estiver bloqueada;
  3. Somente Windows;
  4. Um procedimento complexo para instalar, configurar e atualizar ferramentas (via pacote msi);
  5. Nosso ciclo de regressão para 130 autotestes (cerca de 4000 etapas) começou a levar 7-8 horas.

Algo precisa ser feito ...


Ao analisar os logs de rastreamento de várias ativações de autoteste, encontrando gargalos no desempenho das etapas usadas com freqüência, o tempo total de execução da regressão foi reduzido para 4-5 horas. Mas ficou claro que o uso da camada de middleware na forma de um servidor RPC de automação em conjunto com a interface HACL, que também possui erros "flutuantes" que se acumulam ao longo de todo o sistema, não ajudará a melhorar o desempenho da solução.

Por outro lado, como alternativa ao IBM Personal Communications para Windows, o fornecedor fornece uma solução de plataforma cruzada chamada IBM i Access - Client Solutions.


IBM i Access - Soluções para Clientes

A análise de sua estrutura interna nas manhãs de sábado e domingo sobre xícaras de café mostrou que sua base de códigos é baseada em outro produto da IBM chamado IBM Host on-Demand (IBM HOD). Esta é uma solução completa para acessar o IBM i, desenvolvida em Java 6, que não apenas possui a implementação completa de vários protocolos de comunicação usados ​​em máquinas IBM (TN3270, TN5250, VTxxx etc.), mas também componentes de interface do usuário de alto nível da interface Java, usado para construir seus próprios emuladores de terminal na forma de um construtor, que pode ser montado a partir da escassa documentação da IBM Um estudo mais detalhado do IBM HOD mostrou que os componentes da interface do usuário são baseados na implementação Java da interface HACL, cuja documentação está aberta. O comportamento deles coincide com apenas pequenas diferenças da documentação do C ++ HACL.


IBM Host On-Demand (logotipo)

Em seguida, criamos uma biblioteca Java para uso interno, que implementa a mesma interface que o servidor de automação C ++ RPC, mas usa internamente o IBM HOD. Para reduzir a sobrecarga durante a execução das etapas de autoteste, migramos do Ruby Cucumber para cucumber-jvm com a reimplementação de todas as etapas semelhantes às opções do Ruby. Na presença de uma interface de software semelhante ao servidor RPC, isso não era grande coisa, especialmente considerando que tentamos restringir o crescimento descontrolado no número de etapas em si e tínhamos esse valor na região de 30 unidades.

Qual é o resultado


Como resultado, alcançamos a operacionalidade de todos os autotestes sem alterá-los, e a velocidade do trabalho se tornou tão alta que tivemos que introduzir um atraso artificial entre as etapas para que, ao desenvolver um autoteste, você pudesse observar seu trabalho, caso contrário, a interface do usuário não teria tempo para desenhar a tela até o fim.

Os 180 autotestes já existentes, com mais de 16.000 etapas com um atraso definido de 60 ms entre as etapas, começaram a executar cerca de 30 minutos contra 5 horas e 30 minutos, o que corresponde a um aumento de onze vezes no desempenho do suporte de regressão.

Os resultados superaram todas as expectativas. Estamos próximos dos limites físicos do protocolo TN5250.

Até o momento, a decisão foi publicada em todo o banco e colegas de outras cidades se uniram à melhoria. Das mudanças recentes, os colegas estão integrando a solução ao Jenkins, na versão de teste, testando o lançamento em um servidor Linux com Xvfb e concluindo o estágio da operação piloto de execução de autotestes.

Obrigado por ler até o fim!
Todo o sucesso!

PS Em dezembro de 2018, foi realizada a próxima IBMi Developer Conference, na qual foi feito um relatório sobre o tópico deste artigo.

Até agora, realizamos a Conferência anualmente apenas para funcionários do Banco. A partir de 2019, convidaremos participantes de outras empresas. É muito interessante expandir o círculo da comunicação profissional e pessoal, compartilhar emoções, conhecimentos e experiências.

Source: https://habr.com/ru/post/pt446332/

More articles:


All Articles