CS 213 SOFTWARE METHODOLOGY
LILY CHANG ASSOCIATE TEACHING PROFESSOR DEPARTMENT OF COMPUTER SCIENCE RUTGERS UNIVERSITY – NEW BRUNSWICK FALL 2021
Overview of Software Testing
Copyright By PowCoder代写 加微信 powcoder
Cost of Software Failure
• F-16:crossingequatorusingautopilot
• Result:planeflippedover
• Reason?Reuseofautopilotsoftware
• TheTherac-25accidents(1985-1987),(atleastfivedieddueto overdoses of radiation)
• Reason:BadeventhandlingintheGUIprogram
• NASAMarsClimateOrbiterdestroyedduetoincorrectorbit
insertion (September 23, 1999)
• Reason:Unitconversionproblem
•Boeing MAX 737 – lost hundreds of human lives Reason: software bugs
•Volvo recalled 59,000 cars over software fault that can temporarily shut down the engine
• Reason: software bugs
Terminology
• Reliability – the probability that a software system WILL NOT cause system failure for a specified time under specified conditions [IEEE Std. 982-1989]
• Failure – Any deviation of the observed behavior from the specified behavior
• Erroneous state (error) – the system is in a state such that further processing by the system can
lead to a failure
• Fault (or defect, or bug) – the mechanical or algorithmic cause of an error
• Testing – systematic attempt to find faults in a planned way in the implemented software
Fault Handling Techniques
Fault Handling
Fault Avoidance
Fault Detection
Fault Tolerance
Methodoloy
Configuration Management
Atomic Transactions
Modular Redundancy
Verification
Unit Testing
Integration Testing
System Testing
Static and Dynamic Approach for Software Testing
Software Inspection Process – Static Approach
Individual Preparation Inspection Meeting Rework
Software Testing – Dynamic Approach
• The software system is executed
• The process of finding differences between the expected behavior specified by system models and the observed behavior of the implemented system
• The attempt to show that the implementation of the system is inconsistent with the system models
• The goal is to design tests that exercise defects in the system and to reveal problems
• Software Testing is aimed at breaking the system!
Software Testing Plan
It is impossible to completely test any nontrivial module or system
• Practical limitations – Complete testing is prohibitive in time and cost
• Theoretical limitations: e.g., Halting problem
“Testing can only show the presence of bugs, not their absence” (Dijkstra)
Testing is not for free
• => Define your goals and priorities!!
Testing Activities
Design Document
System Design Document
Requirements Analysis Document
Client Expectation
Unit Integration Testing Testing
System Testing
Acceptance Testing
Unit Testing
Individual component (class or subsystem)
Carried out by developers
Goal: Confirm that the component or subsystem is correctly coded and carries out the intended functionality
Unit Testing Techniques
• Black-box testing
• Functional testing
• Does not focus on the implementation details
• White-box testing
• Structural testing
• Focus on the control structure and coverage of the code being exercised
Code coverage, Branch coverage, Condition coverage, Path coverage
Function /Method
Black-Box Testing
• Required Information: only requirement specification
• Independent of the implementation; test design can be in parallel
with implementation
• Focus on the I/O behavior
• If for any given input, we can predict the output, then the component passes the test
• Requires test oracle (expected test results)
• Goal – Reduce number of test cases by equivalence class
partitioning
• Divide input conditions into equivalence classes
• Choose test cases for each equivalence class.
Black-Box Testing – Test case selection
Input is valid across range of values
• Developer selects test cases from 3 equivalence classes:
• Below the range • Within the range • Above the range
Input is only valid if it is a member of a discrete set
• Developer selects test cases from 2 equivalence classes:
• Valid discrete values
• Invalid discrete values
Boundary value analysis
• test cases at the boundary • min -1 and max + 1
Example – Black box testing
public class MyCalendar {
public int getNumDaysInMonth(int month, int year) throws InvalidMonthException { }
Representation for month:
1: January, 2: February, …., 12: December
Representation for year:
1904, … 1999, 2000,…, 2006, …
How many test cases do we need for the black box testing of getNumDaysInMonth() method?
Example—Equivalence classes
• Forthemonthparameter,
• Valid–3equivalenceclasses
Months with 31 days, JAN, MAR, MAY, JUL, AUG, OCT, DEC
Months with 30 days, APR, JUN, SEPT, NOV, and
February can have 28 or 29 days
• Invalid–0,non-positiveintegersandintegers larger than 12
• Fortheyearparameter,
• Valid–2equivalenceclasses:Leapyearsand
non-leap years
• Invalid:0andnegativeintegers
Equivalence class for valid input
Value for month input
Value for year input
Months with 31 days, non-leap years
Months with 31 days, leap years
Months with 30 days, non-leap years
Months with 30 days, leap years
Months with 28 or 29 days, non-leap years
2 (February)
Months with 28 or 29 days, leap years
2 (February)
Example – Test cases selection
Equivalence class Value for month input Value for year input
Leap years divisible by 400 2 (February) 2000
Non-leap years divisible by 100 2 (February) 1900
0 and Non-positive invalid month 0 1291
Positive invalid months 13 1315
Boundary Testing
• Special case of equivalence testing focuses on the conditions at the boundary of the equivalence classes
• Select elements from the “edges” of the equivalence class
• Software testing is expensive and tedious, thus use CASE (Computer Aided Software Engineering) tools as much as possible
• Automate the tests by implementing test cases, so they are repeatable
• Regression testing, refactoring, software change
• JUnit is the de facto framework for testing Java programs.
• JUnit is a third-party open-source library packed in a jar file, which contains a tool called test runner to run test programs
JUnit Test Framework
• Eclipse and IntelliJ incorporate the JUnit into their IDE
• Resources and documentation • https://junit.org/junit4/
• https://junit.org/junit5/
JUnit Test Framework
Useful Methods in JUnit Assertion class
assertTrue(boolean condition)
assertFalse(boolean condition)
assertNull(Object testobject)
assertEquals(Object expected, Object actual) //according to equals() method assertEquals(int expected, int actual); //according to ==
assertEquals(double expected, double expected); //less than or equal to the tolerance value assertSame(Object expected, Object actual); //if refer to the same object in memory
• Many more overloading methods:
https://junit.org /junit5/docs/current/api/org.junit.jupiter.api/org /junit/jupiter/api/Assertions.html
Creating the Test Suite – JUnit Runner class
import org.junit.runner.RunWith; import org.junit.runners.Suite;
The following annotation specifies the test runner to use is org.junit.runners.Suite
@RunWith(Suite.class) /**
The following annotation run all Java .class listed in the braces. Use comma to separate different .class files.
@Suite.SuiteClasses({ ComplexTest.class,
PostfixEvaluatorTest.class, StackTest.class})
public class TestSuite {
//remains empty, used only as a holder for the above annotations. }
Five Steps of Unit Testing OO Software
Create an object and select a method to execute
Select values (test cases) for the input parameters of the method
Compute the expected values to be returned by the method
Execute the selected method on the created object using the selected input values
Verify the result of executing the method •Compare the expected output and the actual output
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com