Comment planifier des tests whitebox

Question

Je suis relativement nouveau dans le monde des WhiteBox tests et ont besoin d'aide la conception d'un plan d'essai pour 1 des projets sur lesquels je travaille actuellement. En ce moment, je suis juste éclaireur à la recherche de pièces testables de code, puis d'écrire des tests unitaires pour cela. Je me sens en quelque sorte qui est de loin pas la façon dont il devrait être fait. S'il vous plaît pourriez-vous me donner des conseils sur la meilleure façon de me préparer pour tester ce projet? Tous les outils ou modèles de plan de test que je pourrais utiliser? La langue utilisée est C ++ si elle va faire la différence.

Answer 1

L'un des objectifs de tests boîte blanche est de couvrir 100% (ou aussi près que possible) des instructions de code. Je suggère de trouver un outil de couverture de code C ++ afin que vous puissiez voir ce que le code de vos tests et exécuter ce code que vous avez manqué. Ensuite, concevoir des tests afin que le code autant que possible est testé.

Une autre suggestion est de regarder les conditions aux limites si statments, pour les boucles, tout en boucles, etc. et de tester ces derniers pour les zones « grises », les faux positifs et de faux négatifs.

Vous pourriez également concevoir des tests pour examiner le cycle de vie des variables importantes. Testez leur définition, leur utilisation et leur destruction pour vous assurer qu'ils sont utilisés correctement:)

Il y a trois idées pour vous aider à démarrer. Bonne chance

Answer 2

  

En ce moment je suis scouting simplement un tour pour pièces testables de code, puis d'écrire des tests unitaires pour cela. Je me sens en quelque sorte qui est de loin pas la façon dont il faut le faire.

Les gens disent que l'un des principaux avantages de « test de développement conduit » est qu'il vous ecourages de concevoir vos composants avec testabilité à l'esprit: il rend vos composants plus testable

.

---

Mon approche personnelle (non-TDD) est suit comme:

• Comprendre les fonctionnalités requises et mises en œuvre: à la fois « a priori » (à savoir par la lecture / connaissance de la spécification fonctionnelle du logiciel), et en lisant le code source de désosser la fonctionnalité
• Mettre en œuvre des tests de boîte noire pour toutes les fonctionnalités mises en œuvre / nécessaire (voir par exemple « Si l'un test de mise en œuvre interne ou tester uniquement le comportement du public? ').

Mon test est donc pas « boîte blanche » tout à fait, sauf que je l'ingénierie inverse la fonctionnalité testée. Je teste alors que la fonctionnalité ingénierie inverse, et éviter d'avoir un code inutile (et donc non testé). Je pouvais (mais ne pas souvent) utiliser un outil de couverture de code pour voir combien le code source est exercée par les tests de boîte noire.

Answer 3

Essayez "Travailler efficacement avec Legacy Code": http: //www.amazon. com / travail-efficace-Legacy-Michael-plumes / dp / 0131177052

Il est pertinent puisque par « héritage », il signifie le code qui n'a pas de tests. Il est aussi un plutôt bon livre.

outils pertinents sont les suivants: http://code.google.com/p/googletest/ et http://code.google.com/p/gmock/ Il peut y avoir d'autres cadres de tests unitaires et des simulations, mais j'ai connaissance avec ces derniers et je les recommande fortement.