程序代写代做代考 Java gui 10

10
Software Test Specification

Simple Social Card Collection Battling Game
______________________________________________________________________________
Software Test Specification
______________________________________________________________________________
Version 1.0
11/07/2017

Lee Kelvin lxk201
Qianxiang Ma qxm28

1. INTRODUCTION
1.1 purpose
The purpose of this document is to layout the vision of how this software will be tested for release. It will go to detail regarding test cases and the performances that satisfy the requirements that is laid out in Software Requirement Specification.
1.2 Scope
This test document will contain brief descriptions of the test cases and the software components the test cases involved with. The documentation procedure of finding solution to the bugs during testing is also specified. This document also list out the features that needs to be tested, and test cases will have a description regarding usage, execution, and expected outcome.
1.3 Overview of Contents of Document
Test Plan Description
The goal of this section is to layout the test cases that will be used to test each feature of the program. A brief description of the test cases will be included.
Test Design Specification
This section lays out the approach of testing regarding this program. It will detail how a feature of the program passes/fails the test, and what kind of tests are going to be used. The features that will not be tested and the environment requirement of the software testing. The suspension/resumption criteria will also be described in this section.
Test Specification
This section contains detail information regard each test cases and the features that involves the test cases.
Requirement Traceability
This section provides information regarding test cases’ connect to the Software Requirement Specification.
2. Test Plan Description
2.1 Product Summary
This simple social card game allows players to chat and play a card battle game. Players may request battle with friend, or quick match with another player that is also searching for a quick match battle.

Feature
Use Case
Component

View
Client
Server

Login
Log into an existing account
LoginWindow.java
LoginWindow.java
Server.java

Main Window
Main panel for the player to choose actions
MainWindow.java
Game.java
Server.java

Matchmaking
Finding a match for a player, then display the battle screen
/* Not implemented */
MainWindow.java
/* Not implemented */
NetClient.java

/* Not implemented */
Server.java

Gameplay
This feature processes battle information generate during a game
Match.java
Card.java
NetClient.java
Server.java

Deck Editing
Allows user to create a deck to be used in game
MainWindow.java
Card.java

Activity
Description
Exit Criteria

Alpha Testing
Two testers plays game against each other
Test all the possible actions, and report all undesirable behaviors.

Submission Testing
Two testers plays each other again before submitting the assignment
All the desired behaviors are present, and no glitches detected in the testing coverage.

3. Testing Design Specification
3.1 Testing Approach
Tests are prepared according to SRS.
Interface Testing
This software involves interactions between cards and constructions and parsing of the designed transmission protocols. These objects have to be properly constructed and have their fields capable of reading out.
Sub-system Testing
Many of the system runs primarily independently for this software, such as Match and Chat windows. Passing tests on each sub-system can guarantee functionality of the whole.
Field Testing
Because this software is a game, inviting actual testers will provide feedbacks on the controllability, latency, and other aspects.
Acceptance Testing
A Game is meant to be played, and an acceptable game means this game must worth playing.
3.2 Features not tested
Load Test: The stress test for server’s ability to handle internet traffic surge, unusually high volume, is not of important interest. This feature will not be tested.
Security Test: The ability to pass messages between server and client without a third party’s ability to understand the message, if intercepted, and the ability to detect tampering attempt to the message by the third party. The project size does not require security feature, so this feature will not be tested.
Server Reliability: server’s up and operational time will not be tested due to the human resource limitation and time constraint.
Session Timeout/Disconnect: SRS assumes an ideal internet environment. Timeout/disconnect is considered as actively going offline.
3.3 Environment Needs
This section describe the environmental requirement to operate this software.
Client:
· The environment must have internet connection.
· The environment must install Java running environment.
· Standard keyboard and mouse.
· Standard VGA display.
Server:
· The environment must have internet connection.
· The environment must install Java running environment.
· The server must have administrative privilege to open sockets to accept connection.

3.4 Suspension / Resumption Criteria
If a test somehow suspends before completion, then it will resume from step 1. If a test cannot be completed due to continuous application failure, it will be noted in the report.
4. Test Specification
4.1 Login
Login is a window that allows user to input his username and password, and sending them to server. Successful login should also redirect user to mainwindow.
Client side: Login components sends a packet packed using protocol.Login, and retrieves a packed packed using protocol.LoginResult and parse the results.
Server side: Server receives a Login packet and unpacks it verifying its credentials, and pack a LoginResult packet sending it back to client.
Automated tests focuses on Login and LoginResult protocol packing and unpacking process, credential verification and results parsing.
Automated Testing
Test Case ID
STS – 1

Test Name
TestLogin

Description
Ensures Login protocol functionality and results reflection.

Prerequisites
N/A

Test Environment
Server with Login implementation, protocol package

Test Strategy
Interface testing, subsystem testing

Automated Test Description
Test
Description
Expected Result

1
Incomplete fields
No packet sent, notification pops

2
Completed fields, incorrect credentials
Legitimate protocol, LoginResult shows failing

3
Completed fields, invalid inputs
No packet sent, notification pops

4
Completed fields, correct credentials
Legitimate protocol, LoginResult shows success

Manual Testing:
Test Case ID
STS – 2

