Test Mainframe - Tutoriel complet

Avant d'aborder les concepts de test sur mainframe, examinons d'abord la plateforme sur laquelle les tests s'exécutent.

Qu'est-ce qu'un ordinateur central ?

L'ordinateur central est un système informatique haute performance et à grande vitesse. Il est utilisé pour le calcul à grande échelle, exigeant une haute disponibilité et une sécurité renforcée. On le retrouve principalement dans des secteurs comme la finance, l'assurance, la distribution et d'autres domaines critiques où d'énormes volumes de données sont traités plusieurs fois par jour.

Tests sur mainframe

Tests sur mainframe Les tests sur mainframe sont un processus de test des applications et services logiciels reposant sur des systèmes mainframe. Leur objectif est de garantir la performance, la fiabilité et la qualité d'une application ou d'un service grâce à des méthodes de vérification et de validation, et de s'assurer qu'il est prêt à être déployé.

Lors des tests sur mainframe, le testeur doit principalement maîtriser la navigation dans les interfaces CICS. Ces interfaces sont personnalisées pour des applications spécifiques. Lorsqu'il modifie le code en COBOL, JCL et langages similaires, le testeur n'a pas à se soucier de la configuration de l'émulateur sur la machine, car les modifications fonctionnelles sur un émulateur de terminal le seront également sur les autres.

• L'application Mainframe (également appelée traitement par lots) est testée par rapport aux cas de test développés à partir 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 exécutées sur le système central sont accessibles via un émulateur de terminal. Cet émulateur est le seul logiciel à installer sur le poste client.

Étant donné que la plateforme se comporte différemment d'une pile web, il est utile de savoir quelles caractéristiques du mainframe influencent la conception des tests. Les tests sur mainframe se situent donc au même niveau que les autres. types de tests logiciels plutôt que de remplacer l'un d'entre eux.

Attributs du mainframe

1. Stockage virtuel
   • 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.
   • 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.
   • Il utilise le stockage sur disque comme une extension du stockage réel.
2. Multiprogrammation
   • L'ordinateur exécute plusieurs programmes simultanément. Cependant, à un instant donné, un seul programme peut contrôler le processeur.
   • Il s'agit d'une fonctionnalité fournie pour utiliser efficacement le processeur.
3. Traitement par lots
   • Il s'agit d'une technique par laquelle toute tâche est accomplie en unités appelées emplois.
   • Une tâche peut provoquer l'exécution d'un ou plusieurs programmes dans une séquence.
   • 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.
   • Les informations nécessaires au traitement par lots sont fournies par le JCL (JOB CONTROL LANGUAGE). Le JCL décrit le traitement par lots : programmes, données et ressources nécessaires.
4. 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 tâches dont l'exécution est planifiée ultérieurement, l'utilisateur saisit des commandes qui sont traitées immédiatement.
   • C’est ce qu’on appelle « traitement interactif ». Il permet à l'utilisateur d'interagir directement avec l'ordinateur.
   • 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
   • SPOOLing signifie Simultaneous Peripheral Operations en ligne.
   • Le périphérique SPOOL sert à stocker la sortie d'un programme ou d'une application. Cette sortie est ensuite dirigée vers des périphériques de sortie, comme une imprimante (le cas échéant).
   • 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

Ces attributs divisent le travail de test manuel sur le mainframe en deux flux clairement distincts.

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

1. Tests de traitement par lots —

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

2. Tests en ligne —

• Les tests en ligne font référence aux tests des écrans CICS, ce qui est similaire aux tests d'une 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 effectuer des tests sur mainframe

1. L'équipe commerciale prépare les documents d'exigences, qui déterminent comment un élément ou un processus particulier va être modifié au cours du cycle de mise en production.
2. L'équipe de test et l'équipe de développement reçoivent le cahier des charges. Elles déterminent le nombre de processus impactés par la modification. Généralement, lors d'une mise en production, seulement 20 à 25 % de l'application est directement affectée par la personnalisation. Les 75 à 80 % restants sont consacrés aux fonctionnalités standard, notamment aux tests des applications et processus environnants.
3. Ainsi, une application Mainframe doit être testée en deux parties :
   • Conditions de test — Tester l'application pour vérifier la fonctionnalité ou la modification mentionnée dans le document d'exigences.
   • Intégration des tests — Tester l'ensemble du processus ou d'autres applications qui reçoivent ou envoient 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 — le langage de script fourni avec z/OS, largement utilisé pour gérer la soumission de tâches répétitives et les contrôles de sortie.
