L’automatisation ne rend pas forcément le test logiciel plus rapide, plus fiable ou moins onéreux. Les coûts initiaux liés à la configuration et aux outils d’automatisation pouvant être élevés, l’automatisation des tests n’est profitable que si les coûts à long terme compensent ces dépenses initiales. En outre, les outils et méthodologies d’automatisation ne possèdent pas tous les mêmes caractéristiques, fonctionnalités et capacités, et chaque projet peut répondre à des exigences différentes, ce qui a des répercussions sur les coûts et les bénéfices.
Les tests fonctionnels sont un excellent processus de test exhaustif qui parcoure toutes les couches d’une application. Toutefois, pour s’assurer de l’absence des anomalies, il est nécessaire de réitérer la totalité des tests suite à chaque évolution de l’application. L’exécution manuelle des tests fonctionnels d’une application en perpétuelle évolution, est longue et assujettie aux erreurs humaines. En outre, ce processus coûteux, bien qu’il soit nécessaire pour assurer la qualité de l’applicatif, il pousse souvent les organisations à s’en passer, l’exécuter partiellement ou – dans les meilleurs des cas – fixer un cycle de release assez long laissant le temps nécessaire aux tests et validation. Cette dernière alternative assure la qualité de l’application mais diminue considérablement sa compétitivité : Un bon compromis serait d’investir dans l’automatisation des tests fonctionnels. Dans ce qui suit nous étudierons les types d’outils d’automatisation disponibles et justifierons le choix porté sur l’un d’eux.
Chaque logiciel présenté ci-après gère son référentiel d’objets d’une manière différente. vTest propose de visualiser et de modifier les propriétés uniquement des objets qui sont reconnus lors des tests. TestComplete et TestPartner permettent de créer des modèles ou des objets-types et donnent la possibilité de faire reconnaître au logiciel des objets complexes aux propriétés personnalisées.
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é.
24. HITEMA – Groupama Gan Vie L’automatisation des tests fonctionnels SIMON Emeline 23 Bibliographie / Webographie https://fr.wikipedia.org/wiki/Test_unitaire https://fr.wikipedia.org/wiki/Extreme_programming#Tests_de_recette_.28ou_tests_fonctionnels.29 http://blog.octo.com/demarches-de-tests-fonctionnels/ http://fr.slideshare.net/gmantel/automatisation-des-tests-le-mythe-du-roi https://fr.wikipedia.org/wiki/Mantis_Bug_Tracker http://www.e-systemes.com/live-blog/suivi-des-bugs-et-des-projets-quelle-application-pour-e- systemes/434/ http://atatorus.developpez.com/tutoriels/java/test-application-web-avec-selenium/#LI http://www.osaxis.fr/blog/automatiser-ses-tests-fonctionnels-partie-2-2/ http://www.zdnet.fr/actualites/6-conseils-pour-les-tests-d-applications-mobiles-39806167.htm http://www.all4test.fr/actualites/477-test-mobile-comment-tester-les-applications-mobiles https://fr.wikipedia.org/wiki/CAPTCHA http://www.nextinpact.com/news/91233-recaptcha-google-veut-prouver-que-vous-netes-pas-robot- avec-case-a-cocher.htm http://www.conseilorga.com/publications/recettes-tests-et-qualifications Livre : Industrialiser le test fonctionnel - 2e édition: Pour maîtriser les risques métier et accroître l'efficacité du test - Bruno Legeard, Fabrice Bouquet, Natacha Pickaert
Sectional electric drives were developed using control theory. Sectional electric drives are used on different sections of a machine where a precise differential must be maintained between the sections. In steel rolling, the metal elongates as it passes through pairs of rollers, which must run at successively faster speeds. In paper making the paper sheet shrinks as it passes around steam heated drying arranged in groups, which must run at successively slower speeds. The first application of a sectional electric drive was on a paper machine in 1919.[38] One of the most important developments in the steel industry during the 20th century was continuous wide strip rolling, developed by Armco in 1928.[39]
Alors oui, on peut considérer qu’utiliser plusieurs niveaux de tests est une opération répétitive dans le sens ou plusieurs intervenants vont devoir tester plusieurs fois le projet avec des méthodologies différentes. Néanmoins, ce n’est pas redondant car la recherche d’anomalie est beaucoup plus efficace et permet de détecter des instabilités liés à des mécanismes différents.
29. L’automatisation des tests fonctionnels SIMON Emeline Annexe 4 : Exemple de test avec Selenium, classe Selenium. public class selenium { private Selenium selenium; @Before public void setUp() throws Exception { WebDriver driver = new FirefoxDriver(); String baseUrl = "http://localhost:8080/tutoselenium"; selenium = new WebDriverBackedSelenium(driver, baseUrl); } @Test public void testSelenium() throws Exception { // Connexion au site selenium.open("/tutoselenium/"); // On est page 1, on va page 2 selenium.type("id=contentForm:pageText", "2"); selenium.click("id=contentForm:nextPage"); selenium.waitForPageToLoad("30000"); // puis page 3 selenium.click("id=contentForm:page3Button"); selenium.waitForPageToLoad("30000"); // et retour page 1 selenium.select("id=contentForm:pageList_input", "value=1"); selenium.click("id=contentForm:nextPageButton"); selenium.waitForPageToLoad("30000"); // On passe en anglais selenium.click("id=headerForm:english_button"); // etc. } @After public void tearDown() throws Exception { selenium.stop(); } }

En effet, les développeurs construisent une application plus robuste et adaptable aux changements grâce au développement et à l’utilisation de tests unitaires et de tests d’intégration. Sans l’utilisation de ces tests, plus les développements avanceraient et plus les développements seraient ralentis. Chaque modification consommerait plus de charge au fil du temps.
Elle contient  une collection  d’API open-source qui sont utilisées pour automatiser le test d’une application Web. Disponible pour plusieurs langages, l’API permet de programmer des scripts d’actions à réaliser sur l’application Web directement dans le navigateur, pour en vérifier ensuite le comportement par inspection du document de la page Web.. Les actions à réaliser peuvent également être exportées depuis Selenium IDE.
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....
Toutes vos actions sont enregistrées dans un log que vous pouvez modifier. Wildfire contient un « workflow editor » qui vous permet d’éditer les actions enregistrées. Vous pouvez facilement modifier une URL saisie, ajouter ou supprimer des actions : clic, nouvel onglet, fermeture d’onglet, saisie de texte, ajout d’une variable, d’une fonction personnalisée, scroll, sélection de texte, copier/coller, import CSV…
×