Comment écrire de bons cas de test en

utilisant Robot Framework

Table des matières:

 introduction
 Appellation
o Noms des suites de tests
o Noms de cas de test
o Les mots-clés
o Nommer l'installation et le démontage
 Documentation
o Documentation de la suite de tests
o Documentation de cas de test
o Documentation de mot-clé utilisateur
 Structure de la suite de tests
 Structure du cas de test
o Tests de workflow
o Tests pilotés par les données
 Mots-clés utilisateur
 Variables
o Nomenclature des variables
o Passer et renvoyer des valeurs
 Évitez de dormir

introduction

 Ce sont des directives de haut niveau pour écrire de bons cas de test en
utilisant Robot Framework.
o Comment interagir avec le système testé est hors de portée de ce
document.
 La ligne directrice la plus importante consiste à garder les cas de test aussi
faciles à comprendre que possible pour les personnes familiarisées avec le
domaine.
o Cela facilite également la maintenance.
 Pour plus d'informations sur ce sujet, vous pouvez jeter un oeil à ces
excellentes ressources:
 o Robot Framework Dos et ne fait pas de diapositives basées sur ce
tutoriel.
o Rédaction d'un article sur les tests d'acceptation automatisés et
maintenables par Dale Emery.
o Comment structurer un post de test d'acceptabilité évolutif et
supportable Suite par Andreas Ebbert-Karroum.

Appellation

Noms des suites de tests

 Les noms de suites doivent être aussi descriptifs que possible.

 Les noms sont créés automatiquement à partir des noms de fichiers ou de
répertoires:
o Les extensions sont supprimées.
o Les underscores sont convertis en espaces.
o Si le nom est en minuscules, les mots sont en majuscules.
 Les noms peuvent être relativement longs, mais les noms trop longs ne sont
pas pratiques pour le système de fichiers.
 Le nom de la suite de niveau supérieur peut être remplacé à partir de la ligne
de commande en utilisant l' --nameoption si nécessaire.

Exemples:

 login_tests.robot -> Login Tests

 IP_v4_and_v6 -> IP v4 and v6

Noms de cas de test

 Les noms de test doivent être descriptifs comme les noms de suites.
 Si une suite contient de nombreux tests similaires et est bien nommée, les
noms de test peuvent être plus courts.
 Le nom est exactement le même que celui que vous avez spécifié dans le
fichier de test sans conversion.

Par exemple, si nous avons des tests liés à une connexion invalide dans un
fichier invalid_login.robot, ce serait OK noms de cas de test:
*** Test Cases ***
Empty Password
Empty Username
Empty Username And Password
Invalid Username
Invalid Password
Invalid Username And Password

Ces noms seraient un peu longs:

*** Test Cases ***

Login With Empty Password Should Fail
Login With Empty Username Should Fail
Login With Empty Username And Password Should Fail
Login With Invalid Username Should Fail
Login With Invalid Password Should Fail
Login With Invalid Username And Invalid Password Should Fail

Les mots-clés

 Les noms de mots clés doivent être descriptifs et clairs.

 Devrait expliquer ce que le mot-clé fait, pas comment il fait sa tâche (s).
 Niveaux d'abstraction très différents (par exemple Input Textou Administrator
logs into system).
 Il n'y a pas de ligne directrice claire sur la question de savoir si un mot-clé doit
être entièrement encadré ou si seule la première lettre doit être mise en
majuscule.
o Le cadrage de titre est souvent utilisé lorsque le nom du mot clé est
court (par exemple Input Text).
o La capitalisation de la première lettre fonctionne généralement mieux
avec des mots-clés qui sont comme des phrases (par
exemple Administrator logs into system). Ces types de mots clés sont
souvent de niveau supérieur.

Bien:

*** Keywords ***

Login With Valid Credentials

Mal:

*** Keywords ***

Input Valid Username And Valid Password And Click Login Button

Nommer l'installation et le démontage

 Essayez d'utiliser le nom qui décrit ce qui est fait.

o Peut-être utiliser un mot-clé existant.
 Plus de noms abstraits sont acceptables si une configuration ou un démontage
contient des étapes indépendantes.
 o La liste des étapes dans le nom est la duplication et un problème de
