Teste de Mainframe – Tutorial Completo

Antes de aprender os conceitos de teste de mainframe, vamos aprender

O que é um mainframe?

O mainframe é um sistema de computador de alto desempenho e alta velocidade. É usado para fins de computação em larga escala que requerem grande disponibilidade e segurança. É usado principalmente em setores como finanças, seguros, varejo e outras áreas críticas onde grandes dados são processados ​​múltiplas vezes.

Teste de mainframe

Teste de mainframe é um processo de teste de aplicativos de software e serviços baseados em sistemas Mainframe. O objetivo dos testes de mainframe é garantir o desempenho, a confiabilidade e a qualidade do 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 de Mainframe, o testador só precisa saber sobre as navegações das telas do CICS. Eles são personalizados para aplicações específicas. Quaisquer alterações feitas no código em COBOL, JCL, etc. o testador não precisa se preocupar com o emulador configurado na máquina. As alterações que funcionam em um emulador de terminal funcionarão em outros.

  • A aplicação Mainframe (outroswise chamado lote de trabalho) é testado em relação aos casos de teste desenvolvidos usando 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 executados no mainframe podem ser acessados ​​​​por meio do emulador de terminal. O emulador é o único software que precisa ser instalado na máquina cliente.

Neste tutorial para iniciantes, você aprenderá-

Atributos do mainframe

  1. Armazenamento virtual
    1. É uma técnica que permite que um processador simule o armazenamento principal que é maior do que a quantidade real de armazenamento real.
    2. É uma técnica para usar a memória de forma eficaz para armazenar e executar tarefas de vários tamanhos.
    3. Ele usa o armazenamento em disco como uma extensão do armazenamento real.
  2. Multiprogramação
    1. O computador executa mais de um programa ao mesmo tempo. Mas a qualquer momento apenas um programa pode ter o controle da CPU.
    2. É um recurso fornecido para fazer uso eficiente da CPU.
  3. Processamento em lote
    1. É uma técnica pela qual qualquer tarefa é realizada em unidades conhecidas como empregos.
    2. Um trabalho pode fazer com que um ou mais programas sejam executados em sequência.
    3. 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.
    4. As informações necessárias para o processamento em lote são fornecidas através de JCL (JOB CONTROL LANGUAGE). JCL descreve o trabalho em lote – programas, dados e recursos necessários.
  4. Compartilhamento de tempo
    1. Num sistema de time-sharing, cada usuário tem acesso ao sistema através do dispositivo terminal. Em vez de enviar trabalhos agendados para later execução, o usuário insere comandos que são processados ​​imediatamente.
    2. Portanto, isso é chamado de “Processamento Interativo”. Ele permite que o usuário interaja diretamente com o computador.
    3. 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
    1. SPOOLing significa simultâneaneonós Operações Periféricas Online.
    2. O dispositivo SPOOL é usado para armazenar a saída do programa/aplicativo. A saída em spool é direcionada para dispositivos de saída como uma impressora (se necessário).
    3. É uma facilidade que explora a vantagem de bufferpara fazer uso eficiente dos dispositivos de saída.

Classificação de Testes Manuais em Mainframe

estrutura principal Teste Manual podem ser classificados em dois tipos:

1. Teste de trabalho em lote -

  • O processo de teste envolve execuções de trabalhos em lote para a funcionalidade implementada na versão atual.
  • O resultado do teste extraído dos arquivos de saída e do banco de dados é verificado e registrado.

2. Teste on-line -

  • Teste Online refere-se ao teste de telas do CICS que é semelhante ao teste da 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 fazer testes de mainframe

  1. A preparação da equipe de negóciosares documentos de exigência. O que determina como um determinado item ou processo será modificado no ciclo de lançamento.
  2. A equipe de testes e o desenvolvimento recebem o documento de requisitos. Eles descobrirão quantos processos serão afetados pela mudança. Normalmente, em uma versão, apenas 20-25% do aplicativo é afetado diretamente pelo requisito customizado. Os outros 75% da liberação serão para o exterior.box-funcionalidades como testar os aplicativos e processos.
  3. Portanto, uma aplicação Mainframe deve ser testada em duas partes:
    1. Requisitos de teste – Testar o aplicativo quanto à funcionalidade ou alteração mencionada no documento de requisitos.
    2. Testando Integração – Testar todo o processo ou outro aplicativo que recebe ou envia 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
  • sobressair
  • QTP

Metodologia em Testes de Mainframe

Consideremos um exemplo: Uma seguradora XYZ possui um módulo de inscrição de associados. São necessários dados da tela de inscrição de membros e da inscrição offline. Conforme discutimos anteriormente, são necessárias duas abordagens para testes de mainframe: testes on-line e testes em lote.

  • Teste online é feito na tela de inscrição de associados. Assim como uma página web o banco de dados é validado com os dados inseridos nas telas.
  • Inscrição off-line pode ser inscrição em papel ou inscrição em um site de terceiros. Os dados offline (também chamados de lote) serão inseridos no banco de dados da empresa por meio de trabalhos em lote. Um arquivo simples de entrada é preparado de acordo com o formato de dados prescrito e alimentado na sequência de trabalhos em lote. Portanto, para testes de aplicativos de mainframe, podemos usar o seguintewing abordagem.
  • O primeiro trabalho na linha de trabalhos em lote valida os dados inseridos. Digamos, por exemplo, caracteres especiais, alfabetos em campos somente numéricos, etc.
  • A segunda tarefa valida a consistência dos dados com base nas condições de negócios. Por exemplo, uma matrícula de filho não deve conter dados de dependente, CEP do associado (que não está disponível para atendimento pelo plano cadastrado), etc.
  • A terceira tarefa modifica os dados no formato que pode 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 seguro), anexar a data de entrada, etc.
  • A quarta tarefa carrega os dados no banco de dados.
  • Teste de trabalho em lote é feito neste processo em duas fases -
  • Cada trabalho é validado separadamente e o
  • A integração entre os trabalhos é validada fornecendo um arquivo simples de entrada para o primeiro trabalho e validando o banco de dados. (Os resultados intermediários devem ser validados para maior cautela)

O seguintewing é o método seguido para testes de Mainframe:

Passo 1): Shakedown/Teste de Fumaça

O foco principal nesta 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.

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 será feito validando os resultados dos testes nos arquivos de saída e alterações de dados feitas pelos trabalhos em lote sob o escopo do teste e registrando-os.
  2. Teste Online – Este teste será feito no front-end da aplicação mainframe. Aqui, o aplicativo é testado para campos de entrada corretos, como plano de seguro, juros do plano, etc.
  3. Teste de integração on-line em lote – Este teste será feito nos sistemas com processos em lote e aplicação 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 no Plano details como aumento da taxa de juros. A alteração dos juros é feita em uma tela de atualização, e o saldo étails nas contas afetadas serão modificados apenas por um trabalho em lote noturno. O teste neste caso será feito através da validação do Plano details tela e a execução do trabalho em lote para atualizar todas as contas).

  4. Teste de banco de dados – Os bancos de dados onde os dados da aplicação mainframe (IMS, IDMS, DB2, VSAM/ISAM, Conjuntos de dados sequenciais, GDGs) são validados para seu layout e armazenamento de dados.

Passo 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 usam dados do sistema em teste. É importante testar a interface e diferentes tipos de mensagens (como Trabalho bem sucedido, Falha no trabalho, Banco de dados atualizado, etc.) que podem fluir entre os sistemas e as ações resultantes tomadas pelos sistemas individuais.

Os tipos de testes realizados nesta fase são

  1. Teste em Lote
  2. Teste Online
  3. Online – Teste de Integração em Lote

Passo 4): Teste de regressão

O teste de regressão é uma fase comum em qualquer tipo de projeto de teste. Esses testes em Mainframes garantem que os jobs batch e as telas online que não interagem diretamente com o sistema em teste (ou não entram no escopo de requisitos) não sejam afetados pela versão atual do projeto.

Para ter testes de regressão eficazes, um conjunto específico de casos de teste deve ser selecionado dependendo de sua natureza.plexdeve ser criada uma base de regressão (repositório de casos de teste). Este conjunto deve ser atualizado sempre que houver uma nova funcionalidade lançada no lançamento.

Passo 5): Teste de Desempenho

Esses testes são feitos para identificar gargalos em áreas de grande impacto, como dados front-end, atualização de bancos de dados online e para projetar a escalabilidade do aplicativo.

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.

Dois testes de segurança devem ser feitos no sistema – segurança do mainframe e segurança da rede.

Os recursos que precisam ser testados são

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

Etapas envolvidas no teste em lote

  1. Depois que a equipe de controle de qualidade receber o pacote aprovado (o pacote contém procedimentos, JCL, cartões de controle, módulos, etc.), o testador deverá visualizar e recuperar o conteúdo no PDS conforme necessário.
  2. Converta o JCL de produção ou JCL de desenvolvimento em JCL de controle de qualidade outrowise chamado CONFIGURAÇÃO DE TRABALHO.
  3. Copiando arquivo de produção e preparando arquivos de teste.
  4. Para cada funcionalidade, haverá uma sequência de tarefas definida. (Conforme explicado no exemplo da seção Metodologia em Mainframe). Os jobs devem ser submetidos utilizando o comando SUB com os arquivos de dados de teste.
  5. Verifique o arquivo intermediário para identificar os motivos da falta ou erro dos 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 – Defeito deve ser registrado se o resultado real se desviar do esperado.

Etapas envolvidas no teste online

  1. Selecione a tela Online em um 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 – O defeito deve ser registrado se o resultado real se desviar do esperado.

Etapas envolvidas no teste de integração on-line – lote

  1. Execute o trabalho em um Ambiente de teste e validar os dados nas telas online.
  2. Atualize os dados nas telas online e valide se o batch job está sendo executado corretamente com os dados atualizados.

Comandos usados ​​em testes de mainframe

  1. ENVIAR – Envie um trabalho em segundo plano.
  2. CANCELAR – Cancela o trabalho em segundo plano.
  3. ALLOCATE – Alocar um conjunto de dados
  4. COPY – Copiar um conjunto de dados
  5. RENAME – Renomear conjunto de dados
  6. DELETE – Excluir conjunto de dados
  7. JOB SCAN –Para vincular o JCL ao programa, bibliotecas, arquivo, etc., 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

