Quelle méthode d'essai utiliser ?

Question

Tout d'abord, je suis novice en matière de tests de logiciels. Je suppose que je suis plutôt vert. Néanmoins, pour ce projet, j'en ai besoin pour m'assurer que tous les calculs sont effectués correctement. Pour le moment, j'utilise des tests unitaires pour tester chaque module en C# afin de m'assurer qu'il fait ce qu'il doit faire.

Je connais différentes méthodes de test (intégration, tests unitaires), mais je n'arrive pas à trouver un bon livre ou un document de référence sur les tests en général. La plupart d'entre eux sont très pointus dans un domaine spécifique (comme les tests unitaires). Il est donc très difficile (pour moi) d'avoir une bonne compréhension de la façon de tester au mieux votre logiciel et de la méthode à utiliser.

Par exemple, j'utilise également des éléments d'interface graphique, dois-je les tester ? Devrais-je simplement les tester en les utilisant, puis confirmer visuellement que tout est en ordre ? Je sais que cela dépend du caractère critique ou non, mais à partir de quel moment peut-on dire "Ne testons pas cela, car ce n'est pas vraiment pertinent/important" ?

Donc, en résumé : comment choisir la meilleure méthode de test, et où fixer la limite lorsque vous utilisez la méthode pour tester votre logiciel ?

Answer 1

Il existe plusieurs types de tests, mais les plus importants sont les tests unitaires, les tests de composants, les tests de fonctions et les tests de bout en bout.

• Unit tests vérifie si vos classes fonctionnent comme prévu (JUnit). Ces tests sont la base de votre environnement de test car ils indiquent si vos méthodes fonctionnent. Votre objectif est d'obtenir une couverture de 100 %, car il s'agit de la partie la plus importante de vos tests.
• Component tests vérifie comment plusieurs classes fonctionnent ensemble dans votre code. Le composant peut être un grand nombre de choses dans le code, mais c'est essentiellement plus que les tests unitaires, et moins que les tests de fonctions. L'objectif de couverture est d'environ 75%.
• Function tests testent les fonctionnalités réelles que vous mettez en œuvre. Par exemple, si vous voulez un bouton qui enregistre certaines données d'entrée dans une base de données, il s'agit d'une fonctionnalité du programme. C'est ce que vous testez. La couverture visée ici est d'environ 50 %.
• End-to-end tests testent l'ensemble de votre application. Celles-ci peuvent être assez robustes, et vous ne pouvez et ne voulez probablement pas tout tester, ce test est là pour vérifier si l'ensemble du système fonctionne. L'objectif de couverture est d'environ 25%.

C'est aussi l'ordre d'importance.

Mais il n'y a rien de tel dans ce domaine que d'être "meilleur". Tout test que vous pouvez exécuter pour vérifier que votre code fonctionne comme prévu est également bon.

Vous souhaitez probablement que la plupart de vos tests soient automatisés : vous pouvez ainsi tester pendant votre pause café ou vos serveurs peuvent tout tester pendant votre absence du travail, puis vérifier les résultats le matin.

Les tests de l'interface graphique sont considérés comme la partie la plus difficile des tests, et il existe plusieurs outils qui vous aident dans ce domaine, par exemple Selenium pour les tests de l'interface graphique du navigateur. Plusieurs modèles architecturaux comme Model-View-Presenter essaient de séparer la partie GUI de l'application pour cette raison et de travailler avec une GUI aussi muette que possible pour éviter les erreurs. Si vous parvenez à séparer votre graphique, vous serez en mesure de simuler la partie GUI de l'application et de l'exclure de la plupart des processus de test.

Pour référence, je suggère "Effective Software Testing" d'Elfriede Dustin, mais je ne suis pas familier avec les livres sur le sujet ; il pourrait y en avoir de meilleurs.

Answer 2

Cette réponse est spécifique au type d'application dans lequel vous êtes impliqué - WinForms Pour les interfaces graphiques, utilisez le modèle MVC/MVP. Évitez d'écrire du code dans le fichier "code behind". Cela vous permettra de tester unitairement votre code UI. Quand je dis code UI, cela signifie que vous serez en mesure de tester votre code qui sera invoqué lorsqu'un bouton est cliqué ou toute action qui doit être prise sur un événement UI.

Vous devriez être en mesure de tester unitairement chacun de vos fichiers de classe (sauf le code de l'interface utilisateur). Nous nous concentrerons principalement sur les tests basés sur l'état.

Vous serez également en mesure d'écrire des cas de test d'interaction pour les tests impliquant plusieurs fichiers de classe. Ceci devrait couvrir la plupart de vos flux.

Il y a donc deux choses sur lesquelles se concentrer Tests basés sur l'État et Test d'interaction .

Answer 3

Cela dépend vraiment du logiciel que vous devez tester. Si vous êtes surtout intéressé par la logique derrière (les calculs), vous devriez écrire des tests d'intégration qui ne testent pas seulement les méthodes séparées, mais le flux de travail du début à la fin, en essayant d'émuler ce que l'utilisateur typique ferait. J'ai du mal à imaginer que l'utilisateur appelle une méthode en particulier - plus probablement une séquence spécifique de méthodes. Si les calculs sont corrects, il y a peu de chances que l'interface graphique les affiche mal. En outre, l'automatisation de l'interface graphique est un processus qui prend du temps et il faudra beaucoup de compétences et d'énergie pour la construire et la maintenir, car chaque changement simple peut tout casser. Mon conseil est de commencer par écrire des tests d'intégration avec différentes valeurs qui couvriront les scénarios les plus courants.