maintenance (par exemple Login to system, add user, activate alarms
and check balance).
o Souvent préférable d'utiliser quelque chose de générique (par
exemple Initialize system).
 Mot - clé BuiltIn Run Mots - clés peut fonctionner correctement si les mots
clés de mise en œuvre des mesures de niveau inférieur existent déjà.
o Non réutilisable, donc mieux utilisé lorsque le scénario d'installation ou
de démontage n'est nécessaire qu'une seule fois.
 Tous ceux qui travaillent avec ces tests doivent toujours comprendre ce que
fait une installation ou un démontage.

Bien:

*** Settings ***

Suite Setup Initialize System

Bon (si seulement utilisé une fois):

*** Settings ***

Suite Setup Run Keywords
... Login To System AND
... Add User AND
... Activate Alarms AND
... Check Balance

Mal:

*** Settings ***

Suite Setup Login To System, Add User, Activate Alarms And Check Balance

Documentation

Documentation de la suite de tests

 C'est souvent une bonne idée d'ajouter une documentation globale pour
tester les dossiers.
 Doit contenir des informations de base, pourquoi les tests sont créés, des
notes sur l'environnement d'exécution, etc.
 Ne répétez pas simplement le nom de la suite de tests.
o Mieux vaut ne pas avoir de documentation si ce n'est pas vraiment
nécessaire.
 N'incluez pas trop de détails sur les cas de test.
o Les tests doivent être suffisamment clairs pour comprendre seuls.
 o Les informations en double sont un problème de gaspillage et de
maintenance.
 La documentation peut contenir des liens vers plus d'informations.
 Envisagez d'utiliser des métadonnées de suite de tests si vous avez besoin de
documenter des informations représentées par des paires nom-valeur (par
exemple Version: 1.0ou OS: Linux).
 La documentation et les métadonnées de la suite de niveau supérieur peuvent
être définies à partir de la ligne de commande en utilisant --docet --
metadataoptions, respectivement.

Bien:

*** Settings ***

Documentation Tests to verify that account withdrawals succeed and
... fail correctly depending from users account balance
... and account type dependent rules.
... See http://internal.example.com/docs/abs.pdf
Metadata Version 0.1

Mauvais (surtout si la suite est bien nommée account_withdrawal.robot):

*** Settings ***

Documentation Tests Account Withdrawal.

Documentation de cas de test

 Le test n'a normalement pas besoin de documentation.

o Le nom et la documentation possible de la suite parent et le nom du
test devraient fournir suffisamment d'informations générales.
o La structure du cas de test doit être suffisamment claire sans
documentation ni autres commentaires.
 Les balises sont généralement plus flexibles et offrent plus de fonctionnalités
(statistiques, inclusion / exclusion, etc.) que la documentation.
 Parfois, la documentation de test est utile. Pas besoin d'avoir peur de l'utiliser.

Bien:

*** Test Cases ***

Valid Login
[Tags] Iteration-3 Smoke
Open Login Page
Input Username ${VALID USERNAME}
Input Password ${VALID PASSWORD}
Submit Credentials
Welcome Page Should Be Open

Mal:
*** Test Cases ***
Valid Login
[Documentation] Opens a browser to login url, inputs valid username
... and password and checks that the welcome page is open.
... This is a smoke test. Created in iteration 3.
Open Browser ${URL} ${BROWSER}
Input Text field1 ${UN11}
Input Text field2 ${PW11}
Click Button button_12
Title Should Be Welcome Page

Documentation de mot-clé utilisateur

 Pas nécessaire si le mot clé est relativement simple.

o Un bon mot-clé, des noms d'arguments et une structure claire devraient
suffire.
 Une utilisation importante est la documentation des arguments et des valeurs
de retour.
 Illustré dans la documentation du fichier de ressources générée avec Libdoc et
les éditeurs tels que RIDE peuvent l'afficher dans l'achèvement des mots clés
et ailleurs.

Structure de la suite de tests

 Les tests dans une suite doivent être liés les uns aux autres.
o L'installation et / ou le démontage commun est souvent un bon
indicateur.
 Ne devrait pas avoir trop de tests (max 10) dans un fichier sauf s'il s'agit
de tests pilotés par les données .
 Les tests devraient être indépendants. Initialisation en utilisant setup /
teardown.
 Parfois, les dépendances entre les tests ne peuvent pas être évitées.
o Par exemple, cela peut prendre trop de temps pour initialiser tous les
tests séparément.
o Ne jamais avoir de longues chaînes de tests dépendants.
o Envisagez de vérifier l'état du test précédent en utilisant la ${PREV TEST
STATUS}variable intégrée .

Structure du cas de test

 Le cas de test devrait être facile à comprendre.

 Un cas de test devrait tester une chose.
 o Les choses peuvent être petites (partie d'une seule entité) ou grandes
(de bout en bout).
 Sélectionnez le niveau d'abstraction approprié.
o Utiliser le niveau d'abstraction de manière cohérente (principe du
niveau d'abstraction unique).
o N'incluez pas de détails inutiles au niveau du scénario de test.
 Deux types de cas de test:
o Tests de workflow
o Tests pilotés par les données

Tests de workflow

 Généralement avoir ces phases:

o Condition préalable (facultatif, souvent dans la configuration)
o Action (faire quelque chose au système)
o Vérification (valider les résultats, obligatoire)
o Nettoyage (facultatif, toujours dans le démontage pour s'assurer qu'il
est exécuté)
 Les mots-clés décrivent ce qu'un test fait.
o Utilisez des noms de mots clés clairs et un niveau d'abstraction
approprié.
o Doit contenir suffisamment d'informations pour être exécuté
manuellement.
o Ne devrait jamais avoir besoin de documentation ou de commentaire
pour expliquer ce que le test fait.
 Différents tests peuvent avoir différents niveaux d'abstraction.
o Les tests pour une fonctionnalité détaillée sont plus précis.
o Les tests de bout en bout peuvent être de très haut niveau.
o Un test ne doit utiliser qu'un seul niveau d'abstraction
 Différents styles:
o Tests plus techniques pour les détails de niveau inférieur et les tests
d'intégration.
o Les "spécifications exécutables" agissent en tant qu'exigences.
o Utilisez la langue du domaine.
o Tout le monde (y compris le client et / ou le propriétaire du produit)
doit toujours comprendre.
 Aucune logique complexe au niveau du scénario de test.
o Non pour les boucles ou if / else construit.
o Utilisez les affectations de variables avec précaution.
 o Les cas de test ne doivent pas ressembler à des scripts!
 Max 10 étapes, de préférence moins.

Exemple utilisant un style "normal" basé sur un mot clé:

*** Test Cases ***

Valid Login
Open Browser To Login Page
Input Username demo
Input Password mode
Submit Credentials
Welcome Page Should Be Open

Exemple utilisant un style "gherkin" de niveau supérieur:

*** Test Cases ***

Valid Login
Given browser is opened to login page
When user "demo" logs in with password "mode"
Then welcome page should be open

Voir le projet de démonstration web pour les versions exécutables des exemples ci-
dessus.

Tests pilotés par les données

 Un mot-clé de haut niveau par test.

o Des arguments différents créent des tests différents.
o Un test peut exécuter plusieurs fois le même mot clé pour valider
plusieurs variantes associées
 Si le mot-clé est implémenté en tant que mot-clé d'utilisateur, il contient
généralement un flux de travail similaire à celui des tests de workflow .
o Sauf si nécessaire ailleurs, il est judicieux de le créer dans le même
fichier que les tests qui l'utilisent.
 Recommandé pour utiliser la fonctionnalité du modèle de test .
o Pas besoin de répéter le mot-clé plusieurs fois.
o Plus facile de tester plusieurs variations dans un test.
 Possible et recommandé pour nommer les en-têtes de colonnes
 Si un très grand nombre de tests est nécessaire, envisagez de les générer en
fonction d'un modèle externe.

Exemple:

*** Settings ***

Test Template Login with invalid credentials should fail
*** Test Cases *** USERNAME PASSWORD
Invalid Username invalid ${VALID PASSWORD}
Invalid Password ${VALID USERNAME} invalid
Invalid Both invalid invalid
Empty Username ${EMPTY} ${VALID PASSWORD}
Empty Password ${VALID USERNAME} ${EMPTY}
Empty Both ${EMPTY} ${EMPTY}

*** Keywords ***

Login with invalid credentials should fail
[Arguments] ${username} ${password}
Input Username ${username}
Input Password ${password}
Submit Credentials
Error Page Should Be Open

Le projet de démonstration Web contient également une version exécutable de cet

exemple.

Mots-clés utilisateur

 Devrait être facile à comprendre.

o Mêmes règles que pour les tests de workflow.
 Différents niveaux d'abstraction.
 Peut contenir une logique de programmation (pour les boucles, if / else).
o Surtout sur les mots-clés de niveau inférieur.
o Logique complexe dans les bibliothèques plutôt que dans les mots-clés
des utilisateurs.

Variables

 Encapsuler des valeurs longues et / ou compliquées.

 Transmettez les informations à partir de la ligne de commande en utilisant l' --
variableoption.
 Transmettre des informations entre les mots-clés

Nomenclature des variables

 Des noms clairs mais pas trop longs.

 Peut utiliser les commentaires dans la table des variables pour les documenter
davantage.
 Cas d'utilisation systématiquement:
 o Minuscule avec des variables locales uniquement disponibles dans une
certaine portée.
o Majuscules avec d'autres (niveau global, suite ou test).
o L'espace et le trait de soulignement peuvent être utilisés comme
séparateur de mots.
 Recommandé pour également lister les variables qui sont définies
dynamiquement dans la table de variables.
o Définissez généralement à l'aide du mot clé BuiltIn Set Suite Variable .
o La valeur initiale devrait expliquer où / comment la valeur réelle est
définie.

Exemple:

*** Settings ***

Suite Setup Set Active User

*** Variables ***

# Default system address. Override when tested agains other instances.
${SERVER URL} http://sre-12.example.com/
${USER} Actual value set dynamically at suite setup

*** Keywords ***

Set Active User
${USER} = Get Current User ${SERVER URL}
Set Suite Variable ${USER}

Passer et renvoyer des valeurs

 L'approche commune consiste à renvoyer des valeurs à partir de mots-clés, à

les affecter à des variables, puis à les transmettre en tant qu'arguments à
d'autres mots-clés.
o Approche claire et facile à suivre.
o Permet de créer des mots-clés indépendants et facilite la réutilisation.
o On dirait que la programmation est moins bonne au niveau du scénario
de test.
 Une approche alternative consiste à stocker des informations dans une
bibliothèque ou à utiliser le mot-clé BuiltIn Set Test Variable .
o Évitez le style de programmation au niveau du scénario de test.
o Peut être plus complexe à suivre et rendre plus difficile la réutilisation
de mots-clés.

Bien:

*** Test Cases ***

Withdraw From Account
Withdraw From Account $50
Withdraw Should Have Succeeded
*** Keywords ***
Withdraw From Account
[Arguments] ${amount}
${STATUS} = Withdraw From User Account ${USER} ${amount}
Set Test Variable ${STATUS}

Withdraw Should Have Succeeded

Should Be Equal ${STATUS} SUCCESS

Pas si bon:

*** Test Cases ***

Withdraw From Account
${status} = Withdraw From Account $50
Withdraw Should Have Succeeded ${status}

*** Keywords ***

Withdraw From Account
[Arguments] ${amount}
${status} = Withdraw From User Account ${USER} ${amount}
[Return] ${status}

Withdraw Should Have Succeeded

[Arguments] ${status}
Should Be Equal ${status} SUCCESS

Évitez de dormir

 Le sommeil est une façon très fragile de synchroniser les tests.

 Les marges de sécurité provoquent des séjours trop longs en moyenne.
 Au lieu de dort, utilisez le mot-clé que les sondages ont une certaine action
s'est produite.
o Les mots-clés commencent souvent par Wait ....
o Devrait avoir un délai maximum d'attente.
o Possibilité d'envelopper d'autres mots-clés dans le mot-clé BuiltIn Wait
Until Keyword Succeeds .
 Parfois, dormir est la solution la plus facile.
o Toujours utiliser avec soin.
o N'utilisez jamais de mots-clés utilisés fréquemment par des tests ou
d'autres mots-clés.
 Peut être utile dans le débogage pour arrêter l'exécution.
o La bibliothèque de dialogues fonctionne souvent mieux.