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