+ version de couverture meilleure, mais moins amusante Tôt ou tard, tout le monde vient chez AT. La situation lorsque cela se produit tard est compréhensible, et quand est-il tôt? Et comment comprendre ce qui est déjà possible?L'article est basé sur l'expérience d'une équipe: je vais vous parler de nos conditions préalables et des raisons de l'introduction de l'autotest, des critères que nous avons sélectionnés pour la préparation à l'AT et des outils que nous utilisons à la fin. Spoiler: au final, quelques cas réussis et peu nombreux avec Xamarin.UITest.Présentation du produit. , , , , , . offline.
-.
Ce que dit la théorie
Considérez l'approche d'automatisation en utilisant la pyramide de test comme exemple. En tant que niveaux de la pyramide, je prendrai les types de tests que nous utilisons. À savoir, les tests unitaires, les tests d'intégration et les tests de bout en bout (E2E).
Les tests unitaires (tests unitaires) vérifient le fonctionnement de petites parties individuelles du système (fonction, méthode). Ils sont petits, passent rapidement, ne nécessitent pas de gros coûts de développement et de maintenance.Les tests d'intégration testent le fonctionnement de l'application avec des composants externes. Par exemple, avec une base de données ou divers services. Ils prennent plus de temps, à la fois pour la rédaction et la prise en charge des tests, et pour leurs exécutions. Pour de tels tests, vous devez le plus souvent configurer et prendre en charge une sorte d'environnement. Dans ce cas, ils deviennent souvent plus fragiles, car l'environnement a tendance à se briser.Des tests de bout en bout vérifient le fonctionnement du système dans son ensemble, émulant les actions de l'utilisateur final. Le plus souvent, ils accèdent au système via l'interface utilisateur: ils appuient sur les boutons en tant qu'utilisateur, remplissent les champs, etc. Mais ils peuvent également être utilisés dans des systèmes sans interface. Ces tests sont beaucoup plus chers que ceux considérés ci-dessus, car nécessitent plus de temps pour développer et prendre en charge les tests eux-mêmes et l'ensemble de l'environnement. De plus, ils sont très fragiles, car ils sont affectés par des changements dans n'importe quelle partie du système, et le comportement inattendu d'un émulateur ou d'un navigateur peut affecter le résultat d'un test spécifique. La durée de l'exécution de ces tests est également considérablement plus longue que les autres: pour effectuer une action utilisateur individuelle, vous devez en effectuer de nombreuses autres. Par exemple, connectez-vous ou accédez à l'élément de menu souhaité.Selon le principe de la pyramide, plus le test est facile, rapide et moins cher, plus ils devraient être en pourcentage du nombre total de tests. Ceux. un test traversant ne doit pas vérifier l'affectation de différentes valeurs à un champ (sauf si vous devez vérifier le fonctionnement de l'interface utilisateur dans ces cas).Pour tous ces types de tests, un rôle a été attribué. À un moment donné du cycle de vie de l'application, un besoin se fait sentir pour l'une ou l'autre automatisation des tests. Votre produit peut facilement faire avec seulement des tests unitaires et peut rapidement évoluer vers le besoin de tests de bout en bout. L'important lors de la planification de l'automatisation est de comprendre exactement ce dont votre produit bénéficiera actuellement et pour lequel vous risquez de perdre du temps.Lors de la mise en œuvre de l'automatisation, n'oubliez pas les tests manuels, même avec une grande quantité d'automatisation, il y aura toujours des choses à vérifier manuellement. Au minimum, de nouvelles fonctionnalités pour lesquelles il n'est pas rationnel d'écrire immédiatement des tests.Mais toute automatisation, à mon avis, devrait principalement viser à réduire le volume des tests manuels. Et lors de la planification de tests manuels, il convient de considérer les cas déjà automatisés.Comment les tests automatiques sont-ils organisés avec nous?
Chaque produit a individuellement des tests unitaires, exécutés sur chaque PR. Ils sont sous la responsabilité des développeurs.
Les tests d'intégration vérifient l'interaction du service Web avec l'EDMS.Ils simulent le fonctionnement d'une application client. Ils se tournent vers les méthodes de service Web pour obtenir et modifier les données EDS.Exécutez après chaque génération d'une nouvelle version côté serveur.
Les tests de bout en bout simulent les performances de l'utilisateur final. Ils appuient sur les boutons de l'interface de l'application mobile, et l'application fonctionne avec l'EDMS via un service web.Les tests d'intégration et de bout en bout sont désormais effectués par les testeurs.Pourquoi avons-nous besoin d'applications mobiles AT de bout en bout?
Avant de vous lancer dans l'automatisation, il convient de considérer le problème que vous souhaitez résoudre en l'introduisant. Sauf si vous avez des objectifs spécifiques, vous ne pourrez pas expliquer au superviseur ou au responsable du produit pourquoi vous devriez consacrer du temps aux autotests. Il sera difficile d'évaluer les avantages de leur mise en œuvre.Nous testons depuis longtemps les applications mobiles manuellement. Bien qu'il s'agissait d'une application avec peu de fonctionnalités, nous avons réussi à faire face. Tout ce qui a été développé était ± dans un domaine, et les tests manuels pouvaient être organisés de manière à tester rapidement et facilement toutes les fonctionnalités de l'application.Mais après un certain temps, l'application a commencé à se développer avec de nouvelles fonctionnalités, qui étaient assez indépendantes et nécessitaient plus d'attention. Il y avait un problème avec des bogues dans l'ancienne fonctionnalité, que nous ne pouvions trouver que dans les dernières étapes du projet.Par conséquent, les objectifs initiaux de l'introduction de tests d'interface utilisateur d'applications mobiles pour nous étaient les suivants:- AT couverture des principaux cas d'application;
- réduire le nombre de bogues en régression avant la publication.
La réalisation du premier objectif devrait automatiquement conduire à la réalisation du second, des exécutions régulières de tests pour les fonctionnalités de base tout au long du projet devraient trouver des bogues aux étapes précédentes.Après un certain temps, un autre objectif a été ajouté: réduire le nombre de tests de régression manuelle.Et quand est-il temps d'introduire l'automatisation dans les tests?
Avant de vous lancer dans l'automatisation des tests, vous devez évaluer l'état de préparation de votre application à l'automatisation. Et aussi votre disponibilité pour ce processus.Fonctionnalité stable
Pour qu'AT ait une chance d'être utile, l'application doit avoir une fonctionnalité stable. Et cela vaut la peine de couvrir les autotests. Sinon, vous passerez beaucoup de temps et d'efforts à mettre à jour et à mettre à jour les tests à la suite des changements d'application.Plans de développement
L'automatisation ne doit être mise en œuvre que si votre application a un avenir, des plans de développement pour les années à venir. Pourquoi des autotests pour une application qui ne change pas?Ressources
Vous devez disposer de ressources pour développer des tests et, surtout, pour leur assistance supplémentaire. Ceux. Lors de la planification de la mise en œuvre de l'automatisation, il est important de comprendre que les ressources ne seront pas seulement nécessaires pour écrire des tests. Les tests vont certainement tomber pour une raison quelconque. Les résultats des essais devront être analysés et des mesures prises. Comprenant changer quelque chose dans les tests. Eh bien, en plus du support, n'oubliez pas la nécessité de leur développement.Comment décider?
En pensant aux tests d'interface utilisateur des applications mobiles, nous avons immédiatement trouvé de grandes étagères avec des appareils ou des fermes sur lesquels des appareils sont loués. Il y avait beaucoup de problèmes dans les tests en raison de la nécessité de vérifier différentes tailles et résolutions d'écran. Oui, et il n'y avait pas beaucoup d'expérience en développement. C'était effrayant et forcé de mettre des plans de côté.Les objectifs formulés plus tôt sont venus à la rescousse, et le principal était un test fonctionnel. Par conséquent, nous avons commencé petit.En conséquence, nos tests:- courir une fois par jour (cela suffit pour trouver la source du problème si quelque chose se passe);
- exécuter localement sur nos serveurs;
- sur deux appareils (iOS et Android);
- pour Android, il y a maintenant environ 50 tests, la course dure environ une heure (avec l'assemblage);
- pour iOS - environ 40 tests, l'exécution prend environ 30 minutes;
- les tests sont écrits en utilisant Xamarin.UITest;
- ils sont lancés automatiquement par les builds dans TFS, au même endroit dans TFS nous surveillons les résultats des runs.
Un peu sur Xamarin.UITest
Il s'agit d'un cadre de test automatique de l'interface utilisateur pour les projets sur Xamarin.iOS et Xamarin.Android (la prise en charge d'Objective-C / Swift et Java est également annoncée). Les tests sont écrits en C # à l'aide de NUnit. Les projets de contenu peuvent être facilement intégrés.Le principe de fonctionnement du cadre repose sur deux éléments: la recherche d'un élément (requêtes) et l'exécution de toute action avec celui-ci (actions), par exemple, en appuyant ou en exécutant un balayage.Voici, par exemple, un test qui vérifie l'affichage d'erreur lors de la saisie d'une connexion non valide:public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
{
var wrongLogin = TestsSettings.UserLogin + "1";
app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
}
private string ErrorMessage =>
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;
La méthode de saisie des informations d'identification utilisée:public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
{
app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
app.EnterText(Resources.Identifiers.LoginEdit, login);
app.EnterText(Resources.Identifiers.PasswordEdit, password);
app.Tap(Resources.Identifiers.LoginButton);
}
Dans cet exemple, les méthodes de framework standard sont utilisées - attendre un élément, saisir du texte, cliquer sur un élément.Lors du développement et du débogage de tests, il est pratique d'utiliser l'utilitaire de console intégré REPL (read-eval-print-loop), qui vous permet de visualiser l'arborescence des éléments situés maintenant à l'écran, ainsi que d'effectuer des méthodes de framework standard.Être inattendu pour nous
L'adressage des éléments d'interface n'a parfois pas conduit à ce que nous attendions.Par exemple, lorsqu'une nouvelle fenêtre dans une application est ouverte avec un fragment dans la même activité, l'utilisateur ne voit que cette nouvelle fenêtre à l'écran. Mais dans ce cas, il y aura ces éléments dans l'arborescence d'éléments visibles que l'utilisateur ne voit pas maintenant avec ses yeux. La recherche d'un tel élément "invisible" sera réussie et vous pouvez effectuer une action avec lui. C'est juste un clic sera exécuté dans la fenêtre que l'utilisateur voit. Ceux. en fait, ce sera un faux positif.L'arbre peut contenir plusieurs éléments identiques; par défaut, l'action sera effectuée avec le premier élément approprié de l'arbre. Et si dans un test, vous avez accédé à un élément via une étiquette, puis que vous avez un élément avec la même étiquette quelque part, le test commencera à tomber (ou peut-être pas si l'élément dont vous avez besoin est le premier).Nous avons eu un cas où un test écrit et débogué est tombé au tout premier lancement de combat. Parce que les tests ont été exécutés sur un appareil avec une taille d'écran différente. Et l'élément sur lequel on a cliqué sur cet appareil est apparu sous un autre élément d'interface.
Le dossier Boîte d'envoi était sous le bouton Créer une tâche, et cliquer sur le dossier dans ce cas a conduit à cliquer sur le bouton. C'est une situation familière pour l'utilisateur, il fera simplement défiler l'écran. Mais dans l'arborescence des éléments, cette superposition n'est pas visible.De tels problèmes provoquent des inconvénients mineurs et vous font réfléchir plus attentivement à certains tests. Et parfois, nous ajustons simplement les données dans la base de données afin que rien n'interfère avec le test. Après tout, l'objectif de cet exemple est d'ouvrir un dossier et de ne pas vérifier que rien n'empêche son ouverture.Une autre surprise et déception a été l'impossibilité d'exécuter et de déboguer les tests iOS à partir de Visual Studio pour Windows. Cette fonctionnalité n'est pas encore implémentée. Je dois travailler en studio pour MacOS.Quelques résultats de capitaine
Implémentez l'automatisation si cela a du sens.Laissez vos tests avec un minimum de configurations, laissez-les s'exécuter manuellement et seulement une fois par mois, mais s'ils résolvent vos problèmes et vous aident - pourquoi pas?Eh bien, n'oubliez pas le principe de la pyramide.