Test Mainframe - Tutoriel complet

Avant d'apprendre les concepts de tests mainframe, apprenons

Qu'est-ce qu'un ordinateur central ?

Le mainframe est un système informatique hautes performances et haute vitesse. Il est utilisé à des fins informatiques à plus grande échelle qui nécessitent une grande disponibilité et sécurité. Il est principalement utilisé dans des secteurs tels que la finance, l’assurance, la vente au détail et d’autres domaines critiques où d’énormes données sont traitées plusieurs fois.

Tests sur mainframe

Tests sur mainframe est un processus de test d'applications logicielles et de services basés sur des systèmes mainframe. Le but des tests mainframe est de garantir les performances, la fiabilité et la qualité de l'application logicielle ou du service par des méthodes de vérification et de validation et de vérifier s'il est prêt à être déployé.

Lors des tests Mainframe, le testeur a uniquement besoin de connaître les navigations des écrans CICS. Ils sont construits sur mesure pour des applications spécifiques. Toute modification apportée au code dans COBOL, JCL, etc. Le testeur n'a pas à se soucier de l'émulateur installé sur la machine. Les modifications qui fonctionnent sur un émulateur de terminal fonctionneront sur les autres.

• L'application Mainframe (autrement appelée lot de tâches) est testée par rapport aux cas de test développés à l'aide des exigences.
• Les tests mainframe sont généralement effectués sur le code déployé à l’aide de diverses combinaisons de données définies dans le fichier d’entrée.
• Les applications qui s'exécutent sur le mainframe sont accessibles via l'émulateur de terminal. L'émulateur est le seul logiciel qui doit être installé sur la machine client.

Attributs du mainframe

1. Stockage virtuel
   1. Il s'agit d'une technique qui permet à un processeur de simuler un stockage principal supérieur à la quantité réelle de stockage réel.
   2. Il s'agit d'une technique permettant d'utiliser efficacement la mémoire pour stocker et exécuter des tâches de différentes tailles.
   3. Il utilise le stockage sur disque comme une extension du stockage réel.
2. Multiprogrammation
   1. L'ordinateur exécute plusieurs programmes en même temps. Mais à un moment donné, un seul programme peut contrôler le processeur.
   2. Il s'agit d'une fonctionnalité fournie pour utiliser efficacement le processeur.
3. Traitement par lots
   1. Il s'agit d'une technique par laquelle toute tâche est accomplie en unités appelées emplois.
   2. Une tâche peut provoquer l'exécution d'un ou plusieurs programmes dans une séquence.
   3. Le planificateur de tâches prend une décision sur l'ordre dans lequel les tâches doivent être exécutées. Pour maximiser le débit moyen, les tâches sont planifiées en fonction de leur priorité et de leur classe.
   4. Les informations nécessaires au traitement par lots sont fournies via JCL (JOB CONTROL LANGUAGE). JCL décrit le travail par lots : programmes, données et ressources nécessaires.
4. Partage de temps
   1. Dans un système à temps partagé, chaque utilisateur a accès au système via le terminal. Au lieu de soumettre des tâches dont l'exécution est planifiée ultérieurement, l'utilisateur saisit des commandes qui sont traitées immédiatement.
   2. C’est ce qu’on appelle « traitement interactif ». Il permet à l'utilisateur d'interagir directement avec l'ordinateur.
   3. Le traitement en temps partagé est appelé « traitement en premier plan » et le traitement par lots est appelé « traitement en arrière-plan ».
5. Spouling
   1. SPOOLing signifie Périphérique simultané Operaen ligne.
   2. Le périphérique SPOOL est utilisé pour stocker la sortie du programme/de l'application. La sortie spoolée est dirigée vers des périphériques de sortie comme une imprimante (si nécessaire).
   3. Il s'agit d'une installation exploitant l'avantage de la mise en mémoire tampon pour utiliser efficacement les périphériques de sortie.

Classification des tests manuels dans le mainframe

Unité centrale Test manuel peut être classé en deux types :

1. Tests de tâches par lots -

