Réponse.

Les tests manuels d'intégration sont une étape importante du cycle de vie du logiciel, réalisée après les tests unitaires. Leur objectif est de s'assurer que les différents modules ou composants du système interagissent correctement entre eux.

Historique de la question : Initialement, les tests de logiciels étaient effectués par étapes : d'abord les modules individuels (tests unitaires), puis l'ensemble du système. Cependant, dans la pratique, il a été révélé que la plupart des erreurs critiques se produisent précisément à l'interface entre les modules. La nécessité des tests d'intégration est donc apparue, permettant de déceler manuellement les incohérences dans le comportement des différentes parties du système.

Problème : La principale difficulté réside dans une préparation insuffisante des scénarios d'interaction entre les modules et des dépendances oubliées. Cela conduit à des bugs "invisibles" : lors de tests isolés, tout fonctionne correctement, mais après l'intégration, des pannes se produisent (par exemple, un traitement incorrect des données entre l'API et la base de données).

Solution : Une bonne organisation des tests manuels d'intégration comprend :

L'analyse de l'architecture du système et la création d'une carte des interactions entre les composants.
Le développement de cas de test d'intégration basés sur des scénarios utilisateurs et des données limites.
La modélisation des pannes partielles (par exemple, la défaillance d'un des services) et l'évaluation de la réaction de l'ensemble du système.
La documentation des résultats et la fixation des dépendances entre les bugs.

Caractéristiques clés :

Maintien à jour du schéma architectural.
Prise en compte de toutes les dépendances cachées et explicites entre les parties du système.
Attention particulière aux scénarios de transmission et de transformation des données aux interfaces des modules.

Questions pièges.

Quelle est la différence entre les tests manuels d'intégration et les tests manuels système ?

Les tests d'intégration se concentrent sur la vérification des connexions entre des modules spécifiques, tandis que les tests système portent sur la vérification de l'ensemble du système dans son ensemble du point de vue de ses fonctionnalités commerciales.

Faut-il utiliser des services externes réels lors des tests d'intégration, ou des émulateurs suffisent-ils ?

Pour des intégrations critiques, un environnement réel est préférable, mais on peut commencer par des émulateurs (mock/stub). Les tests finaux doivent être effectués dans un environnement aussi proche que possible de la production.

Peut-on détecter toutes les erreurs d'intégration uniquement par automatisation ?

Non : certaines défauts ne peuvent être découverts qu'en manuel, lorsque le testeur remarque des problèmes non évidents dans la logique commerciale de l'échange de données ou dans des scénarios utilisateurs non couverts par l'automatisation.

Erreurs typiques et anti-modèles

Absence d'une liste claire des points d'intégration.
Réalisation de tests sans isolation de l'environnement.
Détail insuffisant des cas de test d'intégration.

Exemple de la vie réelle

Cas négatif

Les tests d'intégration entre le module de paiement et le module de commandes ont été effectués uniquement après l'achèvement de tous les autres tests et sans documentation séparée.

Avantages :

Économie de temps dans la préparation des cas de test.
Exécution rapide des tests sans coordination complexe.

Inconvénients :

Fuite de bugs sérieux en production, liés à des doubles prélèvements.
Retard de la version pour corriger des erreurs trouvées à la dernière minute.

Cas positif

Les scénarios d'intégration ont été fixés dès le départ, et les données de test ont été rapprochées des tâches réelles des utilisateurs.