Table des matières
Le mot «API» scintille dans les postes vacants, même pour les testeurs débutants. Soit l'API REST, puis l'API SOAP, puis juste une API. Quel genre d'animal est-ce? Voyons ça!
"Pourquoi ai-je besoin de ça?" Je teste actuellement le web! Maintenant, si je passe à l'automatisation, alors oui ... Eh bien, ils le testent également en entreprise, j'ai entendu ...
Et non! Il est bon pour tout testeur de connaître l'API. Parce que les systèmes interagissent les uns avec les autres. Et vous voyez cette interaction tous les jours, même sur les sites les plus simples et les plus minables.
Tout paiement passe par l'API du système de paiement. Vous avez acheté un billet de cinéma? Un t-shirt dans une boutique en ligne? Un livre? Dès que vous cliquez sur "payer", le site vous connecte au système de paiement.
Mais même si vous n'avez pas d'intégration avec d'autres systèmes, vous avez toujours une API! Parce que le système à l'intérieur de lui-même communique également via l'API. Et tandis que le développeur frontal scie fortement l'interface graphique (interface graphique), vous pouvez:
- s'ennuyer en attendant;
- vérifier la logique de travail de l'API
Bien sûr, je suis pour la deuxième option! Comprenons donc ce qu'est l'API. Vous pouvez regarder la vidéo sur
youtube ou lire comme un article.
Qu'est-ce qu'une API?
L'API (interface de programmation d'application) est un contrat fourni par un programme. "Je peux être contacté de cette façon et cela, je m'engage à faire ceci et cela."
S'il était traduit en russe, ce serait le mot «contrat». Un accord entre deux parties, comme un accord d'achat d'une voiture:
- mes responsabilités sont de faire un tel montant
- le devoir du vendeur est de donner la voiture.
Vous pouvez traduire, oui. Mais personne ne fait ça ¯ \ _ (ツ) _ / ¯
Tout le monde utilise le mot «contrat». Donc accepté. De plus, ce mot est inclus dans le nom du style de développement:
- Code d'abord - nous écrivons d'abord le code, puis nous générons un contrat dessus
- Contrat d'abord - nous créons d'abord un contrat, puis nous écrivons ou générons du code dessus (dans cet article, je parlerai de ce style)
Nous ne disons pas "un contrat pour la vente d'une voiture"? Les développeurs ne disent donc pas «contrat». Accord tacite.
API - ensemble de fonctionnalités
Lorsque vous achetez une voiture, vous rédigez un contrat dans lequel vous prescrivez tous les points qui vous tiennent à cœur. De même, des contrats devraient être établis entre les programmes. Ils indiquent comment accéder à l'un ou l'autre programme.
En conséquence, l'API répond à la question «Comment puis-je contacter mon système?», Et comprend:
- l'opération elle-même que nous pouvons effectuer
- données d'entrée
- données de sortie (contenu des données ou message d'erreur).
Ici tu peux me dire:
- Hmm, attends. L'opération, les données d'entrée, les données de sortie - en quelque sorte tout cela ressemble beaucoup à une description de fonction!
Si vous avez déjà rencontré du développement ou simplement appris un langage de programmation, vous savez probablement ce qu'est une fonction. En fait, nous avons des données d'entrée, il y a des données de sortie et de la magie qui se transforme l'une en l'autre.Et oui! Vous aurez raison de dire que les définitions sont similaires. Pourquoi? Oui, car l'API est un ensemble de fonctions. Cela peut être une fonction ou plusieurs.
Comment l'ensemble de fonctionnalités est-il compilé
Oui, peu importe comment. Comme le veut le développeur, il se regroupera. Par exemple, vous pouvez regrouper l'API par fonctionnalité. Soit:
- API distincte pour entrer dans le système, où l'enregistrement et l'autorisation seront;
- API séparée pour les rapports - rapport 1, rapport 2, rapport 3 ... rapport N. Pour différents rapports, nous avons différentes formules = différentes fonctions. Et nous les collectons tous dans un ensemble, api pour les rapports.
- API de système de paiement séparée - il existe une fonction pour travailler avec chaque banque.
- ...
Vous ne pouvez pas du tout regrouper, mais créez une API commune.
Une API commune peut être créée et le reste peut être fabriqué sur commande. Si vous avez un produit en boîte, il comprend généralement un ensemble de fonctionnalités standard. Et tous les clients de liste de souhaits sont fabriqués séparément.
Il s'avère que dans notre système, il existe plusieurs API différentes, pour chacune desquelles nous avons un contrat écrit. Chaque contrat précise clairement quelles opérations peuvent être effectuées, quelles fonctions y seront
Et bien sûr, les fonctions peuvent être réutilisées. Autrement dit, la même fonction peut être incluse dans différents ensembles, dans différentes API. Personne ne l'interdit.
Il s'avère que le développeur propose quel type d'API il aura. Soit le général, soit distribue selon la fonctionnalité ou certains de ses propres critères, et dans chaque API ajoute l'ensemble des fonctions dont il a besoin.
Que signifie le mot "interface"
- Attends une minute, Olya! Vous avez vous-même écrit ci-dessus que l'API est une interface de programmation d'application. Pourquoi parlez-vous alors du contrat, alors qu'il y a le mot interface?
Oui, car dans la programmation d'un contrat, c'est l'interface. Dans la description classique de la POO (programmation orientée objet), il y a 3 baleines:
- Encapsulation
- Héritage
- Polymorphisme
L'encapsulation consiste à masquer l'implémentation. Pour l'utilisateur, tout est simple et clair. J'ai cliqué sur le bouton - j'ai reçu un rapport. Et comment cela fonctionne de l'intérieur - il s'en fiche. Quelle base de données est cachée sous le capot? Oracle? MySQL? Dans quel langage de programmation le programme est-il écrit? Comment le code est-il organisé exactement? Pas le point. Le programme fournit une interface et l'utilise.
Le programme ne fournit pas toujours une interface graphique. Il peut s'agir d'un SOAP, d'une interface REST ou d'une autre API. Pour utiliser cette interface, vous devez comprendre:
- quoi entrer;
- ce qui sort;
- quelles exceptions doivent être gérées.
Les utilisateurs travaillent avec l'
interface utilisateur graphique GUI . Les programmes fonctionnent avec
API - Interface de programmation d'application . Ils n'ont pas besoin de graphisme, seulement un contrat.
Comment s'appelle l'API
Vous pouvez appeler l'api directement ou indirectement.
Directement:
- Le système appelle des fonctions en lui-même.
- Le système appelle la méthode d'un autre système
- L'homme appelle une méthode
- Méthodes d'extraction des autotests
Indirectement:
- L'utilisateur travaille avec l'interface graphique
Appel API directement
1. Le système appelle des fonctions en lui-même
Différentes parties du programme communiquent d'une manière ou d'une autre. Ils le font au niveau du programme, c'est-à-dire au niveau de l'API!
C'est le moyen le plus simple à utiliser, car l'auteur de l'API appelée est le développeur. Et il est son consommateur! Donc, il n'y a aucun problème avec la documentation non pertinente =)
Je plaisante, il y a toujours des problèmes de documentation. Juste dans ce cas, en tant que documentation, il y aura des commentaires dans le code. Mais elles, hélas, ne sont pas non plus pertinentes. Soit les développeurs sont différents, soit un, mais j'ai déjà oublié comment j'ai fait l'api d'origine et comment ça devrait fonctionner ...
2. Le système appelle la méthode d'un autre système
Mais c'est un cas typique que les testeurs testent dans les intégrateurs. Ou des testeurs qui testent l'intégration de leur système avec celui de quelqu'un d'autre.
Un système tire à travers l'api une méthode d'un autre système. Elle peut essayer d'obtenir des données d'un autre système. Ou vice versa, envoyez des données à ce système.
Supposons que j'ai décidé de connecter les invites de Dadata à ma boutique en ligne, afin que l'utilisateur entre facilement l'adresse de livraison.
Je connecte des astuces API. Et maintenant, lorsque l'utilisateur commence à entrer l'adresse sur mon site, il voit les invites de Dadata . Comment cela se révèle:
- Il entre une lettre sur mon site
- Mon site envoie une demande à API Dadat hints
- Dadata retourne la réponse
- Mon site le traite et affiche le résultat à l'utilisateur.
Il y a tellement d'étapes! Et donc pour chaque caractère entré. L'utilisateur ne voit pas cette interaction, mais elle l'est.
Et, bien sûr, n'oubliez pas le cas lorsque nous développons la méthode API. Qui ne peut être appelé que via SOAP, il est introuvable dans l'interface. Ce que le client a commandé, nous l'avons fait ¯ \ _ (ツ) _ / ¯
Un exemple peut être trouvé dans Utilisateurs. La méthode MagicSearch est basée sur des événements réels. Bien que je dois admettre que, dans la logique d'origine, c'était encore plus sophistiqué, je l'ai ajusté à mon site.
Mais l'astuce ici est que dans le système lui-même dans l'interface utilisateur, il n'y a qu'une recherche régulière, juste une ligne d'entrée. Eh bien, peut-être quelques filtres. Mais l'intégration avait besoin de tout un tas de fonctionnalités supplémentaires, ce qui a été fait via la méthode SOAP.
La fonctionnalité de super-recherche n'est disponible que par API, l'utilisateur de l'interface ne la ressent pas.
Dans ce cas, vous avez généralement des savoirs traditionnels, selon lesquels la méthode API fonctionne. Votre tâche consiste à le vérifier. Une tâche typique d'un testeur, il suffit d'ajouter aux tests standard de conception de test les fonctionnalités de test API, et tout est question de chapeau!
(ce qui doit être testé exactement dans l'API - je le dirai dans un article séparé un peu plus tard)3. La personne appelle la méthode
Les raisons sont différentes:
- Pour accélérer le travail
- Pour localiser le bug (où est le problème? Sur le serveur ou le client?)
- Pour tester la logique sans spins de bord
Si le système fournit une API, il est généralement plus facile de la retirer que de faire de même via une interface graphique. De plus, l'appel API peut être enregistré dans l'outil. Une fois enregistré - vous appliquez à n'importe quelle base, même s'il est nettoyé 10 fois par jour.
Pour un exemple, nous allons à nouveau aux utilisateurs . Si nous voulons créer un utilisateur, nous devons remplir de nombreux champs!
Bien sûr, cela peut être fait en utilisant des plugins spéciaux tels que Form Filler . Mais que faire si vous avez besoin de données de test adéquates pour votre système? Et en russe?
Remplir les champs manuellement est triste et déprimant! Et si vous devez répéter cela chaque semaine ou chaque jour sur une base de test propre - généralement un cauchemar. C'est immédiatement la première priorité de l'automatisation des actions de routine.
Et dans ce cas, le rôle de l'automatisation joue ... Postman. Un utilisateur peut être créé via une demande REST CreateUser . Une fois enregistrées les données normales «comme réelles», chaque fois que nous les utilisons. Profit!
Au lieu de remplir manuellement le formulaire (1 minute de remplissage inconsidéré des champs avec les valeurs "lprulpk"), nous obtenons 1 seconde en appuyant sur le bouton "Envoyer". Dans ce cas, les valeurs seront beaucoup plus adéquates.
Et dans Postman, vous pouvez créer un dossier séparé pour préparer la base de test, y entasser une douzaine de demandes. Et maintenant, dans n'importe quelle base en quelques secondes, vous obtenez autant de données que vous conduisez manuellement pendant des heures!
Si vous trouvez un bogue et que vous ne savez pas à qui le suspendre - développeur front-end ou back-end, supprimez tout ce qui est inutile. Appelez la méthode sans interface graphique. Et vous pouvez tester la logique du programme jusqu'à ce que l'interface soit prête ou cassée.
4. Méthodes d'extraction des autotests
Il existe une pyramide d'automatisation typique:
- Les tests GUI sont un test honnête, "comment l'utilisateur le ferait."
- Tests API - nous descendons au niveau inférieur, jetant le superflu.
- Tests unitaires - tests pour une seule fonction
Le mot API indique ce qui sera utilisé dans les tests ツ
Disons que nous avons:
- opération : téléchargement du rapport;
- à l'entrée : données d'ajustements manuels ou automatiques ou de certains autres endroits;
- sortie : un rapport construit selon certaines règles
Règles de création de rapport:
- Cellule 1 : X - Y
- Cellule 2 : Z * 6
- ...
Les tests GUI sont un test honnête, le robot fait tout ce que l'utilisateur ferait. Il ouvre le navigateur, pique sur les boutons ... Mais si quelque chose tombe, vous saurez où exactement pendant longtemps.
Les tests d'API sont les mêmes, uniquement sans navigateur. Nous soumettons simplement les données à l'entrée et vérifions les données à la sortie. Par exemple, vous pouvez entrer la réponse finale dans Excel et laisser le robot la réconcilier, les données sont-elles correctement remplies? La localisation du problème devient plus facile.
Les tests unitaires sont lorsque nous testons chaque fonction séparément. Nous examinons séparément le calcul pour la cellule 1, séparément pour la cellule 2, etc. Ces tests sont plus rapidement recherchés et les bogues sont faciles à localiser.
Appel API indirect
Lorsque l'utilisateur travaille avec l'interface graphique, en fait, il travaille également avec l'API. Il ne le sait tout simplement pas, il n'en a tout simplement pas besoin.
Autrement dit, lorsque l'utilisateur ouvre le système et essaie de télécharger le rapport, peu importe comment le système fonctionne, quel type de magie est à l'intérieur. Il dispose d'un bouton «télécharger le rapport», sur lequel il clique. L'utilisateur travaille via l'interface graphique (interface utilisateur graphique).
Mais en fait, il y a une API sous cette interface utilisateur graphique. Et lorsque l'utilisateur clique sur le bouton, le bouton appelle la fonction de construction de rapport.
Et la fonction de création de rapport peut déjà appeler 10 autres fonctions différentes, si cela est nécessaire.
Et maintenant, l'utilisateur voit un rapport prêt à l'emploi devant lui. Il a appelé l'API complexe sans même le savoir!
Que signifie le test API?
Tout d'abord, nous voulons dire tester l'API VIA. «Test API» est un terme couramment utilisé, ils le disent vraiment, mais techniquement, le terme est incorrect. Nous ne testons pas l'API, nous ne testons pas l'interface graphique (interface graphique). Nous testons une sorte de fonctionnalité via une interface graphique ou logicielle.
Mais c'est une expression établie. Vous pouvez l'utiliser et dire «Test API». Et quand nous en parlons, nous voulons dire:
- Auto-tests au niveau de l'API
- ou l'intégration entre deux systèmes différents.
Intégration - lorsqu'un système communique avec un autre via une sorte de protocole de transfert de données. C'est ce qu'on appelle l'API distante, c'est-à-dire la communication sur le réseau, sur certains protocoles (HTTP, JMS, etc.). En revanche, il existe également l'API locale (également appelée «API de mémoire partagée») - c'est l'API par laquelle le programme communique avec lui-même ou communique avec un autre programme au sein de la même mémoire virtuelle.
Lorsque nous parlons de tester des API, nous entendons le plus souvent des tests d'API distantes. Lorsque nous avons deux systèmes situés sur des ordinateurs différents qui communiquent d'une manière ou d'une autre.
Et si vous voyez «API testing» dans l'offre d'emploi, cela implique très probablement la possibilité d'appeler un service SOAP ou REST et de le tester. Même si cela vaut toujours la peine d'être clarifié!
Résumé
L'API (interface de programmation d'application) est un contrat fourni par un programme. "Je peux être contacté de cette façon et cela, je m'engage à faire ceci et cela."
Le contrat comprend:
- l'opération elle-même que nous pouvons effectuer
- données d'entrée
- données de sortie (contenu des données ou message d'erreur). ".