• Le processus de test implique l'exécution de tâches par lots pour la fonctionnalité implémentée dans la version actuelle.
• Les résultats des tests extraits des fichiers de sortie et de la base de données sont vérifiés et enregistrés.

2. Tests en ligne -

• Les tests en ligne font référence aux tests des écrans CICS, similaires aux tests de la page Web.
• La fonctionnalité des écrans existants pourrait être modifiée ou de nouveaux écrans pourraient être ajoutés.
• Diverses applications peuvent avoir des écrans de demande et des écrans de mise à jour. La fonctionnalité de ces écrans doit être vérifiée dans le cadre des tests en ligne.

Comment faire des tests sur le mainframe

1. L’équipe Business prépare les documents d’exigences. Ce qui détermine la manière dont un élément ou un processus particulier va être modifié au cours du cycle de publication.
2. L'équipe de test et le développement reçoivent le document d'exigence. Ils détermineront combien de processus seront affectés par le changement. Habituellement, dans une version, seulement 20 à 25 % de l'application est directement affectée par l'exigence personnalisée. Les 75 % restants de la version seront destinés aux fonctionnalités prêtes à l'emploi, telles que le test des applications et des processus.
3. Ainsi, une application Mainframe doit être testée en deux parties :
   1. Conditions de test – Tester l’application pour la fonctionnalité ou le changement mentionné dans le document d’exigence.
   2. Intégration des tests – Tester l’ensemble du processus ou une autre application qui reçoit ou envoie des données à l’application concernée. Les tests de régression est l’objectif principal de cette activité de test.

Outils de test d'automatisation du mainframe

Vous trouverez ci-dessous la liste des outils pouvant être utilisés pour le mainframe Tests d'automatisation.

• REXX
• Excel
• QTP

Méthodologie des tests mainframe

Prenons un exemple : une compagnie d'assurance XYZ dispose d'un module d'inscription des membres. Il prend les données à la fois de l’écran d’inscription des membres et de l’inscription hors ligne. Comme nous l'avons vu précédemment, il faut deux approches pour les tests Mainframe, les tests en ligne et les tests par lots.

• Test en ligne se fait sur l’écran d’inscription des membres. Tout comme une page Web, la base de données est validée avec les données saisies via les écrans.
• Inscription hors ligne peut être une inscription papier ou une inscription sur un site Web tiers. Les données hors ligne (également appelées lots) seront saisies dans la base de données de l'entreprise via des tâches par lots. Un fichier plat d'entrée est préparé selon le format de données prescrit et transmis à la séquence de tâches par lots. Ainsi, pour les tests d’applications mainframe, nous pouvons utiliser l’approche suivante.
• Le premier travail de la ligne des travaux par lots valide les données saisies. Disons par exemple des caractères spéciaux, des alphabets dans des champs numériques uniquement, etc.
• La deuxième tâche valide la cohérence des données en fonction des conditions commerciales. Par exemple, l'inscription d'un enfant ne doit pas contenir de données dépendantes, de code postal du membre (qui n'est pas disponible pour le service par le plan inscrit), etc.
• Le troisième travail modifie les données dans le format pouvant être saisi dans la base de données. Par exemple, supprimer le nom du plan (la base de données ne stockera que l'identifiant du plan et le nom du plan d'assurance), ajouter la date d'entrée, etc.
• Le quatrième travail charge les données dans la base de données.
• Tests de tâches par lots se fait sur ce processus en deux phases –
• Chaque travail est validé séparément et le
• L'intégration entre les tâches est validée en fournissant un fichier plat d'entrée au premier travail et en validant la base de données. (Les résultats intermédiaires doivent être validés pour plus de prudence)

Voici la méthode suivie pour les tests Mainframe :

Étape 1) Lit de fortune/Test de fumée

L'objectif principal de cette étape est de valider si le code déployé se trouve dans le bon environnement de test. Cela garantit également qu’il n’y a aucun problème critique avec le code.

Étape 2) Test du système

Vous trouverez ci-dessous les types de tests effectués dans le cadre des tests système.

1. Tests par lots – Ces tests seront effectués en validant les résultats des tests sur les fichiers de sortie et les modifications de données effectuées par les travaux par lots dans le cadre des tests et en les enregistrant.
2. Tests en ligne – Ces tests seront effectués sur le front-end de l’application mainframe. Ici, l'application est testée pour vérifier les champs de saisie corrects comme un plan d'assurance, les intérêts sur le plan, etc.
3. Tests d'intégration par lots en ligne – Ces tests seront effectués sur les systèmes ayant des processus par lots et une application en ligne. Le flux de données et l'interaction entre les écrans en ligne et les travaux par lots sont validés.

   (Exemple pour ce type de test – Envisagez une mise à jour des détails du plan comme l’augmentation du taux d’intérêt. Le changement d'intérêt s'effectue sur un écran de mise à jour et les détails du solde des comptes concernés ne seront modifiés que par un travail par lots nocturne. Dans ce cas, les tests seront effectués en validant l'écran des détails du plan et le travail par lots exécuté pour mettre à jour tous les comptes).

4. Test de base de données – Les bases de données où les données de l'application mainframe (IMS, IDMS, DB2, VSAM/ISAM, Sequential datasets, GDGs) sont validées pour leur mise en page et le stockage des données.

Étape 3) Système Test d'intégration

L'objectif principal de ces tests est de valider la fonctionnalité des systèmes qui interagissent avec le système testé.

Ces systèmes ne sont pas directement concernés par les exigences. Cependant, ils utilisent les données du système testé. Il est important de tester l'interface et les différents types de messages (comme la tâche réussie, l'échec de la tâche, la base de données mise à jour, etc.) qui peuvent éventuellement circuler entre les systèmes et les actions résultantes prises par les systèmes individuels.

Les types de tests effectués à cette étape sont

1. Tests par lots
2. Tests en ligne
3. En ligne – Tests d’intégration par lots

Étape 4) Les tests de régression

Les tests de régression sont une phase courante dans tout type de projet de test. Ces tests dans les mainframes garantissent que les travaux par lots et les écrans en ligne qui n'interagissent pas directement avec le système testé (ou n'entrent pas dans le champ d'application des exigences) ne sont pas affectés par la version actuelle du projet.

Afin d'avoir des tests de régression efficaces, un ensemble particulier de cas de test doit être présélectionné en fonction de leur complexité et un lit de régression (référentiel de cas de test) doit être créé. Cet ensemble doit être mis à jour chaque fois qu’une nouvelle fonctionnalité est déployée dans la version.

Étape 5) Test de performance

Ces tests sont effectués pour identifier les goulots d'étranglement dans les domaines très touchés tels que les données frontales, la mise à niveau des bases de données en ligne et pour projeter l'évolutivité de l'application.

Étape 6) Test de sécurité

Ces tests sont effectués pour évaluer dans quelle mesure l'application est conçue et développée pour contrer les attaques anti-sécurité.

Deux tests de sécurité doivent être effectués sur le système : sécurité du mainframe et sécurité du réseau.

Les fonctionnalités qui doivent être testées sont

1. Integrity
2. Confidentialité
3. Autorisation
4. Authentification
5. Disponibilité

Étapes impliquées dans les tests par lots