Básico details necessários para testes de mainframe são:

  • ID de login e senha para fazer login no aplicativo.
  • Breve conhecimento sobre comandos ISPF.
  • Nomes dos arquivos, qualificador de arquivo e seus tipos.

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

  1. Trabalho
    1. Faça uma varredura do trabalho (Command – JOBSCAN) para verificar se há erros antes de executá-lo.
    2. O parâmetro CLASS deve ser apontado para a classe de teste.
    3. Direcione a saída da tarefa para o spool ou JHS ou conforme necessário usando o parâmetro MSGCLASS.
    4. Redirecione o email no trabalho para spool ou um teste mail ID.
    5. Comente as etapas do FTP para testes iniciais e aponte o trabalho para um servidor de teste.
    6. Caso um IMR (registro de Gerenciamento de Incidentes) seja gerado no trabalho, basta adicionar o comentário “TESTING PURPOSE” no trabalho ou no cartão de parâmetros.
    7. Todas as bibliotecas de produção do trabalho devem ser alteradas e apontadas para bibliotecas de teste.
    8. O trabalho não deve ser deixado de lado.
    9. Para evitar que o trabalho seja executado em um loop infinito caso ocorra algum erro, o parâmetro TIME deve ser adicionado com o tempo especificado.
    10. Salve a saída do trabalho incluindo o spool. O spool pode ser salvo usando XDC.
  1. Envie o
    1. Crie apenas um arquivo de teste do tamanho necessário. Use GDGs (Grupos de Dados de Geração - Arquivos com o mesmo nome, mas com números de versão sequenciais - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 e assim por diante) quando necessário para armazenar dados em arquivos consecutivos com o mesmo nome.
    2. O parâmetro DISP (Disposição - descreve o sistema para manter ou excluir o conjunto de dados após o encerramento normal ou anormal da etapa ou trabalho) para que os arquivos sejam codificados corretamente.
    3. Certifique-se de que todos os arquivos usados ​​para execução do trabalho sejam salvos e fechados corretamente para evitar que o trabalho entre em HOLD.
    4. Ao testar usando GDGs, certifique-se de que a versão correta seja apontada.
  2. banco de dados
    1. Ao executar o trabalho ou programa on-line, certifique-se de que dados não intencionais não sejam inseridos, atualizados ou excluídos.
    2. Além disso, certifique-se de que a região correta do DB2 seja usada para teste.
  3. Casos de teste
    1. Sempre teste as condições de limite como – arquivo vazio, processamento do primeiro registro, processamento do último registro, etc.
    2. Sempre inclua condições de teste positivas e negativas.
    3. Caso procedimentos padrão sejam usados ​​no programa como reinicialização de ponto de verificação, módulos Abend, arquivos de controle, etc. inclua casos de teste para validar se os módulos foram usados ​​corretamente.
  4. Dados de teste
    1. A configuração dos dados de teste deve ser feita antes do início do teste.
    2. Nunca modifique os dados na região de teste sem notificar. Pode haver outras equipes trabalhando com os mesmos dados e o teste falhará.
    3. 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 de trabalho em lote, MAX CC 0 é um indicador de que o trabalho foi executado com êxito. Isso não significa que a funcionalidade esteja funcionando bem. O trabalho será executado com êxito mesmo quando a saída estiver vazia ou não conforme a expectativa. Portanto, espera-se sempre verificar todas as saídas antes de declarar o trabalho bem-sucedido.
  2. É sempre uma boa prática fazer uma simulação do trabalho em teste. A simulação é feita com arquivos de entrada vazios. Este processo deve ser seguido para os trabalhos que são impactados pelas alterações feitas no ciclo de teste.
  3. Antes do início do ciclo de teste, a configuração do trabalho de teste deve ser feita com bastante antecedência. Isso ajudará a descobrir qualquer erro JCL com antecedência, economizando tempo durante a execução.
  4. Ao acessar tabelas DB2 através de SPUFI (opção no emulador para acessar tabelas DB2), sempre defina o auto commit como “NO” para evitar atualizações acidentais.
  5. A disponibilidade dos dados de teste é o principal desafio nos testes em lote. Os dados necessários devem ser criados bem antes do ciclo de teste e devem ser verificados quanto à integridade.
  6. Algumas transações on-line e trabalhos em lote podem gravar dados em MQs (Message Queue) para transmitir dados para outros aplicativos. Se os dados não forem válidos, isso poderá desativar/parar os MQs, o que afetará todo o processo de teste. É uma boa prática verificar se os MQs estão funcionando bem após o teste.

Desafios e solução de problemas de testes de mainframe

Desafios Abordagem
Requisitos incompletos/pouco claros

Pode haver acesso ao manual do usuário/guia de treinamento, mas estes não são iguais aos requisitos documentados.

Os testadores devem estar envolvidos no SDLC desde a fase de requisitos. Isso ajudará a verificar se os requisitos são testáveis.
Configuração/Identificação de Dados

Pode haver situações em que os dados existentes devam ser reutilizados conforme o requisito. Às vezes é difícil identificar os dados necessários a partir dos dados existentes.

Para configuração de dados, ferramentas desenvolvidas internamente podem ser usadas conforme a necessidade.
Para buscar dados existentes, as consultas devem ser criadas antecipadamente. Em caso de qualquer dificuldade, pode ser feita uma solicitação à equipe de gerenciamento de dados para criação ou clonagem dos dados necessários.
Configuração do Trabalho

Depois que os trabalhos forem recuperados no PDS, o trabalho precisará ser configurado na região de controle de qualidade. Para que os trabalhos não sejam enviados com qualificador de produção ou detalhe de caminho.

As ferramentas de configuração do trabalho devem ser usadas para superar erros humanos cometidos durante a configuração.
Solicitação ad hoc

