Betatest Cluedo. Sebastian Bschorer. 3. Juli 2015

Transkript

1 Betatest Cluedo Sebastian Bschorer 3. Juli 2015 Am soll die Betatest-Woche beginnen. Dazu müssen Sie bis zu diesem Termin eine vollständig lauffähige Spielversion als.jar fertigstellen. Diese wird dann in das Betatest-Git-Repository eingecheckt, und von je zwei anderen Gruppen auf Fehler getestet. Es kann hierfür vorteilhaft sein, eine gemeinsame Oberfläche zu haben, von der aus sowohl Server, als auch Client und KI gestartet werden können; und in der man zumindest in der Beta-Version auch das Logging einstellen kann (Detailstufe und Ausgabeordner). Es ist aber genauso gut, wenn Sie für Client, Server und KI jeweils eine eigene.jar-datei bereitstellen. Beim Beta-Test soll auch die Kompatibilität zu fremden Clients und Servern verifiziert werden; dies dient dem Test, ob das Protokoll korrekt implementiert ist. Um hier wertvolle Rückmeldungen von den anderen Gruppen zu bekommen, ist es wichtig, dass Sie pünktlich eine stabil lauffähige Version haben. Anschließend haben Sie erneut Zeit, die von Ihren Beta-Testen gefundenen Fehler zu beheben, bevor Sie die finale Version abgeben müssen. Zum Beta-Testen werden jeder Gruppe zwei andere Gruppen zugeteilt, deren Lösung zu testen ist. Die Lösung der anderen Gruppe wird anhand der Version auf dem Webserver getestet. Folgende Gruppenzuteilung wurde festgelegt: Eigene Gruppe Zu testende Gruppe 1 Zu testende Gruppe 2 1

2 Betatest-Dateien bereitstellen Legen sie im master-branch des betatest-repositorys 1 ihre *.jar s ab. Und zwar ohne Unterordner nach folgendem Namenschema: Falls eigene Client-Jar vorhanden: <Gruppenname>_Client.jar Bsp: _Client.jar Falls eigene Server-Jar vorhanden: <Gruppenname>_Server.jar Bsp: _Server.jar Falls eigene KI-Jar vorhanden: <Gruppenname>_KI.jar Bsp: _KI.jar Falls Server und Client beide von einer *.jar aus gestartet werden können, reicht die Bezeichung <Gruppenname>.jar Bsp:.jar Geben Sie sonstigen *.jar-dateien auch sinnvolle Bezeichnungen, nach diesem Schema an: <Gruppenname>_Was_tu_ich_hier.jar Bsp: _Was_tu_ich_hier.jar Jar-Dateien, die nicht nach diesen Schemata hochgeladen werden, gelten als nicht eingecheckt! Falls Sie wollen, können Sie auch eine *.pdf- oder *.txt-datei bereitstellen, wenn Sie auf Besonderheiten (wie bspw. Erweiterungen oder wo Log-Files abgelegt werden) hinweisen möchten. Benennen Sie dieses Dokument nach dem Schema: <Gruppenname>_Anleitung.pdf oder.txt Bsp: _Anleitung.pdf oder.txt Sie haben Zeit, ihre lauffähigen Dateien bis Montag, :00 Uhr einzuchecken. Ab diesem Zeitpunkt haben Sie keinen Schreibzugriff mehr auf das Repository. Sollten Sie es bis dahin nicht schaffen, eine lauffähige Version hochzuladen, müssen Sie per Mail einen Härtefall mit Begründung bei Prof. Ohlbach oder Laith Raed einreichen. Setzen Sie dabei auch ihren Tutor ins CC 2. 1 git@gitlab.cip.ifi.lmu.de:sepss15/betatest.git 2 2

3 Betatest durchführen Erstellen Sie über Ihre Tests ein Testprotokoll für jede Gruppe. Eine Vorlage zum Testprotokoll finden Sie umseitig. Dafür finden Sie auch auf der Cluedo-Website eine LATEX- und eine txt-vorlage. Achten Sie darauf, dass bei Fehlern oder Abstürzen die Beschreibung genau genug ist, so dass die betroffene Gruppe in der Lage ist, den Fehler bzw. Absturz zu reproduzieren und zu beheben. Arbeiten Sie bitte gründlich und genau Ihr Testverhalten entscheidet über die Erfüllung des Betatests. Ihre Auswertungsprotokolle für beide Gruppen stellen Sie bis spätestens Sonntag, den , 18:00 Uhr, in den master-branch des betatest_protokoll-repositorys 3. Verwenden Sie für die Protokolle das pdf- oder txt-format. Benennen Sie die Dateien dabei wie folgt: <TestGruppenName>_<IhrGruppenname>.pdf oder.txt Wenn die die Gruppe testet, sieht die Datei so aus: _.pdf Wenn Sie wollen, können Sie weitere Gruppen testen und auch dafür Protokolle erstellen. 3 git@gitlab.cip.ifi.lmu.de:sepss15/betatest_protokoll.git 3

