Teste de mainframe

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 é um processo de teste de aplicativos de software e serviços baseados em sistemas de 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
Classificação de testes manuais em mainframe
Como fazer testes de mainframe
Ferramentas de teste de automação de mainframe
Metodologia em testes de mainframe
Etapas envolvidas no teste em lote
Etapas envolvidas no teste online
Etapas envolvidas no teste online - integração em lote
Comandos usados em testes de mainframe
Pré-requisitos para iniciar o teste de mainframe
Melhores Práticas
Desafios e solução de problemas de teste de mainframe
Abends comuns encontrados
Problema comum enfrentado durante o teste de mainframe

Atributos de mainframe

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.
Multiprogramação
1. O computador executa mais de um programa ao mesmo tempo. Mas em um determinado momento, apenas um programa pode ter controle da CPU.
2. É uma facilidade fornecida para fazer uso eficiente da CPU.
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 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 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.
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".
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

O teste manual de mainframe pode ser classificado em dois tipos:

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.
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

A equipe de negócios prepara documentos de requisitos. Que determina como um determinado item ou processo será modificado no ciclo de lançamento.
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.
Portanto, um aplicativo de mainframe deve ser testado em duas partes:
1. Requisitos de teste - Testar o aplicativo quanto à funcionalidade ou mudança mencionada no documento de requisitos.
2. Testando a integração - Testando todo o processo ou outro aplicativo que recebe ou envia dados ao aplicativo afetado. O 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 testes de automação de mainframe.

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.

O teste online é feito na tela de inscrição do membro. Assim como uma página da web, o banco de dados é validado com os dados inseridos nas telas.
A inscrição off-line pode ser em papel ou 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.
O 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:

Etapa 1) : Teste de limpeza / fumaça

O foco principal neste estágio é validar se o código implantado está no ambiente de teste correto. Ele também garante que não haja problemas críticos com o código.

Etapa 2) : Teste do sistema

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

Teste em lote - Este teste será feito validando os resultados do teste nos arquivos de saída e nas alterações de dados feitas pelos trabalhos em lote no escopo do teste e registrando-os.
Teste online - Este teste será feito no front-end do aplicativo de mainframe. Aqui, o aplicativo é testado para campos de entrada corretos, como um plano de seguro, juros sobre o plano, etc.
Teste de integração online-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 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 alteração dos juros é 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. Teste neste caso, será feito validando a tela de detalhes do plano e a execução do batch job para atualização de todas as contas).
Teste de banco de dados - Os bancos de dados onde os dados do aplicativo de mainframe (IMS, IDMS, DB2, VSAM / ISAM, conjuntos de dados sequenciais, GDGs) são validados para 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

Teste em lote
Teste Online
Online - Teste de integração em lote

Etapa 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 desempenho

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

Integridade
Confidencialidade
Autorização
Autenticação
Disponibilidade

Etapas envolvidas no teste em lote

Depois que a equipe de QA receber 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.
Converta o JCL de produção ou o JCL de desenvolvimento em JCL de QA, também denominado JOB SETUP.
Copiar arquivo de produção e preparar arquivos de teste.
Para cada funcionalidade, haverá uma sequência de trabalho definida. (Conforme explicado no exemplo em Metodologia na seção Mainframe). Os trabalhos devem ser enviados usando o comando SUB com os arquivos de dados de teste.
Verifique o arquivo intermediário para identificar os motivos da falta ou da falta de dados.
Verifique o arquivo de saída final, o banco de dados e o Spool para validar os resultados do teste.
Se o trabalho falhar, o spool terá o motivo da falha. Resolva o erro e reenvie o trabalho.

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

Etapas envolvidas no teste online

Selecione a tela Online em um ambiente de teste.
Teste cada campo para os dados aceitáveis.
Teste o cenário de teste na tela.
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

Execute a tarefa em um ambiente de teste e valide os dados nas telas online.
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

ENVIAR - Envie um trabalho em segundo plano.
CANCELAR - Cancela o trabalho em segundo plano.
ALLOCATE - alocar um conjunto de dados
COPY - Copia um conjunto de dados
RENAME - Renomear conjunto de dados
DELETE - Excluir conjunto de dados
JOB SCAN - Para vincular o JCL com o 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.

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. Caso um IMR (Registro de Gerenciamento de Incidentes) seja 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.

Arquivo
1. Crie um 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 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 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.
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.
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. No caso de serem usados procedimentos padrão no programa como Check point restart, Abend Modules, Control files, etc. inclua casos de teste para validar se os módulos foram usados corretamente.
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

No caso de uma execução de Batch Job, MAX CC 0 é um indicador de que a tarefa foi executada com sucesso. 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.
É 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 mudanças feitas no ciclo de teste.
Antes de o ciclo de teste começar, 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.
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.
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.
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 desativar / 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	Aproximação
Requisitos incompletos / pouco claros Pode haver acesso ao manual do usuário / guia de treinamento, mas 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 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 Depois 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 pode mudar 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.

Abends comuns encontrados

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.
S002 - Registro de E / S inválido.
Motivo - tentativa de gravar um registro mais longo do que o comprimento do registro.
S004 - Ocorreu erro durante OPEN.
Motivo - DCB inválido
S013 - Erro ao abrir um conjunto de dados.
Motivo - o membro PDS não existe, o tamanho do registro no programa não corresponde ao tamanho real do registro.
S0C1 - Exceção de operação
Motivo - Incapaz de abrir o arquivo, cartão DD ausente
S0C4 - exceção de proteção / violação de armazenamento
Motivo - Tentando acessar o armazenamento não disponível para o programa.
SC07 - Exceção de verificação de programa - Dados
Motivo - Mudança no layout do registro ou layout do arquivo.
Sx22 - Trabalho cancelado
S222 - Trabalho cancelado pelo usuário sem dump.
S322 - O tempo do trabalho ou etapa excedeu o limite especificado, ou o programa está em um loop ou parâmetro de tempo insuficiente.
S522 - tempo limite da sessão TSO.
S806 - Incapaz de vincular ou carregar.
Motivo - o ID do trabalho não foi capaz de encontrar o módulo de carregamento especificado.
S80A - Armazenamento virtual insuficiente para atender às solicitações GETMAIN ou FREEMAIN.
S913 - Tentativa de acessar o conjunto de dados que o usuário não está autorizado.
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

Job Abends - Para a conclusão bem-sucedida do job, você deve verificar os dados, o 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.
Os testes em lote e online devem ser feitos de forma eficaz, sem perder nenhuma funcionalidade mencionada no documento de Requisitos, e nenhum Caso de Teste deve ser poupado.

Teste de mainframe - tutorial completo

Índice:

O que é um mainframe?