Pode haver situações em que o teste de ponta a ponta precise ser suportado devido a um problema no aplicativo upstream ou downstream. Essas solicitações aumentam o tempo e o esforço do ciclo de execução.

O uso de scripts de automação, scripts de regressão e scripts de esqueleto pode ajudar a reduzir a sobrecarga de tempo e esforço.
Lançamentos dentro do prazo para mudança de escopo

Pode haver uma situação em que o impacto do código possa alterar completamente a aparência do sistema. Isso pode exigir uma alteração nos casos de teste, scripts e dados.

O processo de gestão de mudanças no escopo e a análise de impacto devem estar em vigor.

Abenções comuns encontradas

  1. S001 – Ocorreu um erro de E/S.

    Motivo – Leitura no final do arquivo, erro no comprimento do arquivo, tentativa de gravação em arquivo somente leitura.

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

    Motivo – Tentativa de gravar um registro maior que o comprimento do registro.

  3. S004 – Ocorreu erro durante ABERTO.

    Motivo – DCB inválido

  4. S013 – Erro ao abrir um conjunto de dados.

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

  5. S0C1 – Exceção de Operação

    Motivo –Não foi possível abrir o arquivo, cartão DD ausente

  6. S0C4 – Exceção de proteção/Violação de armazenamento
  7. Motivo – Tentativa de acesso ao armazenamento não disponível para o programa.
  8. S0C7 – Exceção de verificação de programa – Dados
  9. Motivo – Alteração no layout do registro ou no layout do arquivo.
  10. Sx22 – O trabalho foi cancelado
  11. S222 – Job cancelado pelo usuário sem dump.
  12. S322 – O tempo do Job ou Step excedeu o limite especificado ou o programa está em loop ou parâmetro de tempo insuficiente.
  13. S522 – Timeout da sessão TSO.
  14. S806 –Não é possível vincular ou carregar.

    Motivo – O ID do trabalho não conseguiu encontrar o módulo de carregamento especificado.

  15. S80A – Armazenamento virtual insuficiente para atender às solicitações GETMAIN ou FREEMAIN.
  16. S913 – Tentativa de acesso ao conjunto de dados para o qual o usuário não está autorizado.
  17. Sx37 – Não é possível alocar armazenamento suficiente para o conjunto de dados.

Error Assist – Uma ferramenta muito popular para obter informações detalhadas sobre vários tipos de encerramentos anormais.

Problema comum enfrentado durante testes de mainframe

  • Trabalho encerrado – Para a conclusão bem sucedida do trabalho, você deve verificar os dados, arquivo de entrada e os módulos presentes no local específico ou não. As anormalidades podem ser enfrentadas por vários motivos, sendo os mais comuns – dados inválidos, campo de entrada incorreto, incompatibilidade de data, problemas ambientais, etc.
  • Arquivo de saída vazio–Embora a tarefa possa ser executada com êxito (MaxCC 0), a saída pode não ser a esperada. Portanto, antes de passar em qualquer caso de teste, o testador deve certificar-se de que a saída foi verificada cruzadamente. Só então prossiga.
  • Arquivo de entrada vazio – Em alguns aplicativos, os arquivos serão recebidos dos processos upstream. Antes de usar o arquivo recebido para testar a aplicação atual, os dados devem ser verificados cruzadamente para evitar reexecução e retrabalho.

Resumo:

  • O teste de mainframe é como qualquer outro procedimento de teste, começando pela coleta de requisitos, design de teste, execução de teste e relatório de resultados.
  • Para testar o aplicativo de forma eficaz, o testador deve participar de reuniões de design agendadas pelas equipes de desenvolvimento e de negócios.
  • É obrigatório que o testador se acostume com as diversas funções de teste do mainframe. Como navegação na tela, criação de arquivos e PDS, salvamento de resultados de testes, etc. antes do início do ciclo de teste.
  • O teste de aplicativos de mainframe é um processo demorado. Um cronograma de teste claro deve ser seguido para design de teste, configuração de dados e execução.
  • Os testes em lote e os testes on-line devem ser feitos de forma eficaz, sem perder nenhuma funcionalidade mencionada no documento de requisitos e sem Caso de teste deveria ser poupado.