☰

Wie führt das Ubuntu-Team automatisierte Tests durch?

tag-icon • tag-icon canonical quality
Wie führt das Ubuntu-Team automatisierte Tests durch?

Wie stellt das Ubuntu-Team sicher, dass keine erneuten Fehler auftreten?

Ich habe es schon mehrmals erlebt. Ein Paket ist nach der Installation unbrauchbar.

Ja, manchmal werden die Fehler sehr schnell behoben.

Ich sehe jedoch keine Bemühungen, die automatisierten Tests zu verbessern, sodass der Fehler nicht erneut auftritt.

Hier sind zwei Beispiele, die mich in den letzten zwei Wochen betroffen haben:

Es gibt noch weitere Beispiele, deren Aufzählung jedoch nicht Teil der Frage ist.

Ein Kommentar von der vsftpFehlerseite:

Bitte helfen Sie uns, indem Sie dieses neue Paket testen. Siehehttps://wiki.ubuntu.com/Testing/EnableProposedfür die Dokumentation, wie -proposed aktiviert und verwendet wird. Ihr Feedback wird uns helfen, dieses Update an andere Ubuntu-Benutzer weiterzugeben.

OK, aber "Testen" im obigen Zitat istHandbuchtesten.

Zur Sicherung der QualitätautomatisiertTests sind erforderlich.

Für mich ist manuelles Testen Zeitverschwendung. Automatisierte Tests hingegen stellen die Qualität sicher.

Hier nochmal die Frage:

Wie stellt das Ubuntu-Team sicher, dass Fehler nicht erneut auftreten?

Geschichte dieser Frage

Zuerst lautete der Titel „Wie stellt das Ubuntu-Team sicher, dass Fehler nicht wieder auftreten?“. Jetzt heißt es „Wie führt das Ubuntu-Team automatisierte Tests durch?“. Dies geschah, weil ich glaube, dass manuelle Tests keine Lösung sind. Bitte bewerten Sie keine Antworten negativ, die nur erklären, wie manuelle Tests durchgeführt werden.

Antwort1

Ubuntu verfügt über automatisierte Tests. Automatisierte Tests werden beispielsweise verwendet, um zu verhindern, dass Ihr erstes Fehlerbeispiel erneut auftritt. Ich war derjenige, der den ersten vsftpd-Fehler behoben hat, den Sie erwähnt haben, und während ich dies tat, habe ich auch einen automatisierten Test hinzugefügt, um zu verhindern, dass dasselbe erneut passiert. Sie können dies im Änderungsprotokolleintrag sehen, der zum Fehler selbst gepostet wurde:

vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium

  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
    calls (LP: #1219857).
  * Add dep8 smoke test.
 -- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000

Ich weiß nicht, warum Sie den Fehler als Beispiel für einen Mangel an automatisierten Tests betrachten, da ich dies im Fehler mehrfach erwähne. In der Zusammenfassung habe ich beispielsweise gesagt: „Dep8-Test hinzugefügt, um dies in Zukunft zu erkennen“ und „Der enthaltene Dep8-Test überprüft automatisch die Behebung dieses Fehlers“.

Denken Sie daran, dass Ubuntu eine Distribution ist: Es ist eine integrierte Aggregation vieler externer Projekte, die wir Upstreams nennen. Ubuntu wäre ohne die Arbeit anderer im breiteren Ökosystem der freien Software nicht möglich, und ebenso sind wir oft auf die Tests der Upstream-Autoren angewiesen, da sie die Experten für ihre Software sind.

Da wir eine Ansammlung verschiedener Projekte sind, ergibt eine einzige automatische Testinfrastruktur keinen Sinn. Verschiedene Bereiche haben unterschiedliche Anforderungen. Unsere Teststrategie ist daher recht breit gefächert, um diesen Anforderungen gerecht zu werden. Sie umfasst sowohl manuelle als auch automatisierte Tests über eine Reihe verschiedener Infrastrukturen.

Wenn Upstream-Projekte automatisierte Tests bereitstellen, führen wir diese als Teil der Paketerstellung aus. Die Paketerstellung schlägt fehl, wenn die Tests nicht bestanden werden. Sicherzustellen, dass alle verfügbaren automatisierten Tests auf diese Weise aktiviert werden, ist Teil unsererVoraussetzungen für die Haupteinbeziehung:Wenn das Paket eine Testsuite enthält und es keinen offensichtlichen Grund gibt, warum diese während des Builds nicht funktionieren kann (z. B. weil sie Root-Rechte oder Netzwerkzugriff benötigt), sollte sie während des Paketbuilds ausgeführt werden und eine fehlgeschlagene Testsuite sollte den Build fehlschlagen lassen.

Zusätzlich führen wir "automatische Tests im installierten Zustand" auf der Grundlage einer Spezifikation namensdep8, das zum Testen der korrekten Integration zwischen Paketen konzipiert ist. Paketaktualisierungen, die Dep8-Tests beeinträchtigen, werden erst dann in die Entwicklungsversion übernommen, wenn sie behoben wurden.

Ich bin weniger vertraut mit den automatisierten Tests, die von den Desktop- und Telefonteams durchgeführt werden, aber ich weiß, dass es weitere Mechanismen gibt, weil ich im Laufe der Jahre Hinweise darauf gesehen habe, und dazu gehören automatisierte GUI-Tests, die ich ziemlich beeindruckend finde. Ich würde mich über eine weitere Antwort freuen, die automatisierte Desktop- und Telefontests abdeckt.

Antwort2

Auf verschiedene Weise.

  1. Viele Augen.

    Ubuntu ist Open Source, das heißt, jeder kann sich den Code ansehen und herausfinden, wo das Problem liegt. Leute, die sich den Code ansehen möchten, werden oft Fehler darin oder bei der Verwendung finden, undmelde sie auf LaunchpadUnddie Öffentlichkeit kann sie sogar reparieren.

    Wenn Sie es getestet und den Fix vorgeschlagen haben, fordern Sie eine Zusammenführung mit dem Hauptpaket von Ubuntu an. Andere Entwickler überprüfen diese Änderung und fügen sie bei Genehmigung hinzu.

    Da sie von jedem behoben werden können, werden sie schnell entdeckt und überprüft, sodass sie nicht so lange im Umlauf bleiben. Dies führt uns zum nächsten Punkt.

    Zu diesen Augen zählen auch Computeraugen:

    Der vorgelagerte QA-Prozess muss dokumentiert/demonstriert und mit dem SRU-Tracking-Bug verknüpft werden. In anderen Fällen, in denen ein solcher vorgelagerter automatischer Test nicht verfügbar ist …

    Dies zeigt, dass normalerweise automatische Tests durchgeführt werden.

  2. Beta-Versionen

    Bevor Ubuntu der Öffentlichkeit zugänglich gemacht wird, gibt es Beta-Versionen. Derzeit ist die 15.10 Beta, dieveröffentlicht am 22. Oktober 2015. Viele, viele Leute werden dies verwendet, überprüft und Fehler behoben haben, bevor es veröffentlicht wurde (für5 Monate 22 Tagein diesem Fall).

    Dies bedeutet, dass sämtliche Fehler umgehend entfernt werden (aufgrund der vielen Augen) und normale Benutzer nicht betroffen sind, weil die Probleme vor der offiziellen Veröffentlichung behoben werden.

  3. Erfahrene Code-Autoren

    Leute, die gut darin sind, qualitativ hochwertigen Code zu schreiben, sind die Leute, die den Code schreiben. Es gibt nicht nur eine Person, die dasitzt und Ubuntu so schreibt:

    Es sind Leute aus aller Welt dabei, und Leute, die bei Canonical angestellt sind, dem Unternehmen hinter Ubuntu. Alle diese Leute tragen ein bisschen neuen Code bei. Wenn ich 2000 Zeilen Code schreibe, gibt es eine Menge Fehler. Wenn 200 Leute nur 10 Zeilen Code schreiben, gibt es viel weniger.

  4. Stabile Fundamente

    Soweit ich weiß, wird Ubuntu bei jeder neuen Version nicht von Grund auf neu geschrieben. Stattdessen beginnt die nächste Version mit der aktuellen Version (d. h. am 30.04.2015 waren 15.10 und 15.04 gleich) und von dort aus werden neue Funktionen hinzugefügt.

    Wenn Sie eine gute Basis haben, von der aus Sie arbeiten können, müssen Sie weniger Code schreiben und können auf das vertrauen, was bereits vorhanden ist. Wenn Sie sich auf das verlassen können, was da ist, treten weniger Fehler auf.

  5. Versionierungs- und Aufzeichnungssoftware

    Wenn derselbe Fehler mehr als einmal auftritt (in verschiedenen Versionen, oder die Fehlerbehebung hat nicht funktioniert, oder der Fehler ist aufgrund eines anderen Patches erneut aufgetreten), dann verfügen sie über die Dokumentation, in der erklärt wird, wie er behoben wurde – und sie können ihn erneut beheben.

Soweit ich weiß, gibt es keine automatisierten Tests. Aber was ist ein automatisierter Test? Wenn er kompiliert, ist das einer? Man kann nicht einfach „automatisierte Tests“ sagen, ohne zu erklären, was das ist.

Antwort3

Schreiben Sie keinen Code mit Fehlern. lol, ok. Ich habe keine Lust mehr, eine ausführliche Antwort darauf zu schreiben. Hier ist ein anständiger Artikel: https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf

und hier ist ein gutes Buch über die HerstellungFehler in C++

Die beste Lösung könnte sein, einfach einige Softwareentwicklungsaufgaben zu übernehmen und selbst herauszufinden, woher die Probleme kommen. Der Umgang mit unerwarteten Eingaben/Ergebnissen ist meiner Erfahrung nach ein ziemlich großes Problem. Dann gibt es Downstream-Fehler. Wenn beispielsweise jemand eine Schwachstelle in iostream.h findet, könnte jede Software, die diese Bibliothek aufruft, auch diesen Fehler aufweisen und muss zumindest überprüft werden.

Automatisierte Tests gibt es zwar, aber auch sie haben ihre Grenzen. Mir ist keine einzige Lösung bekannt, die in allen Sprachen funktioniert. Wenn Sie wirklich interessiert sind, schreiben Sie uns einen genetischen Code-Debugger mit etwas KI. Soweit ich weiß, steckt das alles noch in den Kinderschuhen. Hier sind einige Arbeiten von Doktoranden: https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf

verwandte Informationen