Robot teste SAP ERP

Chez Alfastrakhovanie, nous utilisons SAP ERP comme système de règlement des pertes de processus. Et il se trouve que nous le finalisons un peu, cela conduit inévitablement à des erreurs dans le code. Si les erreurs atteignent un système productif, c'est mauvais. Cela devrait être évité, une façon est le test de régression. Dans cet article, je vais vous expliquer exactement comment nous procédons à la "régression" pour SAP, car nous le faisons (oh!) Non standard.

Tout a commencé il y a quelques années. Au cours de ces années, nous avons déjà utilisé activement les tests de régression, mais nous ne pouvions pas le faire dans SAP - les outils utilisés ne fonctionnaient pas avec SAP, l'équipe de test ne voulait pas étudier les outils «affinés» pour SAP. Je ne me souviens pas exactement pourquoi, mais je l'ai pris comme un défi (c'était même avant de passer à l'ingénierie de date) et j'ai décidé «d'étudier» le problème.

Les résultats de l'étude (ainsi que "faire") - dans cet article (ci-dessous), je dirai brièvement ceci: nous testons automatiquement SAP (et son environnement immédiat), nous le faisons assez efficacement (dans tous les sens), nous n'avons pas dépensé un seul rouble en licences et formation, notre approche est simple et parfaitement reproductible. Et nous n'utilisons aucun outil SAP pour les tests automatiques de SAP (sauf à l'endroit où nous avons intégré son système de transport).

Grands coups

Il y a un risque d'entrer dans les détails et de perdre des lecteurs, je vais essayer de ne pas le faire (en tant qu'auteur, je connais tous les détails).

Tout a commencé par l'étude, la communication avec SAP, nos partenaires et M. Google.

Le résultat de cette communication a été le suivant:

• SAP dispose d'outils pour tester l'automatisation (nous avons examiné eCATT, étroitement SAP CBTA)
• ils nécessitent une immersion substantielle (en particulier SAP CBTA)
• des restrictions peuvent être nécessaires, si nécessaire, dépasser les limites de SAP (il n'est pas dans un «vide» avec nous)
• il existe des produits de tiers (par exemple, HP), mais nous n'avons pas de compétences pour eux, tout comme nous avons acheté des licences
• il existe un moyen de "gérer" SAP de l'extérieur (la société Convista m'a dit cette idée, merci beaucoup)

Comme je ne connaissais pas personnellement SAP, j'ai décidé d'essayer de creuser dans la dernière direction - la gestion de SAP ne vient pas de SAP. M. Google a rapidement fourni le document "SAP GUI Scripting API pour les plates-formes Windows et Java", qui a constitué un excellent début pour cette initiative. Un test rapide sur mon python préféré a montré que cela fonctionne.

