Je travaille sur une application Java qui a beaucoup d'affaires d'usage. Les intrants à l'application sont différents types d'événements se produisant à des moments différents. Ce type d'intrant donne lieu à des centaines de cas de test. Quelqu'un a-t-il fait face à ce genre de scénario? Assurez-vous que tous les cas de test sont couverts avant de faire une publication à l'équipe QA? Ma question est donc la suivante: quelle est la meilleure approche pour les programmes de test avec de nombreux cas de test?
10 Réponses :
Tout dépend de votre temps et de votre budget. Dans un monde idéal, vous devriez faire toutes les possibilités. Mais nous savons tous que c'est un peu loin de la réalité.
La façon dont vous déclarez, il semble qu'il s'agisse d'un projet vraiment important. Dans ce cas, il est prévu de passer beaucoup de temps à tester aussi. Nous devrions mener du temps de test chaque fois que nous estimons tout projet.
Ce que je suggère, c'est de séparer les cas de test dans différentes catégories et de faire ce que vous pouvez avec votre temps et votre budget. Essayez de couvrir les principales catégories avec plus de tests que les secondaires. Ceci est crucial, car généralement 80% du temps est dépensé sur 20% du code. Et c'est la partie la plus importante.
Il est également important de prioriser ce qui est nécessaire pour le reste au travail. Disons que vous avez une application où seuls les utilisateurs souscrits peuvent faire des choses. Ensuite, la partie abonnée doit être très bien testée, si vous souhaitez que votre application soit utile.
Enfin, vous devriez essayer de créer des tests d'acceptation, cela indiquera que quelque chose ne va pas (bien qu'ils ne soient pas une grande partie de la recherche de ce qui ne va pas exactement).
Bien sûr, la meilleure approche serait de tester tous les cas de test ... mais du temps, de l'argent et ainsi de rendre cela impossible ...
L'une des approches serait de cas de test de groupe et de trouver un cas de test "super" par groupe!
Un autre serait de Identifier les modules de critique de votre application et de gérer ses cas de test en priorité.
Pourquoi les contraintes comme le temps et l'argent risquaient-elles de tester tous les cas de test? Si vous ne pouvez pas le tester (automatiquement ou manuellement), comment savez-vous que vous avez livré ce qui a été demandé? Vous devez donc tester tout le cas de test d'une manière ou d'une autre, et je ne l'achète pas qu'il devrait être moins cher ou plus rapide (à plusieurs reprises) le faire manuellement.
@Mark: En théorie, bien sûr que vous avez raison ... mais parfois, vous n'avez pas assez de temps pour mettre en œuvre de nouvelles fonctionnalités et tester tous les cas de test ... parce que vous n'êtes pas assez d'ordinateurs pour les tests automatiques ou pour une autre raison. ..
Parfois, les clients préfèrent les fonctionnalités de Time avec de petits bugs que des fonctionnalités parfaites sans bugs ...
Si vous avez des centaines de cas de test, je suppose que c'est parce qu'il reflète la variabilité de l'entrée et des exigences de l'application?
Si vous n'écrivez pas des tests pour tous ces cas (connus), comment saurez-vous si vous avez livré la fonctionnalité souhaitée?
L'alternative aux tests automatisés est le test manuel, et je ne vois pas comment tester manuellement des centaines de cas de test vous permet de sauvegarder à tout moment par rapport aux tests automatisés.
Habituellement, si vous testez une seule fois, les tests manuels sont plus rapides. Les tests automatisés sont utiles lorsque vous devez faire les mêmes tests sur et sur
À quelle fréquence les choses sont-elles testées une fois et une seule fois?
Écrire beaucoup de tests de l'unité à partir de la toute première étape d'une nouvelle application n'est pas mon approche. En général, lorsque je crée une nouvelle application (à partir de zéro), je crée d'abord un prototype, sans aucune uT . Une fois que j'ai un prototype de travail sur un scénario de la journée ensoleillée, et que certains pairs l'examinent (et approuvent, s'améliorent, etc.) - Je fais deux choses: j'écris des tests d'unité qui couvrent le scénario de la journée ensoleillée, puis j'ai refactoris mon code. < / p>
Ce n'est qu'alors que je continue à travailler sur l'application, mais j'essaie d'écrire UT que je considère important . Trop d'UT peut donner la fausse impression que le code est entièrement couvert. Dans le monde réel, une telle couverture existe rarement.
Écrivez les tests avant d'écrire le code. Cela ne signifie pas les tests d'écriture pour chaque scénario avant même de commencer , cela signifie écrire un test, passez ce test, passez à l'étape suivante. Il ne veut pas Ajoutez que beaucoup au temps de développement, en particulier, vous envisagez maintenant de connaître la seconde quelque chose qui se casse.
Viser 100% de couverture de test dans tous les cas.
Avec le nombre de combinaisons, il n'est probablement pas réaliste de pouvoir couvrir tous les scénarios.
Ce que vous pouvez faire est:
Testez tout code dans la mesure du possible une fois (près de 100% de la couverture de code)
Concentrez-vous sur les zones où vous estimez qu'il peut y avoir un problème d'écrire des tests supplémentaires
Chaque fois que QA trouve une erreur, écrivez un test pour afficher l'erreur avant de le réparer
Si vous ne pouvez pas écrire des tests pour tout ce que la prochaine meilleure chose que je suggère de suggérer est de mesurer votre en utilisant des outils de couverture tels que
Je pense que vous êtes confondre des cas d'utilisation des tests et des tests unitaires. Les cas de test devraient essayer d'être au niveau de la méthode ou au plus au niveau de la classe. Dans ce cas, vous devriez essayer d'avoir le meilleur de la couverture que possible dans vos contraintes de budget / temps et vous devriez les écrire avant / en écrivant votre code.
Je pense que les développeurs devraient également essayer de parcourir les cas d'utilisation réels et de les automatiser avec quelque chose comme Selenium pour s'assurer que le produit est solide mais finalement après une quantité raisonnable de ce type de test, il devrait être livré à QA.
N'essayez pas de couvrir avec des tests unitaires toute l'application du début. Faites-le en petites étapes incrémentielles. Définissez une petite étape pour atteindre en une semaine ou deux, puis commencez à écrire des tests pour la première fonctionnalité de cette étape. Ensuite, commencez à mettre en œuvre cette fonctionnalité. Cela devrait être quelque chose comme ceci:
L'avantage de cette méthode, rompre une tâche énorme sur des pièces gérables, c'est que cela vous donne la chance d'avoir quelque chose de terminé dans une semaine ou de deux. Plus tard, la direction peut repenser les priorités et vous devrez réorganiser la liste du premier point ci-dessus. Un autre avantage est que d'avoir à chaque étape un test unitaire qui vous soutient donne confiance à une idée que vous accomplissez réellement quelque chose, et vous pouvez en réalité livrer quelque chose à votre gestion plus rapidement que vous ne le croirez parce que à chaque étape, vous avez un ( quelque peu) Version de travail de votre programme. Ils peuvent voir des progrès et cela est très important pour vous et eux. Ils voient que le travail est effectivement fait et vous obtenez les commentaires dont vous avez besoin pour votre demande (les exigences changent toujours, continuons à changer le plus tôt possible).
comme Gren a dit, vous êtes probablement déroutant des cas d'utilisation avec des tests unitaires. Les actions qu'un utilisateur peut prendre une application peut tout aussi bien être traitée par une seule méthode du modèle de domaine. Donc, la situation peut ne pas être aussi mauvaise que cela semble.
Quoi qu'il en soit, n'essayez pas d'écrire tous vos tests depuis le début. C'est comme ça que je le faisais et c'était un gros échec. Une fois que vous faites de petites itérations (méthode de test / mise en œuvre de la méthode), vous deviendrez beaucoup plus productif et confiant. Lorsque vous écrivez tous vos tests à l'avant, vous pouvez remarquer qu'en raison des facteurs facteurs nécessaires pour faire passer vos premiers tests, vous devez repenser l'API entière que vous avez envisagée lors de la rédaction des tests en premier lieu, alors que l'écriture d'un test, Ensuite, la mise en œuvre, un test, puis la mise en œuvre, vous vous retrouvez avec ce qu'on appelle la conception émergente. Et c'est le meilleur type de conception. C'est ainsi que des motifs de conception sont apparus. Les modèles de design ne sont pas sortis de quelqu'un qui se trouvaient toute la journée et pensa à des moyens de résoudre le problème. petites étapes incrémentielles
Préparez-vous au changement
NO UP AVANT LA CONCEPTION, MÊME POUR DES TESTS UNITÉS
Très bonne réponse, c'est un endroit idéal pour demander ce genre de réponse: +1
Je fais une utilisation intensive des théories de Junit afin de minimiser les cas de test: sympa, ce n'est pas?
1 commentaires
Il y a un bug dans le chrome qui m'empêche que cela corrige ma réponse :( :( divisible sera appelé avec toutes les combinaisons de A et B :