[SOLVED] CS 213 SOFTWARE METHODOLOGY

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 Assignmentchef assignmentchef

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?

ExampleEquivalence classes
Forthemonthparameter,
Valid3equivalenceclasses
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
Invalid0,non-positiveintegersandintegers larger than 12
Fortheyearparameter,
Valid2equivalenceclasses: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: assignmentchef QQ: 1823890830 Email: [email protected]