Ensuite, c'était une petite affaire - de trouver un cadre approprié pour l'automatisation des tests. Le python étant mon langage préféré, le Robot Framework a rapidement été pris en considération. Et, en fait, après qu'il ait été inscrit sur la liste et qu'il ait été jugé, alors seulement il est resté sur la liste. Soudoyé par le fait que "ça" a tout de suite fonctionné (regarder vers l'avenir - et fonctionne toujours, je ne regrette pas une seule minute de mon choix).

Un petit pilote a montré que SAP est parfaitement «contrôlé» par un robot (j'appellerai le Robot Framework ce mot russe): rapidement, de manière synchrone, prévisible et fiable. En même temps - je le souligne - nous utilisons la manière documentée par SAP d'interagir avec l'interface graphique SAP (pas une sorte de «béquilles»).

L'architecture

(oui permettez-moi d'utiliser ce mot ici)

Comment ça marche:

• le script est exécuté sur le serveur (le mot "serveur" est utilisé ici dans le sens où cet ordinateur sert nos requêtes de test. Dans ce cas particulier, il est plus correct d'utiliser le mot "client" car c'est le script qui contrôle le processus de test)
• grâce au mécanisme standard du robot Remote, le script interagit avec le composant serveur du robot fonctionnant sur SUT (système sous test)
• ce composant serveur appelle les méthodes de la bibliothèque de gestion SAP
• L'interface graphique SAP traite ces demandes (de manière synchrone, c'est important)
• les résultats de l'exécution des requêtes ou simplement des «beats» sont retournés au script sur le «serveur», où ils sont utilisés dans le processus de test

Techniquement

• "serveur" est une machine virtuelle sous Ubuntu
• SUT - le poste de travail où le poste de travail SAP est installé et configuré (dans notre cas, il s'agit d'un ordinateur Windows ou d'une machine virtuelle)
• la bibliothèque de gestion SAP est écrite en python (il y a quelques - quelques centaines de lignes)
• "script" est un "programme" dans un langage compris par le Robot Framework
• le robot (en tant que tel) implique une ligne de commande, les développeurs ABAP n'étant pas habitués, j'ai réalisé une interface WEB qui propose notamment un travail collectif (à ce sujet un peu plus tard).

Ce qui est merveilleux

En fait, qu'avons-nous obtenu, à part l'absence de fardeau de licence?

Beaucoup de choses, si brièvement et sur l'essentiel:

Langue russe

Le script ressemble à ceci:

Au tout début du voyage (probablement pendant le pilote), j'ai pensé - et que nous allons nous casser la langue et trouver nous-mêmes des mots incompréhensibles, même pour nous? Le robot implique la création de vos propres mots clés (désolé pour la terminologie - c'est ainsi qu'il l'appelle). Alors pourquoi ne les présentons-nous pas immédiatement en russe? Il a demandé dans la communauté des testeurs (quelque part dans les entrailles d'Internet) - ils m'ont "déçu": c'est dangereux, pourquoi, qui l'a dit, etc. J'ai suivi mon propre chemin - nous avons tout en russe (variables, mots, seules les structures de contrôle du robot restent, mais elles doivent être cachées dans les mots clés - si vous voyez l'anglais, alors il est temps de refactoriser).

Ce qui est bon à propos de la langue russe (sauf pour la compréhensibilité sans dictionnaire) - le script peut être montré à un spécialiste non informatique, un homme d'affaires. Vous pouvez écrire ce script directement avec lui (je n'essaierai même pas d'entrer dans le sujet ATDD ici - c'est un article séparé et volumineux, je l'écrirai un jour).

Contrôle total et total et extensibilité

Je sais exactement ce qui se passe pendant le processus de test. Il n'y a pas du tout de magie - tout est extrêmement clair. Je ne sais comment personne, j'aime ça.

À propos de l'extensibilité - la fonctionnalité peut être développée dans n'importe quelle direction, que nous avons activement utilisée:

• J'ai réussi à trouver mon propre "langage" de scripts de test, compréhensible pour les entreprises
• il était possible de vérifier automatiquement si les champs de l'interface étaient correctement remplis à la fin du test (pour cela, en particulier, nous avons divisé les variables du robot en paramètres de démarrage et paramètres d'interface, a permis de déterminer quel élément d'interface devait avoir quel paramètre de démarrage)
• des points d'arrêt peuvent être ajoutés aux tests; pendant les points d'arrêt, regardez les valeurs des variables
• Nous avons implémenté un mécanisme pour créer des modèles de fichiers et les mettre dans le processus d'exécution - sans cela, tester un animal tel qu'un VLP serait impossible (et nous l'avons testé en mode complètement automatique - de la génération d'une application à l'analyse d'un extrait)

La présence de notre propre interface Web a ajouté plus d'options d'extension - par exemple, nous pouvons nous permettre de modifier le langage du robot (nous avons proposé, par exemple, notre opérateur conditionnel - nous et nos utilisateurs professionnels n'aimions pas le mot clé "Exécuter le mot clé si"). Cela est devenu possible car les fichiers avec le code source de test sont générés pour le robot par une application Web.

Facilité d'entrée

En règle générale, les testeurs ne connaissent pas l'infrastructure SAP et, en particulier, la programmation SAP. Ils parviennent à maîtriser le robot et nos améliorations en quelques semaines.

Instructions d'utilisation

Nous nous sommes également tournés vers "Notre William ..." - vers la documentation. Ce n'est un secret pour personne - en règle générale, il n'y a pas de documentation pour le système, et même s'il y en a, il devient très rapidement obsolète. Les utilisateurs passent les règles de travail avec le système "bouche à oreille". Si le code de test automatique est une description de l'utilisation du système selon l'auteur, alors pourquoi ne pas le convertir en instruction?

Bien sûr, les détails sont difficiles à voir sur ce fragment, il est important que l'instruction soit générée et mise à jour en mode entièrement automatique, y compris les captures d'écran. L'instruction est toujours à jour (car les autotests fonctionnent toujours). Dans le cas de SAP, les captures d'écran sont généralement bien reçues - dans SAP, vous pouvez toujours trouver un élément d'interface - un rectangle dont les coordonnées seront pertinentes pour l'emplacement actuel dans le code de test, ce contrôle (invisible à l'œil) est utilisé comme paramètre du mot-clé "prendre une capture d'écran" (ce mot , bien sûr, cela ne fonctionne qu'avec le mode de lancement de test approprié - pourquoi dépenser de l'électricité comme ça).

Nous avons formaté les instructions à l'aide de Sphinx (je suis sûr que beaucoup ont appris le schéma de couleurs), elles sont donc disponibles à la fois dans le manuel en ligne et sur papier.

Un peu sur Robot Framework

Néanmoins, rien ne peut être dit sur le robot - il se révélera trop incompréhensible et superficiel. Je vais essayer brièvement.

L'idée principale de ce cadre est la possibilité de créer votre propre langage de test (dans la terminologie du robot, l'unité exécutable est un mot-clé - le mot-clé). Le cadre fournit

• environnement d'exécution du programme (programmeurs - ne soyez pas offensé) dans cette langue
• bibliothèques riches en fonctionnalités (de l'utilisation de chaînes et de listes à ssh et sélénium)
• rapports (dans le processus d'utilisation, il n'était même pas question de rédiger un type de rapport)
• un simple paradigme de formation d'un programme à partir de mots-clés (un peu particulier, mais vous pouvez vous y habituer), il y a des choses comme les variables, les paramètres et les résultats des "appels" (mots-clés)
• extensibilité simple et puissante - il est très simple de créer votre propre bibliothèque en python (par exemple, nous avons travaillé de cette façon avec Excel), à la fois locale (c'est-à-dire exécutée au même endroit que le code de test) et distante (par exemple, qui contrôle l'interface graphique SAP)

Le processus de création d'un test est assez simple

• nous formons une séquence d'actions et la traduisons en termes de robot (un peu plus bas seront des détails sur l'interaction avec le système testé)
• répétition des séquences refactoriser dans leurs (nouveaux) mots clés
• exécuter le test, voir comment cela fonctionne, corriger, améliorer
• le débogage est fourni par des points d'arrêt (avec la possibilité de visualiser les variables - est fourni par l'architecture, plus précisément - l'utilisation de la bibliothèque distante du robot)

Le résultat n'est même pas un programme (voir les exemples ci-dessus), mais plutôt une séquence d'actions formalisée, qui, soit dit en passant, décrit l'utilisation du programme sous la forme voulue par l'auteur (voir ATDD ci-dessus).

Interaction avec le système testé

Dans notre cas, nous testons au niveau de l'interface utilisateur (c'est-à-dire que nos tests interagissent avec le SAP au niveau de l'interface graphique - ils "cliquent" sur les boutons, remplissent les champs de texte, etc.). Il est généralement admis que cette façon d'écrire les tests n'est pas la meilleure. Je suis partiellement d'accord avec cela, mais je suis prêt à écouter et à discuter de la façon de tester les applications SAP GUI (telles que notre SAP FS CM).

Il y a un tel gourou - Robert Martin (alias "oncle Bob" - l'auteur de "Clean coder", si quelqu'un lit), nous avons correspondu un peu à ce sujet. Ils ont convenu que si ce n'est pas très difficile à faire, cela ne change pas très souvent (tests de rupture), alors d'accord - vous pouvez également tester via l'interface.

Pour ma part, je peux dire ceci: dans le cas de l'interface graphique SAP, il n'y a pas beaucoup d'options pour implémenter l'interface utilisateur. Si vous devez ajouter la possibilité, par exemple, de suivre le code IMEI, vous pouvez le faire de presque une façon - en ajoutant le champ approprié à l'un des signets. Je pense donc que toutes les nuances de cet "ajout" peuvent et doivent être pensées par le client (comment ce champ sera appelé dans l'interface, largeur, ordre d'utilisation, etc.). Et il peut le faire directement dans un script, qui le testera ensuite automatiquement. Si vous ne pouvez pas réfléchir à une révision jusqu'à la fin (comme on dit - eh bien, vous le faites, et nous verrons), alors il vaut mieux ne pas faire cette révision. Et pour faire ce que vous pouvez penser. Eh bien, je suis de nouveau dans ATDD ...

Revenons à l'interaction avec l'interface graphique SAP: nous avons géré, comme je l'ai déjà écrit, environ 200 lignes en python et environ 10 fonctions de gestion d'interface différentes (telles que "aller au signet", "remplir le champ", "appuyer sur le bouton"). Cet ensemble s'est formé presque au début et n'a par la suite pas beaucoup augmenté. Au crédit de SAP, je constate que tout fonctionne très rapidement - l'œil n'a pas le temps de suivre la façon dont l'interface "clignote", des retards ont été insérés dans la boucle de contrôle pour ralentir (si nécessaire, le contrôle visuel). Je note également les avantages du fonctionnement synchrone - nulle part dans le code, vous ne devez attendre quoi que ce soit, si, par exemple, le bouton est enfoncé, l'action correspondant au clic sur le bouton est terminée (par exemple, la perte a été enregistrée).

def get_ctrl_attr ( self, uid, attr ): """     (  )   (  )  exception =  (   log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError("  {1}   {0}".decode("utf-8").format(attr,uid)) return retText 

Quelques commentaires sur le code

• fragment de bibliothèque de gestion SAP GUI
• une bibliothèque est un objet, les méthodes sont directement disponibles dans les tests (en mots-clés), par exemple, la méthode ci-dessus peut être appelée comme ceci: "res = get ctrl attr $ {UID} text" (en utilisant la notation du robot)
• en cas d'erreur, le texte d'exception sera visible dans le journal du robot (vous n'avez rien à faire pour cela - il suffit de "tuer" l'exception

Le code est très simple, ça fait plaisir.

Exécution de tests

Suivant la logique du robot, des tests individuels sont combinés dans nos projets. Un test ou un projet peut être démarré manuellement à partir de l'interface Web. Le processus de test de régression est également intégré au système de transport SAP:

• le propriétaire du produit à la fin de la phase de test commercial approuve les demandes de transfert de transport
• les demandes approuvées "se déplacent" une par une vers l'environnement de pré-production, où, conformément aux paramètres, un ensemble particulier de tests (ou plutôt de projets) est lancé
• si le résultat du test est positif, la demande est libérée et "va" à l'environnement de production
• en cas d'erreur, l'auteur de la demande reçoit une lettre avec un lien vers le rapport de test (généré par le robot), la demande ne va pas plus loin

Important - l'interface Web réduit considérablement le seuil d'entrée dans le processus de test: pour démarrer le test est simple - cliquez sur le bouton "Démarrer". En même temps (grâce à l'utilisation de Robot Framework), tous les avantages de la représentation des fichiers des tests (contrôle de version, ligne de commande et automatisation associée, etc.) sont préservés.

Pas de sève om

Nous avons appliqué avec succès notre développement pour tester non seulement l'interface graphique SAP, j'ai eu un petit développement (interface d'enregistrement de perte simplifiée) en python et django. Étant donné que tous les points de base que nous avons déjà mis en œuvre, tout ce qui devait être fait était d'écrire une bibliothèque de gestion de navigateur (la même chose que je devais gérer l'interface graphique SAP, uniquement via Selenium). Et ça s'est avéré super:

• les tests fonctionnent toujours sur la machine virtuelle Linux (sur le même - les tests SAP et non les tests SAP vivent dans la même "instance")
• le navigateur "clignote" sur le lieu de travail du testeur (contrôle visuel complet sans aucune astuce)
• rapports standard, outils familiers

Dans les tests de ce système, je suis allé plus loin (vers ATDD) - des éléments visuellement visibles (étiquettes et espaces réservés) ont été formés initialement dans les tests, là ils étaient d'accord avec l'entreprise et de là "sont tombés" dans le code source du système lui-même (il s'est avéré un peu SEC) - vous ne pouvez pas écrire du code sans d'abord écrire le test. Cool

Bien sûr, de nombreux outils ont été développés pour les applications Web, mais je ne peux pas dire que j'ai rencontré des inconvénients pendant le travail. Ça s'est bien passé ici ...

Pour résumer

Le monde de SAP est vaste et contient, semble-t-il, tout le nécessaire pour le bonheur complet des développeurs. Mais cela ne signifie pas du tout que vous ne devez marcher que sur les chemins que SAP et son écosystème ont "tracés". Il est utile au début du parcours de se poser la question: est-ce que je veux vraiment faire "comme tout le monde"? Chez Alfastrakhovanie, nous le lui demandons nous-mêmes, et pas seulement en informatique.

Et, encore une fois, tout est possible en programmation, la question n'est que du temps et de l'argent (motivation).