Testers Exclusive

Invasive Testing of Java Classes

2009-07-14T20:11:00.003+05:30

Unit testing is an important element of testing software. In object-oriented software development, this term commonly refers to testing an individual class. The term integration testing denotes testing a group of classes, and the term system testing refers to testing the application as a whole. In the simplest and most widely followed testing practice, developers of classes are expected to perform unit and integration testing of their respective classes before releasing their library to other groups. The test team is responsible for system testing before releasing the application to clients.

There is on-going research in the area of testing object-oriented software, and a lot more needs to be done. Since class testing is the starting point of testing object-oriented software, understanding the issues involved and devising a way to perform effective class testing is a crucial first step in delivering high quality software. At Man Machine Systems, we have developed a new model for testing Java classes, called invasive testing. We believe this model can make class testing more interesting and effective. Testing is typically characterized as a destructive process, so the term effective suggests that the tester* must be able to uncover a maximum number of bugs with a minimum of effort. In this article, we describe our model with examples and compare it with conventional unit testing techniques.

Invasive and Intrusive Testing of a Class

We define invasive testing as a technique that uses the normally inaccessible elements of a class to increase the effectiveness of testing. When the class under test is modified to

Support testing, we call this intrusive testing.

If a class C comprises a set M of methods that belong in the class interface, intrusive testing typically assumes the existence of N additional methods and modifications to some or all of the M methods to aid testing. The additional N methods are not intended to be used by normal clients of the class (and are not part of the published class interface), but are defined purely to support testing. If methods in sets M or N access private members of the class, then the technique is invasive as well. Plain invasive testing does not modify the class under test, but would use private details of the class that normal users cannot access.

Let us first review conventional class testing strategies before investigating invasive testing.

Conventional Class Testing Strategies

1. Tester as client, version - 1 (non-invasive, non-intrusive):

This is the most common strategy for testing classes. The tester writes a driver in the same language as the class under test, and exercises the published methods of the class, following a set of test criteria, such as coverage. Since the driver code resides in a different class than the tested one, accessibility rules defined in the language apply. Consider the stack implementation MyStack shown in Figure 1 as an example of a Java class to be tested.

class MyStack

{

private Object[] elems;

private int top, max;

public MyStack(int sz)

{

max = sz;

elems = new Object[sz];

}

public void push(Object obj) throws Exception

{

if( top <>

elems[top++] = obj;

else throw new Exception("Stack overflow");

}

public Object pop() throws Exception

{

if( top > 0 )

return elems[--top];

throw new Exception("Stack underflow");

}

public boolean isFull()

{

return top == max;

}

public boolean isEmpty()

{

return top == 0;

}

Figure 1: MyStack Class

The test driver shown in Figure 2 tests the above stack class.

class StackTester

{

public static void main(String[] args)

{

MyStack s1 = new MyStack (10); // Max of 10 elements

if( !s1.isEmpty() )

Test.error(“Stack is not empty initially!”);

StackTester obj1 = new StackTester(); // An object to stack

s1.push(obj1);

if( s1.isEmpty() )

Test.error(“Stack is empty after a push!”);

StackTester obj2 = (StackTester) s1.pop();

if( obj1 != obj2 )

Test.error(“Problem in push()/pop()!”); // ----- (A)

// ... Other code

}

Figure 2: A Typical Driver to Test the MyStack class

We assume the existence of test support routines such as Test.error(String). The test driver is written to test invocations of MyStack’s public methods in some combination.

Benefits

1) The technique is intuitive since it simulates actual usage of the class under test.

2) The class tested is the class actually released to customer since no modification is performed to the class for testing purposes.

Limitations

1) Since the tester has to exercise public methods in the class interface, certain methods can only be tested in combinations, not individually. For example, the push (or pop) method cannot be tested in isolation. As a result, if the push/pop combination fails, it could be due to a bug in either or both the methods and additional tests may be needed before the actual bug may be isolated. Even if the push/pop combination matches, there is no guarantee that they are both correct; it is conceivable that both have bugs that coincidentally produce the correct behavior. Once again, additional combinations will have to be tried.

2) It is not always possible to exercise all parts of the implementation adequately by invoking public methods alone.

3) There is no way to test interfaces either.

