Supposons que vous travailliez sur un projet et que le budget de temps / monotone ne permet pas une couverture de 100% de tous les codes / chemins.
Il s'ensuit alors qu'un sous-ensemble critique de votre code doit être testé. Il est clair que une approche «gut-free» peut être utilisée pour tester le système, dans lequel l'intuition et l'analyse manuelle peuvent produire une sorte de couverture de test qui sera «OK».
Cependant, je suppose qu'il existe de meilleures pratiques / approches / processus qui identifient des éléments critiques jusqu'à certains seuils et vous permettent de concentrer vos éléments de test sur ces blocs.
Par exemple, un processus populaire d'identification des défaillances dans la fabrication est le mode de défaillance et l'analyse des effets. Je cherche un processus (ES) pour identifier des blocs de test critiques dans des logiciels.
8 Réponses :
Sauf si vous faites du développement Greenfield à l'aide de TDD, il est peu probable que vous obtiendrez (ou souhaitez) une couverture de test à 100%. La couverture de code est plus d'une ligne directrice, quelque chose à poser "ce qui n'a pas été testé?"
Vous voudrez peut-être regarder d'autres métriques, telles que Complexité cyclomatique . Trouvez les zones complexes de votre code et testez-les (puis refactorisateur pour simplifier).
+1 pour "Ce que je n'ai pas testé?" - C'est comme ça que j'utilise les numéros de couverture.
Cela dépend entièrement du type de logiciel que vous développez. S'il est accessible à distance, les tests de sécurité SiteWatch ou Wapiti, qui peut être utilisé. Il existe également des outils pour aider à générer des tests d'unité pour le savon.
Si SiteWatch est votre propre produit (car je vois qu'il est lié dans votre profil), veuillez ajouter un clause de non-responsabilité lorsque vous le recommandez.
@Michael Myers ♦ Je ne suis pas trompeur, je crois honnêtement que ce produit est meilleur que Acunetix et dans tous mes messages, je fournis au lecteur un choix de solutions gratuites et commerciales à leurs problèmes.
Il s'agit simplement de procédure d'exploitation standard définie dans le FAQ . Votre produit peut en effet être supérieur, mais le mentionner comme si vous recommandez un produit tiers se détache comme un peu sife.
@Michael Myers ♦ Je pense honnêtement que la sécurité sera améliorée en modifiant les mots "acunetix" sur "SiteWatch" dans mes propres messages. Je fournis des contenus pertinents et utiles dans mes postes de sécurité, après tout, je suis le meilleur utilisateur voté pour les réponses de sécurité. Nous voulons tous la même chose.
Je n'en doute pas, et vous avez raison de vous lier si vous pensez que cela vous aidera, mais nos règles nécessitent toujours une divulgation d'association avec des produits que vous recommandez. Je ne m'attends pas à ce que les électeurs soient terriblement inquiets à ce sujet, mais si quelqu'un d'autre est retourné et édité dans un lien vers son propre produit sans une divulgation dans leurs anciennes réponses, elle serait probablement traitée comme spam.
La couverture de code 100% n'est pas un objectif souhaitable. Voir Ce blog pour des raisons. Ma meilleure pratique consiste à tirer des cas de test des cas d'utilisation. Créer une traçabilité en béton (j'utilise un outil UML mais une feuille de calcul fera également) entre les cas d'utilisation que votre système est censé mettre en œuvre et tester des cas qui prouve que cela fonctionne. P>
identifier explicitement les cas d'utilisation la plus critique . Maintenant, regardez les cas de test qu'ils tracent. Avez-vous de nombreux cas de test pour les cas d'utilisation critique? Est-ce qu'ils couvrent tous les aspects du cas d'utilisation? Ils couvrent-ils des cas négatifs et exceptions? P>
J'ai constaté que être la meilleure formule (et la meilleure utilisation du temps de l'équipe) pour assurer une bonne couverture. P>
EDIT: P >
Exemple simple et artificiel de la raison pour laquelle la couverture de code 100% ne vous garantit pas de tester 100% des cas. Dis CriticalProcess () est censé appeler Appendfile () pour appeler le texte, mais appelle à la place WrardFile () pour écraser le texte. P>
[UnitTest]
Cover100Percent()
{
CriticalProcess(true, false);
Assert(FileContents("TestFile.txt") == "A is true");
CriticalProcess(false, true);
Assert(FileContents("TestFile.txt") == "B is true");
// You could leave out this test, have 100% code coverage, and not know
// the app is broken.
CriticalProcess(true, true);
Assert(FileContents("TestFile.txt") == "A is trueB is true");
}
void CriticalProcess(bool a, bool b)
{
if (a)
{
WriteFile("TestFile.txt", "A is true");
}
if (b)
{
WriteFile("TestFile.txt", "B is true");
}
}
J'ai trouvé certaines des réponses qui ont fait valoir que 100% est souhaitable de présenter des arguments convaincants: par exemple, si vous avez 100%, vous savez que tout le code est touché - si vous avez 90%, 10% ne sont pas frappés et non frappés. Mais ma question initiale travaille sous la prise de conscience que 100% est impossible en raison des contraintes de budget / temps.
@Paul: Même si vous appuyez sur 100% de vos lignes de code, vous ne vous rapprochez toujours pas de tester tous les chemins d'exécution possibles. Ajout d'un exemple simple à ma réponse pour illustrer. Vous ne concentrez pas vos efforts sur la preuve du logiciel implémentent correctement la fonctionnalité la plus importante si vous êtes concentré sur le maximum de nombreuses lignes de code.
Il y a 3 composants principaux que vous devez être conscients:
Si vous avez cette information, il ne sera probablement pas difficile de choisir comment distribuer vos ressources de test.
faux sens de la sécurité: Vous devez toujours être toujours conscient du fait que la couverture de test peut induire en erreur au faux sentiment de sécurité. Un excellent article sur ce fait peut être trouvé dans Le blog disco . Cela dit s'appuyer sur les informations des indicateurs "verts" vous permet de manquer des chemins non testés.
bon indicateur pour les chemins non testés: D'autre part Couverture de test manquante La plupart des temps affichés en rouge est toujours un excellent indicateur pour les chemins qui ne sont pas couverts. Vous pouvez vérifier ces premiers car ils sont faciles à repérer et vous permettent d'évaluer si vous souhaitez ajouter une couverture de test ici ou non.
Approche centrée sur le code pour identifier les éléments critiques: Il existe un excellent support d'outillage disponible pour vous aider à trouver le désordre et que possible Gotchas dans votre code. Vous voudrez peut-être consulter l'Ide Intellij et ses fonctionnalités d'analyse de code ou par exemple à Findbugs, Checkstyle et PMD. Un excellent outil qui combine ces outils d'analyse de code statiques disponibles gratuitement est Sonar .
Centric Centric APPROCH pour identifier les éléments critiques: Évaluez votre logiciel et décomposez-la en fonctionnalités. Demandez-vous des questions telles que: «Quelles fonctionnalités sont les plus importantes et devraient être plus fiables? Où devons-nous prendre soin de l'exactitude des résultats? Où serait un bogue ou une défaillance être la plus destructeur pour le logiciel?"
Peut-être que le meilleur indice qu'un module est insuffisamment couvert est des rapports de bogues contre elle. Tout module que vous émettez du temps et de nouveau devrait être bien couvert. Mais la complexité cyclomatique corrélait assez bien avec une fréquence de bug, et vous pouvez mesurer que avant les bugs apparaissent!
Si vous avez un code de code hérité, un bon endroit pour commencer est:
Ajoutez un test d'unité pour chaque bogue que vous trouvez et corrigez. Le test de l'unité doit reproduire le bogue, puis vous corriger le code et utiliser le test de l'unité pour vérifier qu'il est corrigé, puis être sûr à l'avenir qu'il ne casse pas à nouveau pour une raison quelconque.
Dans la mesure du possible, ajoutez des tests aux principaux composants de haut niveau de manière à ce que de nombreuses ruptures de faible niveau provoquent toujours une défaillance d'un test d'unité (par exemple, au lieu de tester chaque routine ACESS de base de données indépendamment, ajoutez un test qui crée une base de données, Ajoute 100 utilisateurs, supprime 50 d'entre eux, vérifie le résultat et dépose la base de données. Vous ne verrez pas facilement où l'échec est (vous devrez déboguer pour déterminer pourquoi il a échoué) mais Au moins, vous savez que vous avez un test qui exerce le système de base de données global et vous avertiez rapidement si quelque chose de majeur ne va pas dans cette zone du code. Une fois que vous avez les zones de niveau supérieur couvertes, vous pouvez vous inquiéter de développer plus profondément.
Ajoutez des tests d'unité pour votre nouveau code ou lorsque vous modifiez n'importe quel code.
Au fil du temps, cela vous aidera à construire une couverture dans les endroits les plus importants.
(Gardez à l'esprit que si votre codeBase est un code de travail qui fonctionne depuis des années, alors pour la plupart, vous n'avez pas "besoin" des tests d'unités pour prouver que cela fonctionne. Si vous n'ajoutez que des tests d'unité à tout, Ils vont à peu près tous passer et donc ne vous diront donc pas beaucoup. Bien sûr, au fil du temps, car votre couverture se développe, vous pouvez commencer à détecter les régressions de ces tests et vous trouverez des bogues à travers le processus d'ajout de tests d'unités auparavant non testés. CODE, mais si vous venez de passer à travers le code en ajoutant aveuglément des tests d'unité pour tout, vous obtiendrez un très mauvais rapport coût-bogue-bug)
à tout le testeur de couverture de 90%:
Le problème avec le fait est que le code de 10% du test est également le code non trivial contenant 90% du bogue! C'est la conclusion que je suis devenue empiriquement après de nombreuses années de TDD.
et après tout cela est assez simple conclusion. Ce code de 10% dure à tester est difficile à tester mais aussi:
Supposons que vous travailliez sur un projet et que le budget de temps / monotone ne permet pas une couverture de 100% de tous les codes / chemins. Aucune imagination nécessaire. C'est une impossibilité littérale de tester 100% de tous les codes / chemins.