it-swarm.com.de

Wie können QS-Mitarbeiter die Caching-Logik testen, die sie nicht sehen können?

Ich habe gerade eine Caching-Ebene in meiner Webanwendung implementiert und frage mich jetzt, wie die Qualitätssicherung sie testen soll, da das Caching für den Benutzer transparent ist.

Eine Idee, die ich habe, besteht darin, die Protokollierung in die Methoden einzufügen, die den Code aufrufen, der den Cache auffüllt, und aufzuzeichnen, wann ein Objekt aus dem Cache gezogen wird und wann eine Neuerstellung aus der Datenbank erforderlich ist. Anschließend können die Tester die Protokolle anzeigen, um festzustellen, ob Beispielsweise wird ein bestimmtes Objekt alle 10 Minuten anstelle jeder Seitenansicht aus der Datenbank neu geladen.

Aber kann jemand bessere Praktiken für diese Situation vorschlagen?

33
Joshua Frank

Eine Frage ist, ob der Cache selbst wirklich eine Anforderung ist, die von der Qualitätssicherung getestet werden sollte. Durch das Caching wird die Leistung verbessert, sodass der Leistungsunterschied getestet werden kann, um sicherzustellen, dass einige Anforderungen erfüllt werden.

Aber es ist eine gute Idee, einige Tests zum Thema Caching durchzuführen, wer auch immer dafür verantwortlich ist. Wir haben Leistungsindikatoren verwendet. Wenn Ihr Cache-System diese nutzt, sind sie unkompliziert. Wenn es eine Möglichkeit gibt, eine Zählung aus dem Cache selbst abzurufen, ist dies eine weitere Option.

Ihren Ansatz zu verwenden ist auch schön. Wenn eines davon in automatisierten Tests verpackt ist, die die Ergebnisse überprüfen, muss niemand die Protokolle durchsuchen, um Antworten zu finden.

37

Sie haben einen Cache implementiert (nehme ich an), weil das System nicht gut genug lief. Das ist etwas, das für den Benutzer relevant ist. Hier sind Dinge, die die Qualitätssicherung überprüfen kann:

  • Dass das System nach der Einführung des Caches immer noch korrekt ist. Dies bedeutet, dass sie versuchen sollten, den Cache dazu zu bringen, veraltete Daten bereitzustellen, was von der Qualitätssicherung überprüft werden kann, und sicherzustellen, dass nichts anderes beschädigt wurde.
  • Dass das System jetzt Leistungsschwellenwerte erfüllt, die es nicht erfüllt hat, als Sie beschlossen haben, die Leistung zu verbessern. Sie können die alten Messungen vergleichen und sie mit den neuen vergleichen.

Denken Sie daran, dass Benutzer (und damit auch die Qualitätssicherung) sich nicht darum kümmern , wie Sie ein Problem gelöst haben. Sie kümmern sich nur darum, dass das Problem wurde gelöst und keine neuen Probleme erstellt. Dies gilt unabhängig davon, ob Sie das Caching implementiert, das String-Parsing verbessert, ein Hardware-Upgrade durchgeführt oder magischen Feenstaub auf den Server gestreut haben.

74
durron597

Testleistung, wie in Andys Antwort angegeben.

Ich habe festgestellt, dass das größte Hindernis für die Implementierung von Caching (und Leistung) in vielen Organisationen darin besteht, eine Umgebung zu haben, in der Sie gute Leistungstests durchführen und Tests für verschiedene reale Last- und Leistungstests ausführen können.

Um dies zu erreichen, sollten Sie eine Leistungstestumgebung einrichten, die die Produktion so genau wie möglich und unter Berücksichtigung der Kosten widerspiegelt. Dies wird wahrscheinlich NICHT Ihre aktuelle Entwicklungsumgebung sein, die kleiner und eigenständiger sein sollte, um eine schnelle Anwendungsentwicklung zu ermöglichen. Entwicklungsumgebungen verwenden in der Regel auch weniger Caching und stellen daher die Produktion für Leistungstests nicht gut dar.

In der Umgebung für Leistungstests sollte die App im Produktionsmodus ausgeführt werden. Sie sollten mehr als einen Server haben, wenn die Produktion dies tut. Der Datenbankverbindungspool und das Caching sollten für eine Produktionsumgebung usw. festgelegt werden.

Sie sollten auch ein Tool in Betracht ziehen, das beim Testen der Last hilft.
jmeter ist sehr beliebt, obwohl ich es ziemlich unfreundlich und primitiv finde.
Eine andere Route, die ich verwendet habe, besteht darin, curl mit einem Ruby Skript) zu urlen.

Deutlich sein

  • das Testen der Basisleistung dient zum Testen der Zeit, die EINE Anfrage benötigt.
  • lasttests ähneln Leistungstests, untersuchen jedoch die Reaktion, wenn das System auch von anderen Anforderungen belastet wird.

Möglicherweise finden Sie auch die folgenden Links hilfreich:

3
Michael Durrant

