AWS Concepts de test des applications de modernisation du mainframe

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 :

• Les cas de test d'écran 3270 en ligne sont des cas de test dans lesquels l'utilisateur exécute des boîtes de dialogue d'écran interactives (3270) pour lire, modifier ou produire de nouvelles données commerciales (bases de données et/ou enregistrements d'ensembles de données).

• Les cas de test par lots sont des cas de test nécessitant la soumission d'un lot pour lire, traiter et modifier ou produire de nouvelles données commerciales (ensembles de données et/ou enregistrements de base de données).

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 :

1. Commencez avec les mêmes données d'entrée (ensembles de données, base de données) à la fois sur la source et sur la cible.

2. Exécutez vos scénarios de test sur le système source (mainframe).

3. Capturez les ensembles de données produits et chargez-les dans un compartiment Amazon S3. Vous pouvez transférer des ensembles de données d'entrée de la source vers AWS des journaux, des écrans et des ensembles de données du CDC.

4. Spécifiez l'emplacement du compartiment Amazon S3 où les ensembles de données du mainframe ont été téléchargés lorsque vous avez chargé le scénario de test.

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.

IDENTIQUE

Les données source et cible sont exactement les mêmes.

ÉQUIVALENT

Les données source et cible contiennent de fausses différences considérées comme des équivalences, telles que des dates ou des horodatages qui n'affectent pas l'équivalence fonctionnelle lorsqu'elles sont relatives au moment de l'exécution de la charge de travail. Vous pouvez définir des règles d'équivalence pour identifier ces différences. Lorsque toutes les suites de tests rejouées par rapport à leurs suites de tests de référence affichent le statut IDENTIQUE ou ÉQUIVALENT, votre suite de tests ne montre aucune différence.

DIFFÉRENT

Les données source et cible présentent des différences, telles qu'un nombre différent d'enregistrements dans un ensemble de données ou des valeurs différentes dans le même enregistrement.

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 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 Il compare également 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 moteur d'exécution 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 :

• Téléchargement : capture les données référencées créées sur le mainframe pour chaque scénario de test d'un scénario de test. Il peut s'agir de 3 270 écrans en ligne, d'ensembles de données et d'enregistrements de base de données.

  • Pour les écrans 3270 en ligne, vous devez utiliser l'émulateur de terminal Blu Insights pour capturer votre charge de travail source. Pour plus d'informations, consultez la documentation Blu Insights.

  • Pour les ensembles de données, vous devrez capturer les ensembles de données produits par chaque scénario de test sur le mainframe à l'aide d'outils courants, tels que le FTP ou le service de transfert de jeux de données intégré à la modernisation du AWS mainframe.

  • Pour les modifications de base de données, vous utilisez la documentation AWS Mainframe Modernization Data Replication with Precisely pour capturer et générer des journaux CDC contenant les modifications.

• Rediffusion : La suite de tests est rejouée dans l'environnement cible. Tous les cas de test spécifiés dans la suite de tests sont exécutés. Les types de données spécifiques créés par les scénarios de test individuels, tels que les ensembles de données, les modifications de bases de données relationnelles ou les écrans 3270, seront capturés automatiquement. Ces données sont appelées données de rediffusion et seront comparées aux données de référence capturées lors de la phase de téléchargement.

  Note

  Les modifications apportées à la base de données relationnelle nécessiteront des options de configuration spécifiques au DMS dans votre modèle de condition initial. CloudFormation

• Comparaison : la source des tests, les données de référence et les données de rediffusion cibles sont comparées, et les résultats vous seront présentés sous forme de données identiques, différentes, équivalentes ou manquantes.

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 la comparaison doit être effectuée.

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.