CS代写 SENG201

Software Engineering I SENG201

Lecture 14 – Software testing (part 2) March 22, 2022

Copyright By PowCoder代写 加微信 powcoder

Previous lecture
1. Overview
2. Types of testing
3. Black box testing and white box testing

1. How do identify test cases
2. Unit testing with JUnit

1. How do identify test cases
2. Unit testing with JUnit

Good test cases
• Bad practice
– Demonstration that program works on one input
– Demonstration that program works on a few random inputs
• Define test cases systematically
“Blue sky” scenarios Alternatives Errorcases
• Basic approaches
– Equivalence partitioning and boundary value analysis
– Decision tables

Equivalence partitioning – idea
• Tests should uncover different types of problems – Avoid testing same aspect of program again and again
• Test inputs and outputs partitioned into equivalence sets – Tests in same equivalence set should reveal same type of problem
All possible inputs
Long/short input
Small/big input
Zero/null input
Subsets of inputs

* @param month in 1 (Jan) to 12 (Dec)
* @param year after 1900
public int daysInMonth(int month, int year)
• Negative months and years (equivalence sets 1 and 2)
• Months and years too large (equivalence sets 3 and 4)
• 0 for months and years (equivalence sets 5 and 6)
• Reverse expected parameter order (equivalence set 7)

Another example
• Requirement for a board game
– “When player lands on “Go to jail”, player must pay $50 to get out of jail”
• Test requirement “Go to jail”
– Most important thing is whether player has $50 to get out of jail
• Two equivalence classes
Less than $50
$50 or more
• Choose test cases from each partition

Boundary value analysis (BVA)
• Boundaries of equivalence sets sources of frequent mistakes
– Focus on testing these boundaries
– Boundary value for SUT, e.g.,
• Minimum input value
• Maximum input value
Less than $50
$50 or more

Decision table testing
• Record complex business rules defined as
– Conditions, i.e. possible input conditions
– Actions, i.e., events that should be triggered
• Example (board game)
– If player A lands on property owned by player B, A must pay rent to B
– If A does not have enough money to pay B, A is out of the game
Conditions
A lands on B’s property
A has enough money to pay rent
A stays in game

What tests should we write?
* Returns the factorial of n */
public int factorial(int n) {
Negative numbers
Medium-sized positive numbers (~10) Large inputs (~100)

What tests should we write?
* Returns true if n is prime, false otherwise */
public boolean isPrime (int n) {
Negative numbers
Small primes (3, 5, etc.)
Small composite (8, 9, 15, etc.) Medium-sized / large primes (24907, etc.) Medium-sized / large composite (826359, etc.)

1. How do identify test cases
2. Unit testing with JUnit

Testing is tedious and expensive
• If tests must be run manually, they most likely won’t be run – Lessrigoroustesting
– Regression testing becomes impossible
• IDE’s support integration of testing with development activities – Supportwritingoftests,executionoftests
– Supportanalysisoftestresults,repetitionoftests
• Example testing framework: JUnit
– Automated unit testing framework for Java
• Plug-ins available for different IDE’s
• Automatically checks answers and test results
– JUnit clones exist for other languages and IDE’s, e.g., CppUnit, NUnit

Example – a class to simulate a stack

Create test case…

Create test case…

Create test case…

Note annotations and naming conventions:
• @BeforeAll(setUpBeforeClass()), etc.

@BeforeAll, @BeforeEach
• Optionally override setUp(), setUpBeforeClass()
– @BeforeEach: executed before each test (e.g., reset variables)
• Useful for repeated initialization (e.g., initialization for all shared objects)
– @BeforeAll: runs once before the entire test set
• When multiple tests need to share the same expensive setup code
• E.g., database setup
– Example: If test class has five tests
• @BeforeEach: executed five times; @BeforeAll: executed only once
• Similar idea for @AfterAll, @AfterEach
– Override tearDown(): run after each test case (close files, etc.)
– Override tearDownAfterClass(): run after all tests (close DB, etc.)

What happens…
• testMakeEmpty()
– Pushes two integers on the stack
– Empties the stack
– CallsassertEquals(0,testStack.size());
– Failureif
testStack.size() (i.e., the actual value) is not 0 (the expected value)
• More information about assertions and JUnit
– https://junit.org/junit5/docs/current/user-guide/
– https://junit.org/junit5/docs/current/api/overview-summary.html

assertEquals() in API

Typical assertions
• assertEquals: check that result matches the expected result • assertArrayEquals: check that an entire array matches
• assertNotNull: check that a reference is not null
• assertNull: check that a reference is null
• assertTrue: check that a condition is true
• assertFalse: check that a condition is false • fail: unconditionally fail

Run the test…
JUnit test classes do not require a main()
Test classes run in a special JUnit mode: results of test are reported via JUnit view

Use @BeforeEach

New test case

Test fails – why?

Fix bug in isEmpty()

Test passes

Test coverage
• Measures quality and comprehensiveness of tests
• Metrics like percentage of code executed when tests ran, e.g.,
– Codecoverage
• Path coverage
• Line coverage
• Class coverage
– See also requirements coverage, etc.
• Rule of thumb in practice
– Code coverage below 60 – 70%: poorly tested software
– Code coverage 85 – 90%: “good enough”
– Careful when interpreting test coverage – what does it mean?

• Ecl Code Coverage (Eclipse plugin) and JaCoCo – Recordstatements(instructions)executed
• Visual analysis in custom view
– Visualization in source code editor
• Helps refine tests

Right-click on class or method (then “Properties”)

Different coverage counters
https://www.jacoco.org/jacoco/trunk/doc/counters.html

Reflection on code coverage
https://testing.googleblog.com/2020/08/code-coverage-best-practices.html?m=1

1. How to identify test cases
2. Unit testing with JUnit

Cartoon of the day
Key lesson: Testing can be used to show the presence of bugs, but never to show their absence (Edsger Dijkstra).
Industry average: 10 bugs per 1,000 lines of code

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com