Teste de Mainframe – Tutorial Completo

Antes de aprendermos os conceitos de Teste de Mainframe, vamos primeiro analisar a plataforma na qual os testes são executados.

O que é um mainframe?

O mainframe é um sistema computacional de alto desempenho e alta velocidade. É utilizado para computação em larga escala que exige alta disponibilidade e segurança robusta. É usado principalmente em setores como finanças, seguros, varejo e outras áreas críticas onde grandes volumes de dados são processados ​​várias vezes ao dia.

Teste de mainframe

Teste de mainframe O teste de mainframe é um processo de teste de aplicativos e serviços de software baseados em sistemas mainframe. O objetivo do teste de mainframe é garantir o desempenho, a confiabilidade e a qualidade de um aplicativo ou serviço de software por meio de métodos de verificação e validação, e verificar se ele está pronto para implantação.

Ao realizar testes em mainframe, o testador precisa principalmente conhecer a navegação nas telas do CICS. Essas telas são personalizadas para aplicações específicas. Quando alterações são feitas no código em COBOL, JCL e linguagens similares, o testador não precisa se preocupar com a configuração do emulador na máquina, pois as alterações que funcionam em um emulador de terminal funcionarão em outros.

• A aplicação Mainframe (também chamada de lote de tarefas) é testada em relação aos casos de teste desenvolvidos com base nos requisitos.
• O teste de mainframe geralmente é executado no código implantado usando várias combinações de dados definidas no arquivo de entrada.
• Os aplicativos que rodam no mainframe podem ser acessados ​​por meio de um emulador de terminal. O emulador é o único software que precisa ser instalado na máquina cliente.

Como a plataforma se comporta de maneira diferente de uma pilha web, é útil saber quais características do mainframe orientam o design dos testes. Portanto, o teste de mainframe se situa ao lado dos demais. tipos de testes de software em vez de substituir qualquer um deles.

Atributos do mainframe

1. Armazenamento virtual
   • É uma técnica que permite que um processador simule o armazenamento principal que é maior do que a quantidade real de armazenamento real.
   • É uma técnica para usar a memória de forma eficaz para armazenar e executar tarefas de vários tamanhos.
   • Ele usa o armazenamento em disco como uma extensão do armazenamento real.
2. Multiprogramação
   • O computador executa mais de um programa ao mesmo tempo. Mas, em qualquer dado momento, apenas um programa pode ter o controle da CPU.
   • É um recurso fornecido para fazer uso eficiente da CPU.
3. Processamento em lote
   • É uma técnica pela qual qualquer tarefa é realizada em unidades conhecidas como empregos.
   • Um trabalho pode fazer com que um ou mais programas sejam executados em sequência.
   • O agendador de tarefas toma uma decisão sobre a ordem em que as tarefas devem ser executadas. Para maximizar o rendimento médio, os trabalhos são agendados de acordo com sua prioridade e classe.
   • As informações necessárias para o processamento em lote são fornecidas por meio de JCL (Linguagem de Controle de Tarefas). O JCL descreve a tarefa em lote — programas, dados e recursos necessários.
4. Compartilhamento de tempo
   • Num sistema de time-sharing, cada usuário tem acesso ao sistema através do dispositivo terminal. Em vez de enviar tarefas agendadas para execução posterior, o usuário insere comandos que são processados ​​imediatamente.
   • Portanto, isso é chamado de “Processamento Interativo”. Ele permite que o usuário interaja diretamente com o computador.
   • O processamento de time-share é conhecido como “Processamento em primeiro plano” e o processamento de trabalho em lote é conhecido como “Processamento em segundo plano”.
5. Spooling
   • SPOOLing significa Periférico Simultâneo. Operações Online.
   • O dispositivo SPOOL é usado para armazenar a saída de um programa ou aplicativo. A saída armazenada é direcionada para dispositivos de saída, como uma impressora (se necessário).
   • É uma facilidade que explora a vantagem do buffer para fazer uso eficiente dos dispositivos de saída.

Classificação de Testes Manuais em Mainframe

Esses atributos dividem o trabalho de teste manual no mainframe em dois fluxos claramente separados.

estrutura principal Teste Manual podem ser classificados em dois tipos:

1. Teste de trabalhos em lote —

