Frage

Ich arbeite an einer Dissertation über meassuring Qualität des Produktes aus.Das Produkt in diesem Fall ist eine website.Ich identifiziert haben, die mehrere Qualitätsmerkmale und meassurement Techniken.

Ein Qualitätsmerkmal ist die "Robustheit".Ich möchte meassure, dass irgendwie, aber ich kann nicht finden alle nützliche Informationen, wie man dies in einer objektiven Weise.

Ist es eine statische oder dynamische Metrik, könnte meassure Robustheit?Dh, wie unit-test-Abdeckung, gibt es eine Möglichkeit zu meassure Robustheit wie das?Wenn ja, gibt es eine (Kostenlose) tool, so etwas zu tun?

Hat jemand Erfahrung mit solche Werkzeuge?

Nicht zuletzt, vielleicht gibt es andere Möglichkeiten, um festzustellen, Robustheit, wenn Sie irgendwelche Ideen über, dass ich bin alle Ohren.

Vielen Dank im Voraus.

War es hilfreich?

Lösung

Nun, die kurze Antwort ist "Nein". Robust kann viele Dinge bedeuten, aber die beste definition, die ich mit oben kommen kann ist "funktionieren in jeder situation." Wenn Sie senden eine schlechte HTTP-header, um eine robuste web-server, sollte es nicht Abstürzen.Sollte es wieder genau die richtige Art von Fehler, und es sollte das Ereignis anmelden, irgendwo, vielleicht in einem konfigurierbaren Weg.Wenn eine robuste web-server ausgeführt wird, für eine sehr lange Zeit der Speicherbedarf der sollte gleich bleiben.

Eine Menge von dem, was macht ein system robust ist seine Handhabung von edge-Fällen.Gute unit-tests sind ein Teil davon, aber es ist sehr wahrscheinlich, dass es sich nicht um unit-tests für die Probleme, die ein system hat, wenn diese Probleme bekannt waren, haben sich die Entwickler wohl behoben haben und nur dann Hinzugefügt, test).

Leider ist es fast unmöglich zu Messen die Robustheit zu einem beliebigen Programm, weil damit zu tun, dass Sie benötigen, zu wissen, was das Programm tun soll.Wenn Sie hatte eine Spezifikation, könnten Sie schreiben, eine große Anzahl von tests und führen Sie Sie gegen jede client-als test.Für Beispiel, Blick auf den Acid2 browser test.Es sorgfältig misst, wie gut beliebigen web-browser entspricht einem standard in eine einfache, wiederholbare Mode.Das ist ungefähr so nah wie Sie bekommen können, und die Leute haben darauf hingewiesen, vielen Fehler, die solch ein Konzept (für Beispiel, ist ein Programm, das Abstürze mehr oft, aber nicht eine zusätzliche Sache nach spec robuster?)

Es gibt allerdings verschiedene Prüfungen, die Sie verwenden, wie eine raue, numerische Schätzung, die Gesundheit eines Systems.Unit-test-Abdeckung ist ein ziemlich standard, ebenso wie seine Geschwister, branch coverage, Funktion coverage statement coverage, etc.Eine weitere gute Wahl ist "lint" - Programme wie FindBugs.Diese können zeigen das Potenzial für Probleme.Open-source-Projekte werden oft danach beurteilt, wie Häufig und kürzlich verpflichtet sind, gemacht oder Veröffentlichungen veröffentlicht.Wenn ein Projekt einen bug system, können Sie Messen, wie viele Fehler wurden behoben, und der Prozentsatz.Wenn es eine bestimmte Instanz von dem Programm, das Sie Messen, besonders mit einer Menge von Aktivitäten, MTBF (Mean Time between Failures) ist ein gutes Maß für die Robustheit (Siehe Philip Antwort)

Diese Messungen, aber nicht wirklich sagen, wie robust ein Programm ist.Sie sind bloß Möglichkeiten, um zu erraten, es.Wenn es einfach wäre, herauszufinden, ob ein Programm robust war, würden wir wahrscheinlich nur den compiler überprüfen.

Viel Glück bei Ihrer Arbeit!Ich hoffe, Sie kommen mit ein paar Coole neue Messungen!

Andere Tipps

könnten Sie sehen in mittlere Betriebsdauer zwischen Ausfällen als Robustheit messen . Das Problem ist, dass es sich um eine theoretische Menge ist, die schwierig zu messen, vor allem, bevor Sie Ihr Produkt zu einer realen Situation mit realen Lasten bereitgestellt hat. Ein Teil der Grund dafür ist, dass oft die Prüfung nicht der realen Welt Skalierbarkeitsprobleme abdeckt.

