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. Ele é usado para fins de computação em grande escala que requer 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 ​​várias vezes.

Teste de mainframe

Teste de mainframe é um processo de teste de aplicativos de software e serviços baseados em sistemas mainframe. O objetivo do teste 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 ser implantado.

Ao realizar o teste 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 a configuração do emulador na máquina. As mudanças que funcionam em um emulador de terminal funcionarão em outros.

  • O aplicativo de mainframe (também chamado de 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 de mainframe

  1. Armazenamento Virtual
    1. É uma técnica que permite que um processador simule o armazenamento principal 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 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 jobs.
    2. Um trabalho pode fazer com que um ou mais programas sejam executados em sequência.
    3. O Agendador de trabalhos toma uma decisão sobre a ordem em que os trabalhos devem ser executados. Para maximizar o rendimento médio, os trabalhos são programados de acordo com sua prioridade e classe.
    4. As informações necessárias para o processamento em lote são fornecidas por meio de JCL (JOB CONTROL LANGUAGE). JCL descreve o trabalho em lote - programas, dados e recursos necessários.
  4. Compartilhamento de tempo
    1. Em um sistema de compartilhamento de tempo, cada usuário tem acesso ao sistema por meio do dispositivo terminal. Em vez de enviar tarefas programadas para execução posterior, 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 em lote é conhecido como 'Processamento em segundo plano'.
  5. Spool
    1. SPOOLing significa Operações periféricas simultâneas 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 do buffer para fazer uso eficiente dos dispositivos de saída.

Classificação de testes manuais em mainframe

Mainframe 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 Online -
    • Teste Online refere-se ao teste de telas do CICS, que é semelhante ao teste da página da web.
    • A funcionalidade das telas existentes pode ser alterada ou novas telas podem 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 online.

Como fazer testes de mainframe

  1. A equipe de negócios prepara documentos de requisitos. Que determina como um determinado item ou processo será modificado no ciclo de lançamento.
  2. A equipe de teste 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 personalizado. Os outros 75% do lançamento serão para funcionalidades predefinidas, como testes de aplicativos e processos.
  3. Portanto, um aplicativo de mainframe deve ser testado em duas partes:
    1. Requisitos de teste - Testar o aplicativo quanto à funcionalidade ou alteração mencionada no documento de requisitos.
    2. Teste de integração - Testar todo o processo ou outro aplicativo que recebe ou envia dados ao 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
  • Excel
  • QTP

Metodologia em testes de mainframe

Vamos considerar um exemplo: Uma seguradora XYZ possui um módulo de inscrição de membros. Ele obtém dados da tela de inscrição de membros e da inscrição offline. Como discutimos anteriormente, são necessárias duas abordagens para teste de mainframe, teste online e teste em lote.

  • Teste online é feito na tela de inscrição de membros. Assim como uma página da web, o banco de dados é validado com os dados inseridos nas telas.
  • Inscrição offline pode ser inscrição em papel ou inscrição em um site de terceiros. Os dados off-line (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 para a sequência de trabalhos em lote. Portanto, para o teste de aplicativos de mainframe, podemos usar a abordagem a seguir.
    • O primeiro trabalho na linha de trabalhos em lote valida os dados inseridos. Digamos, por exemplo, caracteres especiais, alfabetos em campos apenas numéricos, etc.
    • O segundo trabalho valida a consistência dos dados com base nas condições de negócios. Por exemplo, a inscrição de uma criança não deve conter dados dependentes, código postal de membro (que não está disponível para serviço pelo plano inscrito), etc.
    • O terceiro trabalho 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 a ID do plano e o nome do plano de seguro), anexar a data de entrada, etc.
    • O quarto trabalho 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 as tarefas é validada fornecendo um arquivo simples de entrada para a primeira tarefa e validando o banco de dados. (Os resultados intermediários devem ser validados para cautela extra)

A seguir está o método seguido para o teste de mainframe:

Passo 1) : Shakedown / Teste de Fumaça

O foco principal neste estágio é 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 de Sistema

Abaixo estão os tipos de teste feitos como parte do Teste do Sistema.

  1. Teste em lote - Este teste será feito validando os resultados do teste em arquivos de saída e alterações de dados feitas pelos trabalhos em lote sob escopo de teste e registro deles.
  2. Teste Online - Este teste será feito no front-end do aplicativo de mainframe. Aqui, o aplicativo é testado para o campo de entrada correto, como um plano de seguro, juros sobre o plano, etc.
  3. Teste de integração em lote online - Este teste será feito nos sistemas com processos batch e aplicação online. O fluxo de dados e a interação entre as telas online e os jobs batch são validados.

    ( Exemplo para este tipo de teste - Considere uma atualização nos detalhes do plano, como aumento da taxa de juros. A mudança de interesse é feita em uma tela de atualização e os detalhes do saldo nas contas afetadas serão modificados apenas por um trabalho em lote noturno. O teste, neste caso, será feito validando a tela de detalhes do plano e a execução do batch job para atualizar todas as contas).

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

