Tests d'intégration - recherche de vos connaissances, conseils et liens!

Question

Hé les gars, je suis après quelques conseils et des conseils sur les tests d'intégration pour une application web. Notre projet existe depuis plusieurs années et c'est raisonnablement complexe. Nous sommes plutôt bien couverts par les tests unitaires, mais il nous manque un ensemble décent de tests d'intégration. Nous n'avons pas de cas d'utilisation documentés ou même un ensemble raisonnable de cas de test au-delà de nos tests unitaires. Les «tests d'intégration» consistent aujourd'hui en la connaissance par le développeur de l'impact probable d'un changement et d'un test manuel et ponctuel de l'application. Ce n'est vraiment pas idéal - nous voulons maintenant concevoir et automatiser un ensemble solide de tests pour nous permettre d'effectuer des tests de régression et augmenter notre confiance dans la qualité de l'application.

Nous avons finalement construit une plate-forme (basée sur Selenium) pour nous permettre de créer et d'automatiser rapidement l'exécution des tests. Le problème maintenant: nous n'avons pas de tests, la page est bel et bien vide. Le système compte environ 30 classes qui interagissent entre elles et influencent l'interface utilisateur. Pour un nouvel utilisateur, il y a environ 40 propriétés qui peuvent être définies, chacune ayant une incidence sur l'expérience. Au cours de la vie de l'utilisateur, ils généreront encore plus d'états. Compte tenu de tant de variables et d'états possibles, c'est une perspective décourageante pour commencer, ce qui explique probablement pourquoi il a été négligé jusqu'à présent.

La douleur de ne pas avoir un ensemble décent de tests devient maintenant destructrice. Je consacre du temps pour résoudre ce problème - je suis après quelques conseils pratiques sur la rédaction des tests. Comment vous l'approchez-vous? Avez-vous des liens que je pourrais trouver utiles? Comment puis-je empêcher mon esprit de s'enfuir avec le nombre apparemment infini d'états pour les données d'un utilisateur? Comment puis-je débusquer les boîtiers de bord qui échouent (et que nos utilisations semblent trouver)?

Aide!

Answer 1

Si elle est l'énorme quantité de combinaisons qui vous retient en essayant de générer testcases, vous devriez definitly jeter un oeil à all-pair test.

Nous avons utilisé PICT de Microsoft comme un outil pour réussir à minimiser la quantité de cas de test tout en étant raisonnablement confiant pour avoir la plupart des cas couverts.

le raisonnement derrière toutes les paires de tests est la suivante: sont généralement déclenchées les bugs les plus simples dans un programme par un seul paramètre d'entrée . La prochaine catégorie la plus simple des bogues se compose de ceux qui dépendent des interactions entre les paires de paramètres, qui peuvent être capturés avec le test de toutes les paires. 1 Bugs impliquant des interactions entre trois ou plusieurs paramètres sont progressivement moins fréquents 2, tandis que en même temps être progressivement plus coûteux à trouver par exhaustive des tests , qui a pour limite la test exhaustive de tous les possibles entrées .