Test automatisé de l'application de bureau :aperçu de l'opportunité et des cadres

Présentation

Vous avez certainement entendu parler des tests de régression et d'acceptation. Mais savez-vous combien est réellement dépensé pour les tests d'acceptation dans un projet ?
Nous pouvons rapidement obtenir une réponse à cette question à l'aide d'un système de suivi du temps comme TMetric.
Sur notre projet, les tests d'acceptation une application de bureau d'environ 100 assemblages a pris plus de 2 semaines-personnes. Les nouveaux spécialistes de l'assurance qualité qui ne connaissaient pas bien l'application rencontraient les plus grandes difficultés. Comparés à des spécialistes de l'assurance qualité plus expérimentés, ils ont passé beaucoup plus de temps sur chaque cas de test.
Cependant, à mon avis, la partie la plus désagréable était la suivante :si des erreurs critiques sont détectées avant la publication, les tests d'acceptation doivent être à nouveau effectués. une fois ces erreurs corrigées.
Les tests unitaires écrits ont un peu aidé, mais ils ont tout de même largement réduit le temps consacré aux tests de régression. Ainsi, lorsque la quantité de tests manuels a atteint un niveau critique, nous avons commencé à nous diriger vers l'automatisation.

ROI

Avant d'écrire des tests d'interface utilisateur automatisés, nous devions évaluer la rentabilité de nos investissements. Nous l'avons fait avec l'aide du ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Calculer le ROI des tests d'interface utilisateur est également devenu une tâche intéressante avec de multiples variables inconnues :

ROI =Bénéfice / Dépenses
ou
ROI =(Bénéfice - Dépenses) / Dépenses

À ce stade, nous avions besoin d'un petit prototype qui nous aiderait à estimer toutes les dépenses nécessaires. Il a montré des résultats très particuliers :effectuer des tests d'acceptation prend à peu près le même temps que l'automatisation de ce processus. Au début, ces informations semblaient douteuses, mais lorsque nous avons approfondi nos recherches, les raisons sont devenues claires :

• Les nouveaux spécialistes du contrôle qualité peuvent avoir une compréhension limitée des étapes décrites dans les scénarios de test. Lorsque cela se produit, quelques personnes seront impliquées dans les tests d'acceptation pour aider à mieux comprendre la situation. Ici, nous devons également garder à l'esprit la question de la pertinence des informations dont nous disposons sur les paramètres et les exigences de l'environnement.
• Parfois, les personnes impliquées dans les tests d'acceptation passent du temps à apprendre la documentation technique.
• L'application elle-même interagit avec un ensemble spécifique de services. Si l'un d'entre eux n'est pas disponible, les spécialistes QA moins expérimentés passeront du temps à décrire des bugs que les développeurs vont, à leur tour, investiguer. Par conséquent, du temps est perdu car le service nécessaire ne fonctionnait tout simplement pas correctement après une panne de courant/une mise à jour du matériel/un redémarrage de l'ordinateur.
• Les ordinateurs des testeurs QA ne sont pas très puissants. S'il n'y a pas de SSD, vous le remarquerez déjà lors de l'installation. De plus, si l'application fonctionne sous une charge importante, il est possible qu'un fichier de pagination lent soit utilisé.
• Pour être honnête, nous nous sommes laissés emporter et avons oublié que nous travaillions avec l'automatisation. Au fait, avez-vous fermé l'onglet Youtube de votre navigateur ?

Revenons maintenant au retour sur investissement. Pour simplifier les choses, les calculs ont été effectués par temps. Calculons le bénéfice en tant qu'économies sur les tests manuels, et la période que nous examinerons est d'un an :

Bénéfice =(X – Y) * N =(60 – 1) * 8 =472 jours

X - temps passé sur les tests manuels (60 jours)
Y - temps passé sur la réalisation de tests automatisés (1 jour)
N - la durée d'acceptation a été effectuée

Ensuite, nous examinerons les dépenses :

Dépenses =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80

A – Le coût de la licence de l'outil d'automatisation. Dans notre cas, un outil gratuit a été utilisé.
B – Formation d'un spécialiste QA (10 jours)
C – Préparation de l'infrastructure (5 jours)
D – Développement des tests (50 jours)
E - Exécution des tests et description des bugs découverts dans le processus (7 jours)
F - Maintenance des tests (8 jours)

Total :

ROI =Bénéfice / Dépenses =472 / 80 =5,9

Bien sûr, certains des aspects ici sont estimés. Pour évaluer nos propres calculs, nous avons passé du temps à étudier les fonctionnalités offertes par les solutions payantes et divers calculateurs de retour sur investissement. Avec cela, nous avons calculé la valeur moyenne du retour sur investissement de 2 ou 3, ce qui est un excellent résultat.

Frameworks existants

