100 likes | 258 Views
Testing & Quality Assurance. T esting is a technical investigation process intended to reveal quality-related information about software. T he standard progression of software testing:. U nit T esting Programmers test the minimal software components (i.e., classes and modules).
E N D
Testing & Quality Assurance Testing is a technical investigation process intended to reveal quality-related information about software The standard progression of software testing: Unit Testing Programmers test the minimal software components (i.e., classes and modules) Integration Testing Expose the defects in the interfaces between integrated modules Validation Testing Ensure that the implemented software meets customer requirements System Testing Determine whether the software will work as desired when installed Acceptance Testing The client tests the delivered software to decide whether it is in an acceptable form Schach - Chapter 6 Page 121
Unit Testing To facilitate the diagnosis of problems within a module, it is usually necessary to isolate that module Place the module or class being tested in an artificial environment that allows you to focus upon its performance. A dummy driver program merely accepts test case data and passes it to the module being tested. Stub programs are used to replace modules that are called by the module being tested. The module being tested. Schach - Chapter 6 Page 122
Integration Testing While individual modules might pass their unit tests, they might not work correctly when integrated together Integration Alternatives: • Big Bang: Test all modules simultaneously ({A, B, C, D, E, F, G, H}) • Fine for small, well-structured systems, but locating bugs may be tough • Top-Down: Incrementally test from the driver down ({A} with stubs for {B,C,D}, then {A, B, C, D} with stubs for {E, F, G, H}, then {A, B, C, D, E, F, G, H}) • Helps localize bugs, but deep nodes are tested last, hurting performance • Bottom-Up: Incrementally test starting at primitive modules ({E}, {F}, {G}, {H}, each with a dummy driver for {C}, then {B}, {C, E, F, G, H}, {D}, each with a dummy driver for {A}, then {A, B, C, D, E, F, G, H}) • Early validation of performance-critical modules, but overall validation is delayed Schach - Chapter 6 Page 123
Validation Testing Rather than testing the internal code, at some point the overall functionality of the software needs to be tested White-box testing is performed by programmers who utilize their skills to examine all of the paths through the software to diagnose internal problems. Black-box testing, on the other hand, takes an external perspective, with the test designer selecting valid and invalid input and examining the corresponding output for accuracy. Schach - Chapter 6 Page 124
System Testing After the software has been fully integrated, its compliance with its specified requirements must be tested Recovery testing is used to determine how well software can recover from crashes, hardware failures, etc. Security testing is used to determine how well software is protected from outside penetration Stress testing is used to determine how well software deals with extreme demands on its resources (e.g., memory, processing) Performance testing is used to determine the speed with which software deals with various workloads Schach - Chapter 6 Page 125
Acceptance Testing In preparation for the software’s actual release, early versions may be provided to clients for testing Alpha testing is performed by clients on iterations of the software to which new features are still being added Beta testing is performed at a stage when all primary features have been added, but active debugging is still taking place Schach - Chapter 6 Page 126
Regression Testing When features are added or altered, the changes might cause previously working code to fail Common methods of regression testing include re-running previously run tests and checking whether previously fixed bugs have reemerged Schach - Chapter 6 Page 127
Designing Test Cases The conditions that a tester will use to determine if a system meets certain requirements must be well designed Test cases need identification parameters: • an identifier and version number, for future reference’s sake • a title and description, making the test case’s purpose and scope obvious • the name of the test designer who is responsible for its development • an identification of the system’s requirement being addressed Test cases require activity parameters: • required hardware/software configurations • initialization actions needed prior to the test • step-by-step actions taken during the test • finalization actions needed after the test Test cases require results parameters: • expected results specifications • actual results specifications Schach - Chapter 6 Page 128