AWS Concepts de test des applications de modernisation du mainframe

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS Les tests d'applications utilisent des termes que d'autres services de test ou progiciels peuvent utiliser avec une signification légèrement différente. Les sections suivantes expliquent comment les tests d'applications de modernisation des AWS mainframes utilisent cette terminologie.

Cas de test

Un scénario de test est l'unité d'action la plus atomique de votre flux de travail de test. Généralement, un scénario de test est utilisé pour représenter une unité indépendante de logique métier qui modifie les données. Des comparaisons seront effectuées pour chaque cas de test. Les cas de test sont ajoutés à une suite de tests. Les cas de test contiennent des métadonnées sur les artefacts de données (ensembles de données, bases de données) que le scénario de test modifie et sur les fonctions métier déclenchées lors de l'exécution du scénario de test : tâches par lots, boîtes de dialogue interactives 3270, etc. Par exemple, les noms et les pages de code des ensembles de données.

Données d'entrée → Scénario de test → Données de sortie

Les cas de test peuvent être en ligne ou par lots :

Suite de tests

Les suites de tests contiennent un ensemble de scénarios de test exécutés dans un ordre séquentiel, un par un. La rediffusion se fait au niveau de la suite de tests. Tous les scénarios de test de la suite de tests sont exécutés sur l'environnement de test cible lorsqu'une suite de tests est rejouée. S'il existe des différences après avoir comparé les artefacts des tests de référence et de rediffusion, les différences seront affichées au niveau du scénario de test.

Par exemple, Test Suite A :

Cas de test 1, cas de test 2, cas de test 3, etc.

Configuration de l'environnement de test

La configuration de l'environnement de test vous permet de configurer l'ensemble initial de données et de paramètres de configuration (ou ressources) CloudFormation dont vous avez besoin pour rendre le test répétable.

Charger

Les téléchargements sont effectués au niveau de la suite de tests. Lors du chargement, vous devez fournir un emplacement Amazon S3 contenant les artefacts, les ensembles de données et les journaux CDC de la base de données relationnelle provenant du mainframe source à comparer. Elles seront considérées comme des données de référence provenant de l'ordinateur central source. Pendant la rediffusion, les données de rediffusion générées seront comparées aux données de référence téléchargées afin de garantir l'équivalence des applications.

Relire

Les rediffusions sont effectuées au niveau de la suite de tests. Pendant la rediffusion, les tests d'applications de modernisation du AWS mainframe utilisent le CloudFormation script pour créer l'environnement de test cible et exécuter l'application. Les ensembles de données et les enregistrements de base de données modifiés pendant la rediffusion sont capturés et comparés aux données de référence du mainframe. Généralement, vous effectuez le téléchargement sur le mainframe une seule fois, puis vous le rejouez plusieurs fois, jusqu'à ce que l'équivalence fonctionnelle soit atteinte.

Compare

Les comparaisons sont effectuées automatiquement une fois la rediffusion terminée avec succès. Lors des comparaisons, les données référencées que vous avez téléchargées et capturées pendant la phase de téléchargement sont comparées aux données de rediffusion générées pendant la phase de rediffusion. Les comparaisons sont effectuées séparément au niveau d'un scénario de test individuel pour les ensembles de données, les enregistrements de base de données et les écrans en ligne.

Comparaison de bases de données

Les tests d'applications utilisent une fonctionnalité de mise en correspondance de l'état de progression lors de la comparaison des modifications des enregistrements de base de données entre les applications source et cible. La correspondance par état et progression compare les différences entre chaque instruction INSERT, UPDATE et DELETE exécutée, contrairement à la comparaison des lignes du tableau à la fin du processus. La mise en correspondance de l'état d'avancement est plus efficace que les alternatives, car elle permet des comparaisons plus rapides et plus précises en comparant uniquement les données modifiées et en détectant les erreurs auto-corrigées dans le flux de transactions. En utilisant la technologie CDC (Changed Data Capture), les tests d'applications peuvent détecter les modifications de base de données de relations individuelles et les comparer entre la source et la cible.

Les modifications de la base de données relationnelle sont générées sur la source et la cible par le code de l'application testée à l'aide d'instructions DML (Data Modification Language) telles que SQL INSERT, UPDATE ou DELETE, mais également indirectement lorsque l'application utilise des procédures stockées, ou lorsque des déclencheurs de base de données sont définis sur certaines tables, ou lorsque CASCADE DELETE est utilisé pour garantir l'intégrité référentielle, déclenchant automatiquement des suppressions supplémentaires.

Comparaisons de jeux de

Les tests d'application comparent automatiquement les ensembles de données de référence et de réexécution produits sur les systèmes source (enregistrement) et cible (rediffusion).

Pour comparer des ensembles de données :

Une fois la rediffusion terminée, les tests d'application comparent automatiquement les ensembles de données de référence et de destination en sortie, en indiquant si les enregistrements sont identiques, équivalents, différents ou manquants. Par exemple, les champs de date relatifs au moment de l'exécution de la charge de travail (jour +1, fin du mois en cours, etc.) sont automatiquement considérés comme équivalents. En outre, vous pouvez éventuellement définir des règles d'équivalence afin que les enregistrements qui ne sont pas identiques aient toujours la même signification commerciale et soient marqués comme équivalents.

État de la comparaison

Les tests d'applications utilisent les états de comparaison suivants : IDENTIQUE, ÉQUIVALENT et DIFFÉRENT.

Règles d'équivalence

Ensemble de règles permettant d'identifier les fausses différences qui peuvent être considérées comme des résultats équivalents. Les tests d'équivalence fonctionnelle hors ligne (OFET) entraînent inévitablement des différences pour certains résultats entre les systèmes source et cible. Par exemple, les horodatages des mises à jour sont conçus différemment. Les règles d'équivalence expliquent comment ajuster ces différences et éviter les faux positifs au moment de la comparaison. Par exemple, si une date correspond à une durée d'exécution de plus de 2 jours dans une colonne de données donnée, la règle d'équivalence la décrit et accepte une durée sur le système cible correspondant à une durée d'exécution de plus de 2 jours au lieu d'une valeur strictement égale à la même colonne dans le téléchargement de référence.

Comparaison des ensembles de données sur l'état final

État final des ensembles de données créés ou modifiés, y compris toutes les modifications ou mises à jour apportées aux ensembles de données par rapport à leur état initial. Pour les ensembles de données, Application Testing examine les enregistrements contenus dans ces ensembles de données à la fin de l'exécution d'un scénario de test et compare les résultats.

Comparaisons de bases de données sur l'état

Comparaisons des modifications apportées aux enregistrements de base de données sous la forme d'une séquence d'instructions DML (Delete, Update, Insert) individuelles. Les tests d'applications comparent les modifications individuelles (insertion, mise à jour ou suppression d'une ligne de table) entre la base de données source et la base de données cible, et identifient les différences pour chaque modification individuelle. Par exemple, une instruction INSERT individuelle peut être utilisée pour insérer dans une table une ligne avec des valeurs différentes dans la base de données source par rapport à la base de données cible.

Equivalence fonctionnelle (FE)

Deux systèmes sont considérés comme fonctionnellement équivalents s'ils produisent les mêmes résultats sur toutes les opérations observables, avec les mêmes données d'entrée. Par exemple, deux applications sont considérées comme fonctionnellement équivalentes si les mêmes données d'entrée produisent des données de sortie identiques (par le biais d'écrans, de modifications d'ensembles de données ou de modifications de base de données).

Comparaisons d'écrans 3270 en ligne

Compare la sortie des écrans 3270 du mainframe avec la sortie des écrans Web des applications modernisées lorsque le système cible s'exécute sous le runtime AWS Blu Age dans le. AWS Cloud Et il compare la sortie des écrans 3270 du mainframe à celle des 3270 écrans de l'application réhébergée lorsque le système cible s'exécute sous le runtime Rocket Software (anciennement Micro Focus) dans le. AWS Cloud

Rejouer les données

Les données de rediffusion sont utilisées pour décrire les données générées par la réexécution d'une suite de tests sur l'environnement de test cible. Par exemple, les données de rediffusion sont générées lorsqu'une suite de tests est exécutée sur une application de service de modernisation AWS du mainframe. Les données de rediffusion sont ensuite comparées aux données de référence capturées à partir de la source. Chaque fois que vous rejouez la charge de travail dans l'environnement cible, une nouvelle génération de données de rediffusion est générée.

Données de référence

Les données de référence sont utilisées pour décrire les données capturées sur le mainframe source. Il s'agit de la référence à laquelle les données générées par le replay (cible) seront comparées. En général, pour chaque enregistrement du mainframe qui crée des données de référence, de nombreuses rediffusions sont effectuées. Cela est dû au fait que les utilisateurs capturent généralement l'état correct de l'application sur le mainframe et rejouent les scénarios de test sur l'application modernisée cible pour valider l'équivalence. Si des bogues sont détectés, ils sont corrigés et les scénarios de test sont rejoués. Souvent, plusieurs cycles de rediffusion, de correction de bogues et de rediffusion pour valider l'occurrence. C'est ce qu'on appelle le paradigme des tests « capture une fois, rejouer plusieurs fois ».

Téléchargez, rejouez et comparez

Les tests d'applications se déroulent en trois étapes :

Différences

Indique que des différences ont été détectées entre les ensembles de données de référence et de rediffusion par comparaison des données. Par exemple, un champ d'un écran 3270 en ligne qui affiche des valeurs différentes du point de vue de la logique métier entre le mainframe source et l'application modernisée cible sera considéré comme une différence. Un autre exemple est un téléchargement dans un ensemble de données qui n'est pas identique entre les applications source et cible.

Équivalences

Les enregistrements équivalents sont des enregistrements différents entre les ensembles de données de référence et de réexécution, mais ne doivent pas être traités comme différents du point de vue de la logique métier. Par exemple, un enregistrement contenant l'horodatage de la date de production de l'ensemble de données (heure d'exécution de la charge de travail). À l'aide de règles d'équivalence personnalisables, vous pouvez demander à Application Testing de traiter une telle différence faussement positive comme une équivalence, même si elle indique des valeurs différentes entre les données de référence et les données de rediffusion.

Application source

L'application mainframe source à laquelle il convient de comparer.

Application cible

Application nouvelle ou modifiée sur laquelle les tests sont effectués et qui sera comparée à l'application source afin de détecter tout défaut et d'obtenir une équivalence fonctionnelle entre les applications source et cible. L'application cible s'exécute généralement dans le AWS cloud.