1 of 22

1DV609 Test Generation

From Requirements and code

2 of 22

Testing Requirements

Requirements pyramid

3 of 22

Requirement Coverage & Pyramid

Example: User wants to get access to a restricted access. �User request access. System asks for credentials. User gives credentials. System verifies credentials and presents restricted access.

Alternative. User gives invalid credentials. System presents that the credentials are invalid.

4 of 22

Testing Requirements

Example: From Use-Case Scenarios

Find all scenarios? Path coverage!

5 of 22

Example

UC1 Authenticate user

Main scenario

  1. Starts when a user wants to authenticate.
  2. System asks for username, password, and if system should save the user credentials
  3. User provides username and password
  4. System authenticates the user and presents that authentication succeeded

Alternate Scenarios

3a. User wants the system to keep user credentials for easier login.

  • The system authenticates the user and presents that the authentication �succeeded and that the user credentials was saved.

4a. User could not be authenticated

  • System presents an error message
  • Step 2 in main scenario

1

2

3

4

3a

4a

6 of 22

Test traceability

Verify implementation

  • Fulfill requirements?
  • Did we get all functionality that was needed?
  • Testing focus

Change management

  • A requirement has changed
  • What functionality does this test exercise?

7 of 22

Requirement-Coverage

8 of 22

Testing Non Functional Requirements

Types of non-functional testing

http://en.wikipedia.org/wiki/Non-functional_testing

Examples: Compatibility testing, Compliance testing, performance testing, load testing, scalability testing, localization testing, security testing, usability testing, accessibility testing (WCAG).

Set realistic goals!

Many of these need specialized tools, manual processes.

9 of 22

Exempel

10 of 22

Load testing tools

11 of 22

What is the ideal test suite?

Coverage

Finds bugs if there are bugs

Automated to reduce painful regression

Easy to change when requirements change

Quick to develop, and can be used during development.

Minimal test suite that still gives us “enough” confidence.

Good enough for acceptance testing (customer “sign of” an iteration/sprint)

12 of 22

Assumptions are made to minimize work

We want these assumptions to be as informed as possible.

For example we only regression test modules that have changed...

13 of 22

Black box testing

Examine functionality from the outside without knowing anything of the internals.

Tests are generated from specification.

14 of 22

Equivalence Partitioning

Divide the input into equivalent disjoint subsets

https://en.wikipedia.org/wiki/Equivalence_partitioning

Example:

public void addUser(int age)�Divide into valid input and invalid input.�

For example age in [0,120]�“name” must be have length [1,100]

15 of 22

max

/**�* Returns the largest of three inputs�* All inputs must be positive numbers >= 0�* Throws exception on negative numbers�**/�int maxOfThree(int a, int b, int c) {...}

16 of 22

White(or. Glass) box testing

Testing with knowledge of code internal workings.

Behaviour

Ex. coverage.

Tests are generated from source code.

17 of 22

Equivalence Partitioning?

public synchronized String read() {

if (buffer.contains("\n")) {

int at = buffer.indexOf('\n');

String ret = buffer.substring(0, at+1);

buffer = buffer.substring(at+1);

return ret;

}

return "";

}

18 of 22

Multiple Partitions

Customers of age 18-65 gets loan if their salary exceeds 25K £ / year

public boolean getLoan(int age, int salary)

  1. Identify Input Domain
  2. Equivalence Partitioning into subsets
  3. Combine Equivalence Classes

19 of 22

public boolean getLoan(int age, int salary)

20 of 22

Boundary Value Analysis

Based on common mistakes by programmers...

  1. Partition input domain
  2. Identify boundaries for partitions
  3. Create test-cases on boundaries, eg. one on each side.

21 of 22

22 of 22

Overkill?