• O processo de teste envolve a execução de tarefas em lote para a funcionalidade implementada na versão atual.
• Os resultados do teste extracOs dados extraídos dos arquivos de saída e do banco de dados são verificados e registrados.

2. Testes online —

• O termo "Teste Online" refere-se ao teste de telas CICS, que é semelhante ao teste de uma página da web.
• A funcionalidade das telas existentes poderá ser alterada ou novas telas poderão ser adicionadas.
• Vários aplicativos podem ter telas de consulta e telas de atualização. A funcionalidade dessas telas precisa ser verificada como parte do teste on-line.

Como realizar testes em mainframe

1. A equipe de negócios prepara os documentos de requisitos, que determinam como um item ou processo específico será modificado no ciclo de lançamento.
2. A equipe de testes e a equipe de desenvolvimento recebem o documento de requisitos. Elas determinam quantos processos serão afetados pela mudança. Normalmente, em uma versão, apenas 20 a 25% do aplicativo é afetado diretamente pelo requisito personalizado. Os 75 a 80% restantes do esforço de lançamento são dedicados à funcionalidade padrão, como testar os aplicativos e processos adjacentes.
3. Portanto, uma aplicação Mainframe deve ser testada em duas partes:
   • Requisitos de teste — Testar a aplicação para verificar a funcionalidade ou a alteração mencionada no documento de requisitos.
   • Testando Integração — Testar todo o processo ou outros aplicativos que recebem ou enviam dados para o aplicativo afetado. Teste de regressão é o foco principal desta atividade de teste.

Ferramentas de teste de automação de mainframe

Abaixo está a lista de ferramentas que podem ser usadas para mainframe Teste de automação.

• REXX — a linguagem de script fornecida com o z/OS, amplamente utilizada para automatizar o envio de tarefas repetitivas e verificações de resultados.
• Excel — usado com macros para construir, comparar e gerar relatórios sobre dados de teste e arquivos de saída.
• OpenText UFT completa — o nome atual da ferramenta que a indústria ainda chama de QTP ou QuickTest Professional; ele automatiza 3270 telas de terminal.
• Galasa — um projeto de código aberto, Estrutura de teste de integração profunda do Open Mainframe Project que controla 3270 telas, trabalhos em lote JCL e Db2 a partir de um pipeline CI/CD.
• Conjuntos de testes z/OS do fornecedor - IBM O Test Accelerator para Z e o BMC AMI DevX Total Test abrangem testes de unidade COBOL e ambientes de teste virtualizados.

Qualquer que seja a ferramenta escolhida, ela só se paga se estiver dentro de um sistema de manutenção. estrutura de automação de testes em vez de uma pilha solta de roteiros.

Metodologia em Testes de Mainframe

Vejamos um exemplo: Uma seguradora XYZ possui um módulo de cadastro de membros. Ele coleta dados tanto da tela de cadastro quanto do cadastro offline. Como discutido anteriormente, são utilizadas duas abordagens para testes em mainframe: testes online e testes em lote.

• Os testes online são realizados na tela de inscrição de membros. Assim como em uma página da web, o banco de dados é validado com os dados inseridos nas telas.
• A inscrição offline pode ser feita em papel ou em um site de terceiros. Os dados offline (também chamados de lotes) serão inseridos no banco de dados da empresa por meio de processos em lote. Um arquivo plano de entrada é preparado de acordo com o formato de dados prescrito e inserido na sequência de processos em lote. Portanto, para testes de aplicativos mainframe, podemos usar a seguinte abordagem.
  • A primeira tarefa na sequência de tarefas em lote valida os dados inseridos — por exemplo, caracteres especiais ou letras em campos que aceitam apenas números.
  • A segunda etapa valida a consistência dos dados com base nas condições de negócio. Por exemplo, a inscrição de uma criança não deve conter dados de dependentes, nem um CEP de um membro que não esteja disponível para o plano contratado.
  • A terceira tarefa modifica os dados para um formato que possa ser inserido no banco de dados. Por exemplo, excluir o nome do plano (o banco de dados armazenará apenas o ID do plano e o nome do plano de saúde), adicionar a data de entrada e outras alterações semelhantes.
  • A quarta tarefa carrega os dados no banco de dados.