Après avoir examiné les questions d'organisation, concentrons-nous sur les questions d'ordre technique. Le plus important d'entre eux a été de choisir un framework pour automatiser les tests de notre application de bureau. Nous avions les exigences suivantes en fonction des fonctionnalités de notre projet :

• Les tests seront développés et exécutés sur des machines Windows
• Le cadre doit être adapté pour tester les applications de bureau
• Les tests d'interface utilisateur peuvent être intégrés au processus CI. Nous utilisions déjà Jenkins, donc c'était préférable ici
• La possibilité d'écrire des tests dans un IDE convivial :il doit disposer de la coloration syntaxique, de la navigation dans les scripts de test et de la complétion de code de style IntelliSense
• Dépenses minimales pour la formation au contrôle qualité. Pour certaines raisons, nos spécialistes QA ne voulaient pas écrire des tests dans Brainfuck
• Une communauté sur Stack Overflow, MSDN, etc. est préférable

Test terminé

Cette plateforme nous a d'abord séduits par sa maturité, ce qui laissait espérer sur les aspects techniques.
La première chose que nous avons rencontrée était un IDE instable et plutôt obsolète. L'environnement a géré la mise en évidence de la syntaxe plus ou moins correctement, mais il y avait des problèmes importants avec la navigation (Aller à la définition), la recherche et l'auto-complétion du code :cette fonctionnalité ne fonctionnait pas du tout environ 60 % du temps. L'enregistreur intégré et un analogue Inspect ont bien fonctionné. Au final, l'IDE nous a donné une mauvaise surprise lorsqu'il a commencé à passer des arguments à l'application. Cela, comme on pouvait s'y attendre, a provoqué des erreurs dans les performances de l'application :

--no-sandbox
program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent

À ce stade, nous avons impliqué le support de TestComplete dans la situation pour essayer de gagner du temps et d'évaluer la qualité du support technique avant d'acheter éventuellement une licence. Après quelques lettres envoyées au support technique, nous avons obtenu une réponse – nous devrions ignorer les arguments passés à l'application. Bizarre, n'est-ce pas ? En poursuivant nos recherches, nous avons découvert que ces arguments sont nécessaires pour tester les applications qui utilisent CEF. Dans notre lettre suivante, nous avons déclaré que nous utilisions CEF, et les spécialistes du support nous ont dit de ne pas ignorer les arguments. Lorsque nous avons demandé comment les utiliser exactement, la réponse est revenue à "Ignorer les arguments".
Laissant notre conversation avec le support technique, nous nous sommes tournés vers la documentation de l'IDE (sans trop d'espoir). Il avait plus d'informations, mais nous n'avons rien trouvé concernant le cas en question. De plus, selon cette même documentation, l'IDE aurait dû se comporter différemment depuis le début.
Il est supposé que les tests dans TestComplete seront écrits en utilisant VBScript.

Si vous le regardez assez longtemps, vous pouvez l'entendre. Microsoft suggère de convertir cette "merveille" en scripts PowerShell. Comme alternative, JavaScript et Python peuvent être utilisés, ce qui améliore la situation.

En tant qu'outil gratuit, TestComplete serait supportable, mais leur site a une page de tarification, et les prix sont par utilisateur. En conséquence, voici ce que nous obtiendrons après l'achat de l'outil :

• IDE que vous souhaitez fermer
• Compatibilité avec les scripts de 1996
• Un enregistreur pour ne pas tout écrire manuellement
• Une autre inspection, mais avec des cloches et des sifflets
• Deux types de réponses de l'assistance technique
• Documentation qui ne représente pas la réalité

Le pire accord commercial de tous les temps, passons à autre chose.

Interface utilisateur codée

Retraite tactique, regroupement, et nous flanquons la question. D'une part, nous avons appris à utiliser Visual Studio comme IDE. D'autre part, notre approche était basée sur les composants de l'interface utilisateur DevExpress que nous utilisons. En conséquence, nous avons trouvé des informations intéressantes sur le framework Coded UI qui est officiellement utilisé dans DevExpress pour automatiser les tests d'interface utilisateur. Ce framework est tellement intégré dans le processus de test interne qu'il existe même une extension Visual Studio.
Il y avait une vaste communauté, Microsoft a promu l'outil sur son site Web, et ce produit a également été mentionné sur le Canal Visual Studio ». Bref, tout semblait prometteur et nous avons commencé à préparer le framework.
La première exigence que nous avons rencontrée était Visual Studio Enterprise. De plus, cette version de Visual Studio n'était pas seulement nécessaire pour écrire des tests, mais aussi pour les exécuter. Cela signifie que mstest par lequel le lancement sera effectué en cas de CI devrait également faire partie de l'édition Enterprise.
Tous les outils d'interface utilisateur codés nécessaires peuvent être installés en activant les cases à cocher correspondantes lorsque VS est installé ou modifié.

