Interactions impliqués dans pannes logicielles – des données empiriques


Original: http://csrc.nist.gov/groups/SNS/acts/ftfi.html

Number of variables involved in triggering software faults
Une des questions les plus importantes dans les tests de logiciels est «combien est assez»? Pour le test combinatoire, cette question consiste à déterminer le niveau approprié d’interaction qui doit être testé. Autrement dit, si une défaillance est déclenchée que par une combinaison inhabituelle de plus de deux valeurs, combien de combinaisons de tests sont suffisants pour détecter toutes les erreurs? Quel est le degré d’interaction se produit dans les défaillances du système réel?

Figue. 1. Nombre de variables impliquées dans le déclenchement de défaillances logicielles

Si vous avez des questions, ou si vous souhaitez apporter des données à cette collection, se il vous plaît écrivez-moi à kuhn@nist.gov.

Données sur les défaillances: Le tableau ci-dessous résume ce que nous savons des études empiriques à partir d’une variété de domaines d’application, montrant le pourcentage d’échecs qui sont induites par l’interaction d’un à six variables. Par exemple, 66% des défaillances de matériels médicaux ont été déclenchée par une valeur de la variable unique, et 97% ont été déclenchée par un ou deux variables interdépendantes. Bien que certainement pas concluantes, les données disponibles suggèrent que le nombre d’interactions invovled dans les défaillances du système est relativement faible, avec un maximum de quatre à six dans les six études citées ci-dessous. (Note: étude de TCAS utilisé erreurs ensemencées, tous les autres sont d’origine naturelle”.) Ces résultats peuvent être résumés dans ce que nous appelons la règle de l’interaction: La plupart des pannes sont induites par des failles de facteurs simples ou par l’effet combinatoire commune (interaction) de deux facteurs, progressivement avec moins de défaillances induites par les interactions entre trois ou plusieurs facteurs.

Tableau 1. Nombre de variables impliquées dans le déclenchement de défaillances logicielles

 

Vars

Vars médicale Navigateur Server NASA
GSFC
Réseau
Sécurité
TCAS
1 66 29 42 68 20 *
2 97 76 70 93 65 53
3 99 95 89 98 90 74
4 100 97 96 100 98 89
5 99 96 100 100
6 100 100

* = Pas signalé
** Note: étude de TCAS utilisé erreurs ensemencées, tous les autres sont d’origine naturelle”

Control branches in avionics software
Données d’analyse statique: Pourquoi les courbes de détection de défaut regardent cette façon? Ce est, pourquoi ne la queue de taux d’erreur à si rapidement avec plusieurs variables en interaction? Une possibilité est qu’il ya simplement quelques interactions complexes dans des points de ramification dans le logiciel. Si quelques branches impliquent quatrevoies, 5 voies, ou 6 voies interactions entre les variables, alors ce degré d’interaction pourrait être rare pour défauts ainsi. Le tableau ci-dessous (Tableau 2 et Fig. 2) donne le nombre et le pourcentage de

Figue. 2. Nombre de variables dans les branches de logiciels avioniques

branches dans le code de l’avionique déclenchées par un à 19 des variables. Je ai développé cette distribution du rapport de Chilenski sur l’utilisation de tests MCDC dans les logiciels de l’avionique, qui contient 20 256 expressions logiques dans cinq systèmes aéroportés différents dans deux modèles d’avion différents. Le tableau ci-dessous comprend toutes les expressions de 7685 si et alors que les déclarations; expressions de cession (: =) des déclarations ont été exclus.

Tableau 2. Nombre de variables dans les branches des logiciels d’avionique

Vars Comte Pct Cumulatif

1

5691 74.1% 74.1%
2 1509 19.6% 93.7%
3 344 4.5% 98.2%
4 91 1.2% 99.3%
5 23 0.3% 99.6%
6 8 0.1% 99.8%

Software faults vs. software branches

Comme le montre la Fig. 2, la plupart des expressions du compte de ramification sont simples, avec plus de 70% contenant une seule variable. Superposer la courbe de la Fig. 2 sur la Fig. 1, nous voyons (Fig. 3) que la plupart des défauts sont déclenchées par des interactions plus complexes entre les variables. Il est intéressant de noter que les défauts de base de données de la NASA distribués, de rapports

Figue. 3. Les défaillances logicielles vs branches de logiciels

de bugs de logiciels développement de phase, ont une distribution similaire à expressions dans ramification déclarations. Cela peut se expliquer par le fait que ce était le développement de phase plutôt que le logiciel mis en service comme tous les autres types présentés dans la figure. 1. Comme défauts sont supprimés, les défauts restants peuvent être plus difficiles à trouver car ils nécessitent l’interaction de plusieurs variables. Ainsi essais et l’utilisation peut pousser la courbe vers le bas et vers la droite.

Domaines de logiciels étroites: nous avons étudié une classe particulière de vulnérabilités, de déni de serivce, en utilisant des rapports de la National Vulnerability Database (NVD), un référentiel de données sur toutes les vulnérabilités révélées publiquement de logiciels de sécurité. NVD peut être interrogé pour les rapports fine granularité sur les vulnérabilités. Les données de 3045 vulnérabilités de déni de service ont la répartition ci-dessous.

Vars NVD
cumulatif %
1 93%
2 99%
3 100%
4 100%
5 100%
6 100%


L’analyse des données de l’échec: Notre étudiant de premier cycle Summer Research Fellowship Menal Modha a préparé un court tutoriel sur l’analyse des rapports de défaillance pour déterminer le degré d’interaction variable dans les échecs. Les ensembles de données NVD Wre analysés par Evan Hartig, Bryan Wilkinson, et Menal Modha, et sont disponibles ici:

NVD:
NVD données de vulnérabilité 2006 déni de service
NVD données de vulnérabilité 2007 déni de service

Sécurité réseau:
Bell a données de thèse

Combinatoire tests exhaustifs vs: Les études citées ci-dessous compare les méthodes combinatoires avec exhaustive (par rapport aux valeurs discrétisées) tests, montrant tests combinatoire produit des résultats équivalents avec seulement une petite fraction des tests requis pour exhaustive:

Giannakopoulou et al. (2011) ont comparé diverses mesures de couverture de code à l’aide de tests combinatoire et exahustive. La couverture était presque identique et les auteurs ont déclaré que seul un segment de code a été manqué de test 3-way, parce qu’elle exigeait une combinaison spécifique de quatre variables qui ont été pris avec un tableau de couverture à 4 voies.

Test set No. de tests Stmt % Direction% Boucle% Condition %
Exhaustive 9.9 x 106 94/94 90/92 46/37 85/83
3-way 6,047 93/94 89/91 46/37 83/81

Montanez et al. (2011) par rapport ensembles de test combinatoire et exhaustives pour les tests de conformité du modèle d’objet document W3C. Une suite de test à 4 voies trouve tous les défauts découverts par des tests approfondis avec moins de 5% du nombre de tests.

t Tests % de
Original
Résultats des tests
Passe échouer
2 702 1.92% 202 27
3 1342 3.67% 786 27
4 1818 4.96% 437 72
5 2742 7.49% 908 72
6 4227 11.54% 1803 72

Références

Medical Devices:  D.R. Wallace, D.R. Kuhn, Failure Modes in Medical Device Software: an Analysis of 15 Years of Recall Data, International Journal of Reliability, Quality, and Safety Engineering, Vol. 8, No. 4, 2001.
D.R. Kuhn and M.J. Reilly, An Investigation of the Applicability of Design of Experiments to Software Testing, 27th Annual NASA Goddard/IEEE Software Engineering Workshop (SEW ’02), Greenbelt, Maryland, December 5-6, 2002, pp. 91-95.
Abstract; DOI: 10.1109/SEW.2002.1199454
Comment: Investigates interaction level required to trigger faults in open source browser and server.
Browser, Server:
NASA database:  D.R. Kuhn, D.R. Wallace, A.J. Gallo, Jr., Software Fault Interactions and Implications for Software Testing, IEEE Trans. on Software Engineering, vol. 30, no. 6, June, 2004.

Network Security:  K.Z. Bell, Optimizing Effectiveness and Efficiency of Software Testing: a Hybrid Approach,  PhD Dissertation, North Carolina State University, 2006.

TCAS module:  D. R. Kuhn, V. Okun, “Pseudo-exhaustive Testing For Software, 30th NASA/IEEE Software Engineering Workshop, April 25-27, 2006 – proof-of-concept experiment on pseudo-exhaustive testing.

Avionics software branches:  J. J. Chilenski, An Investigation of Three Forms of the Modified Condition Decision Coverage (MCDC) Criterion, Report DOT/FAA/AR-01/18, April 2001, 214 pp.

D. Giannakopoulou, D.H. Bushnell, J. Schumann, H. Erzberger, K. Heere, “Formal Testing for Separation Assurance”, Ann. Math. Artif. Intell., 2011.  DOI: 10.1007/s10472-011-9224-3 (abstract)

C. Montanez, D.R. Kuhn, M. Brady, R. Rivello, J. Reyes, M.K. Powers, “An Application of Combinatorial Methods to Conformance Testing for Document Object Model Events”, NIST-IR 7773.  25 Jan 2011.

Comments are closed.