Comment mesurer la robustesse?

Question

Je travaille sur une thèse sur meassuring la qualité d'un produit. Le produit dans ce cas est un site Web. J'ai identifié plusieurs attributs de qualité et des techniques meassurement.

Un attribut de qualité est « Robustesse ». Je veux que meassure en quelque sorte, mais je ne peux pas trouver toutes les informations utiles comment faire cela d'une manière objective.

Y at-il métrique statique ou dynamique qui pourrait robustesse meassure? -À-dire, comme la couverture de test unitaire, est-il un moyen de robustesse meassure comme ça? Si oui, est-il un outil (gratuit) qui peut faire une telle chose?

Quelqu'un at-il une expérience avec un tel outillage?

Enfin, peut-être il y a d'autres façons de déterminer la robustesse, si vous avez des idées à ce sujet, je suis toutes les oreilles.

Merci beaucoup à l'avance.

Answer 1

Eh bien, la réponse est « non ». Robuste peut vouloir dire beaucoup de choses, mais la meilleure définition que je peux venir avec est « l'exécution correcte dans toutes les situations. » Si vous envoyez une mauvaise tête HTTP à un serveur Web robuste, il ne devrait pas tomber en panne. Elle doit retourner exactement le bon type d'erreur, et il doit se connecter quelque part l'événement, peut-être d'une manière configurable. Si un serveur Web robuste fonctionne depuis très longtemps, son empreinte mémoire doit rester le même.

Beaucoup de ce qui rend un système robuste est le traitement des dossiers de bord. De bons tests unitaires sont une partie de cela, mais il est fort probable qu'il n'y aura pas de tests unitaires pour l'un des problèmes qu'un système a (si ces problèmes étaient connus, les développeurs auraient probablement les fixes et seulement alors ajouté un test) .

Malheureusement, il est presque impossible de mesurer la robustesse d'un programme arbitraire parce que, pour ce faire, vous devez savoir ce que ce programme est censé faire. Si vous aviez un cahier des charges, vous pouvez écrire un grand nombre de tests, puis les exécuter contre tout client comme un test. Par exemple, regardez le test du navigateur Acid2. Il mesure avec soin comment un navigateur Web donnée est conforme à une norme de façon simple et reproductible. C'est à peu près aussi proche que vous pouvez obtenir, et les gens l'ont souligné de nombreux défauts avec une telle approche (par exemple, est un programme qui se bloque plus souvent, mais fait une chose supplémentaire selon les spécifications plus robuste?)

Il y a, cependant, divers contrôles que vous pouvez utiliser comme une estimation approximative, numérique de la santé d'un système. couverture de test unitaire est un assez standard, tout comme ses frères et sœurs, la couverture de la branche, la couverture de la fonction, la couverture des instructions, etc. Un autre bon choix est des programmes de « peluches » comme FindBugs. Ceux-ci peuvent indiquer les problèmes potentiels. Les projets open source sont souvent jugés par la fréquence et récemment commits sont faits ou communiqués publiés. Si un projet a un système de bug, vous pouvez mesurer combien de bugs ont été corrigés et le pourcentage. S'il y a une instance spécifique du programme que vous mesurez, en particulier avec beaucoup d'activité, MTBF (Mean Time Between Failure) est une bonne mesure de robustesse (voir Philip réponse)

Ces mesures, cependant, ne vous disent pas vraiment comment un programme est solide. Ils sont simplement des façons de le deviner. S'il était facile de savoir si un programme était solide, nous aurions probablement juste faire le chèque du compilateur pour elle.

Bonne chance avec votre thèse! J'espère que vous venez avec quelques frais de nouvelles mesures!

Answer 2

Vous pouvez regarder dans temps moyen entre défaillances comme une mesure de robustesse. Le problème est qu'il est une quantité théorique qui est difficile à mesurer, en particulier avant d'avoir déployé votre produit à une situation réelle avec des charges réelles. Une partie de la raison est que le test ne couvre pas souvent des problèmes d'évolutivité dans le monde réel.

Answer 3

