types of testing in software engineering

types of testing in software engineering

• 1.
  SYSTEM TESTING • Systemtesting is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. • It verifies that system elements have been properly integrated and perform allocated functions. 1
• 2.
  1. Recovery system Recoverytesting is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is automatic (performed by the system itself), re-initialization, check pointing mechanisms, data recovery, and restart are evaluated for correctness. 2
• 3.
  2. Security testing Securitytesting attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. 3. Stress testing Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume. A variation of stress testing is a technique called sensitivity testing. 3
• 4.
  4. Performance testing Performancetests are often coupled with stress testing and usually require both hardware and software instrumentation. 5. Deployment testing Deployment testing, sometimes called configuration testing, exercises the software in each environment in which it is to operate. deployment testing examines all installation procedures and specialized installation software (e.g., “installers”) that will be used by customers, and all documentation that will be used to introduce the software to end users. 4
• 5.
  Debugging Debugging occurs asa consequence of successful testing. That is, when a test case uncovers an error, debugging is the process that results in the removal of the error. 5
• 6.
  1. Debugging process 6
• 7.
  2. Debugging strategies •Regardless of the approach that is taken, debugging has one overriding objective— to find and correct the cause of a software error or defect. • Three debugging strategies have been proposed: (1) brute force, (2) backtracking, and (3) cause elimination. 7
• 8.
  Debugging tactics. • Thebrute force category of debugging is probably the most common and least efficient method for isolating the cause of a software error. You apply brute force debugging methods when all else fails. • Backtracking is a fairly common debugging approach that can be used successfully in small programs. • cause elimination—is manifested by induction or deduction and introduces the concept of binary partitioning. 8
• 9.
  3. Correcting theerror • Once a bug has been found, it must be corrected. • three simple questions that you should ask before making the “correction” that removes the cause of a bug: – Is the cause of the bug reproduced in another part of the program? – What “next bug” might be introduced by the fix I’m about to make? – What could we have done to prevent this bug in the first place? 9
• 10.
  SOFTWARE TESTING FUNDAMENTALS Testability •“Software testability is simply how easily [a computer program] can be tested.” The following characteristics lead to testable software: – Operability – Observability – Controllability – Decomposability – Simplicity – Stability – Understandability 10
• 11.
  Test Characteristics • Agood test has a high probability of finding an error. • A good test is not redundant. • A good test should be “best of breed”. • A good test should be neither too simple nor too complex. 11
• 12.
  WHITE-BOX TESTING • White-boxtesting, sometimes called glass-box testing, is a test-case design philosophy that uses the control structure described as part of component-level design to derive test cases. Using white-box testing methods, you can derive test cases that: – (1) guarantee that all independent paths within a module have been exercised at least once, – (2) exercise all logical decisions on their true and false sides, – (3) execute all loops at their boundaries and within their operational bounds, and – (4) exercise internal data structures to ensure their validity. 12
• 13.
  BASIS PATH TESTING Thebasis path method enables the test-case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. 13
• 14.
  •Flow Graph Notation •Before we consider the basis path method, a simple notation for the representation of control flow, called a flow graph (or program graph) must be introduced. 14
• 15.
  BLACK-BOX TESTING • Black-boxtesting, also called behavioral testing, focuses on the functional requirements of the software. • Black-box testing attempts to find errors in the following categories: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external database access, (4) behavior or performance errors, and (5) initialization and termination errors. 15
• 16.
  OBJECT-ORIENTED TESTING STRATEGIES •Unit Testing in the OO Context • Integration Testing in the OO Context • Validation Testing in an OO Context 16
• 17.
  OBJECT-ORIENTED TESTING METHODS •The Test-Case Design Implications of OO Concepts. • Applicability of Conventional Test-Case Design Methods. • Fault-Based Testing • Test Cases and the Class Hierarchy • Scenario-Based Test Design • Testing Surface Structure and Deep Structure 17