Pas depuis le début
Vous connaissez de nombreux outils de test qui peuvent:
- Obtenez des étapes dans la langue Gherkin directement à partir de ce que l'utilisateur a demandé?
- Voulez-vous créer des instructions vidéo automatiquement, avec sous-titres, Black Jack et Elena ?)
- Créer un fichier * .feature en anglais dans l'interface roumaine, pour un utilisateur qui parle italien?
Ceci est disponible et clairement (avec photos) dans cet article, ne changez pas ...
Entrée
Cet article est un aperçu de l'outil de test d'application 1C créé dans les entrailles d'OpenSource appelé vanessa-automation . Ce projet est une continuation directe du projet de comportement vanessa, largement connu dans les cercles étroits (le fork a été créé sur la version 1.1.131). Au fait, il y a d'autres fourches .
Contexte
Il ne serait pas agréable de penser que tous les lecteurs de cet article sur habr connaissent 1C, tout de même, la triche n'est pas une option. Par conséquent, je ne m'aventurerai pas à continuer sans former la compréhension du lecteur de la plate-forme 1C et de ses capacités utilisées dans vanessa-automation (ci - après va ou Vanessa ).
Ainsi, après avoir installé la plate-forme 1C, vous devez l'exécuter en mode Entreprise ou en mode Configurateur .

Les configurations sont en cours de développement dans le configurateur et les utilisateurs de l' entreprise travaillent avec ces configurations: ils créent, modifient et sauvegardent toutes sortes de ces répertoires et documents, remplissant ainsi la base de données, puis génèrent des rapports et encore: créez, modifiez et enregistrez ... et ainsi de suite en boucle. Cependant, le scénario habituel pour le développeur d'utiliser la plate-forme, en externe, n'est pas très différent de l'utilisateur:
ils démarrent la configuration nécessaire en mode configurateur , puis dans le cycle → développent ou modifient quelque chose → (re) démarrent depuis le configurateur 1C en mode entreprise et vérifient de leurs propres mains qu'ils ont développé ou amélioré.
La situation est sauvée par la fonctionnalité d'une plate-forme appelée Test automatisé , qui permet d'enregistrer, de reproduire et de vérifier les actions des utilisateurs. Comment cette fonctionnalité modifie le scénario d'utilisation par le développeur de la plateforme, nous allons considérer un exemple, MAIS d'abord sur le traitement externe .
Objets de configuration appliqués (alias Métadonnées , alias «Objets de configuration» , elle est Ella Katznelbogen, elle est Valentina Paniyad )
décrire le sujet et les noms de ces objets parlent d'eux-mêmes.