1. Une fois que l'équipe d'assurance qualité a reçu le package approuvé (le package contient des procédures, du JCL, des cartes de contrôle, des modules, etc.), le testeur doit prévisualiser et récupérer le contenu dans PDS selon les besoins.
2. Convertissez le JCL de production ou le JCL de Développement en JCL QA autrement appelé JOB SETUP.
3. Copie du fichier de production et préparation des fichiers de test.
4. Pour chaque fonctionnalité, une séquence de tâches sera définie. (Comme expliqué dans l'exemple dans la section Méthodologie dans Mainframe). Les tâches doivent être soumises à l'aide de la commande SUB avec les fichiers de données de test.
5. Vérifiez le fichier intermédiaire afin d'identifier les raisons des données manquantes ou erronées.
6. Vérifiez le fichier de sortie final, la base de données et le Spool pour valider les résultats du test.
7. Si le travail échoue, le spool aura la raison de l'échec du travail. Corrigez l’erreur et soumettez à nouveau le travail.

Rapports de tests – Défaut doit être enregistré si le résultat réel s’écarte de celui attendu.

Étapes impliquées dans les tests en ligne

1. Sélectionnez l'écran En ligne dans un environnement de test.
2. Testez chaque champ pour les données acceptables.
3. Testez le Scénario de test sur l'écran.
4. Vérifiez la base de données pour les mises à jour des données à partir de l'écran en ligne.

Rapport de test – Le défaut doit être enregistré si le résultat réel s’écarte de celui attendu.

Étapes impliquées dans les tests d’intégration en ligne – par lots

1. Exécutez le travail dans un Environnement de test et validez les données sur les écrans en ligne.
2. Mettez à jour les données sur les écrans en ligne et vérifiez si le travail par lots est correctement exécuté avec les données mises à jour.

Commandes utilisées dans les tests mainframe

1. SOUMETTRE – Soumettez un travail en arrière-plan.
2. ANNULER – Annuler le travail en arrière-plan.
3. ALLOCATE – Allouer un ensemble de données
4. COPIER – Copier un ensemble de données
5. RENAME – Renommer l'ensemble de données
6. SUPPRIMER – Supprimer l’ensemble de données
7. JOB SCAN – Pour lier le JCL au programme, aux bibliothèques, au fichier, etc. sans l'exécuter.

Il existe de nombreuses autres commandes utilisées lorsque cela est nécessaire, mais elles ne sont pas si fréquentes.

Pré-requis pour démarrer les tests mainframe

Les détails de base nécessaires pour les tests sur le mainframe sont :

• Identifiant de connexion et mot de passe pour se connecter à l'application.
• Brève connaissance des commandes ISPF.
• Noms des fichiers, qualificatif de fichier et leurs types.

Avant de commencer les tests sur le mainframe, les aspects ci-dessous doivent être vérifiés.

1. Emploi
   1. Effectuez une analyse du travail (Commande – JOBSCAN) pour vérifier les erreurs avant de l’exécuter.
   2. Le paramètre CLASS doit pointer vers la classe de test.
   3. Dirigez la sortie du travail vers un spool ou un JHS ou selon les besoins à l'aide du paramètre MSGCLASS.
   4. Redirigez l'e-mail du travail vers un spool ou un ID d'e-mail de test.
   5. Commentez les étapes FTP pour les tests initiaux, puis pointez le travail vers un serveur de test.
   6. Dans le cas où un IMR (Incident Management record) est généré dans le travail, ajoutez simplement le commentaire « TESTING PURPOSE » dans le travail ou la carte de paramètre.
   7. Toutes les bibliothèques de production du travail doivent être modifiées et pointées vers des bibliothèques de test.
   8. Le travail ne doit pas être laissé sans surveillance.
   9. Pour empêcher le travail de s'exécuter dans une boucle infinie en cas d'erreur, le paramètre TIME doit être ajouté avec l'heure spécifiée.
   10. Enregistrez le résultat du travail, y compris le spool. La bobine peut être enregistrée à l'aide de XDC.

2. Fichier
   1. Créez un fichier de test de la taille nécessaire uniquement. Utilisez des GDG (Groupes de données de génération – Fichiers portant le même nom mais avec des numéros de version séquentiels – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00, etc.) lorsque cela est nécessaire pour stocker des données dans des fichiers consécutifs portant le même nom.
   2. Le paramètre DISP (Disposition – décrit le système permettant de conserver ou de supprimer l'ensemble de données après la fin normale ou anormale de l'étape ou du travail) pour les fichiers doit être codé correctement.
   3. Assurez-vous que tous les fichiers utilisés pour l'exécution du travail sont enregistrés et fermés correctement pour empêcher le travail de passer en HOLD.
   4. Lors des tests à l'aide des GDG, assurez-vous que la bonne version est indiquée.
3. Base de données
   1. Lors de l'exécution du travail ou du programme en ligne, assurez-vous que des données involontaires ne sont pas insérées, mises à jour ou supprimées.
   2. Assurez-vous également que la région DB2 correcte est utilisée pour les tests.
4. Cas de test
   1. Testez toujours les conditions limites telles que – Fichier vide, Traitement du premier enregistrement, Traitement du dernier enregistrement, etc.
   2. Incluez toujours les conditions de test positives et négatives.
   3. Dans le cas où des procédures standard sont utilisées dans le programme comme le redémarrage du point de contrôle, les modules de fin anormale, les fichiers de contrôle, etc., incluez des cas de test pour valider si les modules ont été utilisés correctement.
5. Données de test
   1. La configuration des données de test doit être effectuée avant le début des tests.
   2. Ne modifiez jamais les données de la région de test sans en informer. Il se peut que d'autres équipes travaillent avec les mêmes données et leur test échouerait.
   3. Si les fichiers de production sont nécessaires pendant l'exécution, une autorisation appropriée doit être obtenue avant de les copier ou de les utiliser.

Meilleures pratiques

1. En cas d'exécution d'un travail par lots, MAX CC 0 est un indicateur que le travail a été exécuté avec succès. Cela ne signifie pas que la fonctionnalité fonctionne correctement. Le travail s'exécutera avec succès même si la sortie est vide ou non conforme aux attentes. Il est donc toujours prévu de vérifier toutes les sorties avant de déclarer le travail réussi.
2. C'est toujours une bonne pratique d'effectuer un essai à sec du travail testé. L'exécution à sec est effectuée avec des fichiers d'entrée vides. Ce processus doit être suivi pour les tâches affectées par les modifications apportées au cycle de test.
3. Avant le début du cycle de test, la configuration du travail de test doit être effectuée longtemps à l'avance. Cela aidera à découvrir à l'avance toute erreur JCL, permettant ainsi de gagner du temps lors de l'exécution.
4. Lors de l'accès aux tables DB2 via SPUFI (option sur l'émulateur pour accéder aux tables DB2), définissez toujours la validation automatique sur « NON » afin d'éviter les mises à jour accidentelles.
5. La disponibilité des données de test est le principal défi des tests par lots. Les données requises doivent être créées bien avant le cycle de test et leur exhaustivité doit être vérifiée.
6. Certaines transactions en ligne et tâches par lots peuvent écrire des données dans des MQ (Message Queue) pour transmettre des données à d'autres applications. Si les données ne sont pas valides, cela peut désactiver/arrêter les MQ, cela affectera l'ensemble du processus de test. C'est une bonne pratique de vérifier que les MQ fonctionnent correctement après les tests.

Tests mainframe Défis et dépannage

Défis	Approche
Exigences incomplètes/peu claires Il peut y avoir accès au manuel d'utilisation/guide de formation, mais ceux-ci ne sont pas les mêmes que les exigences documentées.	Les testeurs doivent être impliqués dans le SDLC dès la phase des exigences. Cela aidera à vérifier si les exigences sont testables.
Configuration/identification des données Il peut y avoir des situations dans lesquelles les données existantes doivent être réutilisées conformément aux exigences. Il est parfois difficile d'identifier les données requises à partir des données existantes.	Pour la configuration des données, des outils développés en interne peuvent être utilisés selon les besoins. Pour récupérer des données existantes, les requêtes doivent être créées à l'avance. En cas de difficulté, une demande peut être adressée à l'équipe de gestion des données pour créer ou cloner les données requises.
Configuration du travail Une fois les tâches récupérées dans PDS, elles doivent être configurées dans la région QA. Afin que les travaux ne soient pas soumis avec un qualificatif de production ou des détails de chemin.	Les outils de configuration des tâches doivent être utilisés de manière à surmonter les erreurs humaines commises lors de la configuration.
Demande ponctuelle Il peut y avoir des situations où les tests de bout en bout doivent être pris en charge en raison d'un problème d'application en amont ou en aval. Ces demandes augmentent le temps et les efforts du cycle d’exécution.	L'utilisation de scripts d'automatisation, de scripts de régression et de scripts squelettes pourrait aider à réduire le temps et les efforts nécessaires.
Publications à temps pour changement de périmètre Il peut arriver que l'impact du code modifie complètement l'apparence du système. Cela peut nécessiter une modification des scénarios de test, des scripts et des données.	Un processus de gestion des changements de portée et une analyse d’impact doivent être en place.

