how develop test scripts using top 5 most popular test automation frameworks
Lorsque vous commencez à vous familiariser avec l'automatisation des tests, vous devez trouver le terme «cadre d'automatisation des tests». Peut-être que certains d'entre vous se sentent mal à l'aise avec ce terme et commencent à sentir que c'est quelque chose qui est difficile à comprendre et encore plus difficile à mettre en œuvre.
Ce didacticiel est écrit dans le but de vous aider à comprendre le plus simplement possible les cadres d'automatisation de test. Lisez tous les tutoriels dans ce ' Série de didacticiels de test d'automatisation ici .
Cadre d'automatisation des tests (dans un langage très simple) est un «ensemble de règles». Les règles nous aident à écrire des scripts de manière à réduire la maintenance.
Pour comprendre complètement le concept du framework, nous devons d'abord apprendre comment nous écrivons des scripts simples et ensuite comment implémenter un framework sur eux.
Dans l'automatisation des tests, nous écrivons des scripts. Le script est essentiellement composé de trois «A»:
- ARRANGEMENT
- ACTION
- AFFIRMATION
Voici les détails de chaque A, avec des exemples:
#1.ARRANGEMENTou identification d'objet
Nous identifions les objets (boutons, listes déroulantes, etc.) soit par leurs identifiants, noms ou par leurs titres de fenêtre, etc.
Dans le cas d'une application Web, nous identifions par ID utilisateur, ou Par XPath ou Par CSS ou Par nom de classe, etc.
Prenons cet exemple de Selenium WebDriver (avec C #) dans lequel nous identifions des objets à l'aide de l'id. (Application Web)
IWebElement txtServer = _webDriver.FindElement(By.Id('tfsServerURL'));
Un autre exemple de MS Coded UI (application de bureau)
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';
Après identification, nous organisons ou stockons ces objets dans UIMaps ou Object Repository pour les réutiliser dans nos scripts. C'est pourquoi cette étape s'appelle ARRANGEMENT.
#deux.ACTIONsur l'objet identifié
Lorsque les objets sont identifiés, nous effectuons des actions sur eux soit à la souris, soit au clavier.Par exemple, soit on clique, soit on double-clique, soit on passe la souris dessus ou parfois on fait glisser-déposer. Parfois, nous écrivons sur des zones de texte. Ainsi, tout type d'action que nous effectuons sur ces objets est couvert dans cette deuxième étape.
Exemple 1 : (Selenium WebDriver avec C #)
txtServer.Clear(); txtServer.SendKeys(“Some sample text”);
Exemple 2 : (Interface utilisateur codée MS avec C #)
Mouse.Click(buttonAdd);
# 3.AFFIRMATION
L'assertion vérifie essentiellement l'objet avec un résultat attendu. Par exemple, si nous appuyons sur 2 + 3 sur la calculatrice, l'écran devrait afficher 5. Dans ce cas, notre résultat attendu est 5. Ce concept est déjà expliqué dans notre premier tutoriel.
Ici nous donnons un exemple d'assertion:
Assert.AreEqual('5', txtResult.DisplayText);
Presque tous les scripts écrits dans l'automatisation des tests contiennent ces trois éléments: Arrangement, Action et Assertion.
Jetez maintenant un œil à un script complet qui contient toutes ces étapes. Le script ouvrira une calculatrice, appuyez sur 1 + 6, puis vérifiez si l'écran affiche 7 ou non.
Exemple A:
(TestMethod) (TestMethod) public void TestCalculator() { var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //Object identification part (ARRANGEMENT) //----*Calculator Window----*// WinWindow calWindow = new WinWindow(app); calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; //----*Button1 ----*// WinButton btn1 = new WinButton(calWindow); btn1.SearchProperties(WinButton.PropertyNames.Name) = '1'; //----*Button Add ----*// WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add'; //----*Button 6 ----*// WinButton btn6 = new WinButton(calWindow); btn6.SearchProperties(WinButton.PropertyNames.Name) = '6'; //----*Button Equals ----*// WinButton btnEquals = new WinButton(calWindow); btnEquals.SearchProperties(WinButton.PropertyNames.Name) = 'Equals'; //----*Text Box Results----*// WinText txtResult = new WinText(calWindow); txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; //(ACTIONS Part) // Click '1' button Mouse.Click(btn1); // Click 'Add' button Mouse.Click(btnAdd); // Click '6' button Mouse.Click(btn6); // Click 'Equals' button Mouse.Click(btnEquals); //evaluate the results (ASSERTIONS) Assert.AreEqual('7', txtResult.DisplayText, “Screen is not displaying 7); //close the application app.Close(); }
Ce que vous apprendrez:
- Quel est le problème avec ce script?
- Il existe cinq frameworks populaires dans l'automatisation des tests:
- #1. Cadre linéaire:
- # 2. Cadre de modularité:
- # 3. Cadre basé sur les données:
- # 4. Cadre basé sur les mots-clés:
- # 5. Framework d'automatisation des tests hybrides:
- Conclusion
- lecture recommandée
Quel est le problème avec ce script?
Le script est facile à comprendre et j'espère que vous comprendrez le concept de trois «A» dans l'exemple ci-dessus. Mais tout ne va pas bien avec ce script.
Ce script ne permet pas une maintenance aisée. Reprenons l'exemple de la calculatrice, si nous devons écrire des cas de test de chaque fonction de la calculatrice, il y aura de nombreux cas de test. S'il y a 10 cas de test et dans chaque test, nous devons définir le même objet, puis si un changement se produit dans le nom ou l'id de l'objet, nous devons changer la partie d'identification de l'objet dans 10 cas de test.
Par exemple, prenons l'exemple du bouton ADD dans le script.
WinButton btnAdd = new WinButton(calWindow); btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Add';
Disons que cette ligne est utilisée dans 10 cas de test. Maintenant, dans la prochaine version de la calculatrice, le développeur a changé le nom du bouton de «Ajouter» à «Plus». Maintenant, lorsque nous exécutons nos cas de test, ils échoueront et nous devons changer la ligne ci-dessus en 10 cas de test.
btnAdd.SearchProperties(WinButton.PropertyNames.Name) = 'Plus';
Nous devons donc améliorer ce cas de test. Nous devrions suivre le fameux principe DRY dans notre codage. DRY signifie «Ne vous répétez pas». Nous devons écrire la partie d'identification de l'objet de telle manière que l'objet ne doit être identifié qu'à un seul endroit et doit être appelé partout.
Jetez un œil au script amélioré.
Exemple B:
//defining the objects outside the script and only once. ApplicationUnderTest app = null; public WinWindow calWindow { get { WinWindow _calWindow = new WinWindow(app); _calWindow.SearchProperties(WinWindow.PropertyNames.Name) = 'Calculator'; _calWindow.SearchProperties(WinWindow.PropertyNames.ClassName) = 'CalcFrame'; return _calWindow; } } public WinText txtResult { get { WinText _txtResult = new WinText(calWindow); _txtResult.SearchProperties(WinText.PropertyNames.Name) = 'Result'; return _txtResult; } } //making functions for similar kind of tasks public void ClickButton(string BtnName) { WinButton button = new WinButton(calWindow); button.SearchProperties(WinButton.PropertyNames.Name) = BtnName ; Mouse.Click(button); } public void AddTwoNumbers(string number1, string number2) { ClickButton(number1); ClickButton('Add'); ClickButton(number2); ClickButton('Equals'); } //Test case becomes simple and easy to maintain. (TestMethod) public void TestCalculatorModular() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers('6', '1'); //evaluate the results Assert.AreEqual('7', txtResult.DisplayText, “screen is not displaying 7”); //close the application app.Close(); }
Dans l'exemple ci-dessus, nous avons séparé les calWindow et txtResult objets et déplacez-les vers le haut afin qu'ils puissent être utilisés dans différentes méthodes de test. Nous les avons définis une seule fois et nous pouvons les utiliser dans autant de cas de test que nous le souhaitons.
Nous avons également créé deux fonctions. ClickButton () qui accepte un nom de bouton et cliquez dessus et AddTwoNumbers () qui prend n'importe quel nombre de deux et les ajoute en utilisant le cliquez sur le bouton fonction à l'intérieur.
Au moment où nous commençons à «améliorer» notre code et à le rendre réutilisable et maintenable, cela signifie que nous utilisons n'importe quel cadre d'automatisation. Maintenant, ça devient intéressant.
Voir également=> Pourquoi avons-nous besoin du cadre d'automatisation des tests?
Il y a cinq frameworks populaires dans l'automatisation des tests :
- Linéaire
- Modularité
- Axé sur les données
- Mot-clé
- Hybride
Nous allons maintenant expliquer chaque framework à l'aide de ses caractéristiques.
#1. Cadre linéaire:
Caractéristiques
- Tout ce qui concerne un script est défini à l'intérieur des scripts.
- Ne se soucie pas de l'abstraction et de la duplication de code
- L'enregistrement et la lecture génèrent normalement du code linéaire
- Facile à démarrer
- Cauchemar de maintenance.
En lisant les 5 caractéristiques ci-dessus de Linear Framework, nous pouvons facilement leur relier notre exemple A. Cet exemple utilise essentiellement le cadre linéaire, toute chose liée à un script est définie à l'intérieur du script. La fenêtre d'appel et TxtResult sont définis à l'intérieur du script. Le script ne se soucie pas de l'abstraction et de la duplication de code. C'est aussi un cauchemar de maintenance comme je l'ai expliqué plus tôt.
Alors pourquoi devrions-nous utiliser ce cadre?
Ce cadre peut être utilisé dans des projets à petite échelle où il n'y a pas beaucoup d'écrans d'interface utilisateur. De plus, lorsque nous utilisons un outil d'automatisation pour la première fois, il génère normalement du code sous forme linéaire. Nous pouvons donc en savoir plus sur le code généré par l'outil d'automatisation pour des actions spécifiques. En dehors de ces raisons, ce cadre doit être évité dans votre script.
=> Voir ici l'exemple de Linear and Keyword Framework avec exemple QTP.
# 2. Cadre de modularité:
Caractéristiques
- Les objets sont définis une seule fois et réutilisables dans toutes les méthodes de test.
- Des méthodes petites et précises sont créées pour les fonctionnalités individuelles
- Le cas de test est la collection de ces petites méthodes et objets réutilisables
- Cela nous permet d'écrire du code maintenable.
En lisant les caractéristiques ci-dessus, nous pouvons relier notre exemple B à ces caractéristiques. Dans cet exemple, nous avons créé une abstraction en déplaçant le calWindow vers le haut et définissez-le dans une propriété qui peut être utilisée partout. Nous avons créé deux petites fonctions indépendantes appelées ClickButton () et AddTwoNumbers () . Nous combinons ces deux petites fonctions pour créer notre script final qui teste la fonctionnalité «Ajouter» de la calculatrice.
Cela facilite la maintenance. Si un changement se produit dans l'interface utilisateur de la calculatrice, nous ne devons changer que les fonctions. Nos scripts resteront intacts. Ce cadre est très utilisé dans l'automatisation. Le fameux Page Object Framework (qui est utilisé avec Selenium) est aussi une sorte de framework de modularité. Nous distribuons l'ensemble de l'application Web sur des pages séparées. Les boutons, listes déroulantes et cases à cocher de chaque page sont définis à l'intérieur de la classe de cette page. Si un changement se produit sur le site Web, nous devons changer uniquement dans cette classe de page et les autres pages restent intactes. Cela se traduit par une meilleure maintenance et une lisibilité plus facile des scripts.
Le seul inconvénient de ce cadre est qu'il nécessite de bons concepts orientés objet et de solides compétences en développement. Si vous en avez, ce cadre est fortement recommandé.
# 3. Cadre basé sur les données:
Caractéristiques:
- Les données de test (valeurs d'entrée et de sortie) sont séparées du script et stockées dans des fichiers externes. Cela peut être un fichier .CSV, une feuille de calcul Excel ou une base de données.
- Lorsque le script est exécuté, ces valeurs sont sélectionnées dans des fichiers externes, stockées dans des variables et remplacent les valeurs codées en dur si elles sont présentes.
- Vraiment utile dans les endroits où le même scénario de test doit être exécuté avec différentes entrées.
Exemple C:
Nous voulons exécuter le cas de test d'ajout avec trois entrées différentes.
Les données sont
7 + 2 = 9
5 + 2 = 7
3 + 2 = 5
Nous avons stocké ces données (à la fois en entrée et en sortie) dans un fichier CSV externe.
(DataSource('Microsoft.VisualStudio.TestTools.DataSource.CSV', '|DataDirectory|\data.csv', 'data#csv', DataAccessMethod. Sequential ), DeploymentItem('TestCalc\data.csv'), TestMethod) public void TestCalculatorDataDrivsen() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations AddTwoNumbers(FromCSV.ADD1, FromCSV.ADD2); //evaluate the results Assert.AreEqual(FromCSV.Sum, txtResult.DisplayText); //close the application app.Close(); }
Dans le script ci-dessus, nous définissons notre source de données en haut du script, qui est un fichier .csv.
Nous avons donné le chemin de ce fichier .CSV et disons au script de l'analyser «séquentiellement». Cela signifie que le script s'exécutera autant de fois qu'il y a de lignes présentes dans le fichier CSV. Dans notre cas, le script s'exécutera 3 fois. À chaque exécution, il ajoutera les deux nombres définis dans les deux premières colonnes et vérifiera que la somme de ces deux nombres correspond au nombre présent dans la troisième colonne.
Il existe divers avantages de ce cadre. Toutes les valeurs sont stockées en dehors du script, donc si un changement se produit dans la prochaine construction, nous devons simplement changer les données dans le fichier externe et le script restera intact.
Le deuxième avantage est que le même script peut être exécuté pour différentes entrées. Prenons l'exemple d'un ERP dans lequel vous devez tester l'inscription de 100 employés. Vous pouvez écrire un script et stocker les noms et autres données relatives aux employés dans un fichier externe. Vous exécuterez un script et il s'exécutera 100 fois. Chaque fois avec des données d'employés différentes. Vous pouvez facilement détecter sur quelles données le script ne parvient pas à enregistrer l'employé. Ce sera un avantage supplémentaire lorsque vous effectuez des tests négatifs.
=> Voir ici l'exemple de cadre basé sur les données et hybride avec exemple QTP.
# 4. Cadre basé sur les mots-clés:
Caractéristiques:
- Les données et les actions sont définies en dehors du script.
- Il a nécessité le développement de mots-clés pour différents types d'actions.
- La fonctionnalité que nous devons tester est écrite étape par étape sous forme de tableau à l'aide des mots-clés que nous développons et des données de test. Nous stockons cette table dans des fichiers externes, tout comme le framework piloté par les données.
- Le script analysera cette table et exécutera les actions correspondantes.
- Permet au testeur manuel qui ne connaît pas le codage de faire partie de l'automatisation dans une certaine mesure.
Exemple D:
Nous avons défini les données (par exemple 1 + 3 = 4) ainsi que les actions (par exemple, Cliquer, Effacer, etc.) dans un fichier Excel sous forme de tableau.
Le script deviendra quelque chose comme ça (le code ci-dessous est juste écrit à des fins de compréhension)
(TestMethod) public void TestCalculator() { app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); Table tb = ReadFromExcel(); Foreach(WinRow row in tb) { WinCell Window = row.Cells(“Window”); WinCell Control = row.Cells(“Control”); WinCell Action = row.Cells(“Action”); WinCell Arguments = row.Cells(“Arguments”); UITestControl c = GetControl(Control.Text,Window.Text); If(Action.Text == “Click”) Mouse.Click (c); If (Action.Text == “Clear”) c.Clear(); if(Action.Text == “Verify Result”) Assert.AreEqual(c.Text, Arguments.Text) //….and so on } }
Le script ci-dessus est juste un analyseur du fichier Excel. Il analyse le fichier Excel ligne par ligne et recherche des mots-clés pour effectuer les actions respectives. S'il trouve le mot-clé «Click», il cliquera sur l'objet défini. S'il trouve «Vérifier le résultat», il effectuera l'assertion.
Il y a plusieurs avantages à utiliser le framework piloté par mots clés.
Le premier avantage est que ce cadre est très utile dans les scénarios où il existe de grandes chances de changement dans les cas de test. Si une étape change dans un scénario de test, nous n'avons pas besoin de toucher au code. Nous devons juste mettre à jour le fichier Excel et le script sera mis à jour.
Vous pouvez définir tous vos scripts dans un fichier Excel et remettre ce fichier Excel à des testeurs manuels pour ajouter de nouveaux scripts ou mettre à jour les scripts existants. De cette manière, les testeurs manuels peuvent également faire partie de l'automatisation des tests car ils n'ont rien à coder. Ils mettront simplement à jour ce fichier Excel en cas de besoin et les scripts seront automatiquement mis à jour.
Le deuxième avantage est que votre script devient indépendant de l'outil. Vous pouvez conserver vos scripts dans un fichier Excel et si vous avez besoin de modifier votre outil d'automatisation à un moment donné, vous pouvez facilement le modifier en écrivant un analyseur Excel dans un autre outil.
L'inconvénient de ce cadre est que vous devez inventer des mots-clés pour différents types d'actions. Dans les projets à grande échelle, il y aura tellement de mots-clés que vous devez vous souvenir et organiser vos scripts et mots-clés. Cela devient en soi une tâche fastidieuse à un moment donné.
Dans certains scénarios complexes, où les objets ne peuvent pas être facilement identifiés et où nous devons utiliser les coordonnées de la souris et d'autres techniques, ce cadre n'est pas très utile.
La gestion par mots-clés est toujours un cadre favori pour de nombreux testeurs d'automatisation. Cadre de robot by Google est un framework basé sur les mots clés pris en charge par une communauté active.
comment démarrer une carrière dans les tests de qualité
# 5. Framework d'automatisation des tests hybrides:
Caractéristiques:
- La combinaison de deux ou plusieurs des techniques ci-dessus, en tirant parti de leurs forces et en minimisant leurs faiblesses.
- Le cadre peut utiliser l'approche modulaire avec un cadre basé sur les données ou sur les mots clés.
- Le framework peut utiliser des scripts pour effectuer certaines tâches qui pourraient être trop difficiles à implémenter dans une approche basée sur des mots clés purs.
En termes simples, cadre hybride, utilisez la combinaison des techniques mentionnées ci-dessus. Nous pouvons utiliser un cadre axé sur les données qui est également de nature modulaire. Pour certains cas de test, nous pouvons utiliser une approche axée sur les mots clés et pour le reste, nous pouvons utiliser modulaire. Ainsi, chaque fois que nous mélangeons deux ou plusieurs techniques mentionnées dans cet article, nous utilisons en fait une approche hybride.
Conclusion
J'espère que le cadre d'automatisation des tests n'est plus un terme effrayant pour vous maintenant. J'ai essayé d'expliquer le plus simplement possible les frameworks les plus populaires.
Les cadres sont là pour vous faciliter la vie. Ils vous aident à écrire des scripts maintenables et fiables. Sans utiliser de frameworks, le domaine de l'automatisation des tests est un cauchemar. Pour chaque petit changement dans l'application, vous devez changer votre code à des centaines d'endroits.
Donc, une compréhension de ces frameworks est un must pour chaque testeur qui veut un avant-goût de l'automatisation des tests.
Dans notre prochain tutoriel dans cette série, nous apprendrons «Exécution et reporting de l’automatisation des tests».
Si j'ai manqué quelque chose dans cet article ou si vous avez besoin de poser une question, n'hésitez pas à demander dans la section commentaires.
Tutoriel PREV # 4 | Tutoriel SUIVANT # 6
lecture recommandée
- Cadres QTP - Cadres d'automatisation des tests - Exemples de cadres linéaires et pilotés par mots-clés - Didacticiel QTP # 17
- Commandes d'automatisation SeeTest: une explication détaillée avec des exemples
- 10 outils RPA d'automatisation des processus robotiques les plus populaires en 2021
- En quoi la planification des tests diffère-t-elle pour les projets manuels et d'automatisation?
- Les cadres d'automatisation de test les plus populaires avec leurs avantages et leurs inconvénients - Tutoriel Selenium # 20
- Framework d'automatisation des tests sans script: outils et exemples
- Automatisation des tests - Est-ce une carrière spécialisée? Les testeurs normaux peuvent-ils également faire de l'automatisation?
- 25 meilleurs cadres et outils de test Java pour les tests d'automatisation (partie 3)