Tout le monde doit être familiarisé avec la pensée prospective et la pensée inversée, car c'est une question courante. Cette façon de penser s'est répandue lors de la conception et de l'exécution de cas de test de logiciels.Le système de théorie scientifique des tests de logiciels existant dépend des résultats attendus et réels du test pour déterminer l'exactitude du logiciel. Permettez-moi de partager avec vous les tests de pensée positive et de pensée inverse.
Pensée positive
La pensée positive des tests logiciels consiste à essayer de vérifier qu'il fonctionne, c'est-à-dire que les fonctions du logiciel sont exécutées conformément à la préconception et que l'exactitude de toutes les fonctions du système est vérifiée une par une avec une pensée positive.
De tels cas de test sont omniprésents dans les tests normaux. Prenons l'exemple du système bancaire: le développeur ajoute un champ d'informations sur le bénéficiaire. Partant d'une pensée positive, nous pensons généralement que ces champs sont disponibles dans nos tests. Oui, les informations sur le bénéficiaire peuvent être affichées normalement et les éléments sont corrects, et les différents formats de données sont vérifiés dans le cadre autorisé par l'entreprise.
Bien sûr, nous pouvons incorporer différentes méthodes de test dans les cas de test de la pensée positive, en utilisant des données efficaces, des processus corrects et divers scénarios pour déduire l'exécution du logiciel; l'exécution de ces cas est basée sur la reconnaissance que le logiciel rencontre Sur la base du besoin, à travers l'exécution de cas pour prouver que le logiciel réussit, c'est une pensée positive
Pensée inversée
La pensée inverse dans les tests de logiciels consiste à tester le logiciel s'il est faux.
Quelqu'un a dit: "Si vous comparez le test positif à un élève qui obéit à l'enseignant, la pensée inverse du test est l'enfant qui s'oppose à l'enseignant et espiègle partout."
Bref: je veux juste vous confronter
d'un point de vue logique. Les deux propositions opposées sont des propositions équivalentes. On peut conclure que
si p? Q est vrai, alors ￢q? ￢p, en
partant de la pensée positive, nous arrivons à une telle proposition vraie: si le BUG est corrigé, alors le programme est exécuté sans erreur.
Le début de l'article mentionnait que les tests logiciels déterminent son exactitude à travers les résultats attendus et les résultats réels, afin de déterminer si le programme répond aux attentes.
Supposons que cette proposition soit considérée comme le processus d'exécution du logiciel. "BUG est corrigé" comme résultat attendu, et "l'exécution du programme est correcte" comme résultat réel. Évidemment, si cette proposition est vraie, une conclusion peut être tirée du processus d'exécution du logiciel - le logiciel répond aux attentes. Maintenant, nous partons de la pensée inverse sous un autre angle, et arrivons à sa proposition inverse:
"Si le programme est mal exécuté, alors le BUG n'a pas été corrigé."
En d'autres termes, si vous voulez prouver que le BUG n'a pas été corrigé, vous devez prouver que le programme est exécuté de manière incorrecte. Sur la base de la réflexion inverse, nous prouvons généralement l'existence de l'hypothèse d'une «erreur d'exécution de programme» en concevant et en exécutant des cas de test. Alors, comment concevoir et exécuter des cas de test basés sur la pensée inverse? Vous pouvez partir des points suivants:
- Penser constamment aux malentendus des développeurs
- Mauvaises habitudes des développeurs
- Limite du code du programme
- Entrée de données invalides
- Faiblesse du système
- Essayez de détruire le système, détruisez le système
Qu'il s'agisse de réflexion prospective ou inverse, le but des tests logiciels est le processus d'exécution de programmes pour trouver des erreurs. Pour reprendre un dicton classique "Un bon cas de test est qu'il peut trouver des erreurs qui n'ont pas été trouvées jusqu'à présent." Je vous souhaite à tous de continuer à améliorer vos qualifications professionnelles et d'évoluer rapidement sur la voie des tests!
Recommander de bons articles:
10 ans de perceptions des ingénieurs de test de logiciels - à des amis encore confus
Quel type de personne convient aux tests de logiciels?
Connaissances pour comprendre les tests automatisés python (3)
Quel est le plus adapté aux tests automatisés, Python ou Java?
Le travail quotidien des testeurs de logiciels
Enfin: Bienvenue à suivre l'éditeur pour recevoir un résumé des connaissances de base des ingénieurs de test automatisé Python avec un document pdf de 300 pages! Groupe d'échange de technologies de test de logiciels: (313782132) Le contenu de ces documents sont tous les points de connaissances que l'intervieweur doit demander pendant l'entretien. Le chapitre comprend de nombreux points de connaissances, y compris les connaissances de base, les bases de Linux, Shell, les principes du programme Internet, Mysql Base de données, rubriques sur les outils de capture de paquets, outils de test d'interface, programmation de tests avancés-Python, tests d'automatisation Web, tests d'automatisation des applications, tests d'automatisation d'interfaces, tests d'intégration continue avancés, framework de tests de développement d'architecture, tests de performances, tests de sécurité, etc.