Abends courants rencontrés

1. S001 – Une erreur d'E/S s'est produite.

   Raison – Lecture à la fin du fichier, erreur de longueur de fichier, tentative d'écriture dans un fichier en lecture seule.

2. S002 – Enregistrement d'E/S invalide.

   Raison – Tentative d'écriture d'un enregistrement plus long que la longueur de l'enregistrement.

3. S004 – Une erreur s'est produite lors de l'OUVERTURE.

   Raison – DCB invalide

4. S013 – Erreur lors de l'ouverture d'un ensemble de données.

   Raison – Le membre PDS n'existe pas, la longueur de l'enregistrement dans le programme ne correspond pas à la longueur réelle de l'enregistrement.

5. S0C1 – OperaException

   Raison – Impossible d'ouvrir le fichier, carte DD manquante

6. S0C4 – Exception de protection/violation de stockage
7. Raison – Tentative d’accès au stockage non disponible pour le programme.
8. S0C7 – Exception de vérification du programme – Données
9. Raison – Modification du cliché d'enregistrement ou du cliché de fichier.
10. Sx22 – Le travail a été annulé
11. S222 – Travail annulé par l'utilisateur sans dump.
12. S322 – Le temps du travail ou de l'étape a dépassé la limite spécifiée, ou le programme est dans une boucle ou un paramètre de temps insuffisant.
13. S522 – Expiration du délai de session TSO.
14. S806 – Impossible de lier ou de charger.

    Raison – L'ID de travail ne parvient pas à trouver le module de chargement spécifié.

15. S80A – Pas assez de stockage virtuel pour satisfaire les requêtes GETMAIN ou FREEMAIN.
16. S913 – Tentative d'accès à l'ensemble de données auquel l'utilisateur n'est pas autorisé.
17. Sx37 – Impossible d'allouer suffisamment de stockage à l'ensemble de données.

Assistance aux erreurs – Un outil très populaire pour obtenir des informations détaillées sur différents types de dépassements anormaux.

Problème courant rencontré lors des tests sur le mainframe

• Fins anormales des tâches – Pour réussir le travail, vous devez vérifier les données, le fichier d’entrée et les modules présents ou non à l’emplacement spécifique. Des anomalies peuvent survenir pour plusieurs raisons, la plus courante étant : données invalides, champ de saisie incorrect, incohérence de date, problèmes environnementaux, etc.
• Fichier de sortie vide–Bien que la tâche puisse s'exécuter correctement (MaxCC 0), le résultat peut ne pas être celui attendu. Ainsi, avant de réussir un scénario de test, le testeur doit s'assurer que la sortie est vérifiée de manière croisée. Ensuite seulement, continuez.
• Fichier d'entrée vide – Dans certaines applications, les fichiers seront reçus des processus en amont. Avant d'utiliser le fichier reçu pour tester l'application actuelle, les données doivent être vérifiées par recoupement pour éviter toute réexécution et retouche.

Résumé

• Les tests mainframe sont comme toute autre procédure de test, depuis la collecte des exigences, la conception des tests, l'exécution des tests et le rapport des résultats.
• Afin de tester efficacement l'application, le testeur doit participer aux réunions de conception programmées par les équipes de développement et commerciales.
• Il est obligatoire pour le testeur de s'habituer aux différentes fonctions de test du mainframe. Comme la navigation sur écran, la création de fichiers et de PDS, l'enregistrement des résultats de test, etc. avant le début du cycle de test.
• Les tests d’applications mainframe sont un processus qui prend du temps. Un calendrier de test clair doit être suivi pour la conception des tests, la configuration des données et l'exécution.
• Les tests par lots et les tests en ligne doivent être effectués efficacement sans manquer aucune fonctionnalité mentionnée dans le document d'exigence, et non Cas de test devrait être épargné.