Avant d'apprendre les concepts de test mainframe, apprenons
Qu'est-ce qu'un mainframe?
Le mainframe est un système informatique haute performance et haute vitesse. Il est utilisé à des fins informatiques à plus grande échelle qui nécessitent une grande disponibilité et une grande 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.
Essais mainframe
Mainframe Testing est un processus de test des applications logicielles et des services basés sur les systèmes Mainframe. Le but des tests mainframe est de garantir les performances, la fiabilité et la qualité de l'application ou du service logiciel par des méthodes de vérification et de validation et de vérifier s'il est prêt à être déployé.
Lors de l'exécution des tests Mainframe, le testeur a seulement besoin de connaître les navigations des écrans CICS. Ils sont conçus sur mesure pour des applications spécifiques. Toute modification apportée au code dans le testeur COBOL, JCL, etc. n'a pas à se soucier de l'émulateur configuré sur la machine. Les modifications qui fonctionnent sur un émulateur de terminal fonctionneront sur d'autres.
- L'application Mainframe (autrement appelée lot de travaux) est testée par rapport aux cas de test développés à l'aide d'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 à installer sur la machine cliente.
Dans ce tutoriel pour débutants, vous apprendrez-
- Attributs mainframe
- Classification des tests manuels dans le mainframe
- Comment faire des tests mainframe
- Outils de test d'automatisation mainframe
- Méthodologie des tests mainframe
- Étapes impliquées dans les tests par lots
- Étapes impliquées dans les tests en ligne
- Étapes impliquées dans les tests d'intégration en ligne - Batch
- Commandes utilisées dans les tests mainframe
- Conditions préalables pour démarrer les tests mainframe
- Les meilleures pratiques
- Défis et dépannage des tests mainframe
- Abends courants rencontrés
- Problème courant rencontré lors des tests mainframe
Attributs mainframe
- Stockage virtuel
- C'est une technique qui permet à un processeur de simuler un stockage principal plus grand que la quantité réelle de stockage réel.
- C'est une technique pour utiliser efficacement la mémoire pour stocker et exécuter des tâches de différentes tailles.
- Il utilise le stockage sur disque comme une extension du stockage réel.
- Multiprogrammation
- L'ordinateur exécute plusieurs programmes en même temps. Mais à tout moment, un seul programme peut avoir le contrôle du CPU.
- Il s'agit d'une installation fournie pour utiliser efficacement le processeur.
- Le traitement par lots
- C'est une technique par laquelle toute tâche est accomplie dans des unités appelées emplois.
- Un travail peut entraîner l'exécution d'un ou de plusieurs programmes dans une séquence.
- Le planificateur de travaux décide de l'ordre dans lequel les travaux doivent être exécutés. Pour maximiser le débit moyen, les travaux sont planifiés en fonction de leur priorité et de leur classe.
- Les informations nécessaires pour le traitement par lots sont fournies via JCL (JOB CONTROL LANGUAGE). JCL décrit le travail par lots - programmes, données et ressources nécessaires.
- Partage de temps
- Dans un système à temps partagé, chaque utilisateur a accès au système via le terminal. Au lieu de soumettre des travaux planifiés pour une exécution ultérieure, l'utilisateur entre des commandes qui sont traitées immédiatement.
- C'est ce qu'on appelle donc le «traitement interactif». Il permet à l'utilisateur d'interagir directement avec l'ordinateur.
- Le traitement en temps partagé est appelé «traitement au premier plan» et le traitement des travaux par lots est appelé «traitement en arrière-plan».
- Spooling
- SPOOLing signifie Simultaneous Peripheral Operations Online .
- Le dispositif SPOOL est utilisé pour stocker la sortie du programme / application. La sortie spoule est dirigée vers des périphériques de sortie comme une imprimante (si nécessaire).
- Il s'agit d'une fonction 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
Les tests manuels mainframe peuvent être classés en deux types:
- Test des travaux par lots -
- Le processus de test implique des exécutions de travaux par lots pour la fonctionnalité implémentée dans la version actuelle.
- Le résultat du test extrait des fichiers de sortie et de la base de données est vérifié et enregistré.
- Test en ligne -
- Le test en ligne fait référence au test des écrans CICS, ce qui est similaire au test 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 d'enquête 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 mainframe
- L'équipe commerciale prépare les documents d'exigence. Ce qui détermine la manière dont un élément ou un processus particulier va être modifié dans le cycle de publication.
- 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, seuls 20 à 25% de l'application sont directement affectés par l'exigence personnalisée. Les 75% restants de la version seront destinés aux fonctionnalités standard telles que le test des applications et des processus.
- Ainsi, une application Mainframe doit être testée en deux parties:
- Exigences de test - Test de l'application pour la fonctionnalité ou le changement mentionné dans le document d'exigence.
- Tester l'intégration - 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 sont le principal objectif de cette activité de test.
Outils de test d'automatisation mainframe
Vous trouverez ci-dessous la liste des outils qui peuvent être utilisés pour les tests d'automatisation mainframe.
- REXX
- Exceller
- QTP
Méthodologie des tests mainframe
Prenons un exemple: une compagnie d'assurance XYZ a 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.
- Les tests en ligne sont effectués sur l'écran d'inscription des membres. Tout comme une page Web, la base de données est validée avec des données saisies à travers les écrans.
- L'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 travaux par lots. Un fichier plat d'entrée est préparé selon le format de données prescrit et envoyé à la séquence de travaux par lots. Ainsi, pour les tests d'applications mainframe, nous pouvons utiliser l'approche suivante.
- Le premier job de la ligne des jobs batch valide les données saisies. Disons par exemple un caractère spécial, des alphabets dans des champs numériques uniquement, etc.
- Le second job valide la cohérence des données en fonction des conditions commerciales. Par exemple, une inscription enfant ne doit pas contenir de données dépendantes, le 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 qui peut être entré dans la base de données. Par exemple, la suppression du nom du plan (la base de données ne stockera que l'ID du plan et le nom du plan d'assurance), l'ajout de la date d'entrée, etc.
- Le quatrième travail charge les données dans la base de données.
- Les tests par lots sont effectués sur ce processus en deux phases -
- Chaque travail est validé séparément, et le
- L'intégration entre les travaux 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) : test Shakedown / Smoke
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 pas de problèmes critiques 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.
- Test par lots - Ce test sera effectué 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 sous la portée du test et en les enregistrant.
- Test en ligne - Ce test sera effectué sur le frontal de l'application mainframe. Ici, l'application est testée pour le champ de saisie correct comme un plan d'assurance, l'intérêt sur le plan, etc.
- Tests d'intégration en ligne par lots - 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 jobs batch 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. La modification des intérêts est effectuée sur un écran de mise à jour et les détails du solde des comptes concernés ne seront modifiés que par un traitement par lots de nuit. Test dans ce cas, cela se fera en validant l'écran Détails du plan et le travail par lots exécuté pour mettre à jour tous les comptes).
- Test de base de données - Les bases de données dans lesquelles les données de l'application mainframe (IMS, IDMS, DB2, VSAM / ISAM, jeux de données séquentiels, GDG) sont validées pour leur mise en page et le stockage des données.
Étape 3) : Test d'intégration du système
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 le travail réussi, le travail échoué, la base de données mise à jour, etc.) qui peuvent 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
- Test par lots
- Test en ligne
- En ligne - Tests d'intégration par lots
Étape 4) : Test de régression
Les tests de régression sont une phase courante dans tout type de projet de test. Ce test dans les mainframes garantit 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 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 zones à haut risque telles 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: la sécurité du mainframe et la sécurité du réseau.
Les fonctionnalités qui doivent être testées sont
- Intégrité
- Confidentialité
- Autorisation
- Authentification
- Disponibilité
Étapes impliquées dans les tests par lots
- Une fois que l'équipe d'assurance qualité a reçu le package approuvé (le package contient des procédures, le JCL, les cartes de contrôle, les modules, etc.), le testeur doit prévisualiser et récupérer le contenu dans PDS selon les besoins.
- Convertissez le JCL de production ou le JCL de développement en JCL QA, autrement appelé JOB SETUP.
- Copie du fichier de production et préparation des fichiers de test.
- Pour chaque fonctionnalité, une séquence de tâches sera définie. (Comme expliqué dans l'exemple de la section Méthodologie dans la section Mainframe.) Les travaux doivent être soumis à l'aide de la commande SUB avec les fichiers de données de test.
- Vérifiez le fichier intermédiaire afin d'identifier les raisons des données manquantes ou manquantes.
- Vérifiez le fichier de sortie final, la base de données et le Spool pour valider les résultats du test.
- Si le travail échoue, le spool aura la raison de l'échec du travail. Corrigez l'erreur et soumettez à nouveau le travail.
Rapport de test - Les défauts doivent être enregistrés si le résultat réel s'écarte des attentes.
Étapes impliquées dans les tests en ligne
- Sélectionnez l'écran En ligne dans un environnement de test.
- Testez chaque champ pour les données acceptables.
- Testez le scénario de test à l'écran.
- Vérifiez la base de données pour les mises à jour des données à partir de l'écran en ligne.
Rapport de test - Les défauts doivent être enregistrés si le résultat réel s'écarte des attentes.
Étapes impliquées dans les tests d'intégration en ligne - Batch
- Exécutez le travail dans un environnement de test et validez les données sur les écrans en ligne.
- 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
- SOUMETTRE - Soumettez un travail d'arrière-plan.
- ANNULER - Annule le travail en arrière-plan.
- ALLOCATE - Allouer un ensemble de données
- COPY - Copier un jeu de données
- RENAME - Renommer l'ensemble de données
- SUPPRIMER - Supprimer l'ensemble de données
- JOB SCAN -Pour lier le JCL avec le programme, les bibliothèques, le fichier, etc. sans l'exécuter.
Il existe de nombreuses autres commandes utilisées en cas de besoin, mais elles ne sont pas si fréquentes.
Conditions préalables pour démarrer les tests mainframe
Les détails de base nécessaires pour les tests mainframe sont:
- ID de connexion et mot de passe pour la connexion à l'application.
- Brève connaissance des commandes ISPF.
- Noms des fichiers, qualificatif de fichier et leurs types.
Avant de commencer les tests mainframe, les aspects ci-dessous doivent être vérifiés.
- Travail
- Effectuez une analyse des tâches (Commande - JOBSCAN) pour vérifier les erreurs avant de l'exécuter.
- Le paramètre CLASS doit pointer vers la classe de test.
- Dirigez la sortie du travail dans un spool ou un JHS ou selon les besoins à l'aide du paramètre MSGCLASS.
- Réacheminez l'e-mail de la tâche vers le spoule ou un ID de messagerie de test.
- Commentez les étapes FTP pour le test initial, puis pointez le travail vers un serveur de test.
- Dans le cas où un IMR (enregistrement de gestion des incidents) est généré dans la tâche, ajoutez simplement le commentaire «OBJECTIF DU TEST» dans la carte de tâche ou de paramètre.
- Toutes les bibliothèques de production du travail doivent être modifiées et dirigées vers des bibliothèques de test.
- Le travail ne doit pas être laissé sans surveillance.
- 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.
- Enregistrez la sortie du travail, y compris le spool. La bobine peut être enregistrée à l'aide de XDC.
- Déposer
- Créez uniquement un fichier de test de la taille requise. Utilisez des GDG (Generation Data Groups - Files avec 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 avec le même nom.
- Le paramètre DISP (Disposition - décrit le système pour effectuer la conservation ou la suppression de l'ensemble de données après l'arrêt normal ou anormal de l'étape ou de la tâche) pour les fichiers doit être codé correctement.
- 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.
- Lors du test à l'aide de GDG, assurez-vous que la bonne version est pointée.
- Base de données
- Lors de l'exécution du travail ou du programme en ligne, assurez-vous qu'aucune donnée involontaire n'est insérée, mise à jour ou supprimée.
- Assurez-vous également que la région DB2 correcte est utilisée pour les tests.
- Cas de test
- Testez toujours les conditions aux limites telles que - Fichier vide, Traitement du premier enregistrement, Traitement du dernier enregistrement, etc.
- Incluez toujours les conditions de test positives et négatives.
- 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 Abend, les fichiers de contrôle, etc., incluez des cas de test pour valider si les modules ont été utilisés correctement.
- Données de test
- La configuration des données de test doit être effectuée avant le début des tests.
- Ne modifiez jamais les données de la zone de test sans notification. Il peut y avoir d'autres équipes travaillant avec les mêmes données et leur test échouerait.
- Dans le cas où 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.
Les meilleures pratiques
- Dans le cas d'une exécution de tâche par lots, MAX CC 0 est un indicateur que la tâche a été exécutée avec succès. Cela ne signifie pas que la fonctionnalité fonctionne correctement. Le travail s'exécutera avec succès même lorsque la sortie est vide ou non selon les attentes. Il est donc toujours attendu de vérifier toutes les sorties avant de déclarer le travail réussi.
- C'est toujours une bonne pratique de faire un essai à sec du travail à tester. L'essai à sec est effectué 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.
- Avant le début du cycle de test, la configuration du travail de test doit être effectuée bien à l'avance. Cela aidera à détecter toute erreur JCL à l'avance, ce qui permettra de gagner du temps lors de l'exécution.
- 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.
- 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 doivent être vérifiées pour leur exhaustivité.
- Certaines transactions en ligne et certains travaux 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, ce qui affectera l'ensemble du processus de test. Il est recommandé de vérifier que les MQ fonctionnent correctement après les tests.
Défis et dépannage des tests mainframe
| Défis | Approcher |
| Exigences incomplètes / peu claires Il peut y avoir accès au manuel de l'utilisateur / guide de formation, mais ce ne sont pas les mêmes que les exigences documentées. | Les testeurs doivent être impliqués dans le SDLC à partir de la phase des exigences. Cela aidera à vérifier si les exigences sont testables. |
| Configuration / identification des données Il peut y avoir des situations où les données existantes doivent être réutilisées conformément à l'exigence. Il est parfois difficile d'identifier les données requises à partir des données existantes. | Pour la configuration des données, des outils locaux 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 la création ou le clonage des données requises. |
| Configuration des tâches Une fois les tâches récupérées dans PDS, la tâche doit être configurée dans la région QA. Pour 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 afin de surmonter les erreurs humaines commises lors de la configuration. |
| Requête ad hoc Il peut y avoir des situations où des tests de bout en bout doivent être pris en charge en raison d'un problème lié à des problèmes d'application en amont ou en aval. Ces demandes augmentent le temps et les efforts dans le 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. |
| Versions à temps pour le changement de portée Il peut y avoir une situation où l'impact du code peut complètement changer l'apparence et la convivialité du système. Cela peut nécessiter une modification des cas de test, des scripts et des données. | Un processus de gestion du changement de périmètre et une analyse d'impact doivent être en place. |
Abends courants rencontrés
- 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.
- S002 - Enregistrement d'E / S non valide.
Raison - Tentative d'écriture d'un enregistrement plus long que la longueur de l'enregistrement.
- S004 - Une erreur s'est produite pendant OPEN.
Raison - DCB non valide
- S013 - Erreur lors de l'ouverture d'un jeu de données.
Raison - Le membre PDS n'existe pas, la longueur d'enregistrement dans le programme ne correspond pas à la longueur d'enregistrement réelle.
- S0C1 - Exception de fonctionnement
Raison - Impossible d'ouvrir le fichier, carte DD manquante
- S0C4 - Exception de protection / violation de stockage
- Raison - Tentative de stockage d'accès non disponible pour le programme.
- SC07 - Exception de vérification de programme - Données
- Raison - Changement de cliché d'enregistrement ou de mise en page de fichier
- Sx22 - Le travail a été annulé
- S222 - Travail annulé par l'utilisateur sans vidage.
- S322 - Le temps de travail ou d'étape a dépassé la limite spécifiée, ou le programme est dans une boucle ou le paramètre de temps est insuffisant.
- S522 - Délai d'expiration de la session TSO.
- S806 - Impossible de lier ou de charger.
Raison - L'ID de tâche n'a pas pu trouver le module de chargement spécifié
- S80A - Stockage virtuel insuffisant pour satisfaire les demandes GETMAIN ou FREEMAIN.
- S913 - Tentative d'accès à l'ensemble de données auquel l'utilisateur n'est pas autorisé.
- Sx37 - Impossible d'allouer suffisamment de stockage à l'ensemble de données.
Error Assist - Un outil très populaire pour obtenir des informations détaillées sur différents types de fins anormales.
Problème courant rencontré lors des tests mainframe
- Job Abends - Pour une exécution réussie du travail, vous devez vérifier les données, le fichier d'entrée et les modules présents à l'emplacement spécifique ou non. Les échecs peuvent être rencontrés pour plusieurs raisons, la plus courante étant - Données invalides, champ de saisie incorrect, décalage de date, problèmes environnementaux, etc.
- Fichier de sortie vide -Bien que la tâche puisse s'exécuter avec succès (MaxCC 0), la sortie peut ne pas être comme prévu. Donc, avant de réussir un cas de test, le testeur doit s'assurer que la sortie est vérifiée de manière croisée. Alors 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 de manière croisée pour éviter une ré-exécution et une reprise.
Résumé:
- Les tests mainframe sont comme toute autre procédure de test à partir de la collecte des exigences, de la conception des tests, de l'exécution des tests et du 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 à diverses fonctions de test mainframe. Comme la navigation à l'é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.
- Le test des applications mainframe est 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 aucun scénario de test ne doit être épargné.