as 2007-11-15 11:02:52 UTC
FreeBSD German Documentation Repository
Modified files:
books/developers-handbook/testing chapter.sgml
Log:
Korrekturen vom Kapitel testing
Gesendet von: Fabian Ruch
Revision Changes Path
1.7 +102 -101 de-docproj/books/developers-handbook/testing/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/developers-handbook/testing/chapter.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -I$FreeBSDde.*$ -r1.6 -r1.7
--- chapter.sgml 4 Sep 2007 13:24:23 -0000 1.6
+++ chapter.sgml 15 Nov 2007 11:02:51 -0000 1.7
@@ -20,58 +20,59 @@
<title>Regressions- und Performance-Tests</title>
- <para>Regressionstests werden benutzt, um zu testen, ob ein bestimmter
- Teil des Systems wie erwartet funktioniert und um sicherzustellen,
- dass alte Bugs nicht wieder eingebaut wurden.</para>
-
- <para>Die &os; Regressionstest-Werkzeuge finden Sie im
- &os;-Quelltextbaum im Verzeichnis <filename
- class="directory">src/tools/regression</filename>.</para>
+ <para>Regressions-Tests werden durchgeführt, um zu überprüfen,
+ ob ein bestimmter Teil des Systems wie erwartet funktioniert, und
+ um sicherzustellen, dass bereits beseitigte Fehler nicht wieder eingebaut
+ werden.</para>
+
+ <para>Die &os;-Regressions-Testwerkzeuge finden Sie im
+ &os;-Quelltextbaum unter <filename
+ class="directory">src/tools/regression</filename>.</para>
<section id="testing-micro-benchmark">
<title>Mikro-Benchmark-Checkliste</title>
- <para>Dieser Abschnitt enhält Tipps, wie man angemessenes
- Mikro-Benchmarking auf &os; oder von Teilen von &os; selbst
- machen kann.</para>
-
- <para>Es ist nicht möglich, jedes einzelne Mal alle der
- folgenden Vorschläge anzuwenden, aber je mehr davon benutzt
- werden, desto besser wird der Benchmark kleine Unterschiede
- nachweisen können.</para>
+ <para>Dieser Abschnitt enthält Tipps, wie
+ ordnungsgemäße Mikro-Benchmarks unter &os; oder für
+ &os; selbst erstellt werden.</para>
+
+ <para>Es ist nicht möglich, immer alle der folgenden
+ Vorschläge zu berücksichtigen, aber je mehr davon,
+ desto besser wird der Benchmark kleine
+ Unterschiede nachweisen können.</para>
<itemizedlist>
<listitem>
<para>Schalten Sie <acronym>APM</acronym> und alles andere,
- das den Systemtakt manipuliert, ab (<acronym>ACPI</acronym>
- ?).</para>
+ das den Systemtakt beeinflusst, ab
+ (<acronym>ACPI</acronym>?).</para>
</listitem>
<listitem>
- <para>Benutzen Sie den Single-User Modus. &man.cron.8; z.B.
- und andere Systemdienste fügen nur Störungen
- hinzu. Der &man.sshd.8; Systemdienst kann ebenfalls
- Probleme verursachen. Falls während des Tests
- ssh-Zugriff benötigt wird, schalten Sie entweder die
- Neuerstellung des SSHv1 Schlüssels ab, oder beenden Sie
+ <para>Starten Sie in den Single-User-Modus. &man.cron.8;
+ und andere Systemdienste verursachen nur Störungen.
+ Genauso der &man.sshd.8;-Systemdienst.
+ Falls während des Tests
+ SSH-Zugriff benötigt wird, schalten Sie entweder die
+ Neuerstellung des SSHv1-Schlüssels ab oder beenden Sie
den <command>sshd</command>-Elternprozess während der
Tests.</para>
</listitem>
<listitem>
- <para>Lassen Sie &man.ntpd.8; nicht laufen.</para>
+ <para>Beenden Sie &man.ntpd.8;.</para>
</listitem>
<listitem>
<para>Falls &man.syslog.3;-Ereignisse erzeugt werden,
starten Sie &man.syslogd.8; mit leerer
- <filename>/etc/syslogd.conf</filename>, ansonsten lassen Sie
- es nicht laufen.</para>
+ <filename>/etc/syslogd.conf</filename> oder beenden Sie
+ es.</para>
</listitem>
<listitem>
- <para>Sorgen Sie für möglichst wenig Disk-I/O; falls
- möglich vermeiden Sie sie ganz.</para>
+ <para>Sorgen Sie für möglichst wenig Disk-I/O;
+ vermeiden Sie es ganz wenn möglich.</para>
</listitem>
<listitem>
@@ -82,89 +83,89 @@
<listitem>
<para>Hängen Sie <filename
class="directory">/</filename>, <filename
- class="directory">/usr</filename>, und jedes andere
- Dateisystem als nur lesbar ein, wenn möglich. Dies
- verhindert, dass atime-Aktualisierungen auf Disk (usw.) das
+ class="directory">/usr</filename> und die anderen
+ Dateisysteme nur lesbar ein wenn möglich. Dies
+ verhindert, dass atime-Aktualisierungen auf der Festplatte (usw.) das
Ergebnis verfälschen.</para>
</listitem>
<listitem>
- <para>Reinitialisieren Sie das beschreibbare
- Test-Dateisystem mit &man.newfs.8; und füllen Sie es
+ <para>Initialisieren Sie das beschreibbare
+ Test-Dateisystem mit &man.newfs.8; neu und füllen Sie es
aus einer &man.tar.1;- oder &man.dump.8;-Datei vor jedem
Lauf. Hängen Sie es aus und wieder ein, bevor Sie den
Test starten. Dies sorgt für einen konsistenten
Dateisystemaufbau. Bei einem <quote>worldstone</quote>-Test
bezieht sich dies auf <filename
- class="directory">/usr/obj</filename> (Reinitialisieren Sie
- es einfach mit <command>newfs</command> und hängen Sie
- es ein). Um 100% reproduzierbare Ergebnisse zu bekommen,
+ class="directory">/usr/obj</filename> (Initialisieren Sie
+ es einfach mit <command>newfs</command> neu und hängen Sie
+ es ein). Um absolut reproduzierbare Ergebnisse zu bekommen,
füllen Sie das Dateisystem aus einer &man.dd.1;-Datei
- (also mit so etwas wie: <command>dd
+ (d.h. <command>dd
if=<filename>myimage</filename> of=<filename
class="devicefile">/dev/ad0s1h</filename>
bs=1m</command>).</para>
</listitem>
<listitem>
- <para>Benutzen Sie malloc-gestützte oder preload-ed
- &man.md.4; Partitionen.</para>
+ <para>Benutzen Sie malloc-gestützte oder vorbelastete
+ &man.md.4;-Partitionen.</para>
</listitem>
<listitem>
- <para>Machen Sie einen Neustart zwischen den einzelnen
- Iterationen des Tests, dies ergibt einen konsistenteren
+ <para>Starten Sie zwischen den einzelnen
+ Durchläufen neu, dies sichert einen konsistenteren
Zustand.</para>
</listitem>
<listitem>
- <para>Entfernen Sie alle nicht unbedingt nötigen
+ <para>Entfernen Sie alle nicht unbedingt benötigten
Gerätetreiber aus dem Kernel. Wenn z.B. USB für
- den Test nicht benötigt wird, entfernen Sie USB aus dem
- Kernel. Gerätetreiber, die sich einhängen, haben
+ den Test nicht benötigt wird, entfernen Sie es aus dem
+ Kernel. Gerätetreiber, die sich Hardware zuteilen, haben
oft <quote>tickende</quote> Timeouts.</para>
</listitem>
<listitem>
- <para>Konfigurieren Sie Hardware <quote>aus</quote>, die
- nicht benutzt wird. Entfernen Sie Disks
- mit &man.atacontrol.8; und &man.camcontrol.8;, wenn die
- Disks für den Test nicht benutzt werden.</para>
+ <para>Konfigurieren Sie nicht Hardware, die
+ nicht benutzt wird. Entfernen Sie Festplatten
+ mit &man.atacontrol.8; und &man.camcontrol.8;, wenn diese
+ für den Test nicht gebraucht werden.</para>
</listitem>
<listitem>
<para>Konfigurieren Sie nicht das Netzwerk, es sei denn es
- wird getestet, oder warten Sie bis der Test fertig ist, wenn
- Sie das Ergebnis zu einem anderen Rechner übertragen
+ wird getestet, oder warten Sie, bis der Test fertig ist, wenn
+ Sie das Ergebnis auf einen anderen Rechner übertragen
wollen.</para>
<para>Falls das System an ein öffentliches Netzwerk
- angeschlossen sein muss, achten Sie auf Spitzen von
- Broadcast-Traffic. Obwohl dieser kaum auffällt, wird
- er CPU Zyklen brauchen. Ähnliches gilt für
+ angeschlossen sein muss, achten Sie auf Spitzen im
+ Broadcast-Verkehr. Obwohl dieser kaum auffällt, wird
+ er CPU-Zyklen brauchen. Ähnliches gilt für
Multicast.</para>
</listitem>
<listitem>
- <para>Legen Sie jedes Dateisystem auf seine eigene Disk.
+ <para>Legen Sie jedes Dateisystem auf eine eigene Festplatte.
Dies minimiert Jitter durch Optimierungen von
Lesekopfbewegungen.</para>
</listitem>
<listitem>
- <para>Minimieren Sie Ausgaben auf serielle or VGA-Konsolen.
- Ausgaben in Dateien umgeleitet ergeben weniger Jitter
- (Serielle Konsolen werden leicht zum Flaschenhals).
- Benutzen Sie die Tastatur nicht während der Test
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Thu 15 Nov 2007 - 12:04:17 CET