Testfälle für die Seitennummerierung: 50+ funktionale & negative Szenarien
Entdecken Sie Testfälle für die Seitennummerierung, die Seitennavigation, Weiter- und Zurück-Buttons, Seitenzahlen, Grenzen, Sortierung, Filterung, UI, API und Performance abdecken.
Die Prüfung der Seitennummerierung zeigt, ob große Datensätze auf Seiten aufgeteilt werden, ohne dass Datensätze verloren gehen oder dupliziert werden. Diese Prüfungen decken die UI und die dahinterliegenden Backend-Schichten wie API und Datenbank ab.
Offset-basierte Seitennummerierung verwendet Seitenzahlen und Limits, sodass Datensätze während einer Sitzung wiederholt auftreten oder fehlen können, wenn sich Daten ändern.
Häufige Fehler sind duplizierte Datensätze über mehrere Seiten hinweg und falsche Seitenzahlen. Leere letzte Seiten und langsame Antworten bei hohen Seitenzahlen treten ebenfalls häufig auf, meist wegen schlechter Offset-Handhabung.
Grenztests müssen Extremwerte wie null Datensätze und Seitenzahlen über der Gesamtzahl abdecken.
Die Azure REST API-Richtlinien von Microsoft verlangen die gleiche Sortierreihenfolge auf allen Seiten einer Liste. Ohne einen sekundären Sortierschlüssel für gleiche Werte können Datensätze bei wiederholten Anfragen zwischen Seiten wechseln.
Haben Sie jemals Seite 2 einer Produktliste geöffnet und Artikel gesehen, an denen Sie gerade auf Seite 1 vorbeigescrollt sind? Das passiert, wenn die Liste nach einer Spalte mit wiederholten Werten sortiert ist, etwa Preis oder Datum. Die Datenbank hat dann keine feste Reihenfolge für gleiche Zeilen, sodass dasselbe Produkt auf zwei Seiten landen kann, während ein anderes verschwindet. Solche Fehler gelangen in die Produktion, weil die Seitennummerierung selten einen eigenen Testplan erhält. Mit strukturierten Testfällen prüft Ihr Team jede Seite gegen ein klares erwartetes Ergebnis und findet diese Probleme vor der Veröffentlichung. Im Folgenden finden Sie über 50 Testfälle für die Seitennummerierung, von der grundlegenden Navigation bis zu API-Tokens, sowie häufige Fehler und Automatisierungsbeispiele.
Was ist das Testen der Seitennummerierung?
Das Testen der Seitennummerierung ist der Prozess, bei dem überprüft wird, ob ein System große Datensätze korrekt in kleinere Seiten aufteilt und dabei die Datenintegrität bewahrt.
Die Seitennummerierung muss UI, API, Datenbankabfrage und Anwendungsstatus aufeinander abstimmen. Ihr Frontend zeigt Seitenzahlen an, und im Hintergrund berechnet Ihre API Offsets oder verwaltet Fortsetzungs-Tokens. Gleichzeitig führt Ihre Datenbank Abfragen mit Limit- und Sortierklauseln aus, und Ihr Anwendungsstatus verfolgt die aktuelle Position des Benutzers. Wenn diese Schichten die Synchronisation verlieren, werden Datensätze dupliziert oder gehen verloren, und die Seitenzahlen stimmen nicht mehr mit den Daten überein.
Die Azure REST API-Richtlinien von Microsoft verlangen, dass Dienste die gleiche Sortierreihenfolge auf allen Seiten einer Liste beibehalten. Dieselben Richtlinien warnen, dass Datensätze über Seiten hinweg übersprungen oder dupliziert werden können, wenn sich die Collection ändert, es sei denn, der Dienst erstellt einen Snapshot. Aus diesem Grund müssen Testfälle für die Seitennummerierung den gesamten Stack über mehrere Anfragen hinweg abdecken, einschließlich gefilterter und sortierter.
KI-generiertes Bild.
Arten der Seitennummerierung
Backend-Seitennummerierungsstrategien
Die Backend-Strategie bestimmt, wie der Server den nächsten Datenbatch findet, was sich direkt auf Konsistenz und Deep-Page-Performance auswirkt:
Offset-basierte Seitennummerierung. Der Client fordert eine Seitenzahl und ein Limit an, etwa ?page=3&limit=20, und die Datenbank übersetzt dies in LIMIT– und OFFSET-Klauseln. Dieses Modell ist einfach aufzubauen und lässt Benutzer direkt zu jeder Seite springen. Allerdings verschieben während einer Sitzung hinzugefügte oder gelöschte Datensätze die Offsets, was zu Duplikaten oder übersprungenen Elementen führt. Die Performance sinkt auch bei hohen Seitenzahlen, da die Datenbank alle Zeilen vor dem Offset noch liest und verwirft. Ihre Tests sollten sich daher auf Seitenzahl-Mathematik und Grenzwerte konzentrieren.
Keyset- (Seek-) Seitennummerierung. Der Client sendet die Sortierwerte des letzten empfangenen Datensatzes, und die Datenbank fährt von dort mit einer Abfrage wie WHERE (created_at, id) > (?, ?) ORDER BY created_at, id LIMIT 20 fort. Da ein Index den Startpunkt lokalisiert, laden tiefe Seiten etwa so schnell wie die erste Seite. Die Methode benötigt jedoch einen eindeutigen, deterministischen Sortierschlüssel, und Benutzer können nicht zu einer beliebigen Seitenzahl springen. Ihre Tests sollten daher das Tie-Breaking bei doppelten Sortierwerten und die Antwortzeiten auf tiefen Seiten prüfen.
Cursor-basierte Seitennummerierung. Der Server gibt ein undurchsichtiges Token zurück, und der Client sendet es zurück, um den nächsten Batch abzurufen. Je nach Implementierung kann das Token die Keyset-Werte des letzten Datensatzes oder einen Verweis auf einen serverseitigen Snapshot kodieren. Google-APIs verwenden dafür ein nextPageToken-Feld, und die GraphQL-API von GitHub nutzt einen endCursor-Wert. Cursor-Seitennummerierung kann Offset-Shift-Probleme reduzieren, wenn sie auf deterministischer Sortierung basiert, doch Einfügungen und Löschungen können dennoch unerwartete Ergebnisse liefern. Das Testen konzentriert sich daher auf Token-Validierung und den dokumentierten Konsistenzvertrag.
Die Seitennummerierung allein benötigt über 50 Testfälle, und die anderen Features Ihrer Anwendung fügen Hunderte weitere hinzu, die Ihr Team schreiben und pflegen muss. aqua cloud hält diese Test-Assets an einem Ort, sodass Ihr Team Cases in wiederverwendbare Szenarien gruppieren und nach Anforderungsänderungen Bulk-Edits anwenden kann. Mit verschachtelten Testfällen definieren Sie allgemeine Seitennummerierungsprüfungen einmal und verwenden sie funktionsübergreifend wieder. Wenn Sie die gemeinsamen Schritte aktualisieren, gilt die Änderung überall, wo sie erscheinen. Darüber hinaus generiert aqua Intelligence Testfälle für die Seitennummerierung aus Ihren Anforderungen in Sekunden. Da die KI in der eigenen Dokumentation Ihres Projekts verankert ist, folgt die Ausgabe Ihrer Terminologie und Ihrem Kontext. aqua synchronisiert sich auch bidirektional mit Jira und verbindet sich mit Confluence für Dokumentation. Ihre Jenkins- und Azure DevOps-Pipelines verbinden sich ebenfalls, und über 10 native Automatisierungsintegrationen decken JMeter, SoapUI, Ranorex, PowerShell und UnixShell ab. Testskripte können mit MSSQL- und Oracle-Datenbanken oder der REST-API von aqua arbeiten, während Capture jede Testausführung mit Video und Screenshots aufzeichnet.
Zentralisieren Sie Ihr Test Case Management und erreichen Sie 100% Testabdeckung mit aqua
Die Seitennummerierung allein benötigt über 50 Testfälle, und die anderen Features Ihrer Anwendung fügen Hunderte weitere hinzu, die das Team schreiben und pflegen muss. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Plattform, hält diese Test-Assets an einem Ort, sodass Ihr Team Cases in wiederverwendbare Szenarien gruppieren und nach Anforderungsänderungen Bulk-Edits anwenden kann. Wenn Sie die gemeinsamen Schritte aktualisieren, gilt die Änderung überall, wo sie erscheinen. Da die KI in der eigenen Dokumentation Ihres Projekts verankert ist, folgt die Ausgabe Ihrer Terminologie und Ihrem Kontext. aqua synchronisiert sich auch bidirektional mit Jira und verbindet sich mit Confluence für Dokumentation. Jenkins- und Azure DevOps-Pipelines verbinden sich ebenfalls, und über 10 native Automatisierungsintegrationen decken JMeter, SoapUI, Ranorex, PowerShell und UnixShell ab. Testskripte können mit MSSQL- und Oracle-Datenbanken oder der REST-API von aqua arbeiten, während Capture jede Testausführung mit Video und Screenshots aufzeichnet.
Zentralisieren Sie Ihr Test Case Management und erreichen Sie 100% Testabdeckung mit aqua
Das Frontend-Muster bestimmt, wie Benutzer sich durch die Daten bewegen und wo Navigations- oder Barrierefreiheitsprobleme auftreten können:
Nummerierte Seitensteuerungen. Benutzer sehen Zurück- und Weiter-Buttons zusammen mit Seitenzahlen, sodass sie direkt zu einer bestimmten Seite springen können. Dieses Muster passt gut zur Offset-Seitennummerierung, da es eine Gesamtseitenzahl benötigt. Tests konzentrieren sich dabei auf Seitenzahl-Mathematik und auf den URL-Status nach einem Reload.
Infinite Scroll. Inhalte laden automatisch, wenn sich der Benutzer dem Ende der Liste nähert. Technisch gesehen ist dies immer noch Seitennummerierung, nur ohne sichtbare Seitensteuerungen. Ihre Tests müssen den Scroll-Trigger und den Ladestatus abdecken. Bestätigen Sie auch, dass die Liste die Position des Benutzers beibehält, nachdem der Benutzer ein Element geöffnet und zurücknavigiert hat.
„Mehr laden“-Button. Benutzer klicken einen Button, um den nächsten Datenbatch an die bereits sichtbare Liste anzuhängen. Diese Hybridlösung teilt Eigenschaften mit nummerierten Seiten und Infinite Scroll. Daher testen Sie die Button-Zustände und die Konsistenz der wachsenden Liste, z. B. dass kein Datensatz nach mehreren Klicks zweimal erscheint.
Wenn UI und API unterschiedliche Ansätze verwenden, testen Sie jede Schicht gegen ihren eigenen Satz von Testfällen für die Seitennummerierung.
Schauen Sie sich Offset-Seitennummerierung an. Verwenden Sie eine separate Eigenschaft in der Antwort für die Ergebnisse und typischerweise eine Metadaten-Eigenschaft für Infos darüber, wie viele Seiten es gibt. Sie könnten auch zusätzliche Parameter für Filterung, Sortierung usw. hinzufügen.
Testfälle für die Seitennummerierung müssen funktionale Abläufe und API-Verhalten sowie die Punkte abdecken, an denen UI-Zustände und Edge Cases sich überschneiden. Wenn Sie lernen, wie man Testfälle für die Seitennummerierung schreibt, denken Sie daran, dass Testfälle für die Seitennummerierungsfunktionalität mehrere Stack-Schichten gleichzeitig ansprechen. Die unten stehenden Gruppen beginnen mit den Grundlagen und gehen dann zu API- und Performance-Prüfungen über.
Basis-Testfälle für die Seitennummerierung
Diese manuellen Testfälle für die Seitennummerierung decken die Kernbewegungen zwischen der ersten und der letzten Seite ab. Ein Fehler hier macht spätere Zustands- und API-Ergebnisse unzuverlässig, also führen Sie diese Gruppe zuerst aus:
TC-PAG-01: Erste Seite laden. Öffnen Sie einen Datensatz mit mehr Datensätzen, als eine Seite aufnehmen kann. Seite 1 sollte die konfigurierte Anzahl von Datensätzen anzeigen und als aktiv erscheinen, mit aktiviertem Weiter und deaktiviertem Zurück. Bei 95 Datensätzen und einer Seitengröße von 20 sollten Sie die Datensätze 1–20 sehen.
TC-PAG-02: Auf Weiter klicken. Von Seite 1 aus auf Weiter klicken und bestätigen, dass Seite 2 aktiv wird mit den Datensätzen 21–40. Vergleichen Sie auch Datensatz-Identifikatoren zwischen beiden Seiten, da unterschiedlich aussehende Inhalte dennoch Duplikate von Seite 1 enthalten können.
TC-PAG-03: Auf Zurück klicken. Von Seite 2 zurück zu Seite 1 gehen. Wenn sich der Datensatz nicht geändert hat und die Seitennummerierung deterministisch ist, sollten Sie genau die Datensätze sehen, die Sie anfänglich gesehen haben.
TC-PAG-04: Bestimmte Seitenzahl auswählen. Direkt zu Seite 4 springen und prüfen, dass sie den korrekten Datenabschnitt lädt. Dieser Fall deckt Offset-Berechnungsfehler auf, die sequenzielle Weiter-Klicks verbergen können.
TC-PAG-05: Letzte Seite erreichen. Bei 95 Datensätzen und einer Seitengröße von 20 hat der Datensatz fünf Seiten. Die letzte Seite sollte 15 Datensätze anzeigen, Seite 5 als aktiv markieren und die Weiter- und Letzte-Steuerungen deaktivieren.
TC-PAG-06: Gesamtanzahl der Datensätze anzeigen. Wenn Ihre Oberfläche „Zeige 1–20 von 95″ anzeigt, prüfen Sie, dass sich beide Zahlen korrekt aktualisieren, wenn Sie sich zwischen Seiten bewegen. Falsch berechnete Summen verwirren Benutzer schnell und reduzieren ihr Vertrauen in die Daten.
Testfälle für die Seitennavigation
Sobald grundlegende Klicks funktionieren, testen Sie, wie die Navigation Zustandsänderungen und reales Benutzerverhalten handhabt. Jeder Testfall für die Seitennummerierungsnavigation unten zeigt, ob Ihre Anwendung die Position des Benutzers konsistent hält:
TC-NAV-01: Erste-Seite-Button. Wenn Ihre UI eine Erste-Steuerung hat, klicken Sie von Seite 7 darauf und bestätigen, dass Sie auf Seite 1 mit den korrekten Anfangsdatensätzen landen.
TC-NAV-02: Letzte-Seite-Button. Von Seite 1 zur letzten Seite springen und prüfen, dass die Daten und Steuerungszustände der letzten Seite entsprechen.
TC-NAV-03: Schnell auf Weiter klicken. Mehrmals hintereinander schnell auf Weiter klicken. Die App sollte die Klicks entprellen oder gleichzeitige Anfragen in Reihenfolge verarbeiten, sodass sie weder ein Dutzend Anfragen in die Warteschlange stellt noch Seiten überspringt.
TC-NAV-04: Navigieren während eine Anfrage läuft. Seite 4 laden, dann auf Seite 2 klicken, bevor Seite 4 fertig ist. Die veraltete Seite-4-Antwort darf die Seite-2-Daten, die der Benutzer angefordert hat, nicht überschreiben.
TC-NAV-05: Browser-Zurück-Button. Von Seite 1 zu Seite 2 zu Seite 3 gehen, dann auf den Browser-Zurück-Button klicken. Sie sollten auf Seite 2 landen, und ein zweiter Zurück-Klick sollte Sie zu Seite 1 bringen.
TC-NAV-06: Aktuelle Seite aktualisieren. Den Browser auf Seite 5 aktualisieren. Sie sollten auf Seite 5 bleiben, es sei denn, Ihre App setzt absichtlich auf Seite 1 bei Reload zurück, und die Spezifikation sollte dieses Verhalten dokumentieren.
TC-NAV-07: Direkter URL-Zugriff. Wenn die Seitenzahl in der URL kodiert ist, etwa /products?page=7, öffnen Sie diese URL direkt. Seite 7 sollte sofort laden, ohne den Benutzer durch Seiten 1–6 zu zwingen.
TC-NAV-08: Zurück zur Liste nach Öffnen eines Datensatzes. Auf Seite 4 mit angewendetem Filter nach unten scrollen, einen Datensatz öffnen und auf Zurück klicken. Die Liste sollte Seite 4 zusammen mit dem aktiven Filter und der vorherigen Scroll-Position wiederherstellen. Dieser Fall unterscheidet sich von TC-NAV-05, da der Zustand durch einen Routenwechsel zu einer anderen Ansicht bestehen bleiben muss.
Grenz- und Edge-Case-Testfälle
Grenzwerte decken Seitenzahl- und Offset-Fehler auf, z. B. eine leere Zusatzseite, wenn die Datensatzanzahl der Seitengröße entspricht. Diese Beispiel-Testfälle für die Seitennummerierung zielen auf Datensatzanzahlen rund um die Seitengröße und ungültige Seitenzahlen:
TC-EDGE-01: Null Datensätze. Einen leeren Datensatz laden. Die Seite sollte einen ordnungsgemäßen Leer-Zustand anzeigen, und Labels wie „Seite 1 von 0″ oder aktive Seitennummerierungssteuerungen dürfen nicht erscheinen.
TC-EDGE-02: Genau ein Datensatz. Bei einem einzelnen Datensatz im Datensatz prüfen, dass Sie eine Seite mit diesem Datensatz erhalten und dass alle Navigationssteuerungen deaktiviert sind.
TC-EDGE-03: Datensätze entsprechen Seitengröße. Bei 20 Datensätzen und einer Seitengröße von 20 sollte das System genau eine Seite anzeigen und keine leere zweite Seite.
TC-EDGE-04: Datensätze eins über Seitengröße. Bei 21 Datensätzen und einer Seitengröße von 20 sollten Sie zwei Seiten erhalten, und Seite 2 sollte den einzelnen verbleibenden Datensatz enthalten.
TC-EDGE-05: Zwei volle Seiten. 40 Datensätze mit einer Seitengröße von 20 testen. Das Ergebnis sollte genau zwei volle Seiten sein, ohne zusätzliche leere dritte Seite.
TC-EDGE-06: Ein Datensatz unter zwei Seiten. Bei 39 Datensätzen sollten Sie dennoch zwei Seiten erhalten, und Seite 2 sollte 19 Elemente zeigen.
TC-EDGE-07: Seitenzahl über Gesamtseitenzahl. Seite 47 anfordern, wenn nur 10 Seiten existieren. Die Antwort sollte dem dokumentierten Vertrag entsprechen, z. B. eine leere Collection oder eine klare Fehlermeldung. Ein 500-Fehler oder Metadaten, die Seite 47 als gültig melden, zählen als Fehler.
TC-EDGE-08: Seite Null. Seite 0 anfordern. Die App sollte ihre dokumentierte Regel für ungültige Seitenzahlen anwenden und darf niemals abstürzen oder irreführende Metadaten zurückgeben.
TC-EDGE-09: Negative Seitenzahl. Seite -1 anfordern. Das erwartete Ergebnis entspricht dem Seite-Null-Fall, sodass die Antwort derselben dokumentierten Regel folgen sollte.
TC-EDGE-10: Extrem große Seitenzahl. Seite 999999999 anfordern. Ihr System sollte den Wert ablehnen oder auf ein definiertes Maximum begrenzen, sodass der Server niemals versucht, einen extrem großen Offset zu berechnen.
Testfälle für Seitengröße
Viele Oberflächen lassen Benutzer wählen, wie viele Datensätze pro Seite erscheinen. Jede Größenänderung erzwingt eine Neuberechnung von Offsets und Seitenzahlen. Ihre Testfälle für die Seitennummerierung müssen daher den Wechsel und die Seite abdecken, auf der der Benutzer landet:
TC-SIZE-01: Seitengröße vom Standard ändern. Mit 10 Datensätzen pro Seite beginnen und auf 25 wechseln. Bis zu 25 Datensätze sollten jetzt angezeigt werden, und die Gesamtseitenzahl sollte sich korrekt neu berechnen.
TC-SIZE-02: Seitengröße von einer späteren Seite ändern. Seite 8 von 100 Datensätzen bei 10 pro Seite öffnen, dann auf 50 pro Seite wechseln. Da jetzt nur zwei Seiten existieren, sollte die App Sie auf Seite 1 zurücksetzen oder Sie zu der Seite bewegen, die Ihre vorherige Ansicht enthält.
TC-SIZE-03: Minimale Seitengröße. Die kleinste erlaubte Größe wählen, oft 5 oder 10, und bestätigen, dass Datensätze und Steuerungen korrekt angezeigt werden.
TC-SIZE-04: Maximale Seitengröße. Zur maximal erlaubten Größe wechseln, etwa 100. Die Seite sollte ohne Performance-Probleme oder Layout-Brüche laden.
TC-SIZE-05: Ungültige Seitengrößen. Wenn Benutzer benutzerdefinierte Größen eingeben können, zuerst 0 oder eine negative Zahl versuchen, dann einen Wert über dem Maximum. Die App sollte diese Eingaben mit einer Validierungsmeldung ablehnen oder auf einen sinnvollen Standard zurückfallen.
TC-SIZE-06: Seitengrößenpräferenz beibehalten. Wenn die App Benutzerauswahlen speichert, die Seitengröße ändern und die Ansicht später erneut öffnen. Die Auswahl sollte gemäß der Produktspezifikation bestehen bleiben.
TC-SIZE-07: Seitengröße größer als Gesamtdatensätze. Bei 15 Datensätzen die Seitengröße auf 50 setzen. Sie sollten eine Seite mit allen 15 Datensätzen erhalten, und die Navigationssteuerungen sollten deaktiviert bleiben.
Sortier- und Filter-Testfälle für die Seitennummerierung
Sortierung und Filterung können sowohl die Datensatzreihenfolge als auch die Seitenzahl ändern, sodass Fehler oft erst nach mehreren Zustandsänderungen auftreten. Die folgenden Testfälle für die Seitennummerierungsfunktionalität decken jede Änderung einzeln und in Kombination ab:
TC-SORT-01: Aufsteigend von Seite 1 sortieren. Eine numerische Spalte aufsteigend sortieren. Seite 1 sollte die niedrigsten Werte enthalten, und die folgenden Seiten sollten diese Reihenfolge fortsetzen.
TC-SORT-02: Absteigend von Seite 1 sortieren. Zu absteigender Sortierung wechseln. Die höchsten Werte sollten jetzt zuerst erscheinen, und die Reihenfolge sollte über Seiten hinweg bestehen.
TC-SORT-03: Sortierrichtung mitten in der Seitennummerierung ändern. Aufsteigend sortieren, zu Seite 3 gehen und dann auf absteigend wechseln. Die App sollte Seite 1 der neuen Sortierung mit den höchsten Werten laden.
TC-SORT-04: Sortierung über Seiten hinweg beibehalten prüfen. Nach Preis aufsteigend sortieren und von Seite 5 zu Seite 6 wechseln. Die Preise sollten in aufsteigender Reihenfolge bleiben, ohne Zurücksetzen auf die Standardsortierung.
TC-SORT-05: Sortierung mit gleichen Werten. Vielen Datensätzen denselben Sortierwert geben, etwa 30 Produkte zum Preis von 10 €. Eine stabile sekundäre Sortierung sollte sie bei wiederholten Anfragen auf denselben Seiten halten.
TC-FILTER-01: Filter von Seite 1 anwenden. Den Datensatz filtern, z. B. nach „Status: aktiv“. Nur übereinstimmende Datensätze sollten erscheinen, und sowohl die Gesamtzahl als auch die Seitenzahl sollten sich aktualisieren.
TC-FILTER-02: Filter von Seite 5 anwenden. Während Sie auf Seite 5 ungefilteter Daten sind, einen Filter anwenden, der nur zwei Ergebnisseiten zurückgibt. Die App sollte Sie zu der gültigen Seite bewegen, die Ihre Spezifikation definiert, oft Seite 1.
TC-FILTER-03: Durch gefilterte Ergebnisse navigieren. Nach dem Filtern von Seite 1 zu Seite 3 wechseln. Der Filter sollte auf jeder Seite aktiv bleiben, ohne zu ungefilterten Daten zurückzukehren.
TC-FILTER-04: Filter entfernen. Den Filter löschen und prüfen, dass der vollständige Datensatz und die ursprüngliche Seitenzahl zurückkehren.
TC-FILTER-05: Filter und Sortierung kombinieren. Ein gefiltertes Ergebnis sortieren und durchblättern. Der Filter und die Sortierreihenfolge sollten beide auf jeder Seite angewendet bleiben.
TC-FILTER-06: Filter, der null Ergebnisse produziert. Einen Filter anwenden, der keine Datensätze entspricht. Sie sollten einen ordnungsgemäßen Leer-Zustand sehen, und die Steuerungen sollten nicht mehr „Seite 1 von 5″ zeigen.
Die Azure-Richtlinien von Microsoft erfordern eine Sortierreihenfolge über alle Seiten einer Liste hinweg, und gleiche Werte brechen diese Regel ohne Fehlermeldung. Wenn Ihre Datenbank Datensätze mit gleichen Werten in einer undefinierten Sequenz zurückgibt, können diese Datensätze zwischen Anfragen die Position ändern. Testdaten mit großen Gruppen identischer Sortierwerte decken die resultierenden Duplikate schnell auf.
Such-Testfälle für die Seitennummerierung
Suchfunktionen erstellen temporäre gefilterte Datensätze, sodass sie eigene Seitennummerierungsprüfungen benötigen. Außerdem übertragen Suchabfragen Benutzereingaben in die URL und die Backend-Abfrage, was Codierungsrisiken hinzufügt:
TC-SEARCH-01: Von Seite 1 suchen. Eine Suchabfrage ausführen, die mehrere Ergebnisseiten zurückgibt, etwa 83 Datensätze bei einer Seitengröße von 20. Die erste Seite sollte relevante Ergebnisse zeigen, und die Seitenzahl sollte fünf anzeigen.
TC-SEARCH-02: Durch Suchergebnisse blättern. Von Suchergebnisseite 1 zu Seite 2 und dann zu Seite 3 wechseln. Die Ergebnisse sollten mit der ursprünglichen Abfrage konsistent bleiben.
TC-SEARCH-03: Suche, die eine Seite zurückgibt. Eine Abfrage eingeben, die 12 Ergebnisse bei einer Seitengröße von 20 zurückgibt. Sie sollten eine einzelne Seite ohne leere zweite Seite erhalten.
TC-SEARCH-04: Suche, die null Ergebnisse zurückgibt. Nach einem String suchen, der keine Datensätze entspricht. Die Seite sollte einen ordnungsgemäßen „Keine Ergebnisse“-Zustand mit versteckten oder deaktivierten Seitennummerierungssteuerungen zeigen.
TC-SEARCH-05: Suchabfrage mitten in der Seitennummerierung ändern. Auf Seite 3 der Ergebnisse für „Laptop“ die Abfrage in „Tastatur“ ändern. Die neue Suche sollte Seite 1 ihrer eigenen Ergebnisse laden, ohne Sie auf Seite 3 zu halten.
TC-SEARCH-06: Suche mit Sortierung kombinieren. Die Ergebnisse einer „Sneakers“-Suche nach Preis sortieren und durchblättern. Die Abfrage und die Sortierreihenfolge sollten beide angewendet bleiben.
TC-SEARCH-07: Sonderzeichen in der Suche. Mit Anführungszeichen oder Ampersands in der Abfrage suchen. Die Seitennummerierung dieser Ergebnisse sollte trotz URL-Codierung und Abfrage-Parsing korrekt funktionieren.
UI-Testfälle für die Seitennummerierung
Seitennummerierungssteuerungen zeigen Benutzern, wo sie sich in einem Datensatz befinden, sodass ein Styling- oder Layout-Fehler sie direkt irreführt. KI-basierte Tools für UX/UI-Tests können Screenshots dieser Steuerungen zwischen Releases vergleichen und Layout-Änderungen in den unten stehenden Fällen markieren:
TC-UI-01: Styling der aktiven Seite. Die aktuelle Seite sollte sich visuell abheben, z. B. durch Hervorhebung oder Fettdruck. Farbe allein reicht nicht aus, da Benutzer mit Farbsehschwächen einen anderen Hinweis benötigen.
TC-UI-02: Styling deaktivierter Steuerungen. Wenn Zurück auf Seite 1 deaktiviert ist, sollte es deaktiviert aussehen und Klicks ignorieren.
TC-UI-03: Seitenzahlen-Kürzung. Bei 500 Seiten kann die UI nicht alle 500 Zahlen zeigen. Prüfen Sie, dass eine Kürzung wie „1 … 48 49 50 … 500″ korrekt funktioniert und dass sich die Auslassungspunkte logisch verhalten.
TC-UI-04: Ladezustände. Während eine neue Seite lädt, sollte die UI einen Spinner oder ein Skeleton-Screen anzeigen. Andernfalls sehen Benutzer weiterhin veraltete Daten an und können nicht erkennen, ob ihr Klick registriert wurde.
TC-UI-05: Layout-Stabilität. Klicks auf Seitennummerierungssteuerungen sollten keine abrupten Inhaltsverschiebungen oder Layout-Reflows verursachen.
TC-UI-06: Lange Seitenzahlen. Testen, wie Ihre UI „Seite 1234 von 5678″ anzeigt. Das Label sollte in seinen Container passen, ohne Überlauf oder gebrochene Ausrichtung.
Barrierefreiheits-Testfälle für die Seitennummerierung
Mit Barrierefreiheitsprüfungen bestätigen Sie, dass Tastatur- und Screenreader-Benutzer sich so zuverlässig durch Seiten bewegen können wie Maus-Benutzer. Laut dem WebAIM Million 2026-Bericht hatten 95,9 % von einer Million Startseiten erkannte WCAG-2-Fehler, und 30,6 % enthielten leere Buttons. Nur-Icon-Zurück- und Weiter-Buttons ohne barrierefreie Namen fallen in diese Kategorie leerer Buttons. Aus diesem Grund sind die unten stehenden Fälle spezifischen WCAG 2.2-Erfolgskriterien zugeordnet:
TC-A11Y-01: Tastatur-Erreichbarkeit. Durch die Seitennummerierungssteuerungen nur mit der Tab-Taste navigieren. Jede Steuerung sollte den Fokus erhalten und allein mit der Tastatur funktionieren, wie WCAG 2.2-Kriterium 2.1.1 verlangt.
TC-A11Y-02: Logische Tab-Reihenfolge. Der Fokus sollte sich von Zurück durch die Seitenzahlen zu Weiter bewegen, in derselben Reihenfolge, in der die Steuerungen auf dem Bildschirm erscheinen. Eine Diskrepanz zwischen visueller Reihenfolge und Fokusreihenfolge verletzt Kriterium 2.4.3.
TC-A11Y-03: Barrierefreie Namen. Die Steuerungen mit einem Screenreader oder dem Barrierefreiheitsbaum des Browsers prüfen. Nur-Icon-Buttons benötigen Namen wie „Nächste Seite“, und das umschließende <nav>-Element sollte ein Label wie „Seitennummerierung“ tragen.
TC-A11Y-04: Marker für aktuelle Seite. Der aktive Seitenlink sollte aria-current="page" tragen, und das Attribut sollte nach jedem Seitenwechsel zum neuen Link wechseln. Screenreader kündigen dann die aktuelle Seite an, ohne sich auf Farbe zu verlassen.
TC-A11Y-05: Deaktivierter Zustand. Auf der ersten Seite sollte Zurück als deaktiviert durch das disabled-Attribut oder aria-disabled="true" ausgewiesen sein. Eine Steuerung, die nur grau aussieht, erreicht Screenreader-Benutzer noch als aktiv.
TC-A11Y-06: Fokus nach einem Seitenwechsel. Nach einem Klick auf Seite 3 sollte der Fokus auf einem vorhersehbaren Element landen, z. B. der Ergebnisüberschrift oder der Seitennummerierungssteuerung selbst. Wenn der Fokus an den Anfang des Dokuments fällt, verlieren Tastaturbenutzer ihre Position.
TC-A11Y-07: Statusankündigungen. Für „Mehr laden“-Buttons und Infinite Scroll sollten neue Ergebnisse eine Ankündigung über eine aria-live-Region auslösen, etwa „20 weitere Produkte geladen“. Kriterium 4.1.3 deckt diese Statusmeldungen ab.
Responsive Testfälle für die Seitennummerierung
Desktop-Seitennummerierungssteuerungen brechen oft auf mobilen Bildschirmen, sodass diese Prüfungen zu Ihren regulären Regressionsdurchläufen gehören. Sie decken Viewport-Größen zusammen mit Barrierefreiheitseinstellungen ab, die Text- und Steuerungsdimensionen ändern:
TC-RESP-01: Mobiler Viewport. Seitennummerierung auf einem schmalen Handybildschirm laden. Die Steuerungen sollten ohne Überlauf oder horizontales Scrollen nutzbar bleiben.
TC-RESP-02: Horizontale Ausrichtung. Das Gerät in die horizontale Ausrichtung drehen und bestätigen, dass die Seitennummerierung noch ohne Layout-Probleme funktioniert.
TC-RESP-03: Touch-Ziele. Auf Touch-Geräten sollten Seitennummerierungs-Buttons groß genug sein, um sie genau anzutippen. Apples Human Interface Guidelines setzen das minimale Tap-Ziel auf 44×44 Punkte.
TC-RESP-04: Reduzierte Seitenzahlenanzeige. Mobile Layouts zeigen oft eine kürzere Reihe von Seitenzahlen, etwa „1 2 3 … 50″. Prüfen Sie, dass die komprimierte Version korrekt navigiert.
TC-RESP-05: Browser-Zoom. Den Browser auf 200 % oder mehr zoomen. Die Seitennummerierung sollte auf dieser Stufe funktionsfähig und lesbar bleiben.
TC-RESP-06: Große Systemschriften. Bei aktivierten großen Barrierefreiheitsschriften sollte der Seitennummerierungstext lesbar bleiben und das Layout intakt halten.
API-Testfälle für die Seitennummerierung
Mit API-Tests prüft Ihr Team den Seitennummerierungsvertrag direkt, ohne die UI dazwischen. Ein Frontend kann API-Fehler verbergen, z. B. wenn es doppelte Datensätze clientseitig entfernt. Feldnamen wie limit und total_count variieren zwischen APIs, also ordnen Sie sie Ihrer eigenen Spezifikation zu:
TC-API-01: Standard-Seitengröße. Eine Anfrage ohne limit-Parameter senden. Die Antwort sollte die dokumentierte Standardanzahl von Elementen zurückgeben und diese Größe in ihren Metadaten melden.
TC-API-02: Benutzerdefinierte Seitengröße.?limit=50 anfordern und prüfen, dass die Antwort 50 Elemente enthält, wenn genügend Datensätze existieren.
TC-API-03: Maximale Seitengröße. Ein Limit über dem dokumentierten Maximum anfordern, etwa ?limit=10000. Die API sollte den Wert begrenzen oder einen 400-Fehler zurückgeben, und die Metadaten sollten das angewendete Limit zeigen.
TC-API-04: Genauigkeit der Gesamtzahl.total_count mit der Anzahl übereinstimmender Datensätze in der Datenbank vergleichen. Bei angewendetem Filter sollte das Feld die gefilterte Summe melden.
TC-API-05: Navigations-Flags. Auf der ersten Seite sollte hasPreviousPage false sein, und auf der letzten Seite sollte hasNextPage false sein. Beide Flags sollten auf jeder Seite dazwischen true sein.
TC-API-06: Letztes Seiten-Token. Auf der letzten Seite sollte nextPageToken leer oder abwesend sein, sodass eine Client-Schleife weiß, wann sie stoppen muss.
TC-API-07: Fehlgeformter Cursor. Ein Token mit geänderten oder zufälligen Zeichen senden. Die API sollte einen 400-Fehler ohne Datensätze zurückgeben.
TC-API-08: Abgelaufener Cursor. Wenn Tokens ablaufen, eines nach seiner Lebensdauer senden. Die Antwort sollte den dokumentierten Ablauf-Fehler enthalten, und der Client sollte von der ersten Seite neu starten können.
TC-API-09: Cursor nach Filteränderung wiederverwendet. Einen Cursor für status=active generieren, ihn dann mit status=inactive senden. Viele Cursor-Systeme kodieren den Abfragestatus im Token, sodass die API die Anfrage ablehnen oder einen neuen Durchlauf starten sollte.
TC-API-10: Vollständiger Durchlauf. Den Next-Page-Tokens oder Links bis zur letzten Seite folgen und alle Datensatz-IDs sammeln. Die Anzahl zurückgegebener IDs sollte der Anzahl eindeutiger IDs entsprechen und total_count entsprechen.
TC-API-11: Serverseitige Sortierung über Seiten hinweg.?sort=price anfordern und das letzte Element von Seite 1 mit dem ersten Element von Seite 2 vergleichen. Die Reihenfolge sollte über jede Seitengrenze hinweg bestehen, einschließlich Datensätzen mit gleichen Werten.
TC-API-12: Metadaten-Konsistenz. Prüfen, dass totalPages gleich ceil(total_count / pageSize) ist. Die Elementzahl auf jeder Seite sollte auch pageSize entsprechen, wobei die letzte Seite die einzige Ausnahme ist.
Testfälle für dynamische Daten und gleichzeitige Änderungen
Produktionsdaten ändern sich, während Benutzer sich durch Seiten bewegen, sodass diese Testfälle für die Seitennummerierung Schreibvorgänge zwischen Anfragen simulieren. Das erwartete Ergebnis hängt vom Konsistenzvertrag ab, den Ihre API dokumentiert. Wenn Ihre API einen Snapshot liefert, zählt jeder duplizierte oder fehlende Datensatz als Fehler:
TC-DYN-01: Datensatz zwischen Seitenanfragen einfügen. Nach dem Laden von Seite 1 einen Datensatz einfügen, der vor der aktuellen Position sortiert, und Seite 2 anfordern. Bei Offset-Seitennummerierung verschiebt sich der letzte Datensatz von Seite 1 zu Seite 2 und erscheint zweimal, sodass das Ergebnis dem dokumentierten Verhalten entsprechen muss.
TC-DYN-02: Bereits gesehenen Datensatz löschen. Nach dem Laden von Seite 1 einen ihrer Datensätze löschen und Seite 2 anfordern. Offset-Seitennummerierung überspringt dann einen ungesehenen Datensatz, was Ihr Test durch ID-Tracking erkennen sollte.
TC-DYN-03: Datensatz vor dem Cursor löschen. Einen Datensatz löschen, der auf einer späteren Seite gehört, bevor der Client sie erreicht. Der gelöschte Datensatz sollte nicht erscheinen, und der Durchlauf sollte ohne Fehler fortfahren.
TC-DYN-04: Zuletzt gesehenen Datensatz löschen. Den letzten Datensatz der aktuellen Seite löschen, dann die nächste Seite anfordern. Ein Keyset-basierter Cursor sollte dennoch von der korrekten Position fortfahren, da er Sortierwerte vergleicht.
TC-DYN-05: Sortierschlüssel während Durchlauf aktualisieren. Während der Client auf Seite 2 einer nach Preis sortierten Liste ist, den Preis eines Datensatzes auf Seite 3 ändern. Abhängig vom neuen Wert kann der Datensatz zweimal erscheinen oder nie, sodass das Ergebnis dem dokumentierten Vertrag entsprechen muss.
TC-DYN-06: Datensätze mit identischen Sortierwerten hinzufügen. Während des Durchlaufs mehrere Datensätze mit demselben Sortierwert wie vorhandene einfügen. Ein eindeutiger Tie-Breaker, etwa die Datensatz-ID, sollte ihre Reihenfolge über Anfragen hinweg deterministisch halten.
TC-DYN-07: Vollständiger Durchlauf unter gleichzeitigen Schreibvorgängen. Einen Hintergrundprozess ausführen, der Datensätze einfügt und löscht, während der Client durch den gesamten Datensatz läuft. Danach die gesammelten IDs mit der dokumentierten Garantie vergleichen, z. B. keine Duplikate für eine Snapshot-basierte API.
Wenn noch kein Konsistenzvertrag existiert, sollte Ihr Team einen definieren, bevor Sie die erwarteten Ergebnisse schreiben.
Testfälle für Berechtigungen und Tenant-Scoping
Seitennummerierungsabfragen müssen Zugriffsregeln anwenden, bevor sie Datensätze zählen und aufteilen. Andernfalls kann die Gesamtzahl oder die Größe einer Seite offenbaren, dass eingeschränkte Datensätze existieren. Führen Sie diese Testfälle für die Seitennummerierung daher als Benutzer mit unterschiedlichen Zugriffsebenen aus:
TC-PERM-01: Eingeschränkte Zeilen auf späteren Seiten. Als Benutzer mit eingeschränktem Zugriff anmelden und durch den gesamten Datensatz blättern. Eingeschränkte Datensätze sollten niemals erscheinen, auch nicht auf der letzten Seite und auf tiefen Seiten.
TC-PERM-02: Gesamtzahl sichtbarer Datensätze.total_count für einen eingeschränkten Benutzer mit der Anzahl der Datensätze vergleichen, die dieser Benutzer öffnen kann. Wenn die Zahl versteckte Datensätze einschließt, leckt die API deren Existenz.
TC-PERM-03: Seitengröße nach Berechtigungsfilterung. Prüfen, dass jede volle Seite für einen eingeschränkten Benutzer die konfigurierte Anzahl von Datensätzen enthält. Kurze Seiten in der Mitte eines Datensatzes deuten darauf hin, dass das System eingeschränkte Zeilen entfernt, nachdem es die Seite aufgeteilt hat.
TC-PERM-04: Tenant-Isolation. In einem Mehrmandantensystem durch einen großen Datensatz als Benutzer von Tenant A blättern. Weder die Datensätze noch die Zählungen sollten Daten von Tenant B einschließen, auch nicht auf tiefen Seiten.
TC-PERM-05: Cursor an seinen Eigentümer gebunden. Einen für einen Benutzer ausgestellten Cursor mit den Anmeldedaten eines anderen Benutzers senden. Die API sollte die Anfrage ablehnen, da ein Cursor die Abfrage und den Zugriffsbereich seines ursprünglichen Eigentümers kodieren kann.
Performance- und Skalierbarkeitstestfälle
Performance-Fälle messen, wie sich die Antwortzeit mit Seitentiefe und Last ändert. Da eine feste 500-ms-Schwelle nur auf manche Systeme passt, beurteilen Sie diese Testfälle für die Seitennummerierung gegen Ihr SLA oder eine gemessene Basislinie:
TC-PERF-01: Erste Seite versus tiefe Seite. Die Antwortzeit für Seite 1 und für eine Seite nahe dem Ende eines großen Datensatzes messen. Bei Offset-Seitennummerierung antwortet die tiefe Seite oft viel langsamer, also beide Werte mit Ihrem SLA vergleichen.
TC-PERF-02: Maximale Seitengröße. Die größte erlaubte Seite anfordern und die Antwortzeit und Payload-Größe aufzeichnen. Beide Werte sollten innerhalb der dokumentierten Grenzen bleiben.
TC-PERF-03: Großer gefilterter Datensatz. Einen Filter auf Ihren größten Testdatensatz anwenden und durch die Ergebnisse blättern. Die Antwortzeiten sollten innerhalb der Basislinie bleiben, was auch zeigt, ob die Filterspalten geeignete Indizes haben.
TC-PERF-04: Großer sortierter Datensatz. Einen großen Datensatz nach einer Spalte ohne Index sortieren und eine tiefe Seite anfordern. Wenn die Antwortzeit das SLA überschreitet, benötigt die Datenbank einen Index oder eine andere Seitennummerierungsstrategie.
TC-PERF-05: Gleichzeitige Seitennummerierungsanfragen. Seitennummerierungsanfragen von vielen simulierten Benutzern gleichzeitig senden, z. B. mit JMeter. Die Latenz sollte innerhalb des SLA bleiben, und jede Antwort sollte noch die korrekten Datensätze enthalten.
KI-generiertes Bild.
Negative Testfälle für die Seitennummerierung
Negative Testfälle für die Seitennummerierung belasten das System mit ungültigen Eingaben und unerwarteten Ausfällen. Öffentliche URLs und APIs akzeptieren Parameter, die jeder von Hand bearbeiten kann, sodass der Server ungültige Werte ablehnen muss, ohne abzustürzen oder Daten preiszugeben:
TC-NEG-01: Nicht-numerischer Seitenparameter.?page=abc senden und prüfen, dass das System seinem dokumentierten Verhalten folgt, z. B. ein 400-Fehler oder die erste Seite.
TC-NEG-02: Dezimale Seitenzahl.?page=3.5 versuchen. Ihre App kann den Wert abrunden oder ablehnen, und in beiden Fällen muss sie stabil bleiben.
TC-NEG-03: Böswillige Parameterwerte. Sonderzeichen oder ein SQL-Fragment in den page– und limit-Parametern senden. Die API sollte die Eingabe mit einem 400-Fehler ablehnen, und die Datenbankabfrage sollte gebundene Parameter verwenden.
TC-NEG-04: Extrem große numerische Eingabe. Seite 2147483647, die maximale 32-Bit-Signed-Integer, oder einen größeren Wert anfordern. Ihr System sollte die Zahl begrenzen oder ablehnen, ohne Fehler oder Verlangsamungen.
TC-NEG-05: Fehlende erforderliche Parameter. Den Seiten- oder Limit-Parameter weglassen, wo die API ihn verlangt. Die Antwort sollte eine aussagekräftige Fehlermeldung enthalten.
TC-NEG-06: Netzwerkausfall mitten in der Seitennummerierung. Verbindungsverlust simulieren, während Seite 4 lädt. Die App sollte einen Fehler anzeigen oder einen Wiederholungsversuch anbieten, und Seite 4 darf nicht als geladen erscheinen.
TC-NEG-07: Timeout. Die Serverantwort über die Timeout-Grenze hinaus verzögern und prüfen, dass der Benutzer eine klare Fehlermeldung erhält.
TC-NEG-08: Serverfehler (500). Das Backend einen 500-Fehler bei einer Seitennummerierungsanfrage zurückgeben lassen. Das Frontend sollte den Fehler dem Benutzer melden und Teil- oder veraltete Daten verbergen.
TC-NEG-09: Nicht authentifizierte Anfrage. Eine Seite ohne Anmeldedaten oder mit einem ungültigen Zugriffstoken anfordern. Die API sollte 401 Unauthorized ohne Teildaten in der Antwort zurückgeben.
TC-NEG-10: Verbotene Anfrage. Eine Seite mit gültigen Anmeldedaten für einen Benutzer anfordern, dem die Berechtigung zur Ressource fehlt. Die API sollte 403 Forbidden zurückgeben, und die Antwort sollte die Gesamtzahl nicht offenbaren.
Häufige Seitennummerierungsfehler, nach denen zu suchen ist
Die unten stehenden Defekte sind diejenigen, die die obigen Testfälle für die Seitennummerierung aufdecken sollen:
Duplizierte Datensätze. Datensatz 20 erscheint sowohl auf Seite 1 als auch auf Seite 2. Die übliche Ursache ist ein Off-by-One-Fehler in Offset-Berechnungen oder instabile Sortierung von Datensätzen mit identischen Werten.
Fehlende Datensätze. Datensatz 60 erscheint nie auf einer Seite. Dieser Fehler kommt oft gepaart mit Duplikation, da ein doppelt gezählter Datensatz einen anderen aus der Sequenz drängt.
Falsche Seitenzahl. Die App behauptet sechs Seiten, während nur fünf Daten enthalten, oder sie zeigt „Seite 5 von 4″. Die Ursache ist typischerweise ein Rundungsfehler in der ceil(total_records / page_size)-Berechnung.
Leere letzte Seite. Die letzte Seite zeigt null Datensätze an, obwohl einige Datensätze verbleiben. Unsachgemäße Grenzbehandlung oder ein falscher Offset bei der letzten Anfrage verursacht dies.
Veraltete Daten nach Filter. Alte ungefilterte Daten bleiben sichtbar, nachdem der Benutzer einen Filter anwendet, da der Filter keine Datenaktualisierung ausgelöst hat.
Verlorener Zustand bei Seitengrößenänderung. Auf Seite 8 ändert der Benutzer von 10 auf 50 Datensätze pro Seite, und die App bricht oder zeigt eine leere Seite. In diesem Fall wurde die Position nie für die neue Größe neu berechnet.
Sortierung bleibt nicht bestehen. Nach einer aufsteigenden Sortierung und einem Wechsel zu Seite 3 kehren die Daten zur Standardreihenfolge zurück. Der Sortierparameter wurde nicht durch die Seitennummerierungsanfrage getragen.
Instabile Sortierung mit gleichen Werten. Datensätze, die denselben Sortierwert teilen, etwa Preis, wechseln bei wiederholten Ladevorgängen zwischen Seiten. Ein fehlender sekundärer Sortierschlüssel verursacht dies.
Race Conditions bei schnellen Klicks. Fünf schnelle Klicks auf Weiter produzieren Antworten außerhalb der Reihenfolge, sodass die UI Seite-2-Daten zeigt, während sie behauptet, Sie seien auf Seite 5.
Off-by-One-Fehler. Eine Anfrage für Seite 2 gibt Daten für Seite 1 oder Seite 3 zurück. Normalerweise sind sich Frontend und Backend über Null-basierte und Eins-basierte Indizierung uneinig.
Cursor-Token-Beschädigung. Ein modifiziertes Fortsetzungs-Token verursacht stille Fehler oder falsche Ergebnisse ohne klare Fehlermeldung.
Performance-Verschlechterung bei hohen Seiten. Die Antwortzeit wächst mit der Seitenzahl, sodass tiefe Seiten weit langsamer laden als Seite 2. Dieses Muster ist häufig bei Offset-basierter Seitennummerierung, wo die Datenbank alle Zeilen vor dem Offset noch liest und verwirft.
Kaputte Browser-Navigation. Der Zurück-Button kehrt zur falschen Seite zurück, oder ein Refresh setzt den Benutzer unerwartet auf Seite 1 zurück.
Unzugängliche Steuerungen. Tastaturbenutzer können die Seitennummerungs-Buttons nicht erreichen, oder Screenreader kündigen die aktuelle Seite nicht an.
Mobiles Layout-Überlauf. Seitennummerierungssteuerungen laufen über den Bildschirm oder erfordern horizontales Scrollen auf schmalen Viewports.
Wenn einer dieser Fehler auftritt, protokollieren Sie ihn in einem Bug-Tracking-Tool mit der Seitenzahl und der aktiven Sortierung oder dem Filter. Ihre Entwickler können dann die exakte Anfrage reproduzieren, da die meisten dieser Fehler vom Zustand früherer Seiten abhängen.
Best Practices für das Testen der Seitennummerierung
Die wertvollsten Prüfungen in umfassenden Testfällen für die Seitennummerierung konzentrieren sich auf Datensatzidentität, Grenzen, tiefe Seiten, Konsistenzgarantien und kombinierte Zustandsänderungen:
1. Datensatz-IDs über Seiten hinweg verfolgen
Die IDs von jeder geladenen Seite sammeln und prüfen, dass zurückgegebene IDs gleich eindeutigen IDs und total_count entsprechen. Eine Differenz von einem Datensatz bedeutet ein Duplikat oder ein fehlendes Element.
2. Sechs Grenzwerte pro Limit abdecken
Für eine Seitengröße von 20 Datensätze mit 0, 1, 19, 20 und 21 Datensätzen sowie dem maximal erlaubten Wert testen. Diese sechs Punkte decken Off-by-One-Fehler auf, die typische Werte wie 50 oder 95 übersehen.
3. Tiefe Seiten auf produktionsgroßen Daten testen
Die PostgreSQL-Dokumentation weist darauf hin, dass von OFFSET übersprungene Zeilen noch innerhalb des Servers berechnet werden, sodass große Offsets langsam werden. Daher die 95. Perzentil-Antwortzeit von Seite 1 und der letzten Seite gegen Ihr SLA vergleichen.
4. Den Konsistenzvertrag zuerst definieren
Die Azure REST API-Richtlinien von Microsoft sagen Diensten, zu dokumentieren, dass Datensätze über Seiten hinweg übersprungen oder dupliziert werden können. Ihr Team sollte aufzeichnen, welches Ergebnis Ihre API erlaubt, bevor sie die dynamischen Datenfälle ausführt.
5. Durchlauf automatisieren und Kombinationen manuell erkunden
Vollständigen Durchlauf automatisieren und manuelle Sitzungen für Zustandskombinationen reservieren, etwa einen Filter auf Seite 8 plus eine Seitengrößenänderung.
6. Barrierefreiheitsprüfungen in jedem Release ausführen
Seit dem 28. Juni 2025 gilt der European Accessibility Act für E-Commerce- und Bankdienstleistungen in der EU, und nationale Regulierungsbehörden können Geldstrafen verhängen. axe-core-Scans in CI mit einem kurzen manuellen Tastatur- und Screenreader-Durchgang vor jedem Release paaren.
Was die API-Endpunkte angeht, auf die man es anwenden soll, beurteilen Sie es basierend auf der Datenmenge (Zeilen, Elemente usw.), die der Endpunkt zurückgeben kann. Ich wende es generell global auf alle meine Endpunkte an, setze aber standardmäßig sinnvolle Werte, sodass eine Standardanzahl von Zeilen auf einmal zurückgegeben wird, wenn die API-Anfrage die Paging-Parameter nicht angibt.
Automatisierte Testfälle für die Seitennummerierung gehen durch alle Seiten und sammeln Datensatz-IDs dabei. Am Ende muss die Anzahl zurückgegebener IDs der Anzahl eindeutiger IDs entsprechen, und beide müssen der erwarteten Gesamtzahl entsprechen.
Das Playwright-Beispiel unten steuert die UI und prüft die Netzwerkantwort neben dem DOM. Auf diese Weise zeigt der Test, ob ein Defekt von der API oder vom Rendering kommt. Damit der Test läuft, benötigen die Zeilen und das Gesamtzahl-Element data-testid-Attribute. Die Seite benötigt auch einen „Nächste Seite“-Button, und die API-Antwort benötigt ein items-Array:
import { test, expect, type Page } from '@playwright/test';
const rowIds = (page: Page) =>
page.getByTestId('row').evaluateAll((rows) => rows.map((r) => r.getAttribute('data-id')!));
test('UI-Seitennummerierung zeigt jeden Datensatz genau einmal', async ({ page }) => {
await page.goto('/products');
const total = Number(await page.getByTestId('total-count').innerText());
const next = page.getByRole('button', { name: 'Nächste Seite' });
const seen = await rowIds(page);
let current = 1;
while (await next.isEnabled()) {
const [response] = await Promise.all([
page.waitForResponse((r) => r.url().includes('/api/products') && r.ok()),
next.click(),
]);
current += 1;
await expect(page.locator('[aria-current="page"]').toHaveText(String(current));
const ids = await rowIds(page);
const apiIds = (await response.json()).items.map((i: { id: string }) => i.id);
expect(ids).toEqual(apiIds); // das DOM zeigt, was die API zurückgegeben hat
seen.push(...ids);
}
expect(seen.length).toBe(new Set(seen).size); // keine Duplikate
expect(seen.length).toBe(total); // keine fehlenden Datensätze
});
Das API-Beispiel folgt nextPageToken bis zur letzten Seite und wendet dieselben ID-Assertions an. Es verlässt sich auf die baseURL aus Ihrer Playwright-Konfiguration. Zusätzlich stoppt ein Anfragenlimit die Schleife, wenn die API weiter Tokens zurückgibt, was an sich ein Fehler ist:
test('API-Cursor-Durchlauf gibt jeden Datensatz genau einmal zurück', async ({ request }) => {
const seen: string[] = [];
let token: string | undefined;
let total = 0;
let requests = 0;
do {
if (++requests > 500) throw new Error('Durchlauf hat die letzte Seite nicht erreicht');
const res = await request.get('/api/products', {
params: token ? { limit: 50, pageToken: token } : { limit: 50 },
});
expect(res.status()).toBe(200);
const body = await res.json();
total = body.total_count;
seen.push(...body.items.map((i: { id: string }) => i.id));
token = body.nextPageToken || undefined;
} while (token);
expect(seen.length).toBe(new Set(seen).size); // keine Duplikate
expect(seen.length).toBe(total); // keine fehlenden Datensätze
});
Beide Tests passen in eine CI-Pipeline, z. B. in Jenkins oder Azure DevOps, sodass Seitennummerierungsregressionen bei jedem Build auftauchen. In aqua cloud kann Ihr Team dann diese automatisierten Durchläufe mit den passenden Testfällen für die Seitennummerierung und ihren Anforderungen verknüpfen.
Fazit
Seitennummerierung sieht wie eine Reihe von Seitenzahlen aus, doch sie hängt davon ab, dass UI und Backend synchron bleiben, wenn sich Filter und Sortierungen ändern. Die Testfälle für die Seitennummerierung in diesem Leitfaden decken diesen Vertrag von grundlegenden Klicks bis zum API-Token-Handling ab. Mit ihnen kann Ihr Team nachweisen, dass jeder berechtigte Datensatz genau einmal an der richtigen Stelle erscheint. Fügen Sie diese Cases Ihrer Suite hinzu, und duplizierte oder fehlende Datensätze werden in Testläufen auftauchen, bevor sie die Produktion erreichen.
Mit über 50 Testfällen für die Seitennummerierung auf Ihrer Liste ist die nächste Aufgabe, sie über die gesamte Anwendung hinweg aktuell zu halten. Die manuelle Dokumentation jedes Falls kostet Zeit. Mit aqua cloud, einer KI-gesteuerten Test- und Anforderungsmanagement-Plattform, und aqua Intelligence können Sie detaillierte Testfälle aus Ihren Anforderungen in Sekunden generieren. Da die KI aus der in ein Projekt hochgeladenen Dokumentation schöpft, entspricht die Ausgabe Ihrem spezifischen Kontext und Ihrer Terminologie. Vollständige Rückverfolgbarkeit verbindet jede Anforderung mit ihren Tests und Defekten, und Dashboards zeigen, wo duplizierte Datensätze oder fehlende Grenzprüfungen noch Aufmerksamkeit benötigen. Manuelle und automatisierte Tests bleiben auf einer Plattform, die sich über Jenkins und Azure DevOps mit Ihrer CI/CD verbindet. Für die Testausführung gehören Ranorex, JMeter, SoapUI, PowerShell und UnixShell zu über 10 nativen Automatisierungsintegrationen. MSSQL- und Oracle-Datenbankverbindungen und die REST-API runden diese Gruppe ab. Confluence verbindet sich für gemeinsame Dokumentation. Schließlich fügt Capture Video und Screenshots jedes Testlaufs dem Datensatz hinzu.
Mit über 50 Testfällen für die Seitennummerierung auf Ihrer Liste ist die nächste Aufgabe, sie über die gesamte Anwendung hinweg aktuell zu halten. Die manuelle Dokumentation jedes Falls kostet Zeit. Mit aqua cloud, einer KI-gesteuerten Test- und Anforderungsmanagement-Plattform, und aqua Intelligence können Sie detaillierte Testfälle aus Ihren Anforderungen in Sekunden generieren. Da die KI aus der in ein Projekt hochgeladenen Dokumentation schöpft, entspricht die Ausgabe Ihrem spezifischen Kontext und Ihrer Terminologie. Vollständige Rückverfolgbarkeit verbindet jede Anforderung mit ihren Tests und Defekten, und Dashboards zeigen, wo duplizierte Datensätze oder fehlende Grenzprüfungen noch Aufmerksamkeit benötigen. Manuelle und automatisierte Tests bleiben auf einer Plattform, die sich über Jenkins und Azure DevOps mit Ihrer CI/CD verbindet. Für die Testausführung gehören Ranorex, JMeter, SoapUI, PowerShell und UnixShell zu über 10 nativen Automatisierungsintegrationen. MSSQL- und Oracle-Datenbankverbindungen und die REST-API runden diese Gruppe ab. Confluence verbindet sich für gemeinsame Dokumentation. Schließlich fügt Capture Video und Screenshots jedes Testlaufs dem Datensatz hinzu.
Sparen Sie 12,8 Stunden pro Woche mit aqua Intelligence, einer RAG-gesteuerten KI, die auf Projektdokumentation arbeiten kann
Was sind die wichtigsten Testfälle für die Seitennummerierung?
Die wichtigsten Testfälle für die Seitennummerierung prüfen die Navigation zwischen der ersten und letzten Seite. Sie decken auch Grenzwerte wie null Datensätze oder eine Seitenzahl außerhalb des Bereichs ab. Schließlich sollte Ihr Team bestätigen, dass kein Datensatz über Seiten hinweg dupliziert oder fehlend ist.
Wie testet man die Seitennummerierungsfunktionalität auf einer Website?
Um die Seitennummerierungsfunktionalität auf einer Website zu testen, durch den Datensatz mit Weiter und direkten Seitenzahl-Klicks navigieren, während Sie Datensatz-IDs vergleichen. Danach Browser-Zurück- und Refresh-Verhalten prüfen, dann bestätigen, dass Steuerungen auf mobilen Bildschirmen funktionieren.
Was sind die negativen Testfälle für die Seitennummerierung?
Negative Testfälle für die Seitennummerierung senden ungültige Eingaben, etwa ?page=abc oder eine negative Seitenzahl. Sie simulieren auch Ausfälle wie Netzwerkverlust oder einen 500-Serverfehler. Für Cursor-basierte APIs decken sie erfundene und abgelaufene Tokens ab, die klare Fehler zurückgeben sollten.
Wie testet man Seitennummerierung mit Sortierung und Filterung?
Um Seitennummerierung mit Sortierung und Filterung zu testen, eine der beiden auf einer späteren Seite anwenden und prüfen, dass die App Sie zu einer gültigen Seite bewegt. Als Nächstes bestätigen, dass beide Einstellungen über Seiten hinweg aktiv bleiben und dass gleiche Sortierwerte eine stabile sekundäre Reihenfolge beibehalten.
Wie testet man Seitennummerierung in einer API?
Um Seitennummerierung in einer API zu testen, Anfragen mit Grenz- und ungültigen Parametern senden, dann Statuscodes und Metadaten wie total_count prüfen. Als Nächstes den Seiten-Tokens bis zum Ende folgen und gesammelte Datensatz-IDs vergleichen. Für dynamische Daten Datensätze zwischen Anfragen hinzufügen oder löschen.
Pavel ist Quality-Assurance-Berater und Autor mit tiefem Fachwissen in der Lösung komplexer Testherausforderungen. Sein Hintergrund in der Softwareentwicklung hat Organisationen dabei geholfen, ihre QA-Praktiken von reaktiv zu proaktiv zu entwickeln. Neben der Beratung entwickelt Pavel Best-Practice-Leitfäden und Fallstudien für aqua cloud, die praxisnahe QA-Lösungen demonstrieren…
Die Verbesserung des aqua-Produkts ist Martins Hauptaufgabe und größte Mission. Sein Fachwissen umfasst ITIL-Prozessberatung, Änderungsmanagement, Qualitätssicherung, Qualitätsmanagement und Anforderungsmanagement. Martin arbeitet seit mehr als 18 Jahren in der Qualitätssicherung für regulierte Branchen und ist eine unersetzliche Führungskraft bei der andagon Group.
Nurlan, ein QA-Koordinator, ist stolz darauf, nahtlose QA-Operationen zu orchestrieren. Seine Expertise in der Koordination von QA-zentrierten Projekten und der Integration von QA-Lösungen hat konsequent höchste Kundenzufriedenheit erzielt. Neben seiner Vollzeittätigkeit als QA-Koordinator beinhaltet Nurlans Rolle das Erstellen von überzeugenden Inhalten, die Nutzer über die…
Beginnen Sie Ihre Arbeit nicht mit gewöhnlichen E-Mails: Fügen Sie eine gesunde Dosis an aufschlussreichen Softwaretest-Tipps von unseren QS-Experten hinzu.
Home » Testautomatisierung » Testfälle für die Seitennummerierung: 50+ funktionale & negative Szenarien
Lieben Sie das Testen genauso wie wir?
Werden Sie Teil unserer Community von begeisterten Experten! Erhalten Sie neue Beiträge aus dem aqua-Blog direkt in Ihre Inbox. QS-Trends, Übersichten über Diskussionen in der Community, aufschlussreiche Tipps — Sie werden es lieben!
Wir sind dem Schutz Ihrer Privatsphäre verpflichtet. Aqua verwendet die von Ihnen zur Verfügung gestellten Informationen, um Sie über unsere relevanten Inhalte, Produkte und Dienstleistungen zu informieren. Diese Mitteilungen können Sie jederzeit wieder abbestellen. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie.
X
🤖 Neue spannende Updates sind jetzt für die aqua-Intelligenz verfügbar! 🎉