• O teste de trabalhos em lote é realizado neste processo em duas fases —
  • Cada tarefa é validada separadamente, e
  • A integração entre as tarefas é validada fornecendo o arquivo plano de entrada à primeira tarefa e validando o banco de dados. (Resultados intermediários devem ser validados por precaução adicional.)

O método seguido para testes em mainframe é o seguinte:

Etapa 1) Verificação/Teste de fumaça

O foco principal desta etapa é validar se o código implantado está no ambiente de teste correto. Também garante que não haja problemas críticos com o código. Isso é o equivalente em mainframe de Teste de Fumaça em qualquer outra plataforma.

Passo 2) Teste do sistema

Abaixo estão os tipos de testes realizados como parte do Teste do Sistema.

1. Teste em Lote — Este teste é realizado validando os resultados dos testes nos arquivos de saída e as alterações de dados feitas pelos trabalhos em lote no escopo do teste, e registrando-os.
2. Teste Online — Este teste é realizado na interface do aplicativo mainframe. Aqui, o aplicativo é testado para verificar se os campos de entrada, como um plano de seguro, juros do plano e valores semelhantes, estão corretos.
3. Teste de integração on-line em lote — Este teste é realizado em sistemas que possuem tanto processos em lote quanto um aplicativo online. O fluxo de dados e a interação entre as telas online e os trabalhos em lote são validados.

   (Exemplo para este tipo de teste — Considere uma atualização nos detalhes do plano, como um aumento na taxa de juros. A alteração da taxa de juros é feita em uma tela de atualização, e os detalhes do saldo nas contas afetadas serão modificados apenas por uma tarefa em lote executada à noite. O teste, neste caso, é feito validando a tela de detalhes do plano e a execução da tarefa em lote para atualizar todas as contas.)

4. Teste de banco de dados — Os bancos de dados onde os dados do aplicativo mainframe são armazenados (IMS, IDMS, Db2, VSAM/ISAM, conjuntos de dados sequenciais, GDGs) são validados quanto ao seu layout e armazenamento de dados.

Etapa 3) Sistema Teste de integração

O objetivo principal deste teste é validar a funcionalidade dos sistemas que estão interagindo com o sistema em teste.

Esses sistemas não são diretamente afetados pelos requisitos. No entanto, eles utilizam dados do sistema em teste. É importante testar o interface e os diferentes tipos de mensagens (como "Tarefa bem-sucedida", "Tarefa falhou", "Banco de dados atualizado") que podem fluir entre os sistemas, e as ações resultantes tomadas por cada sistema individualmente.

Os tipos de testes realizados nesta fase são

1. Teste em Lote
2. Teste Online
3. Online — Teste de integração em lote

Etapa 4) Teste de regressão

Os testes de regressão são uma fase comum em qualquer tipo de projeto de teste. Em mainframes, esses testes garantem que os processos em lote e as telas online que não interagem diretamente com o sistema em teste (ou que não estão no escopo dos requisitos) não sejam afetados pela versão atual do projeto.

Para realizar testes de regressão eficazes, um conjunto específico de casos de teste deve ser selecionado com base em sua complexidade, e um repositório de casos de teste (ou banco de regressão) deve ser criado. Esse conjunto deve ser atualizado sempre que uma nova funcionalidade for implementada na versão. Caso o repositório de regressão seja muito grande para ser executado por completo, Teste Baseado em Risco É usado para decidir quais tarefas e telas serão executadas novamente primeiro.

Passo 5) Teste de Desempenho

Esses testes são realizados para identificar gargalos em áreas de alto impacto, como entrada de dados na interface do usuário e atualizações de banco de dados online, e para projetar a escalabilidade da aplicação. Janelas de processamento em lote de longa duração geralmente são examinadas com Teste de estresse contra volumes máximos.

Passo 6) Teste de Segurança

Este teste é feito para avaliar quão bem o aplicativo foi projetado e desenvolvido para combater ataques anti-segurança.

É necessário realizar testes de segurança em duas etapas no sistema: segurança do mainframe e segurança da rede.

As funcionalidades que precisam ser testadas são:

1. Integrity
2. Confidencialidade
3. Autorização
4. Autenticação
5. Disponibilidade

Etapas envolvidas no teste em lote