2. Tester as client, version – 2 (non-invasive, intrusive):

In this scenario, the class to be tested is modified to support testing. Accessible getter and setter methods are added for all state variables that are otherwise inaccessible.

Alternatively, all elements of the class are made public to grant unrestricted access. This permits the tester to overcome the limitations of approach (1) above. The MyStack class of Figure 1, according to this strategy, might be modified as depicted in Figure 3:

class MyStack

{

// Private elements are public – FOR TESTING ONLY

public Object[] elems;

// Private elements are public – FOR TESTING ONLY

public int top, max;

public MyStack(int sz)

{

max = sz;

elems = new Object[sz];

}

public void push(Object obj) throws Exception

{

if( top <>

elems[top++] = obj;

else throw new Exception("Stack overflow");

}

public Object pop() throws Exception

{

if( top > 0 )

return elems[--top];

throw new Exception("Stack underflow");

}

public boolean isFull()

{

return top == max;

}

public boolean isEmpty()

{

return top == 0;

}

Figure 3: Modified MyStack Class

The test driver is now rewritten to take advantage of private details of the class to perform more effective testing. Figure 4 shows how this can be done.

class StackTester

{

public static void main(String[] args)

{

MyStack s1 = new MyStack (10); // Max of 10 elements

if( !s1.isEmpty() )

Test.error( “Stack is not empty initially!”);

StackTester obj1 = new StackTester(); // An object to stack

s1.push(obj1);

Test.assert( (s1.top == 1) && (s1.elems[s1.top-1] == obj1),

“Push failed!”);

StackTester obj2 = (StackTester) s1.pop();

Test.assert( (s1.top == 0) && (obj2 == obj1), “Pop failed!”);

// ... Other code

}

Figure 4: Stack Tester Driver

Benefits

The semantics of individual methods can be verified. This can reduce the test effort, since the number of methods is much less than the number of method combinations.

Limitations

1) The class tested is different than the one released to a client.

2) The tester needs to understand the class implementation details, in addition to its interface. For complex classes, this could be quite difficult.

3) If the class implementation changes in future, the driver code will have to be appropriately modified.

4) The source code for the class is required.

3. Automatically instrumenting the code with assertions (invasive, intrusive):

This is a very promising approach for testing object-oriented software. In this case, the developer embeds assertions (class invariant, method pre- and post conditions) inside comments in the source code. A preprocessor parses these assertions and emits the modified source where the assertions have been appropriately moved to method bodies. The preprocessed code is compiled using a standard Java compiler. The resulting application is then run as if it were the original program. Any violation of contracts will be reported by the assertions layer. Figure 5 below gives an example of how assertions might be specified.

