Antwort
Je näher Sie einer fehlerfreien Anwendung kommen, desto besser teurer wird es. Es ist so, als würde man eine 100% ige Codeabdeckung anstreben: Sie verbringen die gleiche Zeit und das gleiche Geld damit, von 0% bis 95%, von 95% bis 99% und von 99% bis 99,9% zu gelangen.
Benötigen Sie diese zusätzlichen 0,1% der Codeabdeckung oder -qualität? Wahrscheinlich ja, wenn Sie an einem Softwareprodukt arbeiten, das das Kühlsystem eines Kernreaktors steuert. Wahrscheinlich nicht, wenn Sie an einer Geschäftsanwendung arbeiten.
Für die Erstellung hochwertiger Software ist außerdem erforderlich Ein ganz anderer Ansatz . Sie können nicht einfach ein Entwicklerteam, das sein Leben damit verbracht hat, Geschäftsanwendungen zu schreiben, bitten, eine nahezu fehlerfreie Anwendung zu erstellen. Hochwertige Software erfordert verschiedene Techniken, z. B. formaler Beweis , etwas, das Sie aufgrund der extrem hohen Kosten, die es darstellt, sicherlich nicht in einer Business-App verwenden möchten.
Wie ich in erklärt habe Meine Artikel :
-
Geschäftsanwendungen sollten nicht auf die Qualität abzielen, die für lebenswichtige Software erforderlich ist, denn wenn diese Geschäftsanwendungen von Zeit zu Zeit fehlschlagen, ist dies einfach nicht der Fall. Ich habe Fehler und Ausfallzeiten auf Websites wahrscheinlich aller großen Unternehmen gesehen, wobei Amazon die einzige Ausnahme darstellt. Diese Ausfallzeit und diese Fehler sind ärgerlich und kosten das Unternehmen möglicherweise ein paar Tausend Dollar pro Monat, aber die Behebung wäre viel teurer.
-
Die Kosten sollten im Vordergrund stehen. und sollte pragmatisch studiert werden. Stellen wir uns einen Fehler vor, der 5 000 Kunden betrifft und so wichtig ist, dass diese Kunden für immer gehen. Ist das wichtig? Ja? Denken Sie mehr darüber nach. Was ist, wenn ich sage, dass jeder dieser Kunden 10 USD pro Jahr zahlt und dass dies der Fall ist Die Fehlerbehebung kostet jetzt fast 100.000 US-Dollar. Die Fehlerbehebung sieht jetzt viel weniger interessant aus.
Beantworten Sie nun Ihre Fragen speziell:
Warum werden Fehler auch nach so vielen Tests gemeldet? Handelt es sich um unser Anforderungsproblem? Unser Kunde scheint mit nichts, was wir anbieten, zufrieden zu sein? Machen wir etwas falsch?
Viele Dinge können schief gehen. Meinen Sie mit Testen tatsächlich automatisiertes Testen? Wenn nicht, ist dies ein großes Problem für sich. Verstehen Tester die Anforderungen? Kommunizieren Sie regelmäßig mit dem Kunden – mindestens einmal pro Iteration, bestenfalls Der Kundenvertreter ist für jedes Mitglied Ihres Teams sofort vor Ort erreichbar. ? Sind Ihre Iterationen kurz genug? Testen Entwickler ihren eigenen Code?
Ähnlich wie schreiben sie den richtigen Artikel , nehmen Sie einen Fehlerbericht und studieren Sie warum dieser Fehler überhaupt aufgetreten ist und warum er von jedem Tester übersehen wurde . Dies kann Ihnen einige Ideen zu den Lücken im Prozess Ihres Teams geben.
In einem wichtigen Punkt, den Sie berücksichtigen sollten: Zahlt Ihr Kunde für Fehlerkorrekturen? Wenn nicht, wird er möglicherweise aufgefordert, viele Dinge zu berücksichtigen Wenn Sie ihn für die Zeit bezahlen lassen, die Sie für Fehler aufwenden, wird die Anzahl der Fehlerberichte erheblich reduziert.
Hat jemand eine Anwendung entwickelt, die dies war? Was ist der Prozess? Warum können wir die Anwendung nicht mit kleineren Fehlern bereitstellen? Sollen wir Perfektionist sein?
Ich. Ich habe am letzten Wochenende eine App für mich geschrieben und bisher noch keinen Fehler gefunden.
Fehler sind nur Fehler, wenn sie gemeldet werden. Theoretisch ist eine fehlerfreie Anwendung durchaus möglich: Wenn sie von niemandem verwendet wird, kann niemand Fehler melden.
Schreiben Sie nun eine groß angelegte Anwendung, die perfekt zu der passt Spezifikation und hat sich als richtig erwiesen (siehe oben genannten formalen Beweis) ist eine andere Geschichte. Wenn dies ein lebenskritisches Projekt ist, sollte dies Ihr Ziel sein (was nicht bedeutet, dass Ihre Bewerbung wird fehlerfrei sein.
Ist das aktuelle Szenario der richtige Entwicklungs- und Testprozess? Wenn nicht, wie können Entwickler, Tester und Kunden gemeinsam den größtmöglichen Nutzen erzielen?
-
Um sich gegenseitig zu verstehen sollten sie kommunizieren. Dies ist in den meisten Unternehmen, die ich gesehen habe, nicht der Fall. In den meisten Unternehmen ist der Projektmanager der einzige, der mit dem Kunden (manchmal mit einem Vertreter) spricht.Anschließend teilt er (manchmal teilweise) sein Verständnis der Anforderungen mit Entwicklern, Interaktionsdesignern, Architekten, Datenbankadministratoren und Testern.
Aus diesem Grund ist es entweder für den Kunden (oder den Vertreter des Kunden) wichtig, dies zu tun für jeden im Team erreichbar sein (agiler Ansatz) oder über formelle Kommunikationsmittel verfügen, die eine Person dazu berechtigen, nur mit wenigen anderen Personen in einem Team zu kommunizieren und dies so zu tun, dass die Informationen an das gesamte Team weitergegeben werden können; Sicherstellen, dass alle über die gleichen Informationen verfügen.
-
Es gibt viele Prozesse, die entwickelt und getestet werden müssen. Ohne das Unternehmen und das Team genau zu kennen, gibt es keine Möglichkeit zu bestimmen, welche Informationen erforderlich sind In Ihrem Fall sollten Sie einen Berater oder einen Projektmanager einstellen, der geschickt genug ist.
Kommentare
- +1. Bevor Sie ein Projekt starten, müssen Sie wissen, was " für die Veröffentlichung gut genug ist " und entsprechend erstellen.
- @JuliaHayward ' kann nicht mehr zustimmen. Das Endspiel hier ist nicht ' t null Fehler – es produziert funktionale Software, die zeitnah Mehrwert schafft.
Antwort
Nicht alle Fehler sind gleich, daher müssen Sie die Spreu vom Weizen trennen.
Erwartungen
Viele Fehler treten einfach auf, weil die Software nicht funktioniert und was der Endbenutzer erwartet. Diese Erwartung kommt aus vielen Bereichen: Verwendung anderer Software, falsche Dokumentation, übereifriges Verkaufspersonal, Funktionsweise der Software usw. usw.
Scope Creep
Es versteht sich von selbst, dass das Potenzial für Fehler umso größer ist, je mehr Sie liefern. Viele Fehler werden einfach aufgrund neuer Funktionen ausgelöst. Sie liefern X & Y, aber der Kunde sagt, dass auf der Rückseite jetzt auch Z ausgeführt werden sollte.
Verstehen Sie die Problemdomäne
Viele Fehler treten aus dem einfachen Grund auf, dass die Problemdomäne schlecht verstanden wurde. Jeder Kunde hat seine eigenen Geschäftsregeln, Fachsprache und Vorgehensweisen. Vieles davon wird nirgendwo dokumentiert – es wird nur in den Köpfen der Menschen sein. Mit dem besten Willen der Welt können Sie nicht hoffen, all dies in einem Durchgang festzuhalten.
Also … was tun?
Automatisierte Komponententests
Viele Fehler werden als unerwarteter Nebeneffekt einer Codeänderung oder einer anderen eingeführt Wenn Sie automatisierte Komponententests durchführen, können Sie viele dieser Probleme vermeiden und von Anfang an besseren Code erstellen.
Tests sind nur so gut wie die bereitgestellten Daten. Stellen Sie daher sicher, dass Sie die Problemdomäne vollständig verstehen.
Codeabdeckung
Dies geht Hand in Hand mit automatisierten Komponententests Stellen Sie sicher, dass so viel Code wie möglich getestet wird.
Lernen Sie die Lektionen
Madness macht immer wieder dasselbe und erwartet unterschiedliche Ergebnisse.
Verstehst du die Ursachen des letzten Fehlers? Hast du? Wirklich? Du hast vielleicht aufgehört das Problem aufgetreten, aber was war die wahre Wurzelquelle? Schlechte Daten? Benutzerfehler? Festplattenbeschädigung? Netzwerkausfall?
Nichts stört Clients mehr, als immer wieder auf dieselben Probleme zu stoßen, ohne Fortschritte bei der Lösung zu erzielen.
Antwort
Seit Beginn der Softwareentwicklung sind Fehler aufgetreten. Anhand Ihrer Frage ist schwer zu erkennen, inwieweit und in welcher Schwere die Fehler die Benutzerfreundlichkeit oder Funktionalität beeinträchtigen.
Es gibt fehlerfreie Programme, aber fast jedes nicht triviale System weist Fehler auf.
Sie müssen sich für eine Priorisierung entscheiden und wahrscheinlich die Ursache der Fehler untersuchen – wo sie eingeführt wurden. Es gibt viel zu viel, um über solche Dinge in einem einfachen Q & Ein Beitrag.
Es wurden ganze Bücher über die Ursachenanalyse und den Behebungsprozess für eine Organisation mit Qualitätsproblemen geschrieben.
Also meine Empfehlung ist: (in keiner bestimmten Reihenfolge)
- Implementieren Sie ein Fehlerverfolgungssystem, falls Sie noch keines gefunden haben
- Bestimmen Sie eine Möglichkeit, die Schwere von Fehlern zu klassifizieren
- Finden Sie heraus, warum Sie die Kundenerwartungen nicht erfüllen (sind es die Entwickler, die Qualitätssicherung, der Kunde usw.)
- Erfahren Sie mehr über einige Übungen wie die „Fünf Gründe“ und führen Sie ähnliche Untersuchungen durch Auf einige der Ursachen Ihrer Mängel eingehen.
Antwort
Hängt davon ab, wie Sie eine Anwendung aufrufen.
Wenn Sie ein interaktives Programm meinen, bei dem Sie sicher sein müssen, dass das Echtzeitverhalten unter bestimmten Umständen genau so und so ist, ist es grundsätzlich unmöglich, zu beweisen, dass es keine Fehler gibt drin. Ich nehme an, es wäre möglich, wenn Sie das -Stoppproblem lösen könnten, aber Sie können es nicht.
Wenn Sie sich jedoch darauf beschränken Eine Aussage über „solche und solche Eingaben wird letztendlich zu solchen und solchen Endzuständen führen“, dann sind Ihre Chancen auf einen „fehlerfreien Beweis“ besser, da Sie Invarianten . Dies und nur das ermöglicht es, einen Korrektheitsnachweis in Teilprobleme aufzuteilen, von denen jedes relativ einfach nachgewiesen werden kann, dass es unter allen Umständen korrekt funktioniert des verbleibenden Programms (obwohl Sie im Allgemeinen nicht genau sagen können, wie viel Zeit & Speicher benötigt wird).
Solche Techniken sind grundsätzlich in jedem möglich Programmiersprache (obwohl einige esoterische wie Malbolge versuchen, das zu widerlegen!), aber in allen zwingenden Sprachen wird es sehr schnell chaotisch, weil man akribisch viel im Auge behalten muss impliziter Programmstatus. In funktionalen Sprachen 1 sehen die Beweise in der Regel viel besser aus ( reine Sprachen oder die rein funktionale Teilmenge einer Sprache). Insbesondere bei dynamischen Typen müssen Sie jedoch viele Anforderungen darüber aufschreiben, welche Eingaben zulässig sind. Das ist natürlich einer der Hauptvorteile starker statischer Systeme: Die Anforderungen sind genau dort im Code!
Idealerweise. In der Praxis enthalten O „Caml- oder sogar Haskell-Programme in der Regel Nicht-Gesamtfunktionen , dh Funktionen, die für bestimmte Eingaben trotz des korrekten Typs 2 abstürzen / hängen / werfen. Denn obwohl diese Sprachen sehr flexible Typsysteme haben, ist es manchmal immer noch nicht möglich, sie zu verwenden, um etwas vollständig einzuschränken.
Geben Sie abhängig typisierte Sprachen ein ! Diese können Typen genau nach Bedarf „berechnen“, sodass alles, was Sie definieren, genau die Typensignatur haben kann, die alles beweist, was Sie benötigen. Tatsächlich werden Sprachen mit abhängiger Eingabe meistens als Proof-Umgebungen . Leider denke ich, dass keiner von ihnen wirklich in der Lage ist, Produktionssoftware zu schreiben. Für praktische Anwendungen denke ich, dass das Schreiben in Haskell mit so umfassenden Gesamtfunktionen wie möglich am vollständigsten ist, um vollständig fehlerfrei zu sein möglich. Damit sind Sie ziemlich nahe an fehlerfrei –, allerdings nur in Bezug auf die Funktionsbeschreibung. Haskell Die einzigartige Art, mit E / A mit Monaden umzugehen, liefert auch einige sehr nützliche Beweise, sagt aber im Allgemeinen nichts darüber aus, wie lange etwas dauern wird Fertig. Möglicherweise kann unter bestimmten Umständen – vom POV des Benutzers eine exponentielle Zeit in Anspruch genommen werden. Dies wäre wahrscheinlich ein so schwerwiegender Fehler, als ob das Programm vollständig hängen würde.
1 Oder allgemeiner beschreibende Sprachen. Ich habe nicht viel Erfahrung mit logischen Sprachen, aber ich nehme an, dass sie im Beweis ähnlich gut sein können Grüße.
2 Wenn es nicht der richtige Typ ist, wird der Compiler es nie in diesen Sprachen zulassen; Dadurch werden bereits viele Fehler beseitigt. (Und dank der Inferenz vom Typ Hindley-Milner werden die Programme auch präziser!)
Kommentare
- " Wenn Sie ein interaktives Programm meinen, bei dem Sie sicher sein müssen, dass das Echtzeitverhalten unter bestimmten Umständen genau so und so ist, dann ist es das auch ' Es ist grundsätzlich unmöglich zu beweisen, dass ' keine Fehler vorliegen drin. Ich nehme an, es wäre möglich, wenn Sie das Halteproblem lösen könnten, aber Sie können ' t. ": Ich bin nicht sicher, ob dies der Fall ist Aussage ist richtig. Es ist unmöglich, ein beliebiges Programm zu überprüfen, aber was ist mit einem Programm, das Sie so geschrieben haben, dass eine solche Überprüfung möglich ist?
- Siehe z. cs.cmu.edu/~rwh/smlbook/book.pdf am Anfang von Seite 198: " Schließlich ist zu beachten, dass Spezifikation, Implementierung und Verifizierung Hand in Hand gehen. Es ist unrealistisch vorzuschlagen, zu überprüfen, ob ein beliebiger Code eine beliebige Spezifikation erfüllt. Grundlegende Ergebnisse zu Berechenbarkeit und Komplexität machen deutlich, dass wir in einem solchen Unterfangen niemals Erfolg haben können. Zum Glück ist es auch völlig künstlich. In der Praxis spezifizieren, codieren und verifizieren wir gleichzeitig, wobei jede Aktivität die andere informiert."
- @Giorgio: Sicher können Sie einige Programme so schreiben, dass eine solche Überprüfung möglich ist , aber das schränkt Sie wirklich ein viel. In einem großen Programm müssen Sie ' fast immer irgendwo die Vollständigkeit von Turing ausnutzen. – Ja, in der Praxis geben Sie Code an und " überprüfen " gleichzeitig, aber diese Überprüfung ist oft genug heuristisch (basierend auf z. B. Komponententests) (keine wirklichen Beweise).
- Was meinen Sie mit " Ausnutzen der Vollständigkeit von Turing "?
- " … aber diese Überprüfung ist oft genug heuristisch (basierend auf z. B. Unit-Tests, keine echten Beweise) ": Nein Wenn Sie die Notizen sorgfältig lesen, geht es um den Nachweis der Korrektheit durch formale Methoden (z. B. durch Induktion), nicht um Unit-Tests. Siehe auch compcert.inria.fr/doc .