an excellent way data testing using xml technologies
Dans le SDLC , si l'application utilise le modèle en cascade, les activités de test sont planifiées à la fin. Cela pose un risque de retouches en ce qui concerne les exigences, la conception, le code et les cas de test si l'équipe d'assurance qualité identifie des défauts. Il vaut mieux éviter d'attendre la fin pour identifier les défauts d'une application.
Les tests qui ne sont pas basés sur l'exécution fonctionnelle de l'application peuvent détecter des défauts sans exiger la publication de tous les composants dans l'environnement de test. Cela peut être accompli par des tests de données.
Le XML et les technologies associées utilisées pour la communication entre les différents niveaux d'une application offrent la possibilité d'effectuer les tests qui n'ont pas besoin d'attendre que l'application entière soit facilement disponible pour les tests.
Ce document décrit une façon possible d'examiner l'option de test des données au début du cycle de vie d'une version de produit.
Ce que vous apprendrez:
- Hypothèse:
- Groupe de discussion:
- But:
- Cycle de vie de la gestion des données de test
- Conclusion
- lecture recommandée
Hypothèse:
Ce document suppose que le lecteur est familiarisé avec concepts de test de logiciels et l'utilisation fondamentale d'une base de données et des technologies XML.
Groupe de discussion:
Équipe QA (QA), équipe de données (DT), développeur (DEV)
But:
Le exemple de données identifié pour tester un produit définit l'étendue des tests effectués, ajoute la confiance dans les résultats des tests et la qualité du produit. L'identification des données pour un test dépend des exigences du test à effectuer.
Ce document se concentre sur la validation des données de test avant de les voir sur l'interface utilisateur.
Ce processus nécessite une gestion des données de test afin d'obtenir des résultats de test efficaces. Comme nous le savons tous, les données peuvent être enregistrées dans une base de données ou un fichier plat. Mais le transfert de données depuis / vers une base de données peut être géré en utilisant XML. Il existe une relation très étroite entre XML (1), XSD (2), XPATH (3) & XSLT (4). (Voir toutes les définitions ci-dessous).
(1) XML - est X tendu M Arkup L anguage. Il s'agit d'une recommandation du World Wide Web Consortium (W3C) pour décrire les données. Avec un ensemble de règles de syntaxe correctes appliquées, on peut s'assurer qu'un document XML est «bien formé»
(2) XSD - Utilisé pour désigner la structure d'un document XML. Un document XML «bien formé» peut être validé par rapport à un XSD (XML Schema) pour le valider
(3) XPATH - Un XML «valide» et «bien formé» doit être parcouru pour récupérer les données appropriées du XML. Les expressions XPATH ressemblent à un chemin de fichier traditionnel dans un répertoire.
(4) XSLT - est X tendu S feuille de style L anguage T ransformations - Tout en représentant les données d'un XML sur une interface utilisateur (UI), n'importe quel style (police, couleur, taille, etc.) peut être appliqué à l'aide de XSLT. XSLT utilise XPath pour localiser des informations à partir du XML.
Données présentées dans le XML est validé par rapport à un schéma (fichier XSD). Le XML peut être sorti dans différents formats avec XSLT et XPATH.
meilleures pratiques d'automatisation dans les tests logiciels
Aux fins de cette discussion, nous utiliserons l'exemple suivant.
Exemple - Une maison d'édition dispose d'un site Web affichant des informations sur les livres qu'elle a publiés. L'une des pages Web affiche un résumé de chaque chapitre d'un livre. Les tests doivent garantir que le contenu est approprié sur cette page Web. La maison d'édition a maintenant publié des millions de livres.
Toutes les informations relatives aux livres publiés sont enregistrées dans une base de données. Pourtant, la page Web en question a besoin d'un sous-ensemble de données (sur un nouveau livre et ses chapitres) à extraire de la base de données dans un XML.
Le XML ci-dessous représente les métadonnées sur le livre.
Fichier XML Book.xml
A book on test data Jim 2015 Technical English 120 10 Acknowledgement Introduction What is data List of references
XML Schema Book.xsd
Cycle de vie de la gestion des données de test
Similaire à d'autres processus, gestion des données de test a ses propres étapes de cycle de vie (LC).
- Identifier les besoins en données
- Planifier la collecte de données
- Construisez les données
- Tester les données
- Maintenance des données (non détaillée dans ce document car elle n'est pas pertinente)
#1. Identifier les besoins en données
Dans l'exemple ci-dessus, la base de données stocke des millions d'enregistrements. Si le contenu de tous les livres est extrait dans un fichier XML, il nécessite une validation détaillée. Au fur et à mesure que de nouvelles informations doivent être sorties dans la page Web, le XML et le schéma peuvent subir des modifications.
Les modifications apportées au XML, XSD, XPATH et XSLT nécessitent une validation appropriée. Mais ces tests n'ont pas besoin d'attendre la publication de la présentation, du middleware et du niveau de données. L'équipe QA peut analyser XSD pour préparer un plan d'exigence de données.
Etape du cyle de vie | Critères d'admission | Activités / Responsabilité | Critère de sortie |
---|---|---|---|
Identifier les exigences en matière de données de test | Les documents suivants sont disponibles Conception de base de données, conception d'interface utilisateur, spécification des exigences, architecture technique, diagramme de flux de données, diagrammes de cas d'utilisation | Comprendre les exigences en matière de données référençant les documents à partir des critères d'entrée (QA, DT, DEV) Exigences en matière de données de test (QA, DT, DEV) - documente tous les besoins en données pour chaque écran en montrant un mappage entre les noms d'affichage d'écran et l'élément XML correspondant | Examiner le document sur les exigences des données de test (QA, DEV, DT) |
Le processus d'identification de toutes les exigences en matière de données pour un produit doit aborder les points suivants:
a) Couverture et exhaustivité - Les exigences identifiées couvrent-elles tous les cas d'utilisation?
Exemple - Il est très important de tester les combinaisons de données pour le titre, l'auteur, la catégorie, la langue dans l'exemple XML ci-dessus; puisque le schéma impose ces champs.
Cela peut être facilement géré en regardant le schéma XML qui décrit la présence d'un élément / attribut et leur ordre dans le XML
b) Qualité - Les données collectées sont-elles de la meilleure qualité possible? Les données de test utilisées déterminent la qualité des tests effectués sur l'application.
- Positif et scénarios négatifs - Les tests doivent vérifier le comportement de l'application avec les données d'entrée valides / non valides
Le document sur les exigences des données d'essai répertorie les besoins en données à tous les niveaux de l'application. Les données de la base de données peuvent être utilisées directement dans l'interface utilisateur et / ou manipulées (calculs, concaténation, etc.). Par conséquent, il est nécessaire de saisir tous les besoins en données.
Le tableau ci-dessous représente un exemple de tableau de données:
Nom de domaine | Type de données | Données de test | Remarques | Résultat du test |
---|---|---|---|---|
Auteur | Chaîne de caractères | Champ vide | Puisqu'il s'agit d'un champ obligatoire. Le test doit échouer. | |
Auteur | Chaîne de caractères | Auteur + @ | A des caractères spéciaux | Ce test devrait échouer |
Auteur | Chaîne de caractères | Nom de l'auteur | Comprend un espace | Ce test devrait réussir |
Auteur | Chaîne de caractères | 123Auteur | Commence par un nombre | Ce test devrait échouer |
Auteur | Chaîne de caractères | @!Auteur | Commence par des caractères spéciaux | Ce test devrait échouer |
Auteur | Chaîne de caractères | Auteur | Préfixé avec des espaces | Ce test devrait échouer |
Dans l'exemple ci-dessus, l'utilisation du type de données chaîne pour le champ Auteur peut être évitée. Au lieu de cela, un modèle peut être appliqué.
Par exemple. alphabets uniquement, commencez par une lettre majuscule, pas de caractères spéciaux, etc. modèle (restreindre une valeur d'élément définie dans XSD) peut être définie comme .
Si cela est défini pour le auteur élément dans l'exemple ci-dessus, cela signifie, le auteur L'élément doit avoir la valeur avec une combinaison d'alphabets majuscules, minuscules et d'entiers positifs uniquement.
# 2. Planifier la collecte de données
Stade LC | Critères d'admission | Activités / Responsabilité | Critère de sortie |
---|---|---|---|
Planifier la collecte de données | Document sur les exigences relatives aux données d'essai approuvées | Identifier la fréquence des besoins en données (DEV, QA) Répertorier les données de test (QA) Définir le schéma XML (DEV) | Examiner la fréquence des besoins en données et des données de test (DT) |
# 3. Construisez les données
Stade LC | Critères d'admission | Activités / Responsabilité | Critère de sortie |
---|---|---|---|
Construire des données | Fichier de demande de données | Construire les données dans la base de données (DT) Extraire les données de la base de données dans le XML (DT) Valider le XML par rapport au schéma (DT) Partager le fichier XML avec QA (DT) | Le fichier XML est reçu par l'équipe QA |
# 4. Tester les données
Stade LC | Critères d'admission | Activités / Responsabilité | Critère de sortie |
---|---|---|---|
Tester les données | Fichier XML de demande de données | Valider le XML par rapport au schéma pour l'exhaustivité et l'exactitude (QA) Mettre à jour le document de mappage avec les résultats des tests (QA) | Résultats des tests partagés avec l'équipe DEV, DT |
Comme indiqué dans les tableaux ci-dessus, le contrôle qualité valide le XML par rapport au schéma pour vérifier si les données sont disponibles comme prévu. Une fois que le schéma correspond, le contenu et sa structure peuvent être confirmés. Pourtant, cela ne confirme pas que les données sont captées avec précision par le système.
Comme nous le savons, XML montre une structure arborescente avec p arent-enfant-frère-sœur-ancêtre-descendant relation entre les nœuds.
comment rendre la passerelle par défaut disponible
Consultez le tableau ci-dessous pour comprendre les conventions XPATH les plus simples:
Afin de représenter les champs du XML sur un écran (comme HTML par exemple), la combinaison XSLT - XPATH est utilisée.
Latest Book
Title Author Publication_Year Category Language Pages
Sur un navigateur enfin, le XML résultant est représenté comme ci-dessous. Étant donné que les données ont déjà été vérifiées, les tests peuvent se concentrer davantage sur l'apparence et la convivialité de l'écran.
Conclusion
- Les tests de données effectués tôt dans le cycle de vie des tests de développement permettent d'économiser de l'argent car le coût de la correction d'un bogue pendant l'exécution du test fonctionnel est bien plus que de le corriger tôt dans le cycle de vie.
- L'effort consacré initialement à la validation du fichier XML, XPath et XSLT avec les documents XSD permet d'éviter les itérations multiples de la version
- L'équipe QA peut travailler en étroite collaboration avec l'équipe de développement et fournir un service à valeur ajoutée
- L'équipe QA peut aider à simuler diverses combinaisons de données pour assurer la couverture et l'exactitude
Je suis sûr que vous trouverez cette technique utile. N'hésitez pas à commenter si vous avez des questions.
lecture recommandée
- Une approche simple pour les tests de bases de données XML
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
- Différences clés entre les tests de boîte noire et les tests de boîte blanche
- Top 10 des outils d'entrepôt de données et des technologies de test les plus populaires
- Tutoriel de test de test de l'entrepôt de données ETL (un guide complet)
- Téléchargement de l'e-book 'Testing Primer'
- Qu'est-ce que le test de mutation: tutoriel avec des exemples
- Comment effectuer des tests basés sur les données à l'aide de l'outil TestComplete