Bewährte Praktiken für Leistungstests bei der Durchführung von TDD?

Question

Ich arbeite an einem Projekt, das dringend eine Leistungsoptimierung benötigt.

Wie schreibe ich einen Test, der fehlschlägt, wenn meine Optimierungen die Geschwindigkeit des Programms nicht verbessern?

Um das etwas näher auszuführen:

Das Problem besteht nicht darin, herauszufinden, welche Teile zu optimieren sind. Hierfür kann ich verschiedene Profiling- und Benchmarking-Tools verwenden.

Das Problem ist die Verwendung von automatisiert Tests, um zu dokumentieren, dass eine bestimmte Optimierung tatsächlich die beabsichtigte Wirkung erzielt hat. Es wäre auch sehr wünschenswert, wenn ich die Testsuite nutzen könnte, um später mögliche Leistungseinbußen zu entdecken.

Ich nehme an, ich könnte einfach meine Profiling-Tools ausführen, um einige Werte zu erhalten und dann behaupten, dass mein optimierter Code bessere Werte erzeugt. Das offensichtliche Problem dabei ist jedoch, dass Benchmarking-Werte keine harten Werte sind. Sie variieren je nach der lokalen Umgebung.

Besteht die Lösung also darin, immer dieselbe Maschine für diese Art von Integrationstests zu verwenden? Wenn ja, müsste man trotzdem eine gewisse Unschärfe in den Ergebnissen einkalkulieren, denn selbst auf derselben Hardware können die Benchmarking-Ergebnisse variieren. Wie kann man dies berücksichtigen?

Oder liegt die Antwort vielleicht darin, dass man ältere Versionen des Programms behält und die Ergebnisse vorher und nachher vergleicht? Dies wäre meine bevorzugte Methode, da sie weitgehend unabhängig von der Umgebung ist. Hat jemand Erfahrung mit diesem Ansatz? Ich könnte mir vorstellen, dass es nur dann notwendig wäre, eine ältere Version zu behalten, wenn alle Tests bestanden werden können, wenn die Leistung der neuesten Version mindestens so gut ist wie die der vorherigen.

Answer 1

Ich vermute, dass die Anwendung von TDD zur Steigerung der Leistung ein Fehler ist. Verwenden Sie es auf jeden Fall, um zu einem guten Design und funktionierendem Code zu gelangen, und verwenden Sie die im Laufe von TDD geschriebenen Tests, um die fortgesetzte Korrektheit zu gewährleisten - aber sobald Sie gut fundierten Code und eine solide Testreihe haben, sind Sie in guter Verfassung, um zu tunen, und andere (von TDD) Techniken und Werkzeuge gelten.

TDD bietet Ihnen ein gutes Design, zuverlässigen Code und ein Sicherheitsnetz für die Testabdeckung. Das bringt Sie in eine gute Position für die Abstimmung, aber ich denke, dass wegen der Probleme, die Sie und andere zitiert haben, ist es einfach nicht gehen, um Sie viel weiter auf dem Weg der Abstimmung zu nehmen. Ich sage das als ein großer Fan und Befürworter von TDD und ein Praktiker.

Answer 2

Zunächst müssen Sie einige Kriterien für eine akzeptable Leistung festlegen, dann müssen Sie einen Test entwickeln, bei dem diese Kriterien bei Verwendung des vorhandenen Codes nicht erfüllt werden, und dann müssen Sie Ihren Code für die Leistung optimieren, bis er den Test besteht. Sie werden wahrscheinlich mehr als ein Kriterium für die Leistung haben, und Sie sollten sicherlich mehr als einen Test haben.

Answer 3

Erfassen Sie die Laufzeit des aktuellen Codes.

if (newCode.RunningTime >= oldCode.RunningTime) Fail

Answer 4

Die Tests + Profilerstellung im CI-Server. Sie können auch regelmäßig Lasttests durchführen.

Es geht Ihnen um Unterschiede (wie Sie erwähnten), es geht also nicht darum, einen absoluten Wert zu definieren. Führen Sie einen zusätzlichen Schritt durch, der die Leistungskennzahlen dieses Laufs mit denen des letzten Builds vergleicht, und geben Sie die Unterschiede in Prozent an. Sie können eine rote Fahne für wichtige Abweichungen in der Zeit setzen.

Wenn Sie auf Leistung bedacht sind, sollten Sie klare Ziele haben, die Sie erreichen wollen, und diese auch durchsetzen. Sie sollten diese mit Tests am gesamten System messen. Selbst wenn Ihre Anwendungslogik schnell ist, kann es sein, dass Sie aufgrund von Problemen mit der Ansicht das Ziel nicht erreichen. Sie können diese Methode auch mit der Differenzmethode kombinieren, aber in diesem Fall haben Sie weniger Toleranz gegenüber Zeitschwankungen.

Beachten Sie, dass Sie denselben Prozess auch auf Ihrem Entwicklungscomputer ausführen können, nur dass Sie nur die vorherigen Läufe auf diesem Computer verwenden und nicht einen gemeinsamen Prozess für alle Entwickler.

Answer 5

Für die Abstimmung selbst können Sie den alten und den neuen Code direkt vergleichen. Aber behalten Sie nicht beide Kopien herum. Das klingt nach einem Alptraum in der Verwaltung. Außerdem vergleichen Sie immer nur eine Version mit einer anderen Version. Es ist möglich, dass eine Änderung der Funktionalität Ihre Funktion verlangsamt, und das ist für die Benutzer akzeptabel.

Ich persönlich habe noch nie Leistungskriterien der Art "muss schneller sein als die letzte Version" gesehen, weil es so schwer zu messen ist.

Sie sagen, dass die Leistung dringend optimiert werden muss. Wo? Welche Abfragen? Welche Funktionen? Wer sagt das, das Unternehmen, die Benutzer? Was ist akzeptable Leistung? 3 Sekunden? 2 Sekunden? 50 Millisekunden?

Der Ausgangspunkt für jede Leistungsanalyse ist die Festlegung der Kriterien für das Bestehen/Nichtbestehen. Sobald Sie diese haben, können Sie die Leistungstests automatisieren.

Für die Zuverlässigkeit können Sie einen (einfachen) statistischen Ansatz verwenden. Führen Sie zum Beispiel dieselbe Abfrage 100 Mal unter denselben Bedingungen durch. Wenn 95 % von ihnen in weniger als n Sekunden zurückkehren, ist die Abfrage erfolgreich.

Ich persönlich würde dies zur Integrationszeit tun, entweder von einem Standardrechner oder vom Integrationsserver selbst. Zeichnen Sie die Werte für jeden Test irgendwo auf (der Tempomat hat einige nette Funktionen für diese Art von Dingen). Auf diese Weise können Sie sehen, wie sich die Leistung im Laufe der Zeit und mit jedem Build entwickelt. Sie können sogar ein Diagramm erstellen. Manager mögen Diagramme.

Eine stabile Umgebung ist bei Leistungstests immer schwer zu erreichen, unabhängig davon, ob Sie automatisierte Tests durchführen oder nicht. Dieses Problem stellt sich immer, egal wie Sie entwickeln (TDD, Wasserfall usw.).