Wo finden Sie guten Testfall-Vorlagen/Beispiele?
Ich versuche zu etablieren, die mehr formalen Anforderungen und Prüfverfahren dann haben wir jetzt, aber ich kann nicht finden, eine gute Referenz Beispiele von Dokumenten beteiligt.
Im moment, nach dem feature-freeze Tester "klicken Sie sich durch die Anwendung" vor der Bereitstellung, jedoch gibt es keine formale Spezifikation, was getestet werden muss.
Erste, ich denke über ein Dokument, die angibt, jedes feature, das getestet werden muss, so etwas wie dieses (aus):
- user registration form
- dropdown-Land (die Länder vom server abgerufenen richtig?)
- password validation (sind alle Passwort-Regeln beachtet, wird der Benutzer benachrichtigt, wenn das Passwort zu schwach?)
- Dankeschön-für-die Registrierung
...und so weiter. Dieses könnte auch dazu dienen, als etwas, das client anmelden kann, da ein Teil der Anforderungen, bevor der Programmierer mit dem Programmieren beginnen. Nachdem die feature-Liste ist komplett, ich bin Gedanken darüber macht diese Liste die erste Spalte in einer Tabellenkalkulation, die auch sagt, Wann war das Letzte feature getestet, hat es funktioniert, und wenn es nicht funktioniert, wie haben Sie es brechen. Dies würde mir ein Dokument Tester füllen könnte nach jedem Prüf-Zyklus, so dass Programmierer haben to-do-Liste, mit Informationen, was nicht funktioniert und Wann hat Sie Pause.
Zweitens, ich denken, dass die Testfälle für den Tester, mit detaillierten Schritten, wie:
- Load user registration form.
- (Merkmal 1.1) Überprüfen, Land-dropdown-Menü.
- Ist Land dropdown-besiedelten mit den Ländern?
- Sind Namen von Ländern lokalisiert?
- Ist die Sortierreihenfolge korrekt für jede Sprache?
- (Merkmal 1.2) und Geben Sie diese Passwörter: "a", "bob", "Passwort", "password123", "password123#". Nur das Letzte Passwort akzeptiert werden sollten.
- Drücken Sie "OK".
- (Funktion 2) Überprüfen Sie Dankeskarte.
- Ist der text lokalisiert jede unterstützte Sprache?
Diese geben die Tester bestimmten Fällen und Checkliste was ist zu beachten, mit Zeigern auf die Funktionen, die in das erste Dokument. Dies würde auch mir etwas schenken zu starten, die Automatisierung von Testverfahren (derzeit haben wir nicht viel testen, Automatisierung, abgesehen von unit-tests).
Ich bin auf der Suche nach einigen Beispielen, wie andere dies getan haben, ohne viel Papierkram. In der Regel, tester sollte in der Lage sein zu gehen durch alle tests in einer Stunde oder zwei. Ich bin auf der Suche nach einem einfachen Weg, um Kunden vereinbaren, welche features sollen wir implementieren für die nächste version, und für Tester, um zu überprüfen, dass alle neuen features implementiert sind und alle vorhandenen Funktionen arbeiten, und ein Bericht an die Programmierer.
Dies ist hauptsächlich auf die interne Prüfung material, die sein sollte, ein paar Word/Excel-Dokumente. Ich werde versuchen zu halten, einem testing/bugfixing-Zyklus unter zwei Tagen. Ich bin tracking Programmierung der Zeit, die Implementierung von neuen features und Kunden-tickets, die auf andere Weise (JIRA), das wäre grundsätzlich die Prüfung der Dokumentation. Dies ist der lifecycle, die ich im Sinn hatte:
- Uhr macht die Liste der features. Kunde unterschreibt es. (Dokument 1 erstellt).
- Testfälle erstellt werden. (Dokument 2.)
- Programmierer Funktionen implementieren.
- Tester test bietet laut test Fällen. (Und bugs durch Dokument 1.)
- Programmierer die Fehler beheben.
- GOTO 4, bis alle bugs behoben sind.
- Ende der internen Prüfung; Produkt nachweislich Kunden.
Hat jemand ein Wegweiser, wo Sie einige Beispiel-Dokumente mit test-Fällen gefunden werden kann? Auch alle Tipps in Bezug auf den Prozess, den ich oben beschrieben sind willkommen. 🙂
Du musst angemeldet sein, um einen Kommentar abzugeben.
ive entwickelte zwei Dokumente, die ich verwenden.
ist für Ihre weitere " standard-Webseiten (z.B. business-web-Präsenz):
http://pm4web.blogspot.com/2008/07/Qualität-test-plan.html
den anderen, den ich verwenden für web-basierte Anwendungen:
http://pm4web.blogspot.com/2008/07/Schrift-system-test-plan.html
hoffe, das hilft.
Erste, ich denke, die Kombination der Anforderungen Dokument mit der Testfall-Dokument macht am meisten Sinn, da ein Großteil der Informationen ist für beide gleich und haben die Anforderungen vor, die Tester-und test-cases vor dem Anwender und Entwickler verstärkt die Anforderung und bietet unterschiedliche Sichtweisen von Ihnen. Hier ist ein guter Ausgangspunkt für das Dokument-layout: http://www.volere.co.uk/template.htm#anchor326763 - wenn Sie hinzufügen: Schritte zum testen, was den Erwartungen von der test -, edge/gebundene Fällen sollten Sie haben eine ziemlich solide Anforderung, Spezifikation und Test-Spezifikation ein.
Für die Schritte, vergessen Sie nicht, bewerten der Schritt, wo Sie die Tester, Entwickler, etc. Bewertung der Testergebnisse und Aktualisierung der Bedarfs - /test-doc für die nächste Runde (Sie wird oft in Dinge, die hätten Sie nicht gedacht und sollte in der Skillung...sowohl aus Anforderungen Perspektive und Erprobung eins).
Ich auch empfehlen, mit mindmapping/work-breakdown-Struktur, um sicherzustellen, Sie haben alle Anforderungen korrekt erfasst.
David Peterson Concordion web-site hat eine sehr gute Seite über Technik für das schreiben von Spezifikationen (wie auch der Rahmen für die Ausführung der genannten Vorgaben). Seine Beratung ist einfach und prägnant.
Als auch Sie können prüfen wollen, Dan North, klassische blog-post auf das Verhalten-DrivenDevelopment (BDD). Sehr hilfreich!!!
Müssen Sie unbedingt eine detaillierte Spezifikation vor Beginn der arbeiten; andernfalls werden Ihre Entwickler nicht wissen, was zu schreiben oder, wenn Sie fertig sind. Joel Spolsky hat geschrieben ein gutes essay zu diesem Thema, mit Beispielen. Erwarte nicht, dass die spec unverändert bleiben, während der Entwicklung aber: bauen Revisionen in den plan.
meade, oben, hat empfohlen, die Kombination der spec mit den tests. Dies ist bekannt als Test Driven Development und ist eine sehr gute Idee. Es pins Dinge nach unten in einer Weise, die Natürliche Sprache oft nicht, und reduziert die Menge der Arbeit.
Du auch daran denken müssen, unit-tests und Automatisierung. Dies ist eine große Zeitersparnis und Qualitäts-booster. Die GUI-level-tests kann schwierig sein, zu automatisieren, aber man sollte die GUI-Schicht so Dünn wie möglich, und haben automatisierte tests für die Funktionen unter. Dies ist eine große Zeitersparnis später in der Entwicklung, da können Sie testen, die gesamte Anwendung gründlich wie oft, wie Sie möchten. Manuelle tests sind teuer und langsam, so gibt es eine starke Versuchung, Sie zu schneiden Ecken: "wir änderten nur die Foo Modul, so brauchen wir nur zu wiederholen, die tests 7, 8 und 9". Dann die Kunden-Telefone bis zu Klagen, dass etwas in der Bar-Modul ist gebrochen, und es stellt sich heraus, dass Foo hat eine obskure Nebeneffekte auf die Bar, dass die Entwickler verpasst. Automatisierte tests fangen würde dies, weil automatisierte tests sind Billig zu laufen. Sehen hier für eine wahre Geschichte über einen solchen Fehler.
Wenn Ihre Anwendung ist groß genug, um es brauchen, dann geben Sie-Modulen unter Verwendung von TDD, und schalten Sie diese Modul-tests in automatisierte tests.
Einer Stunde zu laufen, durch die manuellen tests klingt ein wenig zu optimistisch, es sei denn, es ist eine sehr einfache Anwendung. Vergessen Sie nicht, Sie haben, um zu testen, alle Fehler-Fällen sowie die Haupt-Pfad.
Gehen durch den alten bug-reports und bauen Sie Ihre Testfälle aus Ihnen. Sie können testen, die für bestimmte alte bugs und machen auch mehr Verallgemeinerungen. Da die gleichen Arten von Fehlern neigen dazu auftauchen, immer und immer wieder, dies wird Ihnen eine test-suite, die mehr über den Fang von echten bugs und weniger über das, unmöglich (oder sehr teuer) Aufgabe vollständige Abdeckung.
Machen Verwendung von GUI-und web-Automatisierung. Selen, zum Beispiel. Vieles kann automatisiert werden, viel mehr als Sie denken. Ihre Benutzer-Registrierung-Szenario, zum Beispiel, ist automatisierbar. Auch wenn Sie überprüft werden muss, von einem Menschen, zum Beispiel cross-browser-Tests, um sicherzustellen, dass alles Recht, den test aufgenommen und wiedergegeben werden können später, während der QA-Ingenieur-Uhren. Entwickler können auch die Schritte aufzeichnen, die zu reproduzieren sind schwer zu automatisieren, Fehler und übergeben an QS, anstatt die zeitaufwendig und oft fehlerbehaftet, Aufgabe aufschreiben der Anleitung. Sparen Sie als Teil des Projekts. Geben Sie Ihnen gute Beschreibungen, wie der Zweck des Tests. Link zu einem ticket. Sollte die GUI ändern, also der test funktioniert nicht mehr, und es wird geschehen, Sie können schreiben Sie den test, um zu bedecken Ihre Absicht.
Werde ich verstärken, was Paul Johnson sagte über das GUI-Schicht so Dünn wie möglich. Separates Formular (die GUI oder HTML-Formatierung) von der Funktionalität (was es tut), zu automatisieren und testen die Funktionalität. Funktionen, die die Erzeugung der Land-Liste, test, gründlich. Dann wird eine Funktion verwendet, die zur Generierung von HTML oder AJAX oder was auch immer, und Sie haben nur zum test, es sieht in etwa richtig, weil die Funktion, die die eigentliche Arbeit ist gut getestet. User-login. Passwort-checks. - E-Mails. Diese können geschrieben werden, um zu arbeiten, ohne eine GUI. Dies wird drastisch reduzieren auf die Menge langsam, teuer, fehlerhaft manuelle Tests, die gemacht werden muss.