Dans notre livre de fuzzing (par Takanen, DeMott, Miller), nous avons plusieurs chapitres consacrés à des mesures et de la couverture dans les tests négatifs (robustesse, fiabilité, tests de grammaire, fuzzing, beaucoup de noms pour la même chose). Aussi j'ai essayé de résumer les aspects les plus importants dans notre livre blanc de la société:

http://www.codenomicon.com/products/coverage.shtml

Snippet à partir de là:

---

La couverture peut être considérée comme la somme de deux caractéristiques, la précision et la précision. La précision est concernée avec une couverture de protocole. La précision des tests est déterminée par la façon dont les tests portent sur les différents messages de protocole, des structures de message, les balises et les définitions de données. La précision, d'autre part, mesure la précision des tests peuvent trouver des bogues dans les différents domaines de protocole. Par conséquent, la précision peut être considérée comme une forme de couverture anomalie. Cependant, la précision et l'exactitude sont assez termes abstraits, donc, nous devrons examiner des mesures plus spécifiques pour l'évaluation de la couverture.

Le premier aspect de l'analyse de couverture est liée à la surface d'attaque. analyse des besoins de test commence toujours par identifier les interfaces qui ont besoin de tests. Le nombre de différentes interfaces et les protocoles qu'ils mettent en œuvre dans différentes couches énoncent les conditions les fuzzers. Chaque protocole, le format de fichier, ou API peut nécessiter son propre type de fuzzer, en fonction des exigences de sécurité.

Deuxième métrique de couverture est liée à la spécification qu'un fuzzer soutient. Ce type de mesure est facile à utiliser avec fuzzers à base de modèles, comme la base de l'outil est formé par les spécifications utilisées pour créer le fuzzer, et donc ils sont faciles à énumérer. Un générateur de bruit basé sur un modèle devrait couvrir l'ensemble du cahier des charges. Considérant que, fuzzers à base de mutation ne couvrent pas nécessairement entièrement les spécifications, comme la mise en œuvre ou dont un échantillon d'échange de messages à partir d'un cahier des charges ne garantit pas que l'intégralité de la spécification est couvert. Typiquement, quand un générateur de bruit sur la base mutation revendique support de mémoire, cela signifie qu'il est interopérable avec des cibles de test mettant en oeuvre le cahier des charges.

En particulier en ce qui concerne le fuzzing de protocole, la métrique troisième plus critique est le niveau de statefulness de l'approche choisie fuzzing. Un générateur de bruit tout à fait aléatoire généralement tester uniquement les premiers messages dans les protocoles complexes stateful. L'approche de fuzzing plus conscients état que vous utilisez est, plus la fuzzer peut aller dans les échanges complexes de protocoles. Le statefulness est une exigence difficile à définir pour les outils de fuzzing, car il est plus une mesure pour définir la qualité du modèle de protocole utilisé, et peut donc être vérifiée que par l'exécution des tests.

---

J'espère que cela a été utile. Nous avons également des études dans d'autres mesures telles que regarder la couverture de code et d'autres données plus ou moins inutiles. ;) Metrics est un grand sujet pour une thèse. Envoyez-moi à ari.takanen@codenomicon.com si vous êtes intéressé d'avoir accès à nos recherches approfondies sur ce sujet.

Answer 4

Robustesse est très subjective, mais vous pouvez jeter un oeil à FingBugs , et href="http://hudson-ci.org/" rel="nofollow noreferrer"> Hudson qui, lorsqu'ils sont combinés ensemble correctement pourrait vous donner un sentiment de sécurité au fil du temps que le logiciel est robuste.

Answer 5

  

Vous pouvez regarder dans le temps moyen entre   échecs en tant que mesure de la robustesse.

Le problème avec « MTBF » est qu'il est généralement mesurée en trafic positif alors que les défaillances se produisent souvent dans des situations inattendues. Il ne donne aucune indication de la robustesse ou la fiabilité. Peu importe si un site Web reste toujours dans un environnement de laboratoire, il sera encore piraté dans un second dans l'Internet si elle a une faiblesse.