In Funktionstests soll ich vergleiche alle tabellarischen Daten im Browser gerendert mit dem aus der DB kommt?

Question

Ich arbeite an einem Testplan für eine Website, wo einige Tests des folgenden Pfad nehmen:

1. Drücken Sie die angeforderten URI und die Daten innerhalb einiger Tabelle wiedergegeben erhalten (20 Zeilen pro Seite).
2. Erstellen Sie eine Datenbank-Abfrage die Daten zu erhalten, die angeblich in der Tabelle wiedergegeben werden.
3. Vergleichen Sie die 2-Daten Zeile für Zeile, sollten sie übereinstimmen.

Ist das eine richtige Art und Weise der Funktionsprüfung zu tun? Wenn dieser Antrag eine Ajax-Anforderung ist, was auch die Antwort sein? Lautet die Antwort unterscheiden sich für den Integrationstest?

Ich habe einen Grund, die ich glaube, dass dies irgendwie falsch ist .... noch Ihre Meinung Jungs brauchen!

Answer 1

Ja, könnte dies ein produktiver Test. Entweder Sie haben einen festen Datensatz oder nicht.

Wenn Sie eine feste Datenmenge haben, ist dies viel einfacher zu testen, weil alles, was Sie tun Vergleich gegen einen festen ausgegeben wird.

Wenn Sie nicht über einen festen Datensatz haben, dann müssen Sie die Business-Logik duplizieren, effektiv durch die Entwickler die bereits geleistete Arbeit zu duplizieren. Dann haben Sie zwei Sätze von Logik zu halten.

Der zweite ist der beste Ansatz, weil man zwei Möglichkeiten bekommen, die gleiche Sache zu tun, effektiv einen Peer-Review der Spezifikation und Code. Es ist auch sehr teuer in Bezug auf Zeit und Ressourcen, weshalb die meisten Menschen wählen einen festen Datensatz haben.

Um Ihre Frage zu beantworten, wenn Ihre Geschäftslogik in der Abfrage einfach ist, dann können Sie einen Test sehr leicht. Jedoch, dass der Wert der Test bringt, ist nicht groß, weil Sie nicht sehr viel getestet wird.

Wenn die Business-Logik komplex ist, werden Sie mehr Wert aus dem Test bekommen, aber es wird schwieriger sein, auf lange Sicht zu erhalten.

Für mich, was Ihr Test bringt eine einfache Integration Test, der beweist, dass das System korrekt aus der Datenbank liest und zeigt die Daten korrekt. Dies ist ein guter Test, noch besser, wenn es automatisiert ist.

Answer 2

Das scheint gut für die Funktionsprüfung. Integrationstests in meinem Kopf haben mit der Prüfung verschiedener Technologien oder Komponenten zu tun, die zusammen arbeiten sollen, die in der Regel breiter als Funktionsprüfung ist. Aber natürlich ist diese Art der Prüfung auch als Integrationstests werden könnte, je nachdem, wie Ihre Anwendung gebracht wird zusammen und in dem die Tests in dem Lebenszyklus Ihrer Entwicklung geschah. Zum Beispiel kann es, dass für diese Website sein, um Sie zusammen ein paar Komponenten setzen müssen, um zu arbeiten, die unabhängig voneinander entwickelt wurden; Dies könnte einer der Tests zu bestätigen, dass die Integration funktioniert.

Do nicht sehen, wie das ist, Ajax oder nichts hat mit der Herstellung der Antwort anders zu tun.

Answer 3

Ich werde wahrscheinlich eine abweichende Meinung hier sein, aber ich halte dies nicht für einen produktiven Test. Was Sie tun, Duplizieren wird einfach den Code, der die Seite erzeugt. Und jedes Mal, wenn duplizierten Code einführen (auch abteilungsübergreifend) Sie suchen werden, werden bei Defekten auftauchende langfristig.

Es ist viel besser, die DB mit bekannten Daten zu laden (entweder über die App oder direkt), und dann prüfen, ob die Ausgabe übereinstimmt, was man erwarten würde. Damit ist auch sichergestellt, dass Ihre DB-Schicht oder DB selbst hat die Daten in einer Weise verändert man nicht erwarten.

Das heißt:

1. Last bekannten Daten (vorzugsweise durch die Anwendung selbst)
2. Laden Sie die angeforderten URI
3. Überprüfen Sie, ob Daten entspricht Ihrer bekannten Daten angezeigt

Answer 4

Diese Art von Test könnte gut sein für mit relativ wenig Aufwand Tester eine große Menge von Daten zu testen, ob es nicht viel Entwickler Logik zwischen der Datenbank und dem Display an den Endverbraucher ist. Unser Team hat auf einer Reihe von Gelegenheiten dies getan, und es ist besonders nützlich für den Betrieb große Mengen von realen Produktionsdaten durch unsere Tests sicher sein, dass die tatsächlichen Szenarien behandelt werden wie erwartet. Do sicherzustellen, dass Sie zumindest eine wenig feste Eingangsprüfung für seltene Szenarien, die besonders wahrscheinlich anders in der DB und auf der Webseite behandelt werden könnten - Nullwerte, Sonderzeichen und anderen Merkwürdigkeiten.

Persönlich würde ich nenne den „Integrationstest“, da man die Integration der DB testen und auf der Website, und nicht die „Funktionsprüfung“. Für „Funktionsprüfung“, würde ich wahrscheinlich ein Modell von der Datenquelle machen will (zum Beispiel der Datenbank), die bereits geschriebenen Sätze von Daten in dem Format zur Verfügung stellen werden Sie erwarten.

Having said that, wenn ich ein hohes Vertrauen in der Gültigkeit der DB-Daten habe und wenn die Logik zwischen der DB-Abfrage und der Webseite Anzeige ist sehr klein und mit geringem Risiko, würde ich wahrscheinlich mit dem Modell nicht stören und würde lassen Sie den Integrationstest als auch die Funktionalität abzudecken. Ich weiß nicht, dass die Funktionalität und Integrationstests separat eine große Qualität gewinnt in diesem Fall wäre, und es gibt wahrscheinlich bessere Dinge, die Sie mit der zur Verfügung stehenden Testzeit tun können. Wenn es eine Menge von Logik, um dieses Daten vorhanden sind, sollten Sie vielleicht die Integration testen getrennt von der Funktionalität. Weitere Integrationstests würden wahrscheinlich gehören Dinge wie: „Was ist, wenn die Datenbank nicht erreicht werden kann?“ und „Was passiert, wenn die Datenbank langsam?“.

Während diese Technik mit Ajax arbeiten, stellen Sie sicher, Ihre Test-Tools mit Ajax arbeiten. Insbesondere darüber nachdenken, wie Sie die Datenbankabfrageergebnisse werden erfasst und wie Sie die Ergebnisse auf der Webseite angezeigt sammeln.

Ich gehe davon aus, dass die Gültigkeit der Daten in der Abfrage getestet wird an anderer Stelle, da Sie erwähnte, dass dies nur eine Art von Test im Testplan. Ich bin auch nur Integration diskutieren mit die Datenbank und Dieser Bericht und nicht andere Funktionen oder Komponenten, und nicht andere Aspekte der Prüfung (Leistung, Sicherheit. Etc.), da das war der Umfang Ihrer Frage.