1. Após a equipe de controle de qualidade receber o pacote aprovado (o pacote contém procedimentos, JCL, cartões de controle, módulos e itens similares), o testador deve visualizar e recuperar o conteúdo no PDS conforme necessário.
2. Converter o JCL de produção ou o JCL de desenvolvimento em JCL de QA, também chamado de JOB SETUP.
3. Copie o arquivo de produção e prepare os arquivos de teste.
4. Para cada funcionalidade, haverá uma sequência de tarefas definida (conforme explicado no exemplo da seção Metodologia em Testes de Mainframe). As tarefas devem ser submetidas usando o comando SUB com os arquivos de dados de teste.
5. Verifique o arquivo intermediário para identificar as razões da ausência ou dos erros nos dados.
6. Verifique o arquivo de saída final, o banco de dados e o Spool para validar os resultados do teste.
7. Se o trabalho falhar, o spool terá o motivo da falha do trabalho. Resolva o erro e reenvie o trabalho.

Relatório de teste - UMA defeito Deve ser registrado se o resultado real divergir do resultado esperado.

Etapas envolvidas nos testes online

1. Selecione a tela Online em Ambiente de teste.
2. Teste cada campo para obter os dados aceitáveis.
3. Teste o Cenário de Teste na tela.
4. Verifique o banco de dados para atualizações de dados na tela online.

Relatório de teste — Um defeito deve ser registrado se o resultado real divergir do resultado esperado.

Etapas envolvidas no teste de integração online em lote

1. Execute a tarefa em um ambiente de teste e valide os dados nas telas online.
2. Atualize os dados nas telas online e verifique se o processo em lote é executado corretamente com os dados atualizados.

Comandos usados ​​em testes de mainframe

Essas etapas são executadas a partir do terminal, portanto, um pequeno vocabulário de comandos abrange a maior parte do dia de um testador.

1. ENVIE — Envie uma solicitação de trabalho em segundo plano.
2. CANCELAR — Cancelar uma tarefa em segundo plano.
3. ALOCAR — Alocar um conjunto de dados.
4. CÓPIA — Copiar um conjunto de dados.
5. RENOMEAR — Renomear um conjunto de dados.
6. EXCLUIR — Excluir um conjunto de dados.
7. ANÁLISE DE EMPREGOS — Vincule o JCL ao programa, bibliotecas, arquivos e outros recursos sem executá-lo.

Existem muitos outros comandos usados ​​quando necessário, mas eles não são tão frequentes.

Pré-requisitos para iniciar os testes de mainframe

Os detalhes básicos necessários para testes em mainframe são:

• ID de login e senha para fazer login no aplicativo.
• Conhecimento básico dos comandos ISPF.
• Nomes dos arquivos, qualificador de arquivo e seus tipos.

Antes de iniciar os testes de mainframe, os seguintes aspectos devem ser verificados.

1. Trabalho
   • Execute uma verificação de tarefas (comando — JOBSCAN) para verificar se há erros antes de executá-las.
   • O parâmetro CLASS deve apontar para a classe de teste.
   • Direcione a saída do trabalho para a fila de spool ou para um JHS, ou conforme necessário, usando o parâmetro MSGCLASS.
   • Redirecione o e-mail da tarefa para a fila de espera ou para um endereço de e-mail de teste.
   • Comente as etapas de FTP para os testes iniciais e, em seguida, direcione a tarefa para um servidor de teste.
   • Caso um IMR (Registro de Gerenciamento de Incidentes) seja gerado na tarefa, adicione o comentário “OBJETIVO DE TESTE” na tarefa ou no cartão de parâmetros.
   • Todas as bibliotecas de produção do trabalho devem ser alteradas e apontadas para bibliotecas de teste.
   • O trabalho não deve ser deixado de lado.
   • Para evitar que a tarefa entre em um loop infinito em caso de erro, o parâmetro TIME deve ser adicionado com um tempo especificado.
   • Salve a saída do trabalho incluindo o spool. O spool pode ser salvo usando XDC.