L'approche d'écriture des tests était plutôt agréable :des commandes intégrées au shell permettaient de lancer rapidement un enregistreur qui génère un test unitaire et une classe « map » décrivant l'UI. Des outils supplémentaires intégrés à VS offraient la possibilité de créer des classes de test distinctes sans appeler le code.
La seule particularité que nous avons remarquée était une classe partielle contenant la description du contrôle et divisée en deux parties. Avec beaucoup d'autres choses, il est décrit dans la documentation. Cette documentation est suffisante pour un processus de travail confortable :des exemples de code et des captures d'écran rendent toutes les informations techniques facilement accessibles et faciles à comprendre. Pour faire simple, lorsque l'enregistreur décrit l'UI, un fichier « Designer.cs » est généré. Ce fichier est responsable de la réutilisation du code qui décrit l'interface utilisateur. Tout ce que l'enregistreur ne peut pas gérer doit être écrit manuellement et enregistré quelque part en dehors de la partie générée automatiquement de la classe. Ceci est très similaire aux classes partielles écrites par les concepteurs VS lors de la création de contrôles. La priorité des opérations effectuées sur les contrôles et de leurs vérifications d'état est décrite dans une méthode à laquelle l'enregistreur ajoute utilement un attribut TestMethod standard. . Tout d'abord, cela a masqué certains des problèmes de l'application :la propriété Name de certains contrôles n'a pas été spécifiée, et l'enregistreur a jugé acceptable d'appeler cette instance ridicule de violation de règle et a recherché des contrôles dans le texte. De plus, il gérait des contrôles complexes de manière très inefficace. Par exemple, les nœuds TreeView ont été recherchés par index de nœud, ce qui a rendu la classe "map" créée inutilisable dans le cas d'une extension d'interface. Et la valeur de l'enregistreur a chuté de manière significative à nos yeux - à quoi bon générer automatiquement le code si vous avez besoin de le vérifier par la suite ?
Nous pourrions faire la paix avec toutes ces choses et trouver une solution louable, mais soudain, le tonnerre a frappé :Microsoft a déclaré que cette technologie est désormais obsolète. Avec cela, VS 2019 est devenu la dernière version de Visual Studio qui prend en charge l'interface utilisateur codée. La possibilité de dépendre de VS 2019 maintenant et pendant quelques années à l'avance ne semblait pas vraiment effrayante, mais notre projet est assez vaste, donc les difficultés pourraient commencer quelque part sur la ligne (2025, par exemple).
Résumons. Avec l'interface utilisateur codée, nous aurons :

• Un puissant IDE payant
• Toute l'infrastructure déjà créée pour les tests :tant du côté de l'IDE que de notre CI
• La possibilité de demander de l'aide à n'importe quel développeur de notre projet, car nous écrivons des tests en C# dans le même IDE
• Une quantité importante de documentation de bonne qualité
• Quelques tristes spécialistes de l'assurance qualité qui ont placé leur code dans la partie générée automatiquement de la classe, puis l'ont perdu pendant le processus de génération automatique
• Beaucoup de code généré qui fonctionne et que vous devez soumettre à un examen strict
• Une approche outrageusement transparente de la CI :vous pouvez écrire du code pour lancer des tests via mstest les yeux fermés
• Un géant rouge de l'automatisation en voie de disparition qui grandit constamment à partir de nouveaux tests et est dangereusement proche de se transformer soit en une naine blanche décolorée représentée par une machine absolument isolée avec un logiciel irréversiblement obsolète, soit en une explosion de supernova lorsque le projet implose sous le pression des nouvelles mises à jour.

Tout sonnait bien sauf le dernier point. C'est pourquoi nous devions poursuivre nos recherches.

TestStack.White

Nous travaillions sur des tests de prototypage avec l'aide de White parallèlement à l'étude des fonctionnalités de l'interface utilisateur codée.
White lui-même est un enveloppement autour des bibliothèques "Microsoft.Automation" qui semblaient très prometteuses, et White est également similaire à Coded UI. Cependant, en y regardant de plus près, nous avons trouvé qu'il était beaucoup plus austère, et vous pouviez le remarquer partout - du fait qu'il n'y avait pas d'enregistreur à la structure de test réelle. Par exemple, exécuter l'application, rechercher une fenêtre et appuyer sur le bouton "Exécuter" ressemble à ceci :

var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);

var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);

var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();

app.WaitWhileBusy();

Même s'il n'y a rien à redire sur l'exécution de l'application, la nécessité de travailler avec la classe InvokePattern est très discutable. La classe InitializeOption semble également étrange car elle a accès au membre statique WithCache, mais est censée être utilisée strictement en interne :

