11. HITEMA – Groupama Gan Vie L’automatisation des tests fonctionnels SIMON Emeline 10 Il faut évidemment tester les scénarios « passants » : quels sont les résultats attendus pour une utilisation correcte ? Mais il faut également tester les scénarios non passants – aussi appelés « bloquants » : que se passe-t-il si je provoque une erreur ? La réponse à cette question est définie entre le client, la maitrise d’ouvrage et la maitrise d’œuvre. Il faut définir ce que le client attend et ce qui est réalisable, c’est la maitrise d’ouvrage qui effectue le lien entre les deux parties. Créer un scénario pour tester une fonctionnalité nécessite d’envisager une multitude de tests différents. Prenons l’exemple d’un champ de saisie à l’écran : si celui-ci attends un numéro de téléphone, il faut tester l’écriture d’un numéro de téléphone à 10 chiffres et vérifier que cela ne provoque pas d’erreur. Il faut également tester l’écriture de caractères (voire caractères spéciaux) pour provoquer une erreur. Mais aussi : un mix entre chiffre et lettres, un champ vide (ce champ est- il obligatoire ou facultatif ?), la taille du champ (celui-ci est-il limité ?)… Tous ces scénarios sont écris uniquement sur une seule et même «fonction » : celle du champ « numéro de téléphone ». Il y a donc environ 6 tests pour celui-ci, tout en sachant que l’on peut en faire 1, 2 ou plus, en fonction du temps imparti et de la pertinence des scénarios. Cet exemple basique prouve qu’il existe alors une quantité importante de tests pour une application. De nos jours, chaque logiciel ou applications possède plusieurs interfaces, composées elle-même de plusieurs fonctionnalités, boutons et autres actions. Ces actions peuvent être très simple comme l’exemple précédent ou bien plus compliquées : on peut imaginer des affichages de données en fonction de critères choisis, mais encore des envois de mails automatiques à des adresses différentes en fonction d’une maille entité / produit / objet. C. L’exécution de recette et les suivis d’avancement. Un cahier de recette correctement rédigé et précis, facilite grandement le travail à effectuer sans oublier de tests « évidents ». Cela permet également un suivi du travail effectué ou non, en cours, validé ou non. Ce cahier permet aussi de répertorier les problèmes rencontrés. En effet, le but étant de corriger les anomalies découvertes, il est ainsi très pratique de savoir pour chaque scénario ce qui pose problème. Lorsqu’un bogue est découvert, nous procédons comme suit : - Définir si le bogue est reproductible o Si oui, alors il est assez simple de définir la manipulation effectuée. o Si non, cela peut être dû à un problème qui n’est pas lié au développement, mais d’éléments externes (exemple : mauvaise connexion internet). Cela peut être également un problème « aléatoire ». Dans ce dernier cas, il est difficile de les résoudre. - Définir le périmètre du bogue : entité, écran, utilisateurs particuliers, etc. - Rapporter le bogue aux développeurs et le rapporter dans le cahier de tests. Pendant que l’anomalie est en cours d’analyse et de correction chez l’équipe de développement, la maitrise d’ouvrage peut poursuivre les autres tests. Lorsque le bogue est corrigé, un patch est alors appliqué et il est possible de tester à nouveau le scénario bloquant. Ce schéma est répété jusqu’à ce que le scénario soit complètement validé.
The total number of relays, cam timers and drum sequencers can number into the hundreds or even thousands in some factories. Early programming techniques and languages were needed to make such systems manageable, one of the first being ladder logic, where diagrams of the interconnected relays resembled the rungs of a ladder. Special computers called programmable logic controllers were later designed to replace these collections of hardware with a single, more easily re-programmed unit.
Likewise, a Feedback Control System is a system which tends to maintain a prescribed relationship of one system variable to another by comparing functions of these variables and using the difference as a means of control.[6] The advanced type of automation that revolutionized manufacturing, aircraft, communications and other industries, is feedback control, which is usually continuous and involves taking measurements using a sensor and making calculated adjustments to keep the measured variable within a set range.[7][8] The theoretical basis of closed loop automation is control theory.

