<JASK Gaming> <!Everybodys Perfect> <Iteration/ Master> Test Plan. Test Plan. Version <1.0> 1.Introduction. 2.Evaluation Mission and Test Motivation

Transkript

1 <!Everybodys Perfect> <Iteration/ Master> Test Plan Version <1.0> Test Plan 1.Introduction 1.1.Purpose The purpose of the Iteration Test Plan is to gather all of the information necessary to plan and control the test effort for a given iteration. It describes the approach to testing the software, and is the top-level plan generated and used by managers to direct the test effort. This Test Plan for the!everybody s Perfect supports the following objectives: Functional Testing Unit Testing UI-Testing 1.3.Intended Audience Project Manager Project Developers Peer Review Partners 2.Evaluation Mission and Test Motivation Testing symbolizes an comfortable way to ensure the correctness of written code and automatic generated parts of the software project. 2.1.Background Der Entwicklungsprozess besteht aus unterschiedlichen Phasen. Dies trifft nicht nur auf die einzelnen Entwicklungsabläufe zu sondern auch hinsichtlich der Programmstruktur. Die Aufteilung in Use-Cases verlangt förmlich nach einem modularen Aufbau. Um schon während des Entwicklungsprozesses Aussagen über die Korrektheit der einzelnen Programmteile tätigen zu können bedarf es für jedes Programmmodul eigene Tests. 2.2.Evaluation Mission Fehler finden die die Programmstabilität bedrohen Fehler finden welche die Spielintegrität bedrohen 2.3.Test Motivators Use-Cases Performance Behaviour 3.Target Test Items The listing below identifies those test items software, hardware, and supporting product elements that have

2 been identified as targets for testing. This list represents what items will be tested. Android Studio integrated testing suite PC/MAC running Android Studio Android powered device (final testrun is represented by playing the game) 5.Test Approach 5.1.Initial Test-Idea Catalogs and Other Reference Sources 5.2.Testing Techniques and Types Function Testing Function Testing wird durch die Kombination von Unit Testing und UI-Testing erreicht.

3 5.3.User Interface Testing Das User Interface wird per Skript getestet. Im Testskript werden verschiedene Usereingaben getriggert. Geprüft wird nun ob die getätigte Eingabe die erwartete Aktionskette nach sich zieht. Jeder dieser Milestones wird Protokolliert und nach Beendigung gesichtet. Aufgrund von Anpassungen die durch einen Versionswechsel der Entwicklungsumgebung notwendig wurden, werden Screenshots des UI-Tests nachgereicht. 5.4.Unit Testing

4 <JASK Gaming> 9.Environmental Needs 9.1.Base System Hardware The following table sets forth the system resources for the test effort presented in this Test Plan. Client Test System Resources Resource Quantity Name and Type Include special configuration requirements Android Device (with Wifi) Test Repository Network or Subnet Test Development PCs Wifi Network Any System suitable for running Android Studio (Windows, Linux, Unix) 9.2.Base Software Elements in the Test Environment The following base software elements are required in the test environment for this Test Plan. [Note: Add or delete items as appropriate.] Software Element Name Version Type and Other Notes Android not specified Operating System Android Studio not specified IDE

5 10.Metrics Screenshot von SonarQube Integration in Buildprozess Die Integration der Metrics in den Buildprozess wird durch die automatische Analyse von SonarQube realisiert. Alle 30 Minuten wird der neue Stand des Programmcodes von SonarQube gezogen und analysiert. Angewandte Metrics Wie auf dem Screenshot zu sehen ist, ziehen wir für unsere Analyse die Metrics Code-Duplications und Complexity heran. Code-Duplications: Diese Funktion bestimmt Codezeilen, welche in der Software mehr als einmal in identischer Art und Weise vorkommen. Im Vorfeld wurden bereits Redundanzen im Code entfernt.

6 Complexity: Die Cyclomatic Complexity (auch McCabe-Komplexität genannt) ist eine Metrik, mit welcher die Komplexität eines Softwaremoduls bestimmt werden kann. Im Allgemeinen handelt es ich dabei um eine Zählvariable, welche bei jeder Abzweigung im Kontrollflussgraph einer Software (z.b. Funktionsaufruf, if-abfrage, swtich-case- Anweisungen etc.) um eins erhöht wird. Dementsprechend kann angenommen werden, dass die Unübersichtlichkeit des Quellcodes von der Höhe dieser Kennzahl abhängt. Allerdings beziehen sich die laut SonarQube bedenklichen Codeteile auf reguläres Java. Java for Android, wie es in der Android-Studio Entwicklungsumgebung verwendet wird, bedient sich allerdings einiger Erweiterungen die für SonarQube falsch sind. Jedoch sind in der Masse der Komplexitätsverstöße auch sinnvolle hinweise enthalten. Beispielsweise werden unpassende Klassennamen oder auskommentierte Codeschnipsel markiert. Diese stören den Lesefluss und können so Verwirrend wirken oder Unklarheiten bewirken.

7 Vorher/Nachher Die V/N vergleiche werden nachgereicht!