2. Envie o
   • Crie apenas um arquivo de teste com o tamanho necessário. Use GDGs (Grupos de Dados de Geração — arquivos com o mesmo nome, mas com números de versão sequenciais, como MYLIB.LIB.TEST.G0001V00 e MYLIB.LIB.TEST.G0002V00) quando necessário para armazenar dados em arquivos consecutivos com o mesmo nome.
   • O parâmetro DISP (Disposição — indica ao sistema se o conjunto de dados deve ser mantido ou excluído após o término normal ou anormal da etapa ou tarefa) dos arquivos deve ser codificado corretamente.
   • Certifique-se de que todos os arquivos usados ​​para a execução da tarefa sejam salvos e fechados corretamente para evitar que a tarefa entre em modo de espera (HOLD).
   • Ao realizar testes utilizando GDGs, certifique-se de que a versão correta esteja sendo utilizada.
3. banco de dados
   • Ao executar a tarefa ou o programa online, certifique-se de que dados não sejam inseridos, atualizados ou excluídos indevidamente.
   • Além disso, certifique-se de que a região Db2 correta seja usada para os testes.
4. Casos de teste
   • Sempre teste as condições de contorno, como um arquivo vazio, o processamento do primeiro registro e o processamento do último registro.
   • Sempre inclua condições de teste positivas e negativas.
   • Caso sejam utilizados procedimentos padrão no programa, como reinicialização de ponto de verificação, módulos abend ou arquivos de controle, inclua Caso de testepara validar se os módulos foram usados ​​corretamente.
5. Dados de teste
   • A configuração dos dados de teste deve ser feita antes do início do teste.
   • Nunca modifique os dados na região de teste sem notificar os outros. Pode haver outras equipes trabalhando com os mesmos dados, e os testes delas falhariam.
   • Caso os arquivos de produção sejam necessários durante a execução, deverá ser obtida a devida autorização antes de copiá-los ou utilizá-los.

Melhores Práticas

1. No caso de uma execução em lote, MAX CC 0 indica que a tarefa foi executada com sucesso. Isso não significa que a funcionalidade esteja funcionando corretamente. A tarefa será executada com sucesso mesmo que a saída esteja vazia ou não corresponda ao esperado. Portanto, é sempre recomendável verificar todas as saídas antes de declarar a tarefa como bem-sucedida.
2. É sempre uma boa prática realizar um teste preliminar da tarefa em teste. Um teste preliminar é feito com arquivos de entrada vazios. Esse processo deve ser seguido para as tarefas que são impactadas pelas alterações feitas durante o ciclo de teste.
3. Antes do início do ciclo de testes, a configuração da tarefa de teste deve ser feita com bastante antecedência. Isso ajuda a identificar quaisquer erros de JCL antecipadamente, economizando tempo durante a execução.
4. Ao acessar tabelas Db2 por meio do SPUFI (uma opção do emulador para acessar tabelas Db2), sempre defina o commit automático como “NÃO” para evitar atualizações acidentais.
5. A disponibilidade de dados de teste é o principal desafio nos testes em lote. Os dados necessários devem ser criados com bastante antecedência ao ciclo de testes e devem ser verificados quanto à integridade. Tracking essa preparação em um compartilhado gerenciamento de teste O repositório mantém o ambiente de regressão e a configuração dos dados alinhados.
6. Algumas transações online e trabalhos em lote podem gravar dados em MQs (filas de mensagens) para transmitEnviar dados para outros aplicativos. Se os dados não forem válidos, isso pode desativar ou interromper as filas de mensagens (MQs), afetando todo o processo de teste. É uma boa prática verificar se as MQs estão funcionando corretamente após os testes.

Desafios e resolução de problemas em testes de mainframe

Mesmo com essas práticas implementadas, alguns problemas se repetem em quase todas as versões de mainframe. A tabela abaixo relaciona cada um deles com a abordagem que o resolve.