Etapa 3) : Teste de integração do sistema

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 afetados diretamente pelos requisitos. No entanto, eles usam dados do sistema em teste. É importante testar a interface e os diferentes tipos de mensagens (como Job Success, Job Failed, Database updated, etc.) que podem fluir entre os sistemas e as ações resultantes tomadas pelos sistemas individuais.

Os tipos de teste feitos 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. Este teste em mainframes garante que os jobs batch e as telas online que não interagem diretamente com o sistema em teste (ou não entram no escopo dos requisitos) não sejam afetados pela versão do projeto atual.

Para ter um teste de regressão eficaz, um determinado conjunto de casos de teste deve ser selecionado dependendo de sua complexidade e um leito de regressão (repositório de casos de teste) deve ser criado. Este conjunto deve ser atualizado sempre que houver uma nova funcionalidade implementada na versão.

Etapa 5) : Teste de performance

Esse teste é feito para identificar os gargalos em áreas de alta ocorrência, como dados de front-end, atualização de bancos de dados online e para projetar a escalabilidade do aplicativo.

Etapa 6) : Teste de Segurança

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

O teste de segurança duplo deve ser feito no sistema - segurança de mainframe e segurança de 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 QA recebe o pacote aprovado (o pacote contém procedimentos, JCL, cartões de controle, módulos, etc.), o testador deve visualizar e recuperar o conteúdo no PDS conforme necessário.
  2. Converta o JCL de produção ou o JCL de desenvolvimento em JCL de QA, também denominado JOB SETUP.
  3. Copiar arquivo de produção e preparar arquivos de teste.
  4. Para cada funcionalidade, haverá uma sequência de trabalho definida. (Conforme explicado no exemplo na seção Metodologia na seção Mainframe). As tarefas devem ser enviadas usando o comando SUB com os arquivos de dados de teste.
  5. Verifique o arquivo intermediário para identificar os motivos da falta ou erro de 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. Resolva o erro e reenvie o trabalho.

Relatório de teste - Defeito deve ser registrado se o resultado real for diferente do esperado.

Etapas envolvidas no teste online

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

Relatório de teste - o defeito deve ser registrado se o resultado real for diferente do esperado.

Etapas envolvidas no teste online - integração em 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 trabalho em lote é 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 - Copia 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ários, mas eles não são tão frequentes.

Pré-requisitos para iniciar o teste de mainframe

Os detalhes básicos necessários para o teste de mainframe são:

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

