"Standard" Testprozess

9

Mir ist klar, dass der Begriff "Standard" seltsam ist, da das Testen sehr projektabhängig ist, aber wenn ich ein hübsches Standardszenario plane, hoffe ich, Feedback zu den Testarten zu bekommen, mit denen ich mich befassen sollte.

Mein Team ist gerade dabei, eine mittelgroße datengesteuerte Webanwendung zu erstellen. Wir verwenden einen ziemlich agilen Prozess. In den meisten Fällen wurden die Anforderungen festgelegt, aber wir werden in letzter Minute einige Änderungen vornehmen.

Bis jetzt haben wir hauptsächlich manuelle Tests durchgeführt. Wir versuchen, so viel wie möglich zu automatisieren. Ich habe mir einige Tools angeschaut und hier sind die Arten von Tests, mit denen ich mich beschäftigen muss:

  • Komponententest (Test Driven Development Style) - Dies ist ein wenig spät im Spiel, da viel Code geschrieben wurde, aber ich plane, Tests durchzuführen, bevor ich Funktionalität implementiere . Für die Zwecke dieser Frage können wir sogar annehmen, dass ich das Projekt nicht begonnen habe.

  • Integrationstests - Da unsere Anwendung im Web verwendet wird, verwende ich den Begriff Integrationstests, um die Verbindung zwischen den Seiten zu verstehen. Was ist ein gutes Open-Source-Tool dafür (sagen wir .NET)?

  • Regressionstest - Es scheint, dass wir dies kostenlos mit unseren Komponententests bekommen

  • Datenintegritätstest - Nicht sicher, was Sie das nennen, sondern nur die Idee, dass die Daten, die wir vom Client erhalten haben, in die Anwendung geladen werden.

  • Funktionsprüfung - Wird dies normalerweise in der GUI durchgeführt? Gibt es gute Code-gesteuerte Optionen?

  • Performance- und Lasttests - Stellen Sie sicher, dass die Anwendung auch unter Stress schnell reagiert.

Mir wurde immer gesagt, dass das QA-Team fast genauso viel Zeit haben sollte wie das Entwicklungsteam, um die Anwendung zu betrachten, aber es scheint, dass heutzutage viele Aspekte automatisiert werden können. Wird das offizielle "QA-Team" heutzutage viel weniger benötigt?

Meine Hauptfragen sind:

  • Ist das ein angemessener Testaufwand für ein mittelgroßes Projekt mit einem erfahrenen Technologieteam? Gibt es große Dinge, die ich vermisse oder mit denen ich mich beschäftigen sollte?
  • Was sind typische Zyklen dieser Testbemühungen? (z. B. Komponententests, die bei jedem Check-in oder bei jeder Nacht ausgeführt werden)?
  • Wie sind die typischen QA-Mannstunden im Vergleich zu den heutigen Stunden der Entwicklungshelfer?

Vielen Dank!

    
skaz 14.03.2011, 20:26
quelle

2 Antworten

4

Es gibt so viele Dinge , die ich schreiben müsste, um zu antworten ... Ich werde einige Highlights geben, die auf andere zählen um einige gute Einblicke zu geben.

Integrationstest
Normalerweise wird dies als Testen der Integration zwischen Komponenten Ihrer Anwendung verstanden. Dies können Interaktionen zwischen Modulen der Business-Schicht sein. Dies können Interaktionen zwischen Business Objects und Datenzugriffsobjekten sein. Es gibt viele Dinge, die sich hinter Integrationstests verbergen. "Verknüpfung zwischen den Seiten" wäre die letzte, an die ich denken würde. Es überprüft die "Integrität" der Web-Anwendung, aber nicht viele Leute würden dies als Integrationstest bezeichnen. Beginnen Sie vielleicht mit der Wiki-Definition , überprüfen Sie SO Fragen .

Regressionstest
Möchten Sie nur einzelne Klassen oder Funktionen, Geschäftsprozesse, Datenflüsse usw. testen? Der Regressionstest definiert das Motiv, einige Tests zu wiederholen, nicht die Ebene, auf der Sie sie durchführen. Sie führen Regressionstests durch, um zu überprüfen, ob die Funktionalität, die von den angegebenen Tests abgedeckt wird, mit den letzten Änderungen im System gebrochen wurde. Es kann Komponententests sein, es kann Integration sein, es kann funktional sein, es kann GUI-basiert sein oder nicht. Überprüfen Sie die Wiki-Definition .