Desafios	Abordagem
Requisitos incompletos/pouco claros	Pode haver acesso a um manual do usuário ou guia de treinamento, mas estes não são o mesmo que requisitos documentados. Os testadores devem estar envolvidos no processo. ciclo de vida de teste de software A partir da fase de requisitos. Isso ajuda a verificar se os requisitos são testáveis.
Configuração/Identificação de Dados	Pode haver situações em que os dados existentes precisem ser reutilizados conforme a necessidade. Às vezes, é difícil identificar os dados necessários em meio aos dados existentes. Para a configuração dos dados, podem ser utilizadas ferramentas internas, de acordo com a necessidade. Para buscar dados existentes, as consultas devem ser elaboradas previamente. Em caso de qualquer dificuldade, pode-se solicitar à equipe de gerenciamento de dados a criação ou clonagem dos dados necessários.
Configuração do Trabalho	Após os jobs serem recuperados no PDS, é necessário configurá-los na região de QA para que não sejam submetidos com um qualificador de produção ou detalhes de caminho. Ferramentas de configuração de jobs devem ser utilizadas para evitar erros humanos durante a configuração.
Solicitação ad hoc	Pode haver situações em que testes de ponta a ponta É necessário suporte devido a um problema em aplicações upstream ou downstream. Essas solicitações aumentam o tempo e o esforço no ciclo de execução. O uso de scripts de automação, scripts de regressão e scripts básicos pode ajudar a reduzir essa sobrecarga de tempo e esforço.
Lançamentos dentro do prazo para mudança de escopo	Pode haver situações em que o impacto no código altere completamente a aparência e o funcionamento do sistema. Isso pode exigir mudanças nos casos de teste, scripts e dados. Um processo de gerenciamento de mudanças de escopo e uma análise de impacto devem estar em vigor.

Abends comuns encontrados

Quando uma tarefa falha, o spool reporta um código de abend. A lista abaixo abrange os códigos que um testador de mainframe encontra com mais frequência, juntamente com a causa usual.

1. S001 — Ocorreu um erro de entrada/saída.

   Motivo — Leitura no final do arquivo, erro de tamanho do arquivo ou tentativa de gravação em um arquivo somente leitura.

2. S002 — Registro de E/S inválido.

   Motivo — Tentativa de gravar um registro com duração superior à duração permitida.

3. S004 — Ocorreu um erro durante a abertura.

   Motivo — DCB inválido.

4. S013 — Erro ao abrir o conjunto de dados.

   Motivo — O membro do PDS não existe ou o comprimento do registro no programa não corresponde ao comprimento real do registro.

5. S0C1 - OperaExceção de ção.

   Motivo — Não foi possível abrir o arquivo ou o cartão DD está ausente.

6. S0C4 — Exceção de proteção / violação de armazenamento.

   Motivo — Tentativa de acessar um espaço de armazenamento não disponível para o programa.

7. S0C7 — Exceção na verificação do programa, dados.

   Motivo — Alteração no layout do registro ou no layout do arquivo.

8. Sx22 — O trabalho foi cancelado.

   Motivo — O trabalho foi interrompido antes da conclusão; o dígito do meio identifica quem ou o que o cancelou.

9. S222 — Tarefa cancelada pelo usuário sem um dump.
10. S322 — O tempo de execução da tarefa ou da etapa excedeu o limite especificado, ou o programa está em um loop, ou o parâmetro TIME é insuficiente.
11. S522 — Tempo limite da sessão TSO.
12. S806 — Não foi possível criar o link ou carregar o arquivo.

    Motivo — A tarefa não conseguiu encontrar o módulo de carga especificado.

13. S80A — Armazenamento virtual insuficiente para atender às solicitações GETMAIN ou FREEMAIN.
14. S913 — Tentativa de acessar um conjunto de dados para o qual o usuário não possui autorização.
15. Sx37 — Não foi possível alocar espaço de armazenamento suficiente para o conjunto de dados.

Assistência de erros — Uma ferramenta muito popular para obter informações detalhadas sobre vários tipos de abends.

Problemas comuns enfrentados durante os testes de mainframe

• Trabalho encerrado — Para concluir a tarefa com sucesso, você deve verificar os dados, o arquivo de entrada e se os módulos estão presentes no local especificado. As interrupções podem ocorrer por vários motivos, sendo os mais comuns dados inválidos, um campo de entrada incorreto, uma incompatibilidade de datas ou problemas ambientais.
• Arquivo de saída vazio — Embora a tarefa possa ser executada com sucesso (MaxCC 0), a saída pode não ser a esperada. Portanto, antes de executar qualquer caso de teste, o testador deve garantir que a saída seja verificada por meio de validação cruzada. Somente então o teste deve prosseguir.
• Arquivo de entrada vazio — Em algumas aplicações, os arquivos são recebidos de processos upstream. Antes de usar o arquivo recebido para testar a aplicação atual, os dados devem ser verificados para evitar reexecução e retrabalho.

Perguntas Frequentes