Antes de iniciar o teste de mainframe, os aspectos abaixo devem ser verificados.

  1. Trabalho
    1. Faça uma verificação de trabalho (Comando - 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 um JHS ou conforme necessário usando o parâmetro MSGCLASS.
    4. Redirecione o e-mail no trabalho para o spool ou um ID de e-mail de teste.
    5. Comente as etapas do FTP para o teste inicial e aponte o trabalho para um servidor de teste.
    6. No caso de um IMR (registro de gerenciamento de incidentes) ser gerado no trabalho, basta adicionar o comentário 'PROPÓSITO DE TESTE' no trabalho ou cartão de parâmetro.
    7. Todas as bibliotecas de produção no trabalho devem ser alteradas e apontadas para bibliotecas de teste.
    8. O trabalho não deve ser deixado sem supervisão.
    9. Para evitar que o trabalho seja executado em um loop infinito no caso de qualquer erro, o parâmetro TIME deve ser adicionado com o tempo especificado.
    10. Salve a saída do trabalho incluindo o carretel. O carretel pode ser salvo usando XDC.
  1. Arquivo
    1. Crie o arquivo de teste apenas com o tamanho necessário. Use GDGs (Grupos de Geração de Dados - Arquivos com o mesmo nome, mas com números de versão sequenciais - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 etc.) quando necessário para armazenar dados em arquivos consecutivos com o mesmo nome.
    2. O parâmetro DISP (Disposição - descreve o sistema para realizar a manutenção ou exclusão do conjunto de dados após o término normal ou anormal da etapa ou trabalho) para os arquivos devem ser codificados corretamente.
    3. Certifique-se de que todos os arquivos usados ​​para a 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. Base de dados
    1. Ao executar o trabalho ou programa online, certifique-se de que dados indesejados 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 as condições de teste positivas e negativas.
    3. Caso procedimentos padrão sejam usados ​​no programa, como Check point restart, Abend Modules, Control files, 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, deve-se obter 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 sucesso mesmo quando a saída estiver vazia ou não de acordo com a expectativa. Portanto, é sempre esperado que você verifique 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 operação a seco é 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 as tabelas do DB2 por meio de SPUFI (opção no emulador para acessar as tabelas do DB2), sempre defina a confirmação automática como 'NÃO' para evitar atualizações acidentais.
  5. A disponibilidade dos dados de teste é o principal desafio no teste em lote. Os dados necessários devem ser criados com bastante antecedência do ciclo de teste e devem ser verificados quanto à integridade.
  6. Algumas transações online 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, pode desabilitar / parar 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 teste de mainframe

Desafios Abordagem
Requisitos incompletos / pouco claros

Pode haver acesso ao manual do usuário / guia de treinamento, mas esses não são os mesmos que os 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 de acordo com o requisito. Às vezes é difícil identificar os dados necessários a partir dos dados existentes.
Para configuração de dados, ferramentas caseiras podem ser usadas conforme a necessidade. Para buscar dados existentes, as consultas devem ser construídas com antecedência. Em caso de qualquer dificuldade, uma solicitação pode ser feita para a equipe de gerenciamento de dados para criar ou clonar os dados necessários.
Configuração do Trabalho

Uma vez que os trabalhos são recuperados no PDS, o trabalho precisa ser configurado na região de controle de qualidade. Para que as tarefas não sejam enviadas com o qualificador de produção ou detalhes do 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 nos aplicativos 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 de esqueleto pode ajudar a reduzir a sobrecarga de tempo e esforço.
Liberações pontuais para mudança de escopo

Pode haver uma situação em que o impacto do código mude completamente a aparência do sistema. Isso pode exigir uma mudança nos casos de teste, scripts e dados.
O processo de gerenciamento de mudança de escopo e a análise de impacto devem estar implementados.

Noites comuns encontradas

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

    Motivo - Leitura no final do arquivo, erro de 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 mais longo do que o comprimento do registro.

  3. S004 - Ocorreu erro durante OPEN.

    Motivo - DCB inválido

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

    Motivo - o membro PDS não existe, a duração do registro no programa não corresponde à duração real do registro.

  5. S0C1 - Exceção de operação

    Motivo - Incapaz de abrir o arquivo, cartão DD ausente

  6. S0C4 - exceção de proteção / violação de armazenamento
  7. Motivo - Tentando acessar o armazenamento não disponível para o programa.
  8. SC07 - Exceção de verificação de programa - Dados
  9. Motivo - Mudança no layout do registro ou layout do arquivo.
  10. Sx22 - Trabalho cancelado
  11. S222 - Trabalho cancelado pelo usuário sem dump.
  12. S322 - O tempo do trabalho ou etapa excedeu o limite especificado ou o programa está em um loop ou parâmetro de tempo insuficiente.
  13. S522 - tempo limite da sessão TSO.
  14. S806 - Incapaz de vincular ou carregar.

    Motivo - o ID do trabalho não foi capaz de encontrar o módulo de carregamento especificado.

  15. S80A - Armazenamento virtual insuficiente para atender às solicitações GETMAIN ou FREEMAIN.
  16. S913 - Tentativa de acessar o conjunto de dados que 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 abends.

Problema comum enfrentado durante o teste de mainframe

  • Noites de trabalho - Para a conclusão do trabalho com sucesso, deve-se verificar os dados, arquivo de entrada e os módulos presentes no local específico ou não. Abends podem ser enfrentados por vários motivos, sendo o mais comum - dados inválidos, campo de entrada incorreto, incompatibilidade de data, questões ambientais, etc.
  • Arquivo de saída vazio –Embora o trabalho possa ser executado 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 ter certeza de que a saída foi verificada. 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 o aplicativo atual, os dados devem ser verificados para evitar a reexecução e retrabalho.

Resumo:

  • O teste de mainframe é como qualquer outro procedimento de teste, começando com a coleta de requisitos, design de teste, execução de teste e relatório de resultados.
  • Para testar o aplicativo com eficácia, o testador deve participar das reuniões de design agendadas pelas equipes de desenvolvimento e negócios.
  • É obrigatório para o testador se acostumar com várias funções de teste de mainframe. Como navegação na tela, criação de arquivo e PDS, salvamento de resultados de teste, 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.
  • O teste em lote e o teste online devem ser feitos de forma eficaz, sem perder nenhuma funcionalidade mencionada no documento de Requisito, e não Caso de teste deve ser poupado.