/**

* @inv (top >= 0) && (top <>

class MyStack

{

private Object[] elems;

private int top, max;

/**

* @post (max == sz) && (top == 0)

public MyStack(int sz)

{

max = sz;

elems = new Object[sz];

}

/**

* @pre top <>

* @post (top == top$prev + 1) && (elems[top-1] == obj)

public void push(Object obj) throws Exception

{

if( top <>

elems[top++] = obj;

else throw new Exception("Stack overflow");

}

/**

public Object pop() throws Exception

{

if( top > 0 )

return elems[--top];

throw new Exception("Stack underflow");

}

public boolean isFull()

{

return top == max;

}

public boolean isEmpty()

{

return top == 0;

}

Figure 5: MyStack Class with Assertions

The assertion language depends on the tool used; currently there is no standard. The example above uses a syntax supported by our tool JMSAssertTM that generates a

JMScriptTM test script file (discussed later). Reto Cramer’s iContract is another interesting tool in the public domain that supports assertions in Java classes 1.

Benefits

1) Reasonably complex class invariants, pre- and post conditions may be specified.

2) Since the assertions are defined as part of class/method comments, the source can be recompiled to get uninstrumented classes.

3) This approach assists in testing the complete application.

Limitations

1) The class tested is different than the one released to a client.

2) Source code has to be available to instrument with assertions.

3) The assertion language is proprietary, so moving to another preprocessing tool is difficult.

4) To test classes individually (not as a sealed off application), a test driver still has to be written.

5) Individual methods cannot be tested because of access restrictions.

4. Tester is the developer (invasive, intrusive):

In this case, the test driver resides within the class being tested. Typically, this is the main method or a test method that is static. When it is invoked, the test logic is exercised. Since the method is part of the class, access restrictions do not apply; all elements of the class can be accessed.

class MyStack {

// ... Insert stack related elements here.

// ...

// This is the stack test driver. It is part of the class

// itself.

public static void main(String[] args) {

MyStack s1 = new MyStack (10); // Max of 10 elements

if( !s1.isEmpty() )

Test.error( “Stack is not empty initially!”);

MyStack obj1 = new MyStack (); // An object to stack

s1.push(obj1);

Test.assert( (s1.top == 1) && (s1.elems[s1.top-1] == obj1),

“Push failed!”);

MyStack obj2 = (MyStack) s1.pop();

Test.assert( (s1.top == 0) && (obj2 == obj1), “Pop failed!”);

// ... Other code

}

Figure 6: Test Driver in MyStack

Benefits

1) There is no need to convert private elements to public for the sake of testing.

2) The test driver for the class is self-contained, so the driver is more likely to be in sync with the class.

Limitations

1) The test driver cannot be reused when the class evolves. For each version of the class, corresponding version of the driver inside the class (perhaps copying and pasting from previous version) must be developed. To facilitate regression testing, it is better to have the driver separated from the class.

2) The source code has to be available.

3) When the class is delivered to a client, the test driver constitutes excess baggage.

However, if the driver is removed from the code, then two version of the class have to be maintained, one with the driver and another without the driver.

Invasive Testing

It is a widely acknowledged fact that testing object-oriented software is more difficult than testing nonobject-oriented software. Payne et. al.2 point out that “from the value of testing perspective, information hiding reduces the ability for faults to propagate to an observable output and hence reduces the likelihood that faults will be revealed during testing”.

The invasive model that is proposed allows the tester to tunnel through the information hiding barrier and write a driver that accesses the normally inaccessible elements of a class.

This can occur without making changes to the class source. In fact, the approach does not require Java source code to be available for testing purposes. To assist in achieving this, a scripting language has been developed, called JMScript™ that is layered on Java. The language allows a tester to write a script that instantiates Java objects and send messages to them. This is very similar to what happens in the Java language itself. Like many other scripting languages, it is weakly and dynamically typed. These types are associated with values of objects and not with variables. Once a Java object is instantiated in the script, any element of the object, be it private or protected, can be accessed without restriction.

The following JMScript driver illustrates one way of testing the MyStack class.

// MyStackTest.jms

main() {

// Stack size

sz = 1;

// Create a stack instance.

s = new MyStack(sz);

assert(s.top == 0 && s.max == sz);

println("Stack instantiation is OK");

// Push just one object - a stack object

obj1 = new MyStack(1);

s.push(obj1);

assert(s.top == 1 && s.elems[s.top-1] == obj1);

println("Stack.push works OK");

// Pop and check

obj2 = s.pop();

assert(s.top == 0 && obj2 == obj1);

println("Stack.pop works OK");

// Another pop - must result in underflow exception

try {

s.pop();

println("Empty pop fails to throw exception!");

}

catch(Exception e) {

println("Empty pop throws exception as expected");

}

// Simulate stack full condition

s.top = s.max;

// Push, now, must result in overflow exception

try {

s.push(obj1);

println("Push on full fails to throw exception!");

}

catch(Exception e) {

println("Push on full throws exception as expected");

}

// Similarly, test other methods individually

// ...

println("*** Stack test completed - relax now!!");

}

Figure 7 Testing MyStack Using JMScript

The script can be executed by running the command line version of the interpreter (or the more sophisticated JVerify™ environment can be used, that includes the interpreter and much more).

The script accesses even the private elements of a class, bypassing Java’s access control mechanism. Notice how assertions are used after every method call to check the postcondition.

However, explicitly checking the post-conditions can litter the script with too many assertions. There is a more convenient way to do this, as shown in the following test script.

// MyStackTest2.jms

main() {

sz = 1;

// Create a stack instance.

s = new MyStack(sz);

s.push( new Object() );

// ... Other code not shown

}

// Class invariant trigger

invariant(meth, s){

trace("meth=>" + meth);

assert(s.top >= 0 && s.top <= s.max &&

s.elems != null);

trace("Invariant checked inside:" + (meth.equals("") ?

"Constructor": meth));

}

// Automatically called by the interpreter on exit from

// Stack constructor.

postCtor(method, s, sz) {

assert(s.top == 0 && s.max == sz && s.elems != null);

trace("postCtor called");

}

prePush(meth, s, obj) {

assert( s.isFull() == false && obj != null );

trace("prePush called");

}

// This is the static block – meant for one-time execution

static {

// Denote assertion functions

asserts =

{{"","INVARIANT", "MyStackTest2.invariant"},

{"(I)V", "POSTCONDITION", "MyStackTest2.postCtor"},

{"push(Ljava/lang/Object;)V", "PRECONDITION",

"MyStackTest2.prePush"}

};

// Install assertion functions

setClassTrigger("MyStack", asserts);

}

Figure 8 JMScript Using Assertions

This example illustrates that a tester can identify an invariant for a class, a set of pre- and post conditions for methods and register those with the interpreter. When a method is invoked from the test script, the corresponding precondition, postcondition and invariant routines are automatically and appropriately executed by the interpreter. The sequence followed by the interpreter is:

§ Check class invariant

§ Check precondition for the method

§ Invoke method

§ Check Post condition for the method

§ Check class invariant

There are exceptions to this rule, but that is beyond the scope of this article.

It is possible to do better than setting up triggers manually as outlined above. If the class source is available and assertions are embedded in comments as shown in Figure 5, another utility called JMSAssertTM will parse these and automatically generate a script file containing appropriate triggers.

Table 1 gives a comparison of the different techniques considered so far.

Technique Invasive Intrusive

Source

Code

Needed

1) Tester as a client, version 1 No No No

2) Tester as a client, version 2 No Yes Yes

3) Automatic instrumentation with assertions Yes Yes Yes

4) Tester as a developer Yes Yes Yes

5) Invasive testing Yes No No

Table 1. Comparing the Techniques

Testing State Machines

The invasive model provides a convenient approach to testing state machines. In general, testing a state machine tends to be fairly involved because of the potentially infinite

Start

'C'

'A'

'D'

'B'

'H'

'F'

'G' 'J'

'K'

'I'

'E'

Final

Figure 9: State Machine

number of states possible. The ability to access private details could considerably reduce the effort (the downside is that intimate knowledge of the class may be required).

Consider the state machine shown in Figure 9. The corresponding Java source is given in

Figure 10 (to emphasize clarity, several optimizations have been left out).

public class FSM {

private FSMState start, one, two, three, four;

private FSMState current;

public FSM() {

one = new FSMStateOne();

two = new FSMStateTwo();

start = new FSMStateStart();

three = new FSMStateThree();

four = new FSMStateFour();

reset();

}

public void reset() {

current = start;

}

public void transition(char c) {

if(current != null)

current = current.transition(c);

}

public final boolean done() {

return (current != null) && current.isFinal();

}

private static abstract class FSMState {

abstract FSMState transition(char c);

boolean isFinal() {

return false;

}

private class FSMStateStart extends FSMState {

FSMState transition(char c) {

switch (c) {

case 'A':

case 'C': return one;

case 'D': return two;

default: return null;

}

private class FSMStateOne extends FSMState {

FSMState transition(char c) {

switch (c) {

case 'B': return this;

case 'F': return three;

default: return null;

}

private class FSMStateTwo extends FSMState {

FSMState transition(char c) {

switch (c) {

case 'E': return this;

case 'G': return three;

case 'I': return four;

default: return null;

}

private class FSMStateThree extends FSMState {

FSMState transition(char c) {

switch (c) {

case 'H': return two;

case 'J': return four;

default: return null;

}

private class FSMStateFour extends FSMState {

boolean isFinal() {

return true;

}

FSMState transition(char c) {

switch (c) {

case 'K': return this;

default: return null;

}

Figure 10. A State Machine in Java

How can we prove that the Java program of Figure 10 accepts all the strings as per the state machine specification of Figure 9? Clearly, testing with all strings is impossible. Here is how the state machine can be tested using JMScript:

// Testing the FSM involves testing each state transition.

// This requires migrating the FSM to the appropriate state

// and then invoking the transition function.

// File: fsmtest.jms

main() {

createFSM();

checkStateStart();

checkStateOne();

checkStateTwo();

checkStateThree();

checkStateFour();

System.out.println("*** FSM Testing Done!! ***");

}

createFSM() {

this.fsm = new FSM();

assertState("start");

}

checkStateStart() {

setState("start"); // Start at “start”

transition('A');

assertState("one"); // Must be in “one”

setState("start"); // Reset to “start”

transition('C');

assertState("one"); // Must be in “one”

setState("start"); // Reset to “start”

transition('D');

assertState("two"); // Must be in “two”

}

checkStateOne() {

setState("one");

transition('B');

assertState("one");

setState("one");

transition('F');

assertState("three");

}

checkStateTwo() {

setState("two");

transition('E');

assertState("two");

setState("two");

transition('G');

assertState("three");

setState("two");

transition('I');

assertState("four");

}

checkStateThree() {

setState("three");

transition('J');

assertState("four");

setState("three");

transition('H');

assertState("two");

}

checkStateFour() {

setState("four");

transition('K');

assertState("four");

}

// Utility routines

assertState(state) {

if (this.fsm.current != getField(this.fsm, state))

throw new Exception("Bad FSM State!");

}

setState(state) {

this.fsm.current = getField(this.fsm, state);

}

transition(ch) {

this.fsm.transition(ch);

}

exceptionHandler(meth, excp) {

if(meth != "assertState") {

println("Exception: " + excp + " occurred in: " + meth);

}

Figure 11. Testing FSM Using JMScript

The basis for the testing strategy used above, is to drive the state machine to each intermediate state not allowed normally, and then to ensure that when an input is received, it transitions correctly to the next state.

Benefits

1) The class under test is not modified to support testing. The class tested is the same as the class released to a client.

2) Source code for the class does not need to be available. (This means it is possible to test third party libraries.)

3) The test driver accesses implementation details, if necessary, to test individual methods, not combinations. This can minimize testing effort.

4) Class invariant, method pre- and post conditions can be complex in real situations. The support for such arbitrarily complex conditions is taken care of by providing procedures

in JMScript.

5) Since the test driver is separate from the class being tested, reuse of the test cases is possible throughout regression testing.

Limitations

1) The test script is written in a language different than Java. This means learning a new language.

2) Assertions are checked only for Java methods executed directly from JMScript. If a

Java method m1 internally calls another method m2, automatic checking of invariant, pre- and post conditions is performed for m2.

3) This is ideally suited to perform unit testing of individual classes and integration testing of small groups of classes, but not for system testing.

4) This relies heavily on the commitment of the development environment to the usage of

Design by ContractTM.

JVerify™ Test Environment

To create, execute and test JMScript scripts, we have developed JVerify, a GUI-based WindowsTM application. The environment supports a debugger that allows setting breakpoints, and examining the execution snapshot through an object browser, and call stack. Another salient feature of the environment is the facility to understand a class' interface from its .class file. This can be quite useful when the source for the class under test is not available.

Conclusion

Testing object-oriented software is more difficult because of information hiding. Invasive testing, proposed in this article, makes a tester “all powerful” by allowing access to private details of the class under test. This model renders a class more amenable to testing (even if it has not been designed for testability). This model is also particularly useful for testing state machines. A scripting language called JMScript, layered on Java, has been designed to support class invasion in the context of Java programs. More information about the language and associated tools is available at www.mmsindia.com.

This was published by K.Rangaraajan, Man Machine Systems. Thanks to the author.

Quotes on Testers

2009-07-14T18:45:00.000+05:30

· I have to start testing. After all, I need some sleep.

· A bug is what a tester gets when he gets tired of thinking.

· For every developer, there is an equal and opposite tester.

· To tell somebody that he is wrong is called criticism; to do so officially is called testing.

· You never really learn to swear until you begin a testing career.

· 90% of the people in the world are below average. The rest are testers.

· If at first you don't succeed, put it out for beta test.

· Crime doesn't pay... does that mean testing is a crime?

· Sign on testers’ doors: Do not disturb. Already disturbed!

· Testers who seek to be equal to developers lack ambition.

· Testing is like news. Same shit; different day.

· Testers are free of prejudice. They hate everyone equally Testers take a lot of pain to test. They also pass it on to others.

· Testers and developers: they make an extraordinary team. One is extra and the other ordinary

· Definition of a tester: A sophistical rhetorician, inebriated with the exuberance of his own verbosity, and gifted with an egotistical imagination that can at all times command an interminable and inconsistent series of arguments to malign an opponent and to glorify himself.

· Every tester has basically one joke. And he’s it.

· How many testers does it need to change a light bulb? None. It is the developers who do the dirty work. Testers will just point out whether it is screwed up or not.

· "If debugging is the process of removing software bugs, then programming must be the process of putting them in."

· Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code."

· You start coding. I'll go find out what they want." — Computer analyst to programmer

· 3 Biggest Software Lies:

• The program's fully tested and bug-free.

• We're working on the documentation.

• Of course we can modify it."

ISTQB Sample Question Paper

2009-07-13T18:14:00.003+05:30

1 When what is visible to end-users is a deviation from the specific or expected behavior, this is called:
a) an error
b) a fault
c) a failure
d) a defect
e) a mistake

2 Regression testing should be performed:
v) every week
w) after the software has changed
x) as often as possible
y) when the environment has changed
z) when the project manager says

a) v & w are true, x – z are false
b) w, x & y are true, v & z are false
c) w & y are true, v, x & z are false
d) w is true, v, x y and z are false
e) all of the above are true

3 IEEE 829 test plan documentation standard contains all of the following except:
a) test items
b) test deliverables
c) test tasks
d) test environment
e) test specification

4 Testing should be stopped when:
a) all the planned tests have been run
b) time has run out
c) all faults have been fixed correctly
d) both a) and c)
e) it depends on the risks for the system being tested

5 Order numbers on a stock control system can range between 10000 and 99999 inclusive. Which of the following inputs might be a result of designing tests for only valid equivalence classes and valid boundaries:
a) 1000, 5000, 99999
b) 9999, 50000, 100000
c) 10000, 50000, 99999
d) 10000, 99999
e) 9999, 10000, 50000, 99999, 10000

6 Consider the following statements about early test design:
i. early test design can prevent fault multiplication
ii. faults found during early test design are more expensive to fix
iii. early test design can find faults
iv. early test design can cause changes to the requirements
v. early test design takes more effort

a) i, iii & iv are true. Ii & v are false
b) iii is true, I, ii, iv & v are false
c) iii & iv are true. i, ii & v are false
d) i, iii, iv & v are true, ii us false
e) i & iii are true, ii, iv & v are false

7 Non-functional system testing includes:
a) testing to see where the system does not function properly
b) testing quality attributes of the system including performance and usability
c) testing a system feature using only the software required for that action
d) testing a system feature using only the software required for that function
e) testing for functions that should not exist

8 Which of the following is NOT part of configuration management:
a) status accounting of configuration items
b) auditing conformance to ISO9001
c) identification of test versions
d) record of changes to documentation over time
e) controlled library access

9 Which of the following is the main purpose of the integration strategy for integration testing in the small?
a) to ensure that all of the small modules are tested adequately
b) to ensure that the system interfaces to other systems and networks
c) to specify which modules to combine when and how many at once
d) to ensure that the integration testing can be performed by a small team
e) to specify how the software should be divided into modules

10 What is the purpose of test completion criteria in a test plan:
a) to know when a specific test has finished its execution
b) to ensure that the test case specification is complete
c) to set the criteria used in generating test inputs
d) to know when test planning is complete
e) to plan when to stop testing

11 Consider the following statements
i. an incident may be closed without being fixed
ii. incidents may not be raised against documentation
iii. the final stage of incident tracking is fixing
iv. the incident record does not include information on test environments
v. incidents should be raised when someone other than the author of the software performs the test

a) ii and v are true, I, iii and iv are false
b) i and v are true, ii, iii and iv are false
c) i, iv and v are true, ii and iii are false
d) i and ii are true, iii, iv and v are false
e) i is true, ii, iii, iv and v are false

12 Given the following code, which is true about the minimum number of test cases required for full statement and branch coverage:
Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF

a) 1 test for statement coverage, 3 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage
c) 1 test for statement coverage, 1 for branch coverage
d) 2 tests for statement coverage, 3 for branch coverage
e) 2 tests for statement coverage, 2 for branch coverage

13 Given the following:
Switch PC on
Start “outlook”
IF outlook appears THEN
Send an email
Close outlook

a) 1 test for statement coverage, 1 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage
c) 1 test for statement coverage. 3 for branch coverage
d) 2 tests for statement coverage, 2 for branch coverage
e) 2 tests for statement coverage, 3 for branch coverage

14 Given the following code, which is true:
IF A > B THEN
C = A – B
ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF

a) 1 test for statement coverage, 3 for branch coverage
b) 2 tests for statement coverage, 2 for branch coverage
c) 2 tests for statement coverage. 3 for branch coverage
d) 3 tests for statement coverage, 3 for branch coverage
e) 3 tests for statement coverage, 2 for branch coverage

15 Consider the following:
Pick up and read the newspaper
Look at what is on television
If there is a program that you are interested in watching then switch the the television on and watch the program
Otherwise
Continue reading the newspaper
If there is a crossword in the newspaper then try and complete the crossword

a) SC = 1 and DC = 1
b) SC = 1 and DC = 2
c) SC = 1 and DC = 3
d) SC = 2 and DC = 2
e) SC = 2 and DC = 3

16 The place to start if you want a (new) test tool is:
a) Attend a tool exhibition
b) Invite a vendor to give a demo
c) Analyse your needs and requirements
d) Find out what your budget would be for the tool
e) Search the internet

17 When a new testing tool is purchased, it should be used first by:
a) A small team to establish the best way to use the tool
b) Everyone who may eventually have some use for the tool
c) The independent testing team
d) The managers to see what projects it should be used in
e) The vendor contractor to write the initial scripts

18 What can static analysis NOT find?
a) The use of a variable before it has been defined
b) Unreachable (“dead”) code
c) Whether the value stored in a variable is correct
d) The re-definition of a variable before it has been used
e) Array bound violations

19 Which of the following is NOT a black box technique:
a) Equivalence partitioning
b) State transition testing
c) LCSAJ
d) Syntax testing
e) Boundary value analysis

20 Beta testing is:
a) Performed by customers at their own site
b) Performed by customers at their software developer’s site
c) Performed by an independent test team
d) Useful to test bespoke software
e) Performed as early as possible in the lifecycle

21 Given the following types of tool, which tools would typically be used by developers and which by an independent test team:
i. static analysis
ii. performance testing
iii. test management
iv. dynamic analysis
v. test running
vi. test data preparation

a) developers would typically use i, iv and vi; test team ii, iii and v
b) developers would typically use i and iv; test team ii, iii, v and vi
c) developers would typically use i, ii, iii and iv; test team v and vi
d) developers would typically use ii, iv and vi; test team I, ii and v
e) developers would typically use i, iii, iv and v; test team ii and vi

22 The main focus of acceptance testing is:
a) finding faults in the system
b) ensuring that the system is acceptable to all users
c) testing the system with other systems
d) testing for a business perspective
e) testing by an independent test team

23 Which of the following statements about the component testing standard is false:
a) black box design techniques all have an associated measurement technique
b) white box design techniques all have an associated measurement technique
c) cyclomatic complexity is not a test measurement technique
d) black box measurement techniques all have an associated test design technique
e) white box measurement techniques all have an associated test design technique

24 Which of the following statements is NOT true:
a) inspection is the most formal review process
b) inspections should be led by a trained leader
c) managers can perform inspections on management documents
d) inspection is appropriate even when there are no written documents
e) inspection compares documents with predecessor (source) documents

25 A typical commercial test execution tool would be able to perform all of the following EXCEPT:
a) generating expected outputs
b) replaying inputs according to a programmed script
c) comparison of expected outcomes with actual outcomes
d) recording test inputs
e) reading test values from a data file

26 The difference between re-testing and regression testing is
a) re-testing is running a test again; regression testing looks for unexpected side effects
b) re-testing looks for unexpected side effects; regression testing is repeating those tests
c) re-testing is done after faults are fixed; regression testing is done earlier
d) re-testing uses different environments, regression testing uses the same environment
e) re-testing is done by developers, regression testing is done by independent testers

27 Expected results are:
a) only important in system testing
b) only used in component testing
c) never specified in advance
d) most useful when specified in advance
e) derived from the code

28 Test managers should not:
a) report on deviations from the project plan
b) sign the system off for release
c) re-allocate resource to meet original plans
d) raise incidents on faults that they have found
e) provide information for risk analysis and quality improvement

29 Unreachable code would best be found using:
a) code reviews
b) code inspections
c) a coverage tool
d) a test management tool
e) a static analysis tool

30 A tool that supports traceability, recording of incidents or scheduling of tests is called:
a) a dynamic analysis tool
b) a test execution tool
c) a debugging tool
d) a test management tool
e) a configuration management tool

31 What information need not be included in a test incident report:
a) how to fix the fault
b) how to reproduce the fault
c) test environment details
d) severity, priority
e) the actual and expected outcomes

32 Which expression best matches the following characteristics or review processes:
1. led by author
2. undocumented
3. no management participation
4. led by a trained moderator or leader
5. uses entry exit criteria

s) inspection
t) peer review
u) informal review
v) walkthrough

a) s = 4, t = 3, u = 2 and 5, v = 1
b) s = 4 and 5, t = 3, u = 2, v = 1
c) s = 1 and 5, t = 3, u = 2, v = 4
d) s = 5, t = 4, u = 3, v = 1 and 2
e) s = 4 and 5, t = 1, u = 2, v = 3

33 Which of the following is NOT part of system testing:
a) business process-based testing
b) performance, load and stress testing
c) requirements-based testing
d) usability testing
e) top-down integration testing

34 What statement about expected outcomes is FALSE:
a) expected outcomes are defined by the software’s behaviour
b) expected outcomes are derived from a specification, not from the code
c) expected outcomes include outputs to a screen and changes to files and databases
d) expected outcomes should be predicted before a test is run
e) expected outcomes may include timing constraints such as response times

35 The standard that gives definitions of testing terms is:
a) ISO/IEC 12207
b) BS7925-1
c) BS7925-2
d) ANSI/IEEE 829
e) ANSI/IEEE 729

36 The cost of fixing a fault:
a) Is not important
b) Increases as we move the product towards live use
c) Decreases as we move the product towards live use
d) Is more expensive if found in requirements than functional design
e) Can never be determined

37 Which of the following is NOT included in the Test Plan document of the Test Documentation Standard:
a) Test items (i.e. software versions)
b) What is not to be tested
c) Test environments
d) Quality plans
e) Schedules and deadlines

38 Could reviews or inspections be considered part of testing:
a) No, because they apply to development documentation
b) No, because they are normally applied before testing
c) No, because they do not apply to the test documentation
d) Yes, because both help detect faults and improve quality
e) Yes, because testing includes all non-constructive activities

39 Which of the following is not part of performance testing:
a) Measuring response time
b) Measuring transaction rates
c) Recovery testing
d) Simulating many users
e) Generating many transactions

40 Error guessing is best used
a) As the first approach to deriving test cases
b) After more formal techniques have been applied
c) By inexperienced testers
d) After the system has gone live
e) Only by end users

Click here for more sample papers

Please comment here if you want answers and I’ll send them to your email address

If you have any doubts on any topic/question or required more material like: ISTQB Sample Question Papers, Tutorials, Presentations, E-Books, Study Sessions etc. on ISTQB Certification, please add a comment with your requirements I will surely reply you shortly.

How to write a good test case

2007-08-29T17:07:00.001+05:30

Some of the tips for writing good test cases:

1. First, understand the requirement clearly

2. Do required home work for the testability of the requirement

3. Classify the type of requirement(GUI,Functional,Database..)

4. Gather maximum information related and affected areas with this requirement

5. In Details/Prerequisites/Assumptions section write this information(if you are using TD) which will be more useful for other testers

6. Use very simple English and general words in writing the description.(please don't show you english talent here).All test steps should be at low level.

7. Provide test data whenever required(in fact, this is the major factor in mission critical applications).

8. Write detailed database Queries wherever required(it will save time while executing.)

9. Write clear Expected Result.