Test Name
TestLoginWindow

Description
Ensures LoginWindow GUI functionality

Prerequisites
N/A

Test Environment
N/A

Test Strategy
Field testing

Manual Test Description
Test
Description
Expected Result

1
Window Resizing
All fields remains clear to view

2
Window Closing
Completely shuts down the program

4.2 MainWindow
Mainwindow is the main component that allows user to access different aspects of this game, such as view friend list, start a quickmatch, and edit his deck.
Client side: Retrieves message and battle requests from other players and display them, calls edit deck and quickmatch components, and send message and battle requests to others
Server side: Process retrieval and sending requests initiated from client.

Automated Testing
Test Case ID
STS – 3

Test Name
TestMessageRetrieve

Description
Ensures Message (also includes battle requests) and Retrieve protocol functionality and results reflection.

Prerequisites
N/A

Test Environment
Server with Message, User implementation, protocol package

Test Strategy
Interface testing, subsystem testing

Automated Test Description
Test
Description
Expected Result

1
Single Message Client Reflection
Message Displayed

2
Message Box Client Reflection
All Messages Displayed

3
Single Battle Request Client Reflection
Battle Request Displayed

4
Message Construction
Legitimate message is constructed using protocol

5
Battle Request Construction
Legitimate message is constructed using protocol

Manual Testing:
Test Case ID
STS – 4

Test Name
TestMainWindow

Description
Ensures MainWindow GUI functionality

Prerequisites
N/A

Test Environment
N/A

Test Strategy
Field testing

Manual Test Description
Test
Description
Expected Result

1
Window Resizing
All fields remains clear to view

2
Window Closing
Completely shuts down the program

3
QuickMatch Button
Loads quickmatch panel

4
View Friends Button
Loads friends panel

5
Deck Edit Button
Loads deck editing panel

4.3 Matchmaking
A component that can match players into games.
Client-side: Match info retrieval, and reflection.
Server-side: Respond to retrievals, and create match instances.
Automated Testing
Test Case ID
STS – 5

Test Name
TestMatchMaking

Description
Ensures protocol functionality and results reflection.

Prerequisites
N/A

Test Environment
Server with matchmaking implementation, protocol package

Test Strategy
Interface testing, subsystem testing

Automated Test Description
Test
Description
Expected Result

1
Match Info Reflection
Direct into a match, or keep waiting

2
Retrieval Construction
Legitimate retrieval packet

3
Acceptance and Rejection message construction
Legitimate confirmation packet

4.4 Gameplay
The actual match between two players.
Client side: Respond to player actions, record them and send to server. Also parse opponent’s actions and reflect them on board.
Server side: Respond to retrieval requests and record actions sent from client into a buffer.
Automated Testing
Test Case ID
STS – 6

Test Name
TestGameplay

Description
Ensures board functionality, card interactions, and protocol legitimacy.

Prerequisites
N/A

Test Environment
Server with Action, Match implementation, protocol package

Test Strategy
Interface testing, subsystem testing

Automated Test Description
Test
Description
Expected Result

1
Action construction
Legitimate action packet

2
Retrieval Construction
Legitimate retrieval packet

3
Retrieval Reflection
Opponent’s action reflected

4
Card interaction
Summon, Skill Activation can properly trigger

5
Pre-turn and aft-turn checks
Reflect mp regeneration and SP, VP generation and consumption

6
Victory checks
Can determine victory conditions

Manual Testing:
Test Case ID
STS – 7

Test Name
TestGameActions

Description
Ensures Match window can record players actions and send them to server.

Prerequisites
N/A

Test Environment
N/A

Test Strategy
Field testing

Manual Test Description
Test
Description
Expected Result

1
Window Resizing
All fields remains clear to view

2
End turn
An End turn action sent

3
Surrender and Window closing
An surrender action sent and closes the match

4
Summon and skill activation
Corresponding actions sent with options on targets

4.5 Deck Editing
Building a deck of user’s own.
Client side: adding and removing cards from the current deck.
Automated Testing
Test Case ID
STS – 8

Test Name
TestDeckEditing

Description
Ensures Deck Editing functionality

Prerequisites
N/A

Test Environment
N/A

Test Strategy
Interface testing, subsystem testing

Automated Test Description
Test
Description
Expected Result

1
Card addition when cards < 15 Card added 2 Card removal when that card > 0
Card removed

3
Card addition when cards = 15
Rejection

4
Card removal when that card = 0
Rejection

5
Leaving
Deck saved

5. REQUIREMENT TRACEABILITY
Use Case
System Test ID
Design Component

4.1 Login
STS-1:log in information process (Automated)
STS-2:login window event handling (Manual)
Login.java

4.2 MainWindow
STS-3: message processing, sending, and receiving(Automated)
STS-4: MainWindow event handling (Manual)
MainWindow.java

4.3Matchmaking
STS-5: match information response and process(Automated)
Game.java

4.4 Gameplay
STS-6: game play information process(Automated)
STS-7: player action process and window event handling (Manual)
MainWindow.java
Match.java
Card.java
Game.java

4.5 Deck Editing
STS-8: processes information generated from a player building a deck
MainWindow.java