4 Zu den folgenden Punkten soll jeweils ein kurzer Kommentar abgegeben werden: Installation/Ausführbarkeit und Dokumentation Korrektheit (korrekte Funktion, Abstürze) Zuverlässigkeit (Fehlertoleranz, Robustheit) Benutzerfreundlichkeit (insbes. der Oberfläche, Geschwindigkeit) Sinnvolle Fehlermeldungen Sonstige Bemerkungen (z.b. Verbesserungsvorschläge) Die folgenden Fragen sollen jeweils mit ja oder nein beantwortet werden (bei nein ist ggf. eine genaue Fehlerbeschreibung notwendig!) Programmstart: Findet ein Client andere Server im lokalen Netz (UDP)? Kann eine Verbindung zu einem der angezeigten Server aufgebaut werden (TCP)? Kann man eine Verbindung zu einem manuell eingegebenen Server aufgebaut werden? Gibt es eine Lobby? Sieht man bereits vorhandene Spiele? Sieht man angemeldete Clients? Gibt es einen funktionierenden Chat? Kann man ein Spiel erstellen und dabei die Farbe auswählen? Kann man beim Spiel beitreten die Farbe auswählen? Können nur Spieler mit unterschiedlicher Farbe an einem Spiel teilnehmen? (Optional:) Kann ein Client an mehreren Spielen gleichzeitig teilnehmen? Werden Spiele gelöscht, die keine Spieler mehr beinhalten? Spielstart: Kann man sich an ein laufendes Spiel als Spieler nicht mehr verbinden? Kann man sich als Zuschauer jederzeit zu einem Spiel verbinden? Wird die Spielerreihenfolge entsprechend der Regel festgelegt? (Also rot zuerst, falls rot vorhanden, sonst zufällig?) Sind die Startpositionen korrekt? Liegen die Waffen anfangs im Schwimmbad? Erhalten alle Spieler gleich viele Karten? Gibt es jeder Karte genau einmal? Gibt es für das Schwimmbad keine Karte? 4

5 Normales Spiel: Kann man nur einmal (zu Beginn) pro Zug würfeln? Ist die Zufallsverteilung der Würfelaugen plausibel? Kann man nur die Felder erreichen, die mit dem Würfelwurf möglich sind? Kann man also... zum Beispiel mit einer 2 nicht die direkten Felder betreten? nicht auf Felder landen, die bereits belegt sind? belegte Felder nicht überspringen? Kann man einen Raum durch alle Türen verlassen? Darf man einen Raum im selben Zug nicht verlassen und direkt wieder betreten? Muss man nach Betreten eines Raumes einen Verdacht äußern? (Ausnahme Schwimmbad) Kann man nur in einem Raum einen Verdacht aussprechen? Kann man im Schwimmbad keinen Verdacht aussprechen? Ist es unmöglich einen anderen Raum, als den, in dem man sich befindet, für einen Verdacht zu wählen? Kann man nur (maximal) einmal pro Zug einen Verdacht aussprechen? Muss der aktive Spieler warten, bis eine Verdächtigung widerlegt wurde? Werden die Spielfiguren und Waffen in den Verdachtsraum gelegt? Funktionieren die Geheimgänge der gegenüberliegenden Räume? Darf man nach Nutzen eines Geheimgangs nicht mehr würfeln? Falls man den Zug in einem Raum beginnt: Darf man nur dann einen Verdacht äußern, falls die Spielfigur in diesen Raum beordert wurde? Werden einem im Schwimmbad die übrig gebliebenen Karten angezeigt? Gibt es eine sinnvolle Ausnahmebehandlung, falls ein Spieler das Spiel vorzeitig verlässt? Darf man nur im eigenen Spielzug Anklage erheben? Wird das Spielende korrekt erkannt, wenn ein Spieler richtig anklagt oder alle Spieler falsch angeklagt haben? Gibt es für den Spieler einen Notizblock oder ähnliches? Bleiben geheim zu haltende Informationen geheim? Sonstiges... KI-Client: Gibt es eine KI? Reagiert die KI den Regeln entsprechend? Kann die KI aktiv gewinnen? Kompatibilität Ist der Client mit anderen Servern kompatibel? Ist der Server mit anderen Clients kompatibel? 5