Selon une enquête SlashData de 2020, près de 90 % des développeurs interrogés utilisaient des API à un certain niveau. Avec cela en tête, il n’est pas surprenant que, même si vous êtes testeur manuel ou automatisé à la recherche d’un nouvel emploi, l’entretien d’embauche comportera des questions liées aux API.
Dans cet article, je vais vous présenter certaines des questions les plus courantes et importantes posées en entretien concernant les tests d’API, ainsi que la réponse idéale pour chacune d’entre elles. C’est parti !
1. Qu’est-ce que le test d’API ?
Le test d’API est un type de test logiciel qui consiste à évaluer les API (Interface de Programmation d’Application) afin de vérifier qu’elles répondent aux exigences de fonctionnalité, de fiabilité, de performance et de sécurité. Puisque les API n’ont pas d’interface graphique, les tests d’API sont effectués au niveau de la couche de message du système.
2. Quels sont les avantages de réaliser des tests d’API ?
Les tests d’API présentent plusieurs avantages. Parmi les plus importants, on peut citer :
- Test sans interface graphique : les testeurs peuvent réaliser des tests d’API sans devoir utiliser le logiciel directement. C’est un avantage considérable, car cela permet aux ingénieurs QA de déceler tôt les défauts et bugs, et ainsi aux développeurs de les corriger avant d’impacter l’interface graphique.
- Test des fonctionnalités principales : Avant d’effectuer les tests de l’interface graphique, tester le fonctionnement du code de l’application permet d’évaluer la qualité globale du produit. Ceci permet de détecter de petites erreurs susceptibles de se transformer en problèmes majeurs dans l’interface graphique. L’accès au noyau rend également possible le test en parallèle avec le développement, facilitant la communication et le travail d’équipe.
- Efficacité temporelle : Les tests d’API prennent généralement moins de temps que les tests fonctionnels de l’interface graphique. Les tests de l’interface graphique sont plus longs car les composants web doivent être interrogés. L’automatisation des tests d’API implique moins de code et offre une couverture de test plus large et plus rapide comparé aux tests automatisés de l’interface graphique.
- Indépendance du langage : Un test d’API utilise XML ou JSON pour échanger des données. Ces formats de transfert ne sont pas dépendants du langage ; il est donc possible d’utiliser n’importe quel langage de programmation pour écrire des tests automatisés sur votre API.
-
Invicti
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.6 -
Acunetix
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.1 -
Aikido Security
Visit WebsiteThis is an aggregated rating for this tool including ratings from Crozdesk users and ratings from other sites.4.7
3. En quoi le test d’API est-il différent du test d’interface utilisateur ?
Le test d’API se concentre bien plus sur la logique métier, les réponses de données, la sécurité et l’identification des goulots d’étranglement de performance. À l’inverse, le test d’interface utilisateur vise à vérifier l’apparence d’une interface web ou le bon fonctionnement de certains boutons, formulaires, menus déroulants, etc.
4. Quels sont les composants d’une requête HTTP ?
Une requête HTTP comprend cinq éléments :
- Une méthode HTTP (décrite ci-dessous) qui définit l’action à effectuer.
- Un URI (Uniform Resource Identifier), identifiant la ressource sur le serveur.
- Une version HTTP, par exemple HTTP v1.1.
- L’en-tête de la requête transporte les métadonnées (sous forme de paires clé-valeur) pour le message de requête HTTP. Le type de client (ou navigateur), les formats pris en charge par le client, les formats du corps du message, les paramètres de cache, et d’autres informations constituent des exemples de métadonnées.
- Le corps de la requête représente les données envoyées par le client à l’API.
5. Quelles sont les méthodes HTTP les plus utilisées dans les API REST ?
Les méthodes HTTP les plus importantes lorsqu’on effectue des tests d’API REST sont celles qui réalisent des opérations CRUD :
- GET est la méthode HTTP qui lit l’information d’une ressource.
- La méthode POST est utilisée pour créer ou mettre à jour des ressources.
- PUT modifie une ressource existante.
- DELETE permet de supprimer une ressource spécifiée.
6. Quelle est la différence entre les méthodes PUT et POST ?
Voici une question qui m’a souvent été posée en entretien, et la réponse se trouve en partie ci-dessus.
Lorsque vous souhaitez modifier une seule ressource faisant partie d’un ensemble de ressources, vous utilisez la méthode PUT. Quand vous voulez ajouter une ressource enfant dans un ensemble de ressources, il faut utiliser la méthode POST. Si l’appel HTTP PUT est envoyé plusieurs fois, le résultat restera le même. En revanche, si une requête POST est envoyée plusieurs fois, les résultats seront différents, c’est-à-dire que plusieurs ressources pourront être créées ou qu’une erreur sera renvoyée.
Par exemple, si vous avez une ressource pour créer et mettre à jour des utilisateurs, l’envoi de la même méthode PUT pour un utilisateur mettra à jour l’utilisateur à chaque fois. Envoyer la même méthode POST pour un utilisateur entraînera soit la création de plusieurs utilisateurs, soit une erreur indiquant que le nom d’utilisateur ou l’adresse e‐mail est déjà utilisé.
7. Quelles sont les classes de codes de statut de réponse HTTP ?
C’est une autre question courante en entretien et il est important de le savoir lorsque vous effectuez des tests d’API. Les classes de codes de réponse HTTP sont :
- 1xx : les réponses dans cette catégorie sont des réponses d’information. Cela signifie que le client doit poursuivre la demande ou ignorer la réponse si elle est terminée.
- 2xx : un code 200 signifie succès.
- 3xx : ces codes signifient une redirection. Cela indique qu’il existe plusieurs réponses possibles à la demande. L’une d’entre elles doit être sélectionnée par l’agent utilisateur ou l’utilisateur.
- 4xx : les codes de ce groupe indiquent une erreur du client. Ceci signifie que le serveur ne peut pas traiter la demande et la considère comme une erreur côté client, comme une URL non reconnue, une syntaxe de requête incorrecte, etc.
- 5xx : le code HTTP 500 est renvoyé lorsqu’une erreur se produit côté serveur et que le serveur n’est pas en mesure d’effectuer la demande.
Si vous souhaitez découvrir les détails des statuts de réponse, vous pouvez trouver la liste complète en ligne.
8. Quels sont quelques outils courants d’automatisation des tests d’API ?
Pour cette question, je répondrais avec quelques outils avec lesquels j’ai déjà travaillé ou que je connais un peu. Donc, si vous avez de l’expérience avec un outil de test d’API, mentionnez-le. Sinon, vous pouvez répondre avec quelques noms connus, tels que Katalon, Postman ou SoapUI. Consultez notre article sur les meilleurs outils de test d’API pour trouver un peu d’inspiration.
9. Quelles sont les méthodes d’authentification les plus courantes en test d’API ?
Une réponse appropriée à cette question serait :
- Authentification basée sur session/cookies
- Authentification basique
- Authentification par condensé
- OAuth
10. Quelle est la différence entre l’authentification et l’autorisation ?
En bref, l’authentification est le processus de vérification de l’identité d’un utilisateur, tandis que l’autorisation définit le niveau d’accès qui lui est accordé.
11. Pourquoi les tests d’API sont-ils préférés aux tests UI pour les tests automatisés ?
Pour en revenir à la pyramide classique de l’automatisation des tests, il est bien connu dans notre secteur que les tests UI de bout en bout doivent se situer au sommet, ce qui signifie qu’ils doivent représenter le plus petit nombre de tests. En effet, les tests UI automatisés sont plus longs et sujets à l’instabilité parce qu’ils dépendent de beaucoup de facteurs. Les tests API automatisés constituent la partie intégration de la pyramide, ils sont bien plus rapides et en général plus fiables.
12. Quelle est la différence entre les tests d’API et les tests unitaires ?
Les tests unitaires s’inscrivent dans la logique du test "boîte blanche", alors que les tests d’API relèvent en général de tests "boîte noire". Puisque l’utilisateur final utilisera l’interface utilisateur, les tests d’API doivent représenter le système dans son ensemble. En test unitaire, une question clé est de s’assurer que chaque composant ou module fonctionne parfaitement. Autrement dit, pour garantir une architecture modulaire solide, il est important de minimiser les dépendances.
13. Quels types de tests peuvent être appliqués aux API ?
La plupart des types de tests appliqués aux interfaces utilisateur sont possibles pour les API. Quelques-uns des types de tests les plus importants que vous pouvez mentionner pour cette question d’entretien sur les API sont :
- Tests fonctionnels : la plupart du temps, vous souhaiterez vérifier que les API font ce pour quoi elles ont été conçues. Cela signifie que vous allez exécuter des cas de test fonctionnels sur les API.
- Tests manuels : ce n’est pas parce que vous n’êtes pas testeur d’automatisation que vous ne pouvez pas tester des API. Vous pouvez utiliser des outils comme Postman pour envoyer des requêtes et tester les réponses manuellement.
- Tests automatisés : il est judicieux d’automatiser les cas de test API. Beaucoup des outils mentionnés ci-dessus peuvent vous y aider, ou vous pouvez créer votre propre framework d’API.
- Tests de charge : en simulant du trafic sur les API, les testeurs peuvent identifier les goulets d’étranglement avant la mise en production. En l’absence d’une charge en production, il peut être difficile de détecter ces points faibles dans les environnements de développement. Il existe des outils de test de charge qui permettent d’envoyer des appels HTTP vers un endpoint donné et de mesurer le temps de réponse, les erreurs et taux d’erreur, ainsi que d’autres données précieuses issues des réponses. Ils permettent également de simuler de grands volumes de données pour évaluer le comportement d’une application.
- Tests de sécurité : avec les tests de sécurité, l’implémentation de l’API est protégée contre les menaces externes. Les étapes comprennent la vérification des techniques de chiffrement et de l’architecture du contrôle d’accès à l’API. La gestion des accès utilisateurs et la vérification des autorisations sont aussi incluses.
- Tests d’intrusion : avec ce type de test, des utilisateurs non familiers avec l’API tenteront d’évaluer les vecteurs de menace à distance en se concentrant sur des fonctionnalités, des ressources, des flux de travail, ou l’ensemble de l’API et de ses composants.
Que vous soyez testeur manuel ou que vous travailliez sur l’automatisation des tests, il est essentiel de savoir travailler avec les API. Si vous préparez des entretiens sur les tests API, j’espère que cet article vous sera utile.
N’oubliez pas de vous abonner à la newsletter de The CTO Club pour plus d’astuces et de tutoriels sur les tests !