• Excel — utilisé avec des macros pour construire, comparer et générer des rapports sur les données de test et les fichiers de sortie.
• OpenText UFT Un — le nom actuel de l'outil que l'industrie appelle encore QTP ou QuickTest Professional ; il automatise les écrans de terminal 3270.
• Galasa — un logiciel libre, Cadre de test d'intégration approfondie du projet Open Mainframe qui pilote 3270 écrans, des traitements par lots JCL et Db2 à partir d'un pipeline CI/CD.
• Suites de tests z/OS du fournisseur - IBM Test Accelerator for Z et BMC AMI DevX Total Test couvrent les tests unitaires COBOL et les environnements de test virtualisés.

Quel que soit l'outil choisi, il ne sera rentable que s'il est entretenu. cadre d'automatisation des tests plutôt qu'une pile de scripts épars.

Méthodologie des tests mainframe

Prenons l'exemple d'une compagnie d'assurance, XYZ, qui dispose d'un module d'inscription des membres. Ce module collecte les données à la fois via l'écran d'inscription et via l'inscription hors ligne. Comme indiqué précédemment, deux approches sont utilisées pour les tests sur mainframe : les tests en ligne et les tests par lots.

• Les tests en ligne sont effectués sur l'écran d'inscription des membres. À l'instar d'une page web, la base de données est validée à l'aide des données saisies via les écrans.
• L'inscription hors ligne peut se faire sur formulaire papier ou via un site web tiers. Les données hors ligne (également appelées données par lots) seront saisies dans la base de données de l'entreprise par le biais de traitements par lots. Un fichier plat d'entrée est préparé selon le format de données prescrit et transmis à la séquence de traitements par lots. Ainsi, pour les tests d'applications mainframe, nous pouvons utiliser l'approche suivante.
  • La première tâche de la série de traitements par lots valide les données saisies, par exemple les caractères spéciaux ou les lettres dans les champs numériques uniquement.
  • La seconde tâche consiste à vérifier la cohérence des données en fonction des conditions opérationnelles. Par exemple, l'inscription d'un enfant ne doit pas comporter de données relatives à une personne à charge, ni un code postal d'adhérent non couvert par le régime auquel il est inscrit.
  • La troisième étape consiste à modifier les données pour les rendre compatibles avec la base de données. Par exemple, supprimer le nom du régime (la base de données ne conservera que l'identifiant et le nom du régime d'assurance), ajouter la date de saisie, etc.
  • Le quatrième travail charge les données dans la base de données.
• Les tests de traitement par lots sont effectués sur ce processus en deux phases :
  • Chaque tâche est validée séparément, et
  • L'intégration entre les tâches est validée en fournissant le fichier plat d'entrée à la première tâche et en validant la base de données. (Par mesure de précaution supplémentaire, les résultats intermédiaires doivent être validés.)

Voici la méthode suivie pour les tests sur mainframe :

Étape 1) Test de rodage/de fumée

L'objectif principal de cette étape est de vérifier que le code déployé se trouve dans l'environnement de test approprié. Elle permet également de s'assurer qu'il ne comporte aucun problème critique. C'est l'équivalent, pour les systèmes mainframe, de Test de fumée sur toute autre plateforme.

É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 sont effectués en validant les résultats des tests sur les fichiers de sortie et les modifications de données apportées par les traitements par lots dans le périmètre des tests, et en les enregistrant.
2. Tests en ligne Ce test est réalisé au niveau de l'interface utilisateur de l'application mainframe. Il vérifie notamment la validité des champs de saisie, tels que les informations relatives à un contrat d'assurance, les intérêts associés et autres valeurs similaires.
3. Tests d'intégration par lots en ligne Ces tests sont réalisés sur des systèmes comportant à la fois des traitements par lots et une application en ligne. Le flux de données et l'interaction entre les interfaces en ligne et les traitements par lots sont validés.

   (Exemple de test : prenons l’exemple d’une mise à jour des détails d’un plan, comme une augmentation du taux d’intérêt. La modification du taux est effectuée sur un écran de mise à jour, et les soldes des comptes concernés ne sont modifiés que par un traitement par lots nocturne. Le test consiste alors à valider l’écran des détails du plan et l’exécution du traitement par lots pour la mise à jour de tous les comptes.)