public class InitializeOption {
//
// Summary:
//     This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }

//
// Summary:
//     Specify the unique identification for your window. White remembers the location
//     of UIItems inside a window as you find them. Next time when items inside the
//     same window is found they are located first based on position which is faster.
//
// Parameters:
//   identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}

Des décisions étranges comme celle-ci sont partout, et le cadre s'avère trop abstrait pour le contrôle qualité.

La documentation est de bonne qualité et laisse une bonne impression générale. Le code source du projet était hébergé sur github, mais le dernier commit remontait au 8 janvier 2016.
En résumant les informations sur White, nous aurions :

• Documentation correcte
• Accès au code source
• Une petite communauté
• La nécessité d'expliquer à tous les spécialistes de l'assurance qualité que le comportement du contrôle est implémenté via la classe Pattern
• Un ancien référentiel à partir duquel nous aurions certainement besoin de bifurquer

La partie la plus désagréable était la nécessité de développer notre propre framework, ce que nous aimerions éviter. Nous avons donc dû passer à autre chose.

Apium

Nous avons déjà rencontré Appium dans notre recherche, mais nous n'avons commencé à l'envisager sérieusement qu'après que Microsoft a cessé d'utiliser l'interface utilisateur codée.
À première vue, tester avec l'aide d'Appium ressemble à une machine à sous à trois rouleaux. Le premier montre le langage pour lequel il existe une API qui permet l'interaction avec le pilote. Cela permet d'écrire des tests dans n'importe quel langage familier :Python, C#, Java, etc. La deuxième bobine montre l'application pilote qui sert de couche intermédiaire entre les tests et le produit que nous testons. Comme décrit dans la documentation, l'interaction avec les tests est effectuée à l'aide du protocole JSON Wire - c'est ce qui nous donne en fait la possibilité d'écrire des tests dans n'importe quel langage. Et la troisième bobine montre l'objet que nous testons. Peu importe qu'il s'agisse d'un site Web, d'une application mobile ou d'une application de bureau tant que le pilote correspondant est en cours d'exécution. Comme vous pouvez le voir, les composants sont élégamment interchangeables .
L'estimation de la pertinence du package était satisfaisante - sur la page Github, nous pouvions voir que le référentiel avait de nouveaux commits. En examinant le référentiel WinAppDriver, nous avons appris qu'il contenait même un enregistreur.
Nous avons commencé à remarquer quelques problèmes lors de l'écriture d'un prototype. Par exemple, parce que le framework est trop polyvalent, le WindowsElement responsable du contrôle du bureau a une méthode FindElementByCssSelector qui lève l'exception suivante à l'exécution :"Erreur inattendue. Commande non implémentée :la stratégie de localisation de sélecteur css n'est pas prise en charge". Dans le prochain article, nous parlerons plus en détail des problèmes que nous avons rencontrés en travaillant avec ce framework, mais pour l'instant, je voudrais dire que nous avons réussi à tous les gérer.

En résumé, voici ce que nous aurons en utilisant Appium :

• La possibilité de tester les fonctionnalités de l'application qui nécessitent une interaction avec un navigateur (ouverture de la page de commentaires, activation en ligne, vérification de la livraison des e-mails) dans le cadre d'une infrastructure et d'un test
• La possibilité de travailler avec n'importe quelle édition de Visual Studio
• La possibilité de tester une application de bureau qui utilise un navigateur pour afficher l'interface utilisateur. Un bon exemple de ceci serait Azure Data Studio
• Tous les avantages dont nous bénéficions avec l'interface utilisateur codée
• Un cadre gratuit que Microsoft recommande d'utiliser
• Infrastructure familière aux spécialistes de l'assurance qualité qui ont travaillé avec Selenium
• Un référentiel mis à jour avec de nouveaux commits
• Une communauté assez grande qui n'est cependant pas aussi grande que la communauté de Coded UI
• Un enregistreur aux fonctionnalités limitées
• La nécessité d'exécuter une application pilote pour les tests. Pas très pratique, mais il a sa propre fonctionnalité de journalisation
• Beaucoup d'occasions de se tirer une balle dans le pied en raison de l'héritage malheureux de WindowsElement d'AppiumWebElement

En passant en revue tous les points avec les exigences des frameworks et en comparant tous les problèmes rencontrés dans chacun de ces frameworks, nous avons finalement choisi Appium.

Conclusion

Il était intéressant de travailler avec tous ces frameworks car chacun d'eux était basé sur une philosophie unique d'approche des tests automatisés. Une partie d'entre eux n'a fait que commencer son chemin tandis que d'autres atteignaient leur éclipse ou se sont déjà évanouis. Vous pouvez éviter d'être perdu dans les nombreuses solutions disponibles en créant une liste d'exigences spécifiques pour l'outil et en ayant une équipe responsable avec une interaction bien établie entre ses membres. Et n'oubliez pas que les futurs tests sont autant un projet que le code habituel, avec un backlog, des tableaux, des CI, une refactorisation et tout le reste.