In unserem Buch Fuzzing (von Takanen, DeMott, Miller) wir mehrere Kapitel haben für Metriken gewidmet und Berichterstattung in negativem Test (Robustheit, Zuverlässigkeit, Grammatikprüfung, Fusseln, viele Namen für die gleiche Sache). Auch habe ich versucht wichtigsten Aspekte in unserem Unternehmen zusammenfassen White Paper hier:

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

Snippet von dort aus:

Coverage kann als die Summe von zwei Funktionen, Präzision und Genauigkeit zu erkennen. Die Präzision wird mit Protokollabdeckung betroffen. Die Genauigkeit der Tests durch, wie gut die Tests decken die verschiedenen Protokollnachrichten, Nachrichtenstrukturen, Tags und Datendefinitionen bestimmt. Genauigkeit, auf der anderen Seite, der misst, wie genau die Tests Fehler in unterschiedlichen Protokollbereichen finden. Daher kann die Genauigkeit als eine Form der Anomalie Deckung angesehen werden. Allerdings Präzision und Genauigkeit sind ziemlich abstrakt, also müssen wir zur Bewertung der Berichterstattung an spezifischere Metriken suchen.

Der erste Abdeckungsanalyse Aspekt ist auf die Angriffsfläche bezogen. Testanforderungsanalyse beginnt immer durch die Schnittstellen zu identifizieren, die getestet werden müssen. Die Anzahl der verschiedenen Schnittstellen und die Protokolle, die sie in verschiedenen Schichten implementieren setzen die Anforderungen an die Fuzzer. Jedes Protokoll, das Dateiformat oder API könnte seine eigene Art von fuzzer erfordern, je nach den Sicherheitsanforderungen.

Zweite Abdeckung Metrik ist, dass ein fuzzer Träger die Spezifikation bezogen. Diese Art der Metrik ist einfach zu bedienen mit der modellbasierten Fuzzer als Grundlage des Werkzeugs durch die Spezifikationen gebildet wird verwendet, um die fuzzer zu schaffen, und deshalb sind sie leicht zu Liste. Eine modellbasierte fuzzer sollte die gesamte Spezifikation abdecken. Während die Mutation basierte Fuzzer müssen nicht vollständig der Spezifikation abdecken, wie die Umsetzung oder darunter ein Nachrichtenaustausch Probe aus einer Spezifikation nicht garantiert jedoch, dass die gesamte Spezifikation abgedeckt wird. Typischerweise, wenn eine Mutation basierte fuzzer Ansprüche Spezifikation Unterstützung, bedeutet dies, ist es kompatibel mit Testzielen Implementierung der Spezifikation.

Vor allem in Bezug auf Protokoll Fusseln, der dritt kritischste Metrik ist das Niveau der Statusbehaftung des Ansatzes ausgewählt Fuzzing. Eine völlig zufällige fuzzer testen typischerweise nur die ersten Nachrichten in komplexen Stateful-Protokollen. Je mehr staatlich bewusst die Fuzzing Ansatz Sie verwenden ist, desto tiefer ist die fuzzer in komplexe Protokolle Austausch gehen. Die Statusbehaftung ist eine schwierige Voraussetzung für Fuzzing-Tools zu definieren, wie es eine Metrik für die Festlegung der Qualität des verwendeten Protokollmodell ist, und kann somit nur indem die Tests überprüft werden.

Ich hoffe, das war hilfreich. Wir haben auch Studien in anderen Metriken wie bei Code-Abdeckung und andere mehr oder weniger nutzlos Daten suchen. ;) Metrics ist ein großes Thema für eine Diplomarbeit. Bitte schicken Sie mich bei ari.takanen@codenomicon.com Wenn Sie interessiert sind zu diesem Thema Zugang zu unseren umfangreichen Recherchen zu bekommen.

Robustheits ist sehr subjektiv, aber man konnte einen Blick auf FingBugs , Cobertura und Hudson die, wenn sie richtig kombiniert zusammen könnten Sie geben ein Gefühl der Sicherheit im Laufe der Zeit, dass die Software stabil ist.

  

Sie könnten in mittlere Zeit aussehen zwischen   Ausfälle als Robustheit messen.

Das Problem mit „MTBF“ ist, dass es in der Regel in positivem Verkehr gemessen wird, während häufig Ausfälle in unerwarteten Situationen passieren. Es gibt keinerlei Hinweis auf Robustheit und Zuverlässigkeit. Unabhängig davon, ob eine Website bleibt immer in Laborumgebung, wird es noch in einem zweiten im Internet gehackt wird, wenn es eine Schwäche hat.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top