Brève description des données de test
Quelles sont les données de test de la torture de l'âme? Peut-être diriez-vous sans hésitation, les données de test ne sont-elles pas les données que nous utilisons quotidiennement pour les tests? Cette affirmation est trop générale. En fait, les données de test se réfèrent aux données liées au test, qui peuvent être divisées dans les catégories suivantes.
1. Données de demande de test
Les données de demande de test sont les données de test que nous comprenons souvent. Cette partie des données est l'entrée nécessaire à l'exécution du cas de test (le cas de test se réfère ici au cas de test automatisé, généralement sous la forme d'un script de test).
Il peut être directement couplé dans le cas de test, ou il peut être placé dans un fichier externe. Dans le cas des fichiers externes, comme mentionné dans nos tweets précédents, les données de test peuvent être stockées dans des fichiers JSON, YAML, TXT, Excel (xlsx), CSV, SQL ou même .py.
L'utilisation de cette partie des données de test, grâce au partage précédent, je pense que tout le monde ne devrait plus être inconnu. Pour les données de demande de test, elles sont également divisées dans les deux cas suivants.
Données obligatoires
Les données qui doivent être transportées lors de l'envoi de la demande sont les données obligatoires. Par exemple,
dans le test d'automatisation de l'interface utilisateur, les données que vous ne pouvez pas envoyer le formulaire sans remplir;
dans le test d'automatisation de l'API, les paramètres et les données que vous devez transporter dans la demande. Sinon, une erreur sera signalée lors de l'envoi de la demande.
Données non obligatoires
Les données qui ne sont pas obligatoires lors de l'envoi de la demande sont les données non obligatoires. Par exemple:
dans le test d'automatisation de l'interface utilisateur, les données qui peuvent être soumises sans remplir le formulaire;
dans le test d'automatisation de l'API, les données que vous ne faites pas carry in the request sera également envoyé à la demande. Les paramètres et les données qui ne signaleront pas d'erreurs.
2. Tester les données attendues
Test des données attendues, généralement utilisées comme données de comparaison avec les données de résultat générées après le test. Cette partie des données s'accompagne souvent de l'existence d'une fonction d'assertion.
Utilisé pour déterminer si les données de résultat de test générées sur la base des données de demande de test sont les mêmes que les données de test attendues. S'ils sont identiques, cela signifie que le comportement de l'entreprise est conforme aux attentes; s'ils ne le sont pas, cela signifie que le comportement de l'entreprise est incompatible avec la demande et qu'il peut y avoir un bogue.
3. Données de résultat du test
Autrement dit, après l'entrée des données de demande de test, les données de résultat générées par le système, cette partie des données est également divisée en deux cas:
Données de résultat pures
Fait référence à des données agrégées non analysées. Par exemple: les données de résultat d'un certain cas de test. Leur fonction est souvent utilisée pour comparer avec les données d'attente de test fournies par l'utilisateur pour vérifier l'exactitude de l'entreprise.
Données de résultat agrégées
Données de résultat agrégées, généralement appelées rapports de test. En agrégeant des données de résultat pures, les données de résultat agrégées peuvent nous en dire plus sur la qualité du système.
Par exemple: après un test, le rapport de test peut nous dire combien de cas de test ont réussi, combien de cas de test ont échoué et à quel module appartenaient les cas de test ayant échoué.
Grâce à la comparaison de plusieurs rapports de test, nous pouvons voir quel module de test a souvent des problèmes, quel module est fondamentalement stable, les performances de quel module ont diminué, etc. Grâce à l'analyse de données agrégées, nous pouvons vous aider à améliorer notre stratégie de test.
Comment préparer les données de demande de test
La préparation des données de demande de test prend souvent plus de temps dans les tests automatisés. Comment préparer efficacement les données de test est en fait une proposition sans réponse standard. Sur la base de mon expérience de projet précédente, plusieurs méthodes de préparation de données couramment utilisées sont répertoriées ici à titre de référence uniquement.
1. Créer manuellement selon des règles métier
C'est actuellement le moyen le plus simple, le testeur fournit directement les données de la demande de test, y compris les données obligatoires et les données non obligatoires. Enregistrez les données de la demande de test en les fournissant directement à la méthode de test ou en utilisant un fichier externe. Les données de demande de test enregistrées dans le fichier externe sont lues et appliquées au scénario de test (script de test) une par une via le lecteur de données lorsque le test est en cours.
Les données de demande de test créées à la main ont un inconvénient, c'est-à-dire que les données de demande de test ne changeront jamais, ce qui n'est pas conforme à l'utilisation normale de l'utilisateur.
2. Utilisez une fausse bibliothèque de données tierce pour générer automatiquement
Afin de mieux simuler l'utilisation d'utilisateurs normaux, vous pouvez utiliser de fausses données tierces, telles que la faker bibliothèque couramment utilisée en python. En appelant ces fausses bibliothèques de données, vous pouvez générer des données de test plus proches des utilisateurs normaux.
Mais ce type de données n'est généralement utilisé que lors de la création de données. Par exemple, inscription et remplissage du formulaire de commentaires. Pour les données de requête, cela n'est pas applicable, car les données de requête nécessitent généralement que les données existent déjà dans la base de données système.
3. Fichier de données
obtenu via une requête SQL La méthode d'obtention des données de requête de test via une requête SQL est un moyen courant. En général, cette méthode convient à la situation où une demande de données provient de la sortie de différents services.
Par exemple: testez l'interface de déduction du produit, puis l'entrée de cette interface doit avoir des paramètres tels que l'identifiant de l'utilisateur, l'identifiant du produit, le prix du produit, le solde de l'utilisateur, etc., et ces paramètres sont fournis par un ou plusieurs services. Donc, utiliser une requête de combinaison d'instructions SQL est un moyen plus rapide.
Les données de test sont obtenues via une requête d'instruction SQL. S'il y a trop de tables à joindre, il y aura des problèmes d'efficacité de génération de données.
4. Générez automatiquement des données en fonction de la plate-forme de test
. La plate-forme de données est une solution de génération de données populaire ces dernières années. Elle intègre les méthodes de production de données ci-dessus et fournit une interface unifiée afin que les utilisateurs puissent facilement générer des données de test sans se soucier de la façon dont les données est généré, mais la construction de la plate-forme de construction de données nécessite que l'équipe de test dispose d'un certain nombre de capacités d'architecture de développement.
5. Copie depuis l'environnement de production
En copiant le trafic de l'environnement de production, il est utilisé pour les tests d'environnement de test. Cette méthode est couramment utilisée dans les tests de performances. Les données de test sont construites en copiant le trafic en ligne dans l'environnement de test. Dans le processus de test de Big Data, certaines entreprises copieront directement de l'environnement de production vers l'environnement de test afin de réduire les coûts ou de rapprocher les données de test des données de scénario d'utilisation réelle de l'utilisateur.
Les solutions courantes incluent TcpCopy, goreplay, etc. Cette méthode a des exigences relativement élevées pour les capacités architecturales et les capacités de développement de code de l'équipe de test, et nécessite souvent la coopération voire le leadership de l'équipe de développement. Elle est généralement mise en œuvre par la mise en place de projets spéciaux au sein de l'entreprise.
Moment de la préparation des données de demande de test
En ce qui concerne l'étape du test pour créer les données de demande de test, il existe généralement les deux méthodes suivantes dans l'industrie.
1. Préparation avant le test de fonctionnement
Préparez-vous avant l'exécution du test, c'est-à-dire que les données de test existent sous forme de code en dur. Il peut être codé en dur directement dans la méthode de test ou écrit dans des fichiers de données de différents formats. La création manuelle de données de test basée sur des règles métier comme mentionné ci-dessus est le meilleur exemple de préparation avant l'exécution du test.
2. Préparez-vous lorsque le test est exécuté
La préparation pendant l'opération de test signifie que les données de test ne sont pas spécifiées à l'avance, c'est-à-dire qu'il n'y a pas de fichier de données de test dans le code de test. Les données de test doivent générer directement les données de test requises par le scénario de test en appelant la plate-forme de construction de données ou en combinant le DB de requête pendant l'exécution du test, puis démarrer le test.
Quant à savoir quand les données de test doivent être préparées, il n'y a actuellement pas de conclusion unifiée, et peu importe qu'elle soit bonne ou mauvaise. Vous pouvez choisir librement en fonction de votre propre situation.
Problèmes et contre-mesures des données de demande de test
Actuellement, quelle que soit la méthode utilisée pour préparer les données, quel que soit le moment utilisé pour générer les données de demande de test, les données de demande de test peuvent présenter les problèmes suivants:
1. Les données de test sont obsolètes
Cette situation est courante lorsque les données de demande de test sont préparées à l'avance. Par exemple: un ensemble de données est utilisé pour la déduction des coupons, mais les coupons ont généralement une date d'expiration. Une fois le coupon expiré, l'utilisation de cet ensemble de données pour le test entraînera inévitablement l'échec du test. Par conséquent, les données de demande de test préparées à l'avance doivent être mises à jour régulièrement.
2. Plusieurs exécutions conduisent à des résultats de test différents.
Cette situation se produit souvent parce que les données sont préparées à l'avance. Par exemple: un ensemble de données de test est fourni pour l'enregistrement de l'utilisateur. Lorsque le premier test s'exécute, le test réussit normalement, mais le deuxième test échoue car l'utilisateur existe déjà.
Dans le cas où une opération d'écriture de base de données est requise pendant le test, il est préférable d'effectuer une opération de démontage après la fin du test pour restaurer le système à l'état avant le test.
3. Les données de test ne sont pas disponibles en raison du changement d'environnement.
En règle générale, la version d'un produit doit être testée dans plusieurs environnements de test. Par exemple, environnement de développement, environnement de test, environnement de test intégré, environnement de pré-production, environnement de production, etc. Les données de test de chaque environnement peuvent être différentes. Les environnements de commutation doivent garantir que les données de test sont disponibles.
Le problème de l'indisponibilité des données de test en raison du changement d'environnement peut être résolu des deux manières suivantes:
Assurez-vous que chaque environnement de test utilise le même ensemble de données.
Cette méthode est lourde et adaptée aux nouveaux projets. Créez les mêmes données de test pour chaque environnement de test afin d'éviter les erreurs de test causées par le changement d'environnement de test.
Le cadre de test a la capacité de changer d'environnement de test et de trouver automatiquement les données environnementales correspondantes.
Cette méthode est relativement courante. Différents environnements de test peuvent avoir des données de test différentes. Le framework de test a la capacité de monter automatiquement les données de test de l'environnement de test correspondant après le changement d'environnement de test.
4. Les données de test sont modifiées pendant le test. Les
données de test peuvent être modifiées dynamiquement pendant le test. Par exemple, le solde de l'utilisateur est stocké dans la base de données et les données de test sont générées lors de l'exécution du test. C'est-à-dire que lorsque le test est en cours d'exécution, on constate que le solde de l'utilisateur est insuffisant lorsque le solde de l'utilisateur est vérifié et obtenu.
Dans ce cas, il est généralement nécessaire de modifier les conditions de la génération des données de test, c'est-à-dire d'écrire l'instruction de requête de manière plus robuste pour garantir que l'utilisateur acquis doit avoir un équilibre. Ou ajouter un jugement conditionnel, s'il est constaté qu'il n'y a pas d'équilibre, un autre service est appelé pour recharger l'utilisateur.
5. L'exécution simultanée rend les données de test indisponibles. L'
exécution simultanée de cas de test ou de plusieurs personnes exécutant le même scénario de test en même temps peut entraîner le fonctionnement de plusieurs cas de test sur le même ensemble de données. Cela peut entraîner l'échec du test (par exemple: des personnes différentes prennent la même donnée de test pour les opérations d'enregistrement).
Dans ce cas, vous pouvez coder pour permettre à l'infrastructure de test de prendre en charge les exécutions simultanées en utilisant le même fichier de données, mais cela implique généralement beaucoup d'investissement. Afin d'éviter d'investir trop d'efforts de développement, dans la plupart des cas, plusieurs classes sont utilisées pour prendre en charge la concurrence, et les cas de test sous une classe sont exécutés séquentiellement pour éviter les cas de test sous la même classe de test et accéder aux mêmes données de test en même temps. temps.
Pour résumer
Ce que j'ai partagé aujourd'hui, ce sont les problèmes courants des données de demande de test en fonctionnement de test. Attention, vous constaterez peut-être que bien que ces problèmes aient leurs propres solutions, ils ont tous un point commun, c'est-à-dire que l'émergence de ces problèmes est due au manque de gestion des données de test.
Bienvenue à prêter attention au compte public [The Way of Infinite Testing], répondre [Recevoir des ressources] Ressources d'
apprentissage de la programmation Python marchandises sèches,
Python + Appium Framework APP UI Automation,
Python + Selenium Framework Web UI Automation,
Python + Unittest Framework API Automation,
Les ressources et les codes sont envoyés gratuitement ~
Il y a un code QR du compte officiel en bas de l'article, vous pouvez simplement le scanner sur WeChat et le suivre.
Remarques: Mon compte public personnel a été officiellement ouvert, dédié au partage de la technologie de test, y compris: les tests de big data, les tests fonctionnels, le développement de tests, l'automatisation de l'interface API, le fonctionnement et la maintenance des tests, les tests d'automatisation de l'interface utilisateur, etc., WeChat search public compte: "Wuliang The Way of Testing", ou scannez le code QR ci-dessous:
Ajoutez de l'attention et grandissons ensemble!