Summary Software Testing & Verification Midterm (INFOB3STV)

STV Midterm
Unit testing 2

Graph-based Test Coverage 5

Black box testing 8
Partitioning based testing 8
Model Based Testing 9

White box testing 11
Data-flow based testing 11

Integration testing 13

Inter-class testing 14

Automated testing 16




1

,Unit testing
Testing Verifying the correctness of the program by inspecting a finite number of executions
- Pragmatic approach of verification (and have to accept that it is inherently incomplete)
- Example: determining triangle type
- TriangleType TriType(Float a, Float b, Float c) where a, b, and c are sides of a
triangle, returns the type of triangle that these three sides form
- A test could be Assert.AreEqual(Isosceles, TriType(4, 4, 1)), though
note that his only looks at the final result and not the intermediate steps
- Test/test-case: specification of a sequence of interactions along with the needed
parameters for the program, and the expected responded it should produce
- Oracle: specification of the expectation of the program’s responses

V-model
- Illustrates a typical scenario for testing levels and how they relate to software
development activities by isolating each step




- Acceptance testing is done by users/third party, the rest by developers

Unit Functions, methods, maybe even a class
- Different types of units may have different types of interactions, thus requiring different
approaches:
- Function behaviour depends only on its parameters, no side effects
- Procedure may also have side effects besides depending on its params
- Method may depend on and affect variables, possibly class variables
- Class is a collection of potentially interacting methods

Structure of test project
- A solution may contain multiple projects, including multiple test projects
- A test project is used to group related test classes
- A test class is used to group test methods
- A test method does the actual testing work, usually encoding a single test-case

Typical NUnit test class
[TestFixture]
class TriangleTest {



2

, [SetUp] // Will be run before every test
void Init() { ... }

[TearDown]
void Cleanup() { ... }

[Test]
void Test1_Triangle() { Assert.AreEqual(...) }
[Test]
void Test2_Triangle() { ... }
}


Test specification
- Usually, expected responses are determined by an existing specification, or a
specification that is elicited somehow
- Informal specification: expectation expressed in natural language
- “If a, b , c represent the sides of a triangle, Triangle() determines the type of the
triangle.”
- Formal specification: expectation expressed with boolean logic
- Pros: precise, can be turned into executable specifications, change to program
doesn’t require re-programming, allows generating test sequences/inputs
- Cons: capturing intended specification can be hard and adds additional work
- Consists of a pre-condition, method call and a post-condition
- For example, the above triangle example can be formalised to:




In-code specification
- A formal specification can be turned into code as follows (general form):
void MethodSpec(x) {
if (..pre-cond..) {
var retval = Method(x);

Assert.IsTrue(..post-cond..);
}
else // Check that method throws the expected exception when
the pre-condition is violated
Assert.Throws<expected exception>(() => Method(x));
}


3