Das Vergraben wichtiger Geschäftslogiken oder Systemzustände tief in einer Black Box erschwert die Überprüfung des korrekten Systemverhaltens. Es ist einfacher, das Verhalten einer einzelnen Komponente im System ausführlich zu testen als das gesamte System. Ich bevorzuge es, solche Dinge explizit durch einen Mechanismus aufzudecken, damit sie auf sinnvolle Weise auf Einheit/Regression/Integration/Qualitätssicherung getestet werden können.

Eine Option mit einem Cache besteht darin, eine spezielle Seite bereitzustellen, die einige Details zum Cache enthält (Inhalt, Status usw.). Dies kann beim Debuggen in der Entwicklung und möglicherweise in der Produktion hilfreich sein. QA kann diese Seite auch verwenden, um Testfälle für den Cache zu erstellen, wenn sie Details zum erwarteten Verhalten des Caches erhalten. Die Verwendung von Leistungsindikatoren und/oder Protokolldateien zur expliziten Dokumentation des Cache-Verhaltens ist ein weiterer weniger sichtbarer, aber praktikabler Ansatz.

Beachten Sie, dass dieser Ansatz kein Ersatz für End-to-End-Leistungstests ist. Dies ist ein Mechanismus, um sicherzustellen, dass sich der Cache selbst korrekt verhält. Leistungstests sollten verwendet werden, um festzustellen, ob das Caching den beabsichtigten Einfluss auf die Leistung hat.

Beachten Sie auch, dass das Austauschen von Systemkomponenten gegen neue, die dieselbe Schnittstelle wie das Einführen eines Caches implementieren, eine destabilisierende und täuschend komplexe Änderung sein kann. Mit dem Cache-Beispiel führen Sie einen Status in einem Zustand ein, der zuvor zustandslos war. Dies kann zu Fehlern führen, die schwerer zu finden oder zu reproduzieren sind. Eine solche Änderung sollte immer mit vollständigen Regressionstests einhergehen, um das erwartete Systemverhalten zu überprüfen.

3
Eric

Denken Sie daran, die Tester zu veranlassen, die Server neu zu starten und zu überprüfen, ob die von ihnen eingegebenen Daten noch vorhanden sind. Ich habe ein System gesehen, das viele Monate lang getestet wurde.

Am schwierigsten zu testen ist, dass unabhängig von der Aktualisierung der Daten nie veraltete Ergebnisse aus dem Cache zurückgegeben werden.

Dies kann teilweise dadurch unterstützt werden, dass immer die Daten im Cache verwendet werden, um die Bestätigungsseite zu füllen, die ein Benutzer sieht, nachdem er eine Änderung vorgenommen hat. Verwenden Sie beispielsweise nicht das Objekt, mit dem Sie die Datenbank aktualisiert haben, sondern fordern Sie die Daten aus dem Cache an, die sie dann aus der Datenbank anfordern. Etwas langsamer, aber mit größerer Wahrscheinlichkeit treten Fehler schneller auf.

2
Ian

Dieser hat tatsächlich eine sehr einfache Antwort und hängt mit dem Grad der Zwischenspeicherung zusammen. Was Sie feststellen werden, wenn das Caching korrekt ist, ist das Fehlen von Anforderungen am Ziel der Anforderungen. Es kommt also auf die abgedroschene QS-Formulierung "erwartete Ergebnisse" an.

Wenn Sie einen Cache auf der Webebene implementieren, würde ich erwarten, dass Elemente, die dem Caching unterliegen, nur einmal für jede getestete Benutzersitzung (wenn Sie den Client-Cache implementieren) oder einmal für mehrere Benutzer (wenn Sie einen Cache im CDN-Stil implementieren) angezeigt werden. Wenn Sie einen Cache auf der Datenebene implementieren, um allgemeine Ergebnisse zu erzielen, würde ich eine hohe Cache-Trefferquote in Ihrer Caching-Ebene sowie fehlende Abfragen im Profilprotokoll für die Datenebene erwarten.

usw...

1
James Pulley

Die Caching-Logik sollte vom Entwickler einem Unit-Test unterzogen werden, da die Qualitätssicherung hauptsächlich Black-Box-Tests durchführt.

Die Qualitätssicherung würde sich nur um die Leistungsaspekte oder den von Ihnen implementierten Fix kümmern. Sie können der Qualitätssicherung einen Mechanismus zum Aktivieren/Deaktivieren des Cachings oder einen Mechanismus zur Verbesserung der Leistung zur Verfügung stellen und anschließend den Leistungsunterschied überprüfen. Natürlich könnte die Qualitätssicherung auch nur eine alte Version mit Ihrer leistungsverbesserten Version vergleichen.

0
Fred Thomsen

Einige Dinge werden besser von einem Programmierer getestet, vielleicht von dem, der den Code mithilfe von Komponententests geschrieben hat. Das Testen der Richtigkeit Ihres Caching-Codes ist eines dieser Dinge. (Aufgrund der Art und Weise, wie Sie diese Frage stellen, gehe ich davon aus, dass Ihre QS-Mitarbeiter die Anwendung als "Black Box" behandeln und sie über ihre externe Schnittstelle testen.)

0
Alex D