Reference no: EM13169287

Test Plan

Outline a test plan for a substantial real-life system of your choosing. Some possible examples:

• baggage handling system for a major airport
• software for in-car GPS navigation.

Describe how you would approach the design and testing process to ensure success and quality in the result.

Where are the risks? How are you going to address them?

Decompose the problem, think about where the greatest risks are, and how they can be managed first, and probably at a smaller scale, and then progressively assembled using Bottum Up design, Unit Testing and/or other appropriate methodologies, with the goal of proving (or disproving) the feasibility early and at least cost.
Also list (dot point form is fine) what you believe to be:

• The three most important types of tests;

• Three types of testing that you think to be much less important. Justify your reasons. Consider failure modes and their consequences, and by what method and to what extent it is possible to anticipate and prevent them through the software design and test process.

The assessable component for this week will be to write a test plan for either the 2048 program you have been writing, or the software project you intend to use for the pracs next term.

If you haven't read the notes for todays lecture, or watched the lecture, you will probably do well to do at least one of those, as today's lecture discussed a number of the elements that arise in testing and planning to test.

You will likely notice that they all offer contradictory instructions.

You will need to decide on your own methodology for this prac. Considering the material in these and other resources, and the product, i.e., software, you are trying to produce, reason about the kinds of testing that are necessary or appropriate.

You can just write dot points if you like.

Then start shaping that into a coherent plan as to how you intend to test the software.

You will want to be convincing me that your plan will adequately test all relevant aspects of the software with a view to the plan being defensible in the (expected to be highly unlikely) that a defect emerges after "delivery" of your program.

Create the test plan as a plain text or mark-down (.MD) document in the git repository where the program lives (you might need to fork and clone it if you haven't already done so).

Whitebox Testing

Whitebox text one of the following:

You will need to write 10 tests to obtain the checkpoint.

Whitebox tests concentrate on exercising as many code paths and lines of the source code as possible. This is in contrast to the Unit Tests you wrote as part of our Test Driven Design work earlier in the course.

Those tests were blackbox tests, i.e., written without reference to the source code (in that case the source code didn't even exist), and as such were Black Box tests.

Another difference is that Black Box tests are focused on the functionality and specification, rather than verifying correct behaviour of each line of code in the solution.

In other words, Black Box tests are functional, while White Box tests are structural.

There are number of ways you can attack White Box testing, some of which we discussed in the lectuer today. You might want to watch the recording of this week's lecture to get you thinking about these (especially since only a few of you were able to attend today's lecture).

A good guide is that every if or other branch or decision point in a function requires a test. For complex branch expressions you may need to decompose them to identify multiple tests to ensure all decision paths are exercised. For example, if two variables in the expression of an if statement can affect the result, then two tests will be needed (and possibly more).

If we have the statement:
if ((a>7)||(b<5))

Two tests will be needed, one with a>7 and one with b=5 to test the alternate path.

A further good guide is wherever there are boundary conditions, you should also test either side of the boundary condition. For the above example, this might mean the following tests:
a=6, b=10 a=7, b=10 a=8, b=10 b=4, a=1 b=5, a=1 b=6, a=1

This helps to pick up errors where the wrong relative expression has been used, or the logic in the expression suffers from some other flaw.
Of course, the tests should be written with regard to the expected correct behaviour of the function, not merely making sure the function does what the function does!

Where you have multiple branch points, you will end up with many variables or conditions to consider, and you may need to reason more deeply in order to work out which input values will exercise all possible lines and code paths.

This deep inspection of the source code is valuable in itself, and often turns up many bugs (for which you can then write tests that fail to hand back to the developer!). It can also help identify code that never gets run, or where various conditions are not properly accommodated.

These are just a few ideas of how you can go about white box testing.

 

 

 

Example: this a student example to get the idea. Develop entirely different version based on my game.

1. Introduction

This document provides the testing needed for the 2048 game. The main function of this program is to have a board of tiles, with numbers in them. When the board is tilted, these tiles move in the direction of the tile, merging into a larger number if two identical numbers collide. This test plan is split into a number of sections. Section 2 refers to all relevant testing conducted in this test plan. Section 3 specifies what needs to be tested, and the outcome of the test. Section 4 outlines what is not needed to be tested. Section 5 shows the documentation produced by the program and testing. Finally, section 6 shows what risks are involved in this testing, and what the testing is dependent on.

2. Test types to consider

• Unit testing
• White box testing
• Regression testing
• Blackbox testing
• Integration testing

3. What to test:

• Initialisation
  • Initial empty 4x4 board
  • Two 2's are placed
  • User is prompted for first move
• Input
  • Program accepts u,d,l,r, blank input
  • Program rejects all other input, with an error
• Tilting
  • Board tilts in the direction specified by the input
  • If two values next to each other are the same, they will merge into a single tile double the value
  • Unique tiles will not merge
  • A 2 or 4 will be randomly placed if the board is not full
• Full board
  • If the board cannot be tilted, game notify the user the game is over then quit
  • Else game will continue as normal
• Display
  • The game will output exactly what is calculated and stored
• End game
  • If there is a 2048 piece, game produces win message, prompting the user if they want to finish
• Scoring
  • Score is incremented by the number of a merged piece ## 4. What not to test:
• Input
  • Large number of input sent in a small space of time should function
• Compatibility
  • Program works perfectly with every single platform

5. Documentation produced:

• Software documentation
• Commits
• Test log

6. Risks and dependencies:

• Understanding of the 2048 game, and its rules
• Knowledge of C, the language of the program
• System with the ability to conduct test
• 2048 program to test on

Download:- Java.zip