Il arrive souvent qu'une application Web se compose d'un grand nombre de formulaires de restructuration dynamique avec différents textes et contrôles. Tester une telle application se transforme en cauchemar.Vous devez cliquer sur 100 500 pages et vérifier toutes les fonctionnalités ... Et avant la prochaine version, vérifiez à nouveau la même chose ... Et encore ... Et demain encore. À un moment donné, la vérification commence à prendre plus de temps que le développement de nouvelles fonctionnalités. "Qu'en est-il des tests e2e?" - tu demandes. Mais, premièrement, ils doivent encore être écrits. Et deuxièmement, avant de commencer à les écrire, vous devez écrire des cas de test. Beaucoup de cas de test.Si, en lisant ces lignes, votre front est couvert de transpiration, ne vous inquiétez pas. Dans cet article, je partagerai avec vous l'idée de la façon dont nous, à Tinkoff, avons automatisé le test d'une des applications Web sans écrire un seul cas de test et un test e2e.
Écriture automatique de cas de test
Il se trouve que le test de notre application Web est principalement lié aux vérifications d'interface. Vous devez vérifier que le bouton est présent à l'écran, le titre et le texte souhaités sont affichés et lorsque vous entrez une valeur non valide en entrée , un message d'erreur apparaît.Par conséquent, lors de l'écriture d'un scénario de test, vous devez enregistrer toutes les actions:- "J'ai appuyé sur le bouton"
- "Saisie de la valeur de XXX"
- "Sélection de la valeur YYY dans la liste déroulante"
et vérifie:- "Le texte est apparu: XXX"
- "Un message d'erreur est apparu: YYY"
- "Le titre est apparu: ZZZ"
Après avoir analysé toutes les fonctionnalités de notre application Web, nous avons identifié environ 30 actions et vérifications uniques. Il est devenu clair que ce processus peut être automatisé. Pour ce faire, il vous suffit de suivre toutes les actions du testeur sur la page et la réaction du site à ces actions.Commençons par intercepter les événements. Pour suivre l'interaction avec des contrôles tels que des boutons, des boutons radio et des cases à cocher, vous devez vous abonner à l'événement Click. Chaque framework a ses propres méthodes pour cela. Par exemple, fromEvent dans Angular et document.addEventListener dans JavaScript et React. Pour les contrôles d'entrée, tels que le calendrier ou l'entrée, seul le type d'événement auquel vous souhaitez vous abonner changera: au lieu de cliquer, la mise au point sera.fromEvent(this.elementRef.nativeElement, 'click')
.subscribe(tagName => {
if (tagName === 'BUTTON') {
this.testCaseService.addAction(` "${action.name}"`);
} else if (tagName === 'INPUT-CALENDAR') {
this.testCaseService
.addAction(` "${action.name}" "${action.value}"`);
}
});
Et enfin, la chose la plus importante est de vérifier. Le comportement du site en réponse aux actions du testeur.Qu'est-ce que le testeur vérifie habituellement? Par exemple, il a entré une valeur non valide en entrée , le site a répondu avec un message d'erreur. Ou, disons que nous avons cliqué sur un bouton et en réponse un nouvel écran est apparu, le titre a changé, un nouveau texte est apparu, les contrôles ont été reconstruits. Toutes ces modifications sont liées à la modification de l'arborescence DOM. Il existe de nombreuses options pour les suivre. Vous pouvez, par exemple, utiliser MutationObserver dans React et JavaScript ou ngAfterViewInit dans Angular (en mettant une directive sur les éléments de formulaire d'intérêt sur le site).ngAfterViewInit() {
const tagName = this.nativeElement.nodeName;
const text = this.nativeElement.textContent;
if (['SPAN', 'P'].includes(tagName)) {
this.testCaseService.addContent(`** ** "${text}"\n`);
} else if (tagName === 'H1') {
this.testCaseService.addContent(`** ** "${text}"\n`);
} …
}
Le code dépendra beaucoup de la mise en page. Jetons un coup d'œil au balisage. Ces boutons proviennent du traducteur Google.
<div class="tlid-input-button input-button header-button tlid-input-button-text text-icon" role="tab" tabindex="-1">
<div class="text"></div>
</div>
<div class="tlid-input-button input-button header-button tlid-input-button-docs documents-icon" role="tab" tabindex="-1">
<div class="text"></div>
</div>
Malgré le fait que les boutons ne sont pas représentés comme des balises de bouton , en regardant le balisage, vous pouvez sélectionner tous les boutons de la page en utilisant la classe css «input-button», et vous pouvez obtenir les noms des boutons de la classe css «text» imbriquée.La moitié du travail a été fait, il ne reste plus qu'à noter tout ce que nous avons suivi dans un cas de test.Nous incluons l'interception de toutes les actions sur le site pour une combinaison de touches spécifique et uniquement sur le circuit de test. Nous arrêtons l'interception de tous les événements sur le site par une certaine combinaison de touches. Cela vous permet de démarrer et d'arrêter l'enregistrement automatique du scénario de test de n'importe où.Écriture automatique des tests e2e
Si vous regardez le cas de test généré automatiquement, ce sont essentiellement des scripts utilisateur réduits au même format. Ainsi, ils peuvent être convertis en tests e2e. Vous pouvez même écrire immédiatement des tests e2e après avoir intercepté toutes les actions et vérifications, en contournant les cas de test.Il existe maintenant un grand nombre de frameworks différents avec une notation cornichon basée sur des scripts comportementaux: SpecFlow, xBehave.net., Cucumber.js, CodeceptJS, etc.Pour obtenir des fonctionnalités du scénario de test, vous devez ajouter le mot clé When avant les actions et avant toutes les vérifications Alors et Et.Obtenez le test e2e généré automatiquement:Feature: 2-
Background:
When "" ""
Scenario:
When " - "
Then " "
And " - "
When " " ""
When "" " "
When ""
Pour exécuter le test, les fonctionnalités générées sont peu nombreuses - vous devez écrire un gestionnaire pour toutes les actions et vérifications.Il y a une bonne nouvelle: vous n'avez pas besoin d'écrire un gestionnaire pour chaque fonctionnalité. Comme je l'ai déjà dit, malgré le grand nombre de formulaires différents sur le site, nous n'avons obtenu que 30 actions et vérifications uniques, ce qui signifie que le même nombre de méthodes sera exactement dans le processeur général pour tous les tests e2e. Le code sera légèrement différent - selon le cadre choisi avec la notation cornichon et la disposition sur le site. Mais l'écriture du gestionnaire lui-même ne prend pas beaucoup de temps.When(' {string}', async function (button: string) {
const xpath = "//button"
const btn = await getItemByText(xpath, button)
await waitAndClick(btn)
})
When(' {string} {string}', async function (label: string, text: string) {
const xpath = "//*[contains(text(),'" + label + "')]/ancestor::outline"
await inputSendKeys(currentBrowser().element(by.xpath(xpath)), text)
})
Maintenant, en vérifiant la tâche suivante, un scénario de test est automatiquement écrit pour le testeur et le test e2e généré automatiquement est exécuté.En bref, vous devez:- Abonnez-vous aux événements d'interaction avec les contrôles et à la réaction du site à ces actions (grâce au suivi de la reconstruction de l'arborescence DOM).
- Convertissez les données du paragraphe 1 en tests e2e.
- Écrivez un gestionnaire général pour exécuter les tests e2e.
Cette approche vous aidera à vous éloigner de la routine. Vous pouvez automatiser l'écriture des cas de test et des tests e2e pour des vérifications simples liées à l'interface. Nous sommes allés encore plus loin et vérifions automatiquement également l'enregistrement dans la base de données et l'envoi à des services tiers.J'en ai parlé, ainsi que du versioning, de la pile technologique, et même des problèmes lors de la première étape de la mise en œuvre et de leur solution lors de la conférence Heisenbug-2019 à Moscou .Dans cet article, j'ai essayé de transmettre l'idée principale sans entrer dans les détails.Conclusion
Il nous faut maintenant 2 minutes en moyenne pour écrire un cas de test et un test e2e - c'est 60 fois plus rapide que les calculs initiaux, lorsque nous voulions écrire des cas de test et des tests e2e manuellement.Nous n'avons pas changé les processus dans l'équipe. Il n'était plus nécessaire d'allouer la capacité de test pour l'écriture de cas de test et de la porter à l'équipe d'automatisation.Nous sommes complètement passés de la notion de régression. Si auparavant, avec un sprint de deux semaines, la régression nous a pris plus de 3 jours, maintenant la régression prend du temps pour exécuter tous les tests e2e, et ce n'est que 2 heures.Lors de l'écriture manuelle de tests e2e, il est très difficile d'aller en parallèle avec les tests. Désormais, les tests e2e sont écrits automatiquement pendant le test de la tâche, et le testeur n'a pas besoin de vérifier deux fois la même fonctionnalité.En conséquence, notre équipe, sans changer la composition, a commencé à travailler beaucoup plus efficacement.