Les "documents" reflètent les transactions commerciales, par exemple la réception de marchandises. Des "répertoires" sont nécessaires pour saisir, par exemple, le nom de la contrepartie 1 fois, puis le sélectionner et ne pas le saisir à nouveau à chaque fois. Les données sont stockées dans les "Registres" et des tables virtuelles sont construites sur eux pour effectuer des calculs complexes et générer des "Rapports" . Nous sommes donc arrivés au Traitement , avec leur aide, les informations de la base de données sont traitées (par exemple, un mois est clôturé en comptabilité ou divers échanges entre les bases de données d'informations), mais nous sommes intéressés par la possibilité de les télécharger vers un traitement externe .

Les configurations fournies par 1C sont prises en charge (vous ne pouvez pas les modifier pour ne pas perdre la mise à jour automatique), et le traitement externe permet d'effectuer diverses manipulations de données sans supprimer le support, et bien sûr, testez-le!
ExtensionsAprès la sortie de la version 8.3.10 de la plateforme, il est devenu possible, à des fins de test, d'utiliser, en plus du traitement externe, également des extensions (ce sont des patchs).
Avec une certaine simplification, on peut dire que techniquement, le traitement externe 1C est un fichier avec l'extension epf que vous pouvez ouvrir dans le configurateur, vous pouvez créer de nombreux formulaires → placer des contrôles sur les formulaires et programmer certaines fonctionnalités dans les modules de ces formulaires. Le traitement externe a également un module «commun» (alias «module objet» ) et des dispositions, MAIS c'est une histoire complètement différente, et nous revenons aux tests.
Pour utiliser la fonctionnalité de test automatisé , vous devez exécuter deux instances de 1C enterprise, la première avec la clé du gestionnaire de test (/ TESTMANAGER), la seconde avec la clé du client de test (/ TESTCLIENT) et établir une connexion entre le gestionnaire de test et le client. Ainsi, le scénario d'utilisation par le développeur de la plateforme devient ceci:

Depuis le configurateur, démarrez 1C en mode entreprise avec la clé du gestionnaire de test → dans l' entreprise, ouvrez va et utilisez-le pour lancer une autre instance
1C en mode entreprise avec une clé client de test. La connexion va entre le gestionnaire et le client de test est établie automatiquement après le démarrage du client de test. Le client de test peut être un client léger ou un client Web.
Total: 1C a écrit son Selenium, qui est intégré à la plateforme 1C: Enterprise. Et ce sélénium de 1C a des avantages. Par exemple, tout contrôle (ou contrôle) d'un formulaire a toujours un nom unique qui, dans 99,99% des cas, est connu à l'avance. En conséquence, il n'y a aucun problème avec les localisateurs, et pour trouver un contrôle, il suffit d'écrire:
= .(,,);
Fixer le matériau avec un exemple
Il est nécessaire de développer une configuration pour rendre compte de la vente de marchandises avec l'impression des factures.
Le spectateur attentif pouvait remarquer le design
<>
et vous ne vous êtes pas trompé, oui - Vanessa utilise son dialecte de cornichon, qui a des conditions et des cycles. Je pense que l'idée d'ajouter des conditions et des cycles au cornichon est née quelque chose comme ceci:
Certains membres de la communauté OpenSource ont critiqué cette décision, mais si l' on en croit le gitter , ils ont convenu de ce qui suit - la «lisibilité humaine» des fonctionnalités ne nuit pas à cette fonctionnalité, et tout le monde décide de l'utiliser ou non.
À propos de turbo cornichon est prévu un article séparé, restez à l'écoute.
"BDD sur 1C" et un peu d'histoire
va , comme nous le voyons maintenant, a été vu différemment par ses créateurs . Faire le même concombre + sélénium à 1 ° C n'a été décidé qu'après avoir testé les options les plus évidentes et les plus économiques. À un certain moment, il est devenu clair que si vous utilisez du concombre et du sélénium, ces outils devront être finalisés afin d'obtenir les fonctionnalités nécessaires pour tester les solutions métier d'application 1C. Cet alignement, dans le cadre de l'open source et des réalités du monde 1C, a compliqué et prolongé le développement du projet dans le temps. En conséquence, il a été décidé de ne faire qu'avec la plate-forme 1C: Enterprise.
Par exemple, avec la vente de marchandises, nous avons vu comment va va , voyons maintenant comment il est mis en œuvre.
Vérification des étapes
La vidéo "Testing" montre va , dans lequel un fichier de fonctionnalité (ci - après dénommé fonctionnalité ) est déjà téléchargé et une arborescence d'étapes est formée. En cliquant sur le bouton "Exécuter les scripts" , le traitement de chaque étape commence, c'est-à-dire appelez la procédure de vérification des étapes. À propos de l'emplacement de cette procédure, je vais vous expliquer par l'exemple.
Supposons qu'il existe une fonctionnalité avec un script:
: "" 10 "" 300 "" 3000
Pour implémenter la vérification des étapes de ce scénario, vous devez obtenir un traitement externe correspondant à la fonctionnalité. En va, cela se fait automatiquement, par le bouton correspondant.

Par conséquent, le répertoire step_definitions
sera créé dans le même répertoire que la fonction et le traitement externe y sera créé, avec le même nom que la fonction.
..\.feature ..\step_definitions\.epf
Les procédures de vérification des étapes seront situées dans le module du formulaire de traitement.

De plus, lors du chargement d'une fonctionnalité, va recherchera et sérialisera les processus externes pour connaître les procédures de vérification des étapes qui y sont implémentées (processus externes). La procédure suivante en est responsable:

La séquence de recherche pour vérifier les étapes est la suivante:
1. , feature 2. , , 3. ,

Dans le cas où un script est ajouté / supprimé / modifié, le traitement externe de la fonctionnalité correspondante peut être reconstitué par le même bouton «Créer et mettre à jour des modèles de traitement».
Après avoir implémenté le contrôle d'étape une fois, il peut être utilisé dans d'autres fonctionnalités ( réutilisation des étapes ). En fait, dans ce module de formulaire de traitement externe, nous voyons deux procédures de vérification de script en trois étapes.
À quelques pas de l'air et WYCIWYG
Un peu de fonctionnalité Test automatisé de la plate-forme 1C. Je vous rappelle que les tests automatisés vous permettent d'enregistrer, de lire et de vérifier les actions utilisateur reproduites. En fait, il s'agit du même client de test et du même gestionnaire de test , uniquement du côté client, l'enregistrement du journal des actions de l'utilisateur est activé.

En conséquence, nous avons un fichier xml avec une description des actions de l'utilisateur:
<?xml version="1.0" encoding="UTF-8"?> <uilog xmlns:d1p1="http://v8.1c.ru/8.3/uilog"> <ClientApplicationWindow isMain="true"> <CommandInterface> <CommandInterfaceGroup title=" "> <CommandInterfaceButton title=" "> <click/> </CommandInterfaceButton> </CommandInterfaceGroup> </CommandInterface> </ClientApplicationWindow> <ClientApplicationWindow caption=" "> <Form title=" "> <FormGroup name="" title=" "> <FormButton name="" title=""> <click/> </FormButton> </FormGroup> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=" ()"> <Form title=" ()"> <FormTable name="" title=""> <FormGroup name="" title=" "> <FormButton name="" title=""> <click/> </FormButton> </FormGroup> <FormField name="" title=""> <closeDropList/> <executeChoiceFromDropList presentation=""/> </FormField> </FormTable> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=""> <Form title=""> <FormTable name="" title=""> <gotoRow direction="down"> <Field title="" cellText="000000001"/> <Field title="" cellText=""/> </gotoRow> <choose/> </FormTable> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=" () *"> <Form title=" () *"> <FormTable name="" title=""> <endEditRow cancel="false"/> </FormTable> <FormGroup name="" title=" "> <FormButton name="" title=" "> <click/> </FormButton> </FormGroup> </Form> </ClientApplicationWindow> </uilog>
Il est difficile de dire si l'idée de créer la fonctionnalité de conversion du journal des actions de l'utilisateur en actions de script se trouve à la surface, MAIS le premier à deviner et à mettre en œuvre cette idée est Leonid Pautov ( pr-mex ). La quantité de travail effectuée peut être estimée par le contenu et la taille de la bibliothèque , car en plus de traduire le journal des actions de l'utilisateur en cornichon, il était nécessaire de mettre en œuvre des procédures d'exécution et des procédures de vérification des étapes.
Ainsi, pour obtenir un script prêt à l'emploi "de rien", il suffit de permettre l'enregistrement des actions de l'utilisateur dans le gestionnaire de tests.

Dans le client de test, reproduisez les actions de l'utilisateur, par exemple, les fonctionnalités qui doivent être améliorées ou les erreurs qui doivent être corrigées. Eh bien, terminez l'enregistrement des actions de l'utilisateur. Ceci implémente l'approche de développement de test "WYCIWYG" (ce que vous cliquez est ce que vous obtenez).

Les étapes, par exemple, la vérification du résultat des actions de l'utilisateur dans un script peuvent être ajoutées à partir de la bibliothèque.

Étapes détaillées et scénarios d'exportation
Malheureusement, en réalité, le script comprend de nombreuses étapes, plus que dans la capture d'écran suivante.

Il existe au moins deux options pour faciliter la perception de tels scénarios.
Tout d'abord, à l'aide de la tabulation, «déplacez» les étapes à regrouper et donnez-leur un titre mnémonique.

Deuxièmement, rendez le script concis et polyvalent et exportez. Je pense que je ne peux pas mieux décrire cette fonctionnalité qu'Elena dans la vidéo "Utilisation de la balise d'arbre et des pas depuis les airs" et "Passage des paramètres au script" .
Les données vidéo ( 1 , 2 ) sont également créées à partir de scripts sur Gherkin et l'utilisation du moteur "AutoVideoInstructions" est convertie au format mp4 en un clic.
Oui, Vanessa peut créer des vidéos sur le fonctionnement de Vanessa )
AutoVideo
Les instructions vidéo automatiques font l'objet d'un article séparé (le voici ), je ne peux que vous en dire un peu le contexte.
Le moment de la préparation de la base d'informations, la reproduction des actions de l'utilisateur et la vérification de ces actions, c'est-à-dire exécution de script
des instructions assez claires si vous ralentissez les étapes.