4. Test de base de données — Les bases de données où sont stockées les données de l'application mainframe (IMS, IDMS, Db2, VSAM/ISAM, ensembles de données séquentiels, GDG) sont validées quant à leur disposition et leur stockage de 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 des données provenant du système testé. Il est important de tester le interface et les différents types de messages (comme Tâche réussie, Tâche échouée, Base de données mise à jour) qui peuvent circuler entre les systèmes, et les actions qui en résultent entreprises par les différents systèmes.

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) Tests de régression

Les tests de régression constituent une phase courante dans tout projet de test. Sur les systèmes mainframe, ces tests garantissent que les traitements par lots et les interfaces en ligne qui n'interagissent pas directement avec le système testé (ou qui ne font pas partie du périmètre des exigences) ne sont pas affectés par la version actuelle du projet.

Pour réaliser des tests de régression efficaces, il convient de sélectionner un ensemble spécifique de cas de test en fonction de leur complexité et de créer un environnement de régression (référentiel de cas de test). Cet ensemble doit être mis à jour à chaque déploiement de nouvelle fonctionnalité. Si l'environnement de régression est trop volumineux pour être exécuté intégralement, Tests basés sur les risques sert à déterminer quelles tâches et quels écrans sont réexécutés en premier.

Étape 5) Test de performance

Ces tests permettent d'identifier les goulots d'étranglement dans les zones à forte sollicitation, telles que la saisie de données côté client et les mises à jour de bases de données en ligne, et d'évaluer la scalabilité de l'application. Les traitements par lots de longue durée sont généralement analysés avec Test de stress contre les volumes de pointe.

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

Il convient de réaliser des tests de sécurité en deux étapes sur le système : la sécurité du système central et la sécurité du réseau.

Les fonctionnalités à tester 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 QA a reçu le package approuvé (le package contient des procédures, du JCL, des cartes de contrôle, des modules et des éléments similaires), 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, également appelé JOB SETUP.
3. Copiez le fichier de production et préparez les fichiers de test.
4. Pour chaque fonctionnalité, une séquence de tâches sera définie (comme expliqué dans l'exemple de la section « Méthodologie des tests sur mainframe »). Les tâches devront ê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 test - UNE défaut Un enregistrement doit être effectué si le résultat réel diffère du résultat attendu.

Étapes d'un test 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.

Rapports de test — Un défaut doit être consigné si le résultat obtenu diffère du résultat attendu.

Étapes des tests d'intégration en ligne par lots

1. Exécutez la tâche 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 que le traitement par lots s'exécute correctement avec les données mises à jour.

Commandes utilisées dans les tests sur mainframe

Ces étapes sont pilotées depuis le terminal, de sorte qu'un petit vocabulaire de commandes couvre la majeure partie de la journée d'un testeur.

1. ENVOYER — Soumettez une demande d'emploi basée sur les antécédents.
2. ANNULER — Annuler une mission de fond.
3. ALLOUER — Allouer un ensemble de données.
4. COPY — Copier un ensemble de données.
5. RENOMMER — Renommer un ensemble de données.
6. EFFACER — Supprimer un ensemble de données.
7. SCAN DES EMPLOIS — Lier le JCL au programme, aux bibliothèques, aux fichiers et aux autres ressources 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 sur mainframe

Les informations de base nécessaires pour les tests sur mainframe sont les suivantes :

• Identifiant de connexion et mot de passe pour se connecter à l'application.
• Connaissances de base des commandes ISPF.
• Noms des fichiers, qualificateur de fichier et leurs types.

Avant de commencer les tests sur mainframe, les aspects suivants doivent être vérifiés.

1. Emploi
   • 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 vers une file d'attente ou un JHS, ou selon les besoins, en utilisant le paramètre MSGCLASS.
   • Rediriger le courriel de la tâche vers la file d'attente ou vers une adresse courriel de test.
   • Mettez en commentaire les étapes FTP pour les tests initiaux, puis configurez la tâche pour qu'elle pointe vers un serveur de test.
   • Si un IMR (Incident Management Record) est généré dans la tâche, ajoutez le commentaire « TEST » dans la tâche ou la carte de paramètres.
   • Toutes les bibliothèques de production du travail doivent être modifiées et pointées vers des bibliothèques de test.
   • Le travail ne doit pas être laissé sans surveillance.
   • Pour éviter que la tâche ne s'exécute en boucle infinie en cas d'erreur, le paramètre TIME doit être ajouté avec une durée spécifiée.
   • Enregistrez le résultat du travail, y compris le spool. La bobine peut être enregistrée à l'aide de XDC.
2. Fichier
   • Créez un fichier de test de la taille nécessaire uniquement. Utilisez des GDG (Generation Data Groups — fichiers portant le même nom mais avec des numéros de version séquentiels, tels que MYLIB.LIB.TEST.G0001V00 et MYLIB.LIB.TEST.G0002V00) lorsque cela est nécessaire pour stocker les données dans des fichiers consécutifs portant le même nom.
   • Le paramètre DISP (Disposition — indique au système s'il faut conserver ou supprimer l'ensemble de données après la fin normale ou anormale de l'étape ou du travail) des fichiers doit être codé correctement.
   • Veillez à ce que tous les fichiers utilisés pour l'exécution de la tâche soient enregistrés et fermés correctement afin d'éviter que la tâche ne passe en mode HOLD.
   • Lors des tests avec GDG, assurez-vous de pointer vers la bonne version.
3. Base de données
   • Lors de l'exécution de la tâche ou du programme en ligne, veillez à ce qu'aucune donnée non intentionnelle ne soit insérée, mise à jour ou supprimée.
   • Assurez-vous également que la région Db2 appropriée est utilisée pour les tests.
4. Cas de test
   • Toujours tester les conditions limites telles qu'un fichier vide, le traitement du premier enregistrement et le traitement du dernier enregistrement.
   • Incluez toujours les conditions de test positives et négatives.
   • Dans le cas où des procédures standard sont utilisées dans le programme, telles que le redémarrage par point de contrôle, les modules d'arrêt anormal ou les fichiers de contrôle, veuillez les inclure. Cas de tests pour vérifier si les modules ont été utilisés correctement.
5. 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 en informer les autres. D'autres équipes pourraient travailler avec les mêmes données, et leurs tests échoueraient.
   • 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. Lors de l'exécution d'un traitement par lots, la valeur MAX CC 0 indique que le traitement s'est déroulé avec succès. Cela ne signifie pas pour autant que toutes les fonctionnalités sont opérationnelles. Le traitement s'exécutera avec succès même si la sortie est vide ou non conforme aux attentes. Il est donc toujours recommandé de vérifier toutes les sorties avant de considérer le traitement comme réussi.
2. Il est toujours recommandé d'effectuer un test à blanc de la tâche à tester. Ce test s'effectue avec des fichiers d'entrée vides. Cette procédure doit être appliquée aux tâches impactées par les modifications apportées lors du cycle de test.
3. Avant le début du cycle de test, la configuration des tâches de test doit être effectuée bien à l'avance. Cela permet de détecter d'éventuelles erreurs JCL en amont et, par conséquent, de gagner du temps lors de l'exécution.
4. Lors de l'accès aux tables Db2 via SPUFI (une option de l'émulateur permettant d'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 constitue 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. Tracking cette préparation dans un partagé gestion des tests Le dépôt assure la cohérence entre le lit de régression et la configuration des données.
6. Certaines transactions en ligne et certains traitements par lots peuvent écrire des données dans des files d'attente de messages (MQ) pour transmitL'envoi de données à d'autres applications peut poser problème. Si les données sont invalides, cela peut désactiver ou interrompre les files d'attente de messagerie (MQ), ce qui affectera l'ensemble du processus de test. Il est donc recommandé de vérifier le bon fonctionnement des MQ après les tests.

Défis et dépannage des tests sur mainframe

Malgré ces pratiques, certains problèmes persistent presque à chaque nouvelle version de système mainframe. Le tableau ci-dessous associe chaque problème à la solution correspondante.

Défis	Approche
Exigences incomplètes/peu claires	Il est possible d'avoir accès à un manuel d'utilisation ou à un guide de formation, mais cela ne constitue pas une documentation des exigences. Les testeurs devraient être impliqués dans le processus. cycle de vie des tests logiciels à partir de la phase de définition des exigences. Cela permet de vérifier si les exigences sont testables.
Configuration/identification des données	Il peut arriver que des données existantes doivent être réutilisées selon les besoins. Il est parfois difficile d'identifier les données nécessaires parmi les données existantes. Pour la configuration des données, des outils internes peuvent être utilisés en fonction des besoins. Pour extraire les données existantes, les requêtes doivent être préparées au préalable. 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 du travail	Une fois les tâches récupérées dans PDS, il est nécessaire de les configurer dans l'environnement de test afin d'éviter leur soumission avec un qualificateur de production ou un chemin d'exécution. L'utilisation d'outils de configuration des tâches permet de pallier les erreurs humaines lors de cette étape.
Demande ponctuelle	Il peut y avoir des situations où tests de bout en bout Une assistance est nécessaire en raison d'un problème dans les applications en amont ou en aval. Ces requêtes augmentent le temps et les efforts nécessaires au cycle d'exécution. L'utilisation de scripts d'automatisation, de scripts de régression et de scripts squelettes peut contribuer à réduire ces coûts.
Publications à temps pour changement de périmètre	Il peut arriver que l'impact du code modifie complètement l'apparence et le comportement du système. Cela peut nécessiter des modifications des cas de test, des scripts et des données. Un processus de gestion des changements de périmètre et une analyse d'impact doivent être mis en place.

Abords courants rencontrés

En cas d'échec d'une tâche, le système de spool signale un code d'erreur. La liste ci-dessous répertorie les codes les plus fréquemment rencontrés par un testeur mainframe, ainsi que leurs causes habituelles.

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

   Raison — Lecture en fin de fichier, erreur de longueur de fichier ou tentative d’écriture dans un fichier en lecture seule.

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

   Motif — Tentative d'écriture d'un enregistrement plus long que la durée maximale autorisée.

3. S004 — Une erreur s'est produite lors de l'ouverture.

   Motif — DCB invalide.

4. S013 — Erreur lors de l'ouverture d'un jeu de données.

   Raison — Le membre PDS n’existe pas ou la longueur d’enregistrement dans le programme ne correspond pas à la longueur d’enregistrement réelle.

5. S0C1 - OperaException.

   Motif : Impossible d’ouvrir le fichier ou carte DD manquante.

6. S0C4 — Exception de protection / violation de stockage.

   Motif : Tentative d’accès à un espace de stockage non disponible pour le programme.

7. S0C7 — Exception de vérification du programme, données.

   Motif — Modification de la structure des enregistrements ou des fichiers.

8. Sx22 — Le poste a été annulé.

   Motif — Le travail a été interrompu avant son achèvement ; le chiffre du milieu indique qui ou quoi l’a annulé.

9. S222 — Tâche annulée par l'utilisateur sans fichier de vidage.
10. S322 — La durée de la tâche ou de l'étape a dépassé la limite spécifiée, ou le programme est dans une boucle, ou le paramètre TIME est insuffisant.
11. S522 — Expiration de la session TSO.
12. S806 — Impossible de créer un lien ou de charger le chargement.

    Motif — La tâche ne parvient pas à trouver le module de chargement spécifié.

13. S80A — Espace de stockage virtuel insuffisant pour satisfaire les requêtes GETMAIN ou FREEMAIN.
14. S913 — Tentative d'accès à un ensemble de données que l'utilisateur n'est pas autorisé à utiliser.
15. Sx37 — Impossible d'allouer suffisamment d'espace de stockage à l'ensemble de données.

Assistance en cas d'erreur — Un outil très populaire pour obtenir des informations détaillées sur différents types de coudes abend.

Problèmes courants rencontrés lors des tests sur mainframe

• Fins anormales des tâches Pour que la tâche se déroule correctement, vérifiez les données, le fichier d'entrée et la présence des modules à l'emplacement prévu. Les erreurs d'exécution peuvent avoir de multiples causes, les plus fréquentes étant des données invalides, un champ d'entrée incorrect, une incohérence de date ou des problèmes environnementaux.
• Fichier de sortie vide — Même si la tâche s'exécute correctement (MaxCC 0), le résultat peut ne pas être conforme aux attentes. Par conséquent, avant de valider un test, le testeur doit s'assurer que le résultat est bien vérifié. Ce n'est qu'après cette vérification que les tests peuvent se poursuivre.
• Fichier d'entrée vide — Dans certaines applications, des fichiers sont reçus de processus en amont. Avant d'utiliser le fichier reçu pour tester l'application en cours, les données doivent être vérifiées afin d'éviter une réexécution et un travail supplémentaire.

FAQ