Datenintegritätstest
Ich kümmere mich nicht darum, aber ich bin mir nicht sicher, ob Ihr Verständnis korrekt ist. Probieren Sie Google-Suche aus.

Funktionsprüfung
Funktionales Testen wird normalerweise als GUI-Ebene verstanden, muss es aber nicht. Es kann auf Web-Services, auf EJB, sogar auf API erfolgen. Überprüfen Sie diese Definition , um dies zu klären.
Was Code-gestützte Tests für GUI betrifft, gibt es viele Lösungen. MSVS2010 - mit seinen CodedUI-Tests, HP QTP für viele Technologien gibt es ein Tool von IBM, eines von Borland (Silk Test, jetzt gehört Borland zu irgendeinem Unternehmen). Es gibt Open-Source-Tools: WatiN , Selenium , Abt , RobotFramework , viele andere.

Performance Testing
Performance Testing hat viele verschiedene Varianten, Stresstests, Test-Tests , Belastungstest, viele andere. Überprüfen Sie diese MS-Referenz für einen grundlegenden Überblick.

Nun, die Hauptfragen:)

  1. Sie werden von allem etwas machen können, aber Sie werden nur an der Oberfläche kratzen. Außerdem braucht man Leute, die das können. Keine Respektlosigkeit, aber sind Sie sicher, dass Ihre Entwickler das alles wissen und können? Was ist wichtiger, haben sie Zeit, all das zu tun? Fange klein an. Gehen Sie mit Komponententests, Integrationstest von Komponenten, Regressionen auf beiden von ihnen. Starten Sie die Automatisierung des Funktionstests, vielleicht versuchen Sie es mit Akzeptanztest-Entwicklung ( etwas , etwas dort ). Konzentrieren Sie sich mehr auf Bereiche, in denen Sie Fehler finden, maximieren Sie Ihren ROI: P (Wenn Sie keine Leistungsprobleme haben, gehen Sie vielleicht etwas auf Leistungstests ein?).
  2. Einrichtung kontinuierliche Integration . Führen Sie häufig schnelle Tests durch, führen Sie manchmal langsame Tests durch, führen Sie bei Bedarf eine vollständige Regression durch (basierend auf einer Risikobewertung).
  3. Es gibt keine definitive Regel darüber, wie viele Teststunden benötigt werden. Es hängt von vielen Faktoren ab. Am wichtigsten, wie fehlerhaft ist das aktuelle Produkt? Mehr Bugs - & gt; mehr reparieren - & gt; mehr Regressionen = mehr Tests. Es gibt Unternehmen wie Google (ein Tester für viele Projekte) oder Microsoft (bis zu viele Tester pro Entwickler). Es ist schwierig, das Projekt vorherzusagen, ohne historische Daten (von Ihrer Organisation für bestimmte Teams / Projekttypen). Dieser Kurzfilm Post gibt Ihnen vielleicht mehr Einblick.

Prost.

    
yoosiba 14.03.2011, 22:28
quelle
1

Ich stimme der Antwort von yosiba vollkommen zu, (aber) für mich scheint es ein bisschen eine Antwort aus der Sicht des Entwicklers zu sein (Dies ist keine Kritik). Es ist auch wichtig, den Standpunkt des Benutzers nicht zu vergessen.

Wenn also die Entwickler-Tests gut gelaufen sind und Sie ein laufendes System haben, dann ist es Zeit für den Systemtest (Sie können dies vielleicht in Functional Testing von yosibas Antwort sortieren). Und ich würde diesen Teil nicht vollständig automatisieren (Natürlich können Teile davon automatisch gemacht werden).

Besonders gute Ergebnisse habe ich von Exploratory Testing erhalten. Kurz gesagt, Sie benötigen einen erfahrenen Tester (Benutzer), der versucht, Fehler mit dem System aktiv zu finden. Der Tester muss in der Lage sein, knifflige Testfälle zu finden, die das System belasten, Grenzfälle oder seltene Anwendungsfälle finden. Dies wird nicht nur Fehler finden, es wird auch Punkte finden, die aus Sicht der Benutzerfreundlichkeit vielleicht schwierig sind. Wichtig ist hier, dass der Tester nicht der Entwickler ist, denn nach meiner Erfahrung vertrauen Entwickler eher auf ihre Fähigkeiten und ihre Software (das ist nicht schlecht) und testen vielleicht nur, was sie implementiert haben. (Systemtest / Exploratives Testen ist ein Black-Box-Test, d. H. Der Tester muss / sollte nicht über die Implementierung Bescheid wissen)

    
stema 15.03.2011 10:12
quelle

Tags und Links