Sauvegarder les utilisateurs pour regarder l'exécution du script (d'où vient cet humour policier?) N'est pas une option, mais l'auteur ne s'est pas contenté d'implémenter la fonctionnalité de création d'un fichier html avec des étapes et des captures d'écran correspondantes. Il n'a pas été arrêté par le fait que lors de la lecture des actions utilisateur, le curseur de la souris ne s'affiche pas et qu'il n'y a aucun moyen de sélectionner une zone arbitraire sur le formulaire, il a donc écrit les utilitaires correspondants. De plus, à la demande des utilisateurs, un doublage a été ajouté ( Elena ), ce qui, avec le travail de base sur la formation de la vidéo avec sous-titres et le fond musical d'origine, a entraîné une quantité de travail décente, mais les instructions auto-vidéo étaient là. À l'heure actuelle, les instructions auto-vidéo sont considérablement optimisées, en termes de synchronisation de la voix et des actions sur la vidéo.
Quelques statistiques ennuyeuses
va prend en charge:
- Versions de la plate-forme 1C: Enterprise à partir de 8.3.6 et supérieures (il est recommandé d'utiliser la plate-forme 8.3.10 et supérieures).
- Géré et sous forme "normale" (la configuration testée peut être en mode de compatibilité 8.2 ou supérieur).
- Mode d'appel asynchrone.
Afin de travailler correctement dans un tel "zoo" , va a dû apprendre à se tester. Le rapport d'auto-test ressemble à ceci:


Les scripts d'auto-test se trouvent dans le même référentiel .
Bibliothèque d'étapes
Le package va comprend la bibliothèque Gherkin d'étapes standard, qui vous permet de résoudre les tâches quotidiennes d'auto-test, telles que travailler avec l'interface d'application (boutons, champs, tableaux, etc.), travailler avec des fichiers, OS, etc. Pour le moment, c'est plus de 400 marches.
Localisation
L'interface va est localisée en 20 langues:
RU, am, az, bg, et, fr, ka, de, en, hu, it, lv, lt, mn, pl, ro, sl, es, sv, tr, vi.
La localisation va peut être divisée en 3 composants:
- Interface (le mécanisme standard des synonymes de la plate-forme 1C: Enterprise est utilisé).
- Messages à l'utilisateur (au lieu d'appels à des dispositions () avec des traductions de messages sont utilisées).
- Traduction des étapes de Gherkin à partir de la bibliothèque standard va . C'est-à-dire au lieu d'implémenter l'étape "Et je clique sur le bouton 'NameKnopki'" dans chaque langue, le "mapping" est à nouveau utilisé dans l'étape correspondante de Gherkin, qui est déjà implémentée en russe.
En anglais, cette étape sera
And I click 'ButtonName' button
Par conséquent, les utilisateurs anglophones peuvent désormais écrire des scripts sur va en anglais. Toutes les étapes de la bibliothèque standard sont traduites par man. Le résultat peut ressembler à ceci .
Il est logique que pour prendre en charge une telle localisation, nous devions implémenter des outils supplémentaires pour travailler avec les mises en page (une mise en page est quelque chose comme un tableau Excel) pour insérer / supprimer des valeurs, trier des lignes, etc. directement dans la source (fichiers xml).
"TDD en 1C", test de procédures et fonctions (tests unitaires)
Avec va, vous pouvez tester le "comportement" des procédures et des fonctions. Il suffit d'écrire un script similaire:

Si les lecteurs sont intéressés, ce sujet peut être révélé plus en détail dans de futurs articles.
Options de livraison
Initialement, le projet n'était livré que sous la forme d'un ensemble de fichiers epf, qui pouvaient être assemblés à partir des sources sur github , ou téléchargés une version prête. À partir de la version 1.2.009, va est également fourni en un seul fichier epf, qui comprend toutes les bibliothèques, plug-ins, packages de localisation, modules d'assemblage vidéo, etc. Pour ainsi dire - tout en un.
Cette version du framework s'appelle vanessa-automation-single . Il est bien adapté aux utilisateurs qui ne prévoient pas de modifier va , mais ne l'utiliseront que. De plus, cette option de livraison est bien adaptée pour être incluse dans d'autres configurations ou extensions (l'avantage de la licence de projet FreeBSD le permet).
De haut en bas et de bas en haut
Malgré le fait que l'outil a été initialement conçu pour la mise en œuvre de la méthodologie BDD (c'est-à-dire lorsque les scripts sont écrits de haut en bas, c'est-à-dire en fonction des exigences de haut niveau du client), la pratique d'utilisation a montré que les scripts peuvent également être écrits de bas en haut. Un cas typique est quand il existe déjà une configuration prête à l'emploi, et que vous avez juste besoin de la couvrir avec des tests sans vous soucier des méthodologies.
Moral
J'espère que le lecteur a développé (le mot-clé "formé") une idée de va comme un outil de test sérieux. En regardant les analogues étrangers au début, je les dépasse maintenant, à mon humble avis. L'extension de la fonctionnalité de travail avec le cornichon a permis (promis, mais pas implémenté avant le cornichon turbo) d'impliquer à la fois l'analyste et le développeur et testeur dans le processus de développement. Je vais expliquer que l'analyste écrit un script transversal de haut niveau → le développeur détaille également ce script en utilisant des scripts d'exportation, et il n'écrit pratiquement rien sauf le code (toutes les étapes nécessaires de l'interface utilisateur sont déjà dans la bibliothèque) → le testeur ajoute des scripts à vérifier sous un «angle différent» fonctionnalité et tout cela - dans un seul fichier de fonctionnalités , applaudissements camarades!

PS
Sur ce point, permettez-moi de conclure cet article de synthèse.
Soutenez le projet avec un mot aimable / comme / critique (le chat du projet à Gitter est ici ), les auteurs sont toujours ravis.
Merci de votre attention!
Les références