14. HITEMA – Groupama Gan Vie L’automatisation des tests fonctionnels SIMON Emeline 13 3) QAWizard QAWizard, de la société Seapine Software, ne manque pas d’intérêt malgré une présence encore marginale en France. Peu onéreux, QAWizard est très simple d’utilisation. Le passage d’un mode « tableau » pour les débutants à un mode « code » pour les testeurs aguerris permet d’appréhender progressivement et en douceur la complexité des tests fonctionnels. Le support en France reste un des points faibles du produit. B. Les logiciels de tests sur mobile Comme expliqué dans le paragraphe précédent, il existe une multitude de logiciel afin d’automatiser les tests sur PC. Ces logiciels ne sont pas adaptés pour réaliser des tests sur mobile. En effet, une application mobile est parfois développée dans un langage qui diffère de ceux utilisés pour une application PC. Il y a également des actions qui ne sont pas réalisables sur un PC (le zoom à deux doigts par exemple) et donc non pris en compte par les logiciels de test PC. On retrouve notamment les langages JAVA pour Android, mais aussi Objective C pour IOS, et plus couramment HTML5 / JavaScript qui reste le langage le plus simple à ce jour. Je vais dans cette partie exposer les moyens qui ont été conçu afin de réaliser des tests fonctionnels automatisés pour les mobiles. 1) Des tests spécifiques aux mobiles Il existe certains types de tests qui ne sont présents que pour les téléphone portable / tablettes. Ils sont réalisés par les constructeurs de ceux-ci : Les tests d'interopérabilité (IOT) Ces tests sont réalisés en général dans les labos des opérateurs pour s'assurer que le mobile qu'ils vont proposer à leur client est capable de communiquer correctement avec leur réseau sans perturbation. La variété d'équipements avec des fournisseurs différents permet à l'opérateur de réduire les coûts de son réseau en faisant jouer la concurrence, mais aussi d'éviter d'être dépendant d'un seul fabriquant au risque de se confronter à l'obligation de renouveler complètement son réseau au cas où son principal fournisseur disparaît. Ces équipements remplissent les mêmes normes de fonctionnement d'un constructeur à un autre ; mais la norme ne les oblige pas à intégrer les mêmes protocoles de communication. Ce qui explique le but des tests IOT qui permet de s'assurer que le mobile est capable de communiquer avec tous les types d'équipements du réseau de l'opérateur. Les tests protocolaires ou procédures (couche 3 du réseau mobile) Ces tests sont réalisés par les fabricants de téléphonie mobile. Le but est de s'assurer que le mobile implémente correctement les procédures ou protocoles de niveau 3 (couche réseau), comme par exemple les procédures de mise à jour de localisation, l'attachement sur une cellule convenable, les appels entrants et sortants, etc....

Selenium IDE est une extension développée pour Firefox par Shinya Kasatani. Il permet d’utiliser Selenium sans passer par un serveur pour l’exécution de scripts Selenium. Il a été développé en JavaScript et a été conçu pour permettre aux testeurs et aux développeurs d’enregistrer des interactions avec le navigateur. Ces interactions peuvent par la suite être rejoué sous la forme de scénario d’interaction pour simuler un processus fonctionnel à tester. Selenium IDE permet d'enregistrer, d'éditer et déboguer les tests. Il n'est pas seulement un outil d'enregistrement : il s'agit d'un environnement de développement intégré (IDE). L'utilisateur peut choisir d'utiliser sa capacité d'enregistrement, ou peut modifier ses scripts à la main s'il le souhaite.
PhantomJS va nous servir de "Web-Driver" et cela sera là son unique utilité. De quoi s'agit-il ? Afin que Python puisse interagir avec le navigateur Web (Chrome, Firefox ou autres), de la même manière que la communication avec une base de données, il nous faut un driver (pilote). C'est là qu'intervient le Web Driver, il permet la communication entre le navigateur Web et notre script Python. De base, Selenium peut utiliser différents drivers pour différents navigateurs (Chrome, Firefox, Opéra) mais ce qui nous intéresse, ce n'est pas d'ouvrir un navigateur mais d'avoir un navigateur headless (sans interface graphique, uniquement en ligne de commandes). C'est là qu'intervient PhantomJS, qui fournit lui-même son Web Driver. L'utilité c'est donc la rapidité d'exécution par rapport aux navigateurs classiques.
×