Lecture 8: Software testing. The main contents of this chapter include all of the following: Overview of software testing, test coverage and code coverage, practical aspects of unit testing, integration and system testing. | Ivan Marsic Rutgers University LECTURE 8: Software Testing Topics Overview of Software Testing Test Coverage and Code Coverage Practical Aspects of Unit Testing Integration and System Testing Overview of Software Testing “Testing shows the presence, not the absence of bugs.” —Edsger W. Dijkstra A fault, also called “defect” or “bug,” is an erroneous hardware or software element of a system that can cause the system to fail Test-Driven Development (TDD) Every step in the development process must start with a plan of how to verify that the result meets a goal The developer should not create a software artifact (a system requirement, a UML diagram, or source code) unless they know how it will be tested A test case is a particular choice of input data to be used in testing a program A test is a finite collection of test cases Why Testing is Hard A key tradeoff of testing: testing as many potential cases as possible while keeping the economic costs limited Our goal | Ivan Marsic Rutgers University LECTURE 8: Software Testing Topics Overview of Software Testing Test Coverage and Code Coverage Practical Aspects of Unit Testing Integration and System Testing Overview of Software Testing “Testing shows the presence, not the absence of bugs.” —Edsger W. Dijkstra A fault, also called “defect” or “bug,” is an erroneous hardware or software element of a system that can cause the system to fail Test-Driven Development (TDD) Every step in the development process must start with a plan of how to verify that the result meets a goal The developer should not create a software artifact (a system requirement, a UML diagram, or source code) unless they know how it will be tested A test case is a particular choice of input data to be used in testing a program A test is a finite collection of test cases Why Testing is Hard A key tradeoff of testing: testing as many potential cases as possible while keeping the economic costs limited Our goal is to find faults as cheaply and quickly as possible. Ideally, we would design a single “right” test case to expose each fault and run it In practice, we have to run many “unsuccessful” test cases that do not expose any faults Logical Organization of Testing Unit test Unit test Unit test Integration test Component code Component code Component code Tested component Integrated modules Function test Quality test Acceptance test Installation test System test System in use Ensure that each component works as specified Ensures that all components work together Verifies that functional requirements are satisfied Verifies non-functional requirements Customer verifies all requirements Testing in user environment ( Not necessarily how it’s actually done! ) Acceptance Tests - Examples [ Recall Section : Requirements Engineering ] Test with the valid key of a current tenant on his/her apartment (pass) Test with the valid key of a current tenant on someone else’s apartment (fail) .
