it-swarm.com.de

Wie können wir sicher sein, dass die unteren Komponenten der Computerprogrammierung wie Compiler, Assembler, Maschinenanweisungen usw. fehlerfrei sind?

Da wir immer mehr auf Computer angewiesen sind, einschließlich sehr kritischer Aufgaben des täglichen Lebens, habe ich mich nur gefragt, wie diese wichtigen Komponenten getestet werden.

Wie werden die Compiler und Assembler technisch getestet? (Ich nehme an, das bezieht sich auf das Halteproblem !!)

57
Sudip Bhandari

Sie können nicht sicher sein, aber Sie nehmen einfach an, dass dies der Fall ist, bis Sie feststellen, dass dies nicht der Fall ist. Im Laufe der Jahre gab es viele Fehler in Compilern und Hardware.

Die Art und Weise, wie diese getestet werden, beispielsweise ein Compiler, besteht darin, dass sie sehr eng und starr definiert, sorgfältig geschrieben und dann mit einer enormen Testsuite getestet werden, um die Richtigkeit zu überprüfen. Fügen Sie dazu die breite Benutzerbasis eines Compilers hinzu, und weitere Fehler werden erkannt und gemeldet. Eine App zur Terminplanung für Zahnärzte hat vergleichsweise viel weniger Benutzer und noch weniger, die in der Lage sind, Fehler zu erkennen.

SQLite besteht aus ungefähr 73.000 Codezeilen, während die Testsuite aus ungefähr 91378.000 Codezeilen besteht, mehr als das 1250-fache von SQLite selbst. Ich erwarte, dass Compiler und andere Kernwerkzeuge ähnliche Verhältnisse haben. Prozessoren werden heutzutage im Wesentlichen mit Software entwickelt, wobei Hardwarebeschreibungssprachen wie Verilog oder VHDL verwendet werden. Auf diesen werden auch Softwaretests sowie spezielle IO Pins) zum Ausführen von Selbsttests ausgeführt der Herstellung.

Letztendlich handelt es sich um ein Wahrscheinlichkeitsspiel, und durch wiederholte und umfassende Tests können Sie die Wahrscheinlichkeit von Fehlern auf ein akzeptabel niedriges Niveau senken, genau wie bei einem anderen Softwareprojekt.

104
whatsisname

In Laienbegriffen:

  1. Du kannst nicht.
  2. Compiler und Interpreter werden wie jede andere (professionelle) Software getestet.
  3. Ein erfolgreicher Test bedeutet nicht, dass ein Programm fehlerfrei ist, sondern nur, dass keine Fehler erkannt wurden.
  4. Eine breite Benutzerbasis, die den Compiler über einen langen Zeitraum verwendet, ist ein hübscher Indikator dafür, dass er nur sehr wenige Fehler aufweist, da Benutzer normalerweise Testfälle testen, an die die Designer nicht gedacht haben.
  5. Open Source zu sein ist auch ein guter Indikator. "Bei genügend Augäpfeln sind alle Fehler flach ... Bei einer ausreichend großen Beta-Tester- und Co-Entwickler-Basis wird fast jedes Problem schnell charakterisiert und die Lösung wird für jemanden offensichtlich sein." . Ein Closed-Source-Compiler kann Fehler aufweisen, die zu bestimmten Zeiten auftreten oder einen weniger als optimalen Maschinencode generieren, und das dahinter stehende Unternehmen kann seine Existenz einfach nicht offenlegen und ihm in der Roadmap des Produkts eine sehr niedrige Priorität einräumen.

Fazit:

Ich würde sagen, gehen Sie für OOP ( [~ # ~] o [~ # ~] ld, [~ # ~] o [~ # ~] Stift und [~ # ~] p [~ # ~] opular). Ich habe gerade dieses Akronym erfunden.

46

Es sind Schildkröten den ganzen Weg nach unten.

Nichts ist sicher. Sie haben keine andere Wahl, als sich auf Vertrauensbewertungen zu einigen.

Sie können sich das als Stapel vorstellen: Mathematik> Physik> Hardware> Firmware> Betriebssystem> Assembler/Compiler/etc.

Auf jeder Ebene haben Sie Tests, die Sie durchführen können, um Ihre Vertrauensbewertungen zu verbessern. Einige dieser Tests haben die Qualität formaler Beweise, einige basieren auf Beobachtungen, die meisten sind eine Kombination aus beiden.

Der schwierige Teil besteht darin, die Rekursion in einigen dieser Tests zu enträtseln, da wir jetzt Programme verwenden, um Beweise und Beobachtungsanalysen durchzuführen, wo es zu schwierig geworden ist, dies von Hand zu tun.

Letztendlich lautet die Antwort jedoch, dass Sie alles versuchen, was Sie sich vorstellen können. Statische Analyse, Fuzzing, Simulation, Ausführen mit gezielt ausgewählten extremen Eingaben oder zufälligen Eingaben, Ausführen/Zuordnen aller Kontrollpfade, formale Beweise usw. Grundsätzlich sollte Ihr Ziel beim Testen immer darin bestehen, alles zu tun, um zu beweisen, dass Ihr Produkt (z. B. Theorie/Chip/Programm) funktioniert nicht wie vorgesehen. Wenn Sie sich wirklich anstrengen und dennoch scheitern, können Sie Ihre Vertrauensbewertung in die Richtigkeit Ihres Produkts verbessern.

Testen ist bestenfalls ein Halbentscheidungsprozess, was bedeutet, dass Sie einen Fehler finden werden, wenn er vorliegt, aber Sie können nie sicher sein, dass Sie alle gefunden haben. Selbst mit formal verifizierter Software verlassen Sie sich immer noch auf die Physik, die Werkzeuge, mit denen die formalen Beweise erstellt werden, und dass das, was Sie bewiesen haben, notwendig und ausreichend ist, damit Ihr Programm das tut, was (oft subjektiv) "beabsichtigt" ist. Ganz zu schweigen von allen anderen Komponenten, die Sie verwenden und für die keine formalen Beweise vorliegen.

24
voutasaurus

Dies ist eine "gefährliche" Frage für neue Entwickler, da sie anfangen, ihre Tools anstelle ihres Codes zu beschuldigen (dort gewesen, getan, gesehen, zu viele haben es getan). Obwohl es Fehler in Compilern, Laufzeitumgebungen, Betriebssystemen usw. gibt, sollten Entwickler realistisch sein und sich daran erinnern, dass der Fehler ist in Ihrem Code enthalten, bis es Beweise und Komponententests gibt, die etwas anderes belegen.

In mehr als 25 Jahren Programmierung in hauptsächlich C, C++ und Java habe ich gefunden:

  • zwei Fehler aufgrund eines Compiler-Fehlers (gcc und SunOS C)
  • etwa ein oder zwei Mal im Jahr ein Fehler aufgrund eines Java JVM-Problems (normalerweise im Zusammenhang mit Speicherverbrauch/Garbage Collection)
  • etwa einmal im Monat oder zweimal ein Fehler in einer Bibliothek, der häufig durch Verwendung der neuesten Version oder Zurücksetzen auf die vorherige Version der Bibliothek behoben wird

Alle anderen Fehler stehen in direktem Zusammenhang mit einem Fehler oder häufiger mit einem Unverständnis darüber, wie eine Bibliothek funktioniert. Manchmal scheint ein Fehler auf eine Inkompatibilität zurückzuführen zu sein, beispielsweise darauf, wie sich die Klassenstruktur Java) geändert hat, wodurch einige AOP-Bibliotheken beschädigt wurden.

17
Ed Griebel

Ich denke, ein interessanter Punkt hier ist, dass die überwiegende Mehrheit der Lizenzen für kommerzielle Software (und in der Tat Open Source-Software) ausdrücklich angibt, dass Sie der Software nicht vertrauen können.

DIE SOFTWARE IS BIETET "WIE BESEHEN", OHNE JEGLICHE AUSDRÜCKLICHE GEWÄHRLEISTUNG, AUSSCHLIESSLICH OR, EINSCHLIESSLICH DER GEWÄHRLEISTUNG FÜR MARKTGÄNGIGKEIT, EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG.

Aus der Microsoft Word-Lizenzvereinbarung

. Mit Ausnahme der eingeschränkten Garantie und im gesetzlich zulässigen Höchstmaß bieten Microsoft und seine Lieferanten die Software und Support-Services (falls vorhanden) AS IS UND MIT ALLEN FEHLERN an und lehnen hiermit alle anderen Garantien und Bedingungen ab, unabhängig davon, ob ausdrückliche, stillschweigende oder gesetzliche, einschließlich, aber nicht beschränkt auf (falls vorhanden) stillschweigende Garantien, Pflichten oder Bedingungen der Marktgängigkeit, der Eignung für einen bestimmten Zweck, der Zuverlässigkeit oder Verfügbarkeit, der Richtigkeit oder Vollständigkeit der Antworten, der Ergebnisse, von fachmännische Bemühungen, mangelnde Viren und mangelnde Fahrlässigkeit in Bezug auf die Software sowie die Bereitstellung oder Nichtbereitstellung von Support oder anderen Diensten, Informationen, Software und verwandten Inhalten durch die Software oder auf andere Weise aus der Software Nutzung der Software.

Im Wesentlichen sagt Ihnen dieser Satz in der Lizenz in fast jeder Software, die Sie speziell verwenden, dass Sie der Software nicht vertrauen können, geschweige denn dem verwendeten Compiler.

Software ist wie eine wissenschaftliche Theorie. Es wird davon ausgegangen, dass sie wie angegeben funktioniert, bis sie nicht mehr funktioniert.

8
Toby Allen

Als Compiler-Autor für eine mathematische Sprache * kann ich meiner Erfahrung nach theoretisch sagen, dass dies nicht möglich ist. Und einige der Fehler führen nur zu falschen Ergebnissen, z. B. (aus meiner Schamliste) zur Berechnung von 6/3*2 Aus der richtigen 6/(3*2) und zur Ausgabe von 1, ohne dass es zu Abstürzen oder unsinnigen Kompilierungsfehlern kommt.

Aber meiner Meinung nach haben viele Compiler nicht so viele Fehler wie andere Software, weil:

  • Das Schreiben von Unit-Tests ist einfach. Jede Anweisung ist eine Einheit und Sie können Tests so einfach schreiben wie: test_unit("2+(-2)*(-2+1)*3+1",9);
  • Ein Programm ist eine Kombination von Anweisungen, und damit jedes Programm das richtige Ergebnis ausgibt, muss jede einzelne Anweisung (meistens) das richtige Ergebnis liefern. Es ist daher sehr unwahrscheinlich, dass Fehler auftreten, während das Programm das richtige Ergebnis liefert.
  • Mit zunehmender Größe und Anzahl der geschriebenen Programme steigt die Wahrscheinlichkeit, Fehler zu erkennen, dramatisch an.

Für Monteure, Maschinenanweisungen usw. gilt auch das oben Gesagte; Auf der anderen Seite haben Verifikation und Validierung im Chipdesign und in der Produktion viel strengere Prozesse, da es sich um ein großes Geschäft handelt: Electronic Design Automation .

Vor dem Produktionsstart sollte jede CPU gründlich getestet werden, da jeder Fehler fast ein paar Millionen Dollar kostet: Die Chipherstellung verursacht enorme einmalige Produktionskosten. Unternehmen geben also viel Geld aus und schreiben viel Simulationscode für ihr Design, bevor sie mit der Produktion beginnen, obwohl dies keine 100% ige Garantie bietet - zum Beispiel: der Pentium FDIV-Fehler.

Kurz gesagt, es ist sehr unwahrscheinlich, dass es ernsthafte Fehler in Compilern, Maschinencodes usw. Gibt.

Meine bescheidene Mathe-Sprache *

2
Gorkem

Makellos? Sie sind nicht. Ich habe kürzlich einige "Updates" installiert, und es dauerte Monate (und mehrere neu programmierte Codeabschnitte) später, bis meine ASP.NET-Site wieder ordnungsgemäß funktionierte, da unerklärliche Änderungen an der Funktionsweise oder dem Fehlschlagen verschiedener grundlegender Dinge vorgenommen wurden.

Sie werden jedoch von vielen sehr intelligenten, detailorientierten Personen getestet und dann verwendet, die dazu neigen, die meisten Dinge zu bemerken, zu melden und zu beheben. Stack Exchange ist ein großartiges Beispiel (und eine Verbesserung dafür), wie alle Benutzer dieser Tools helfen, zu testen und zu analysieren, wie diese erstaunlich komplexen und einfachen Tools funktionieren, zumindest was die praktische Anwendung betrifft.

Aber makellos, nein. Obwohl Sie auch sehen können, wie Benutzer von Stack Exchange beeindruckende Einblicke in Leistungsdetails und die Einhaltung von Standards und Macken erhalten, gibt es immer Fehler und Unvollkommenheiten, insbesondere wenn unterschiedliche Personen unterschiedliche Meinungen darüber haben, was ein Fehler ist.

0
Dronz