Partage d'expérience en matière de tests de logiciels et 8 suggestions

Cet article présente principalement le partage d'expériences en matière de tests de logiciels et 8 suggestions. Il a une certaine valeur de référence. Maintenant, je le partage avec tout le monde. Les amis dans le besoin peuvent s'y référer

Beaucoup de gens pensent qu'un logiciel peut le faire. Les cas de test ne sont pas importants.Cette idée est fausse.Les cas de test les plus élémentaires ne sont pas disponibles, cela équivaut à tester sans but et n'obtiendra certainement pas l'effet. Ici, je vais vous expliquer comment rédiger des cas de test. Si quelque chose ne va pas, vous pouvez m'envoyer un message afin que je puisse en tirer des leçons.

Les cas de test doivent être rédigés avant le démarrage du projet. Pour les petits projets, vous pouvez simplement utiliser une feuille de calcul Excel. Pour les grands projets, vous pouvez utiliser des outils en ligne, tels que bugfree et ZenTao.

Je voudrais vous donner quelques suggestions pour écrire :

1. Vous pouvez cliquer sur le bouton de la page pour écrire. Par exemple, la page de connexion, comment accéder à la page de connexion est considérée comme un scénario de test. Revenez à la page précédente pour calculer un scénario de test. Cliquez pour vous connecter. Dans plusieurs cas, il y aura plusieurs cas de test. Plus ils sont détaillés, mieux c'est.

2, peut être écrit en effet page. Par exemple, sur la page d'accueil, s'il y a des fautes de frappe dans le texte, cela comptera pour un, si la catégorie est ajoutée, modifiée ou supprimée, et si l'affichage est normal, cela sera compté pour un.

3. S'il s'agit d'une commande, le montant doit être testé en faisant des erreurs. Par exemple, une erreur est signalée une fois le paiement de la commande réussi. L'argent de l'utilisateur a été payé, mais le logiciel ne l'a pas reçu. Existe-t-il une solution de suivi ?

4. Les niveaux de bugs peuvent être divisés en : S erreur fatale, qui affecte sérieusement l'utilisation ou l'interface ne peut pas être ouverte et les exigences ne sont pas satisfaites. Une erreur de données. B a répondu trop lentement (dépassé le temps de réponse). C fait des suggestions de modifications déraisonnables.

5. La version du téléphone mobile ou de l'ordinateur, la version du système, le testeur et l'heure du test doivent être clairement indiqués.

6. Si S et A existent, ils ne peuvent pas être en ligne.

7. Statistiques graphiques de bugs pour une visualisation facile par les dirigeants.

8. Les bugs doivent être traités par le personnel correspondant afin qu'un bug n'ait pas le même problème trois fois. Une entreprise stricte ne permet pas que le même problème se reproduise deux fois.

Ce qui précède représente l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'étude de chacun. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois !