SOFTWARE ENGINEERING 191 CSC 301 T Dr K

SOFTWARE ENGINEERING 191 CSC 301 T Dr. K. M. Anandkumar Mrs. V. Rathinapriya Ms. S. Sriheera

UNIT IV TESTING AND MAINTENANCE Software testing fundamentals-Internal and external views of Testing-white box testing- basis path testing-control structure testing-black box testing- Regression Testing – Unit Testing – Integration Testing – Validation Testing – System Testing And Debugging – Software Implementation Techniques: Coding practices-Refactoring Maintenance and reengineering-BPR modelreengineering process model-Reverse and forward engineering

Objectives 1. To study the fourth phase of Software Engineering in detail 2. To understand the Testing process and its methodologies 3. Learn various testing and maintenance measures

Software testing fundamentals What is it? • Software is tested to uncover errors that were made inadvertently as it was designed and constructed Who does it? • A strategy for software testing is developed by the project manager, software engineers, and testing specialists

Software testing fundamentals Why is it important? • Testing often accounts for more project effort than any other software engineering action. • If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected. • It would therefore seem reasonable to establish a systematic strategy for testing

Software testing fundamentals What are the steps? • Testing begins “in the small” and progresses “to the large. ” • Early testing focuses on a single component or a small group of related components • After components are tested they must be integrated until the complete system is constructed. At this point, a series of high-order tests are executed to uncover errors in meeting customer requirements

Software testing fundamentals What are the steps? • As errors are uncovered, they must be diagnosed and corrected using a process that is called debugging.

A Strategic Approach to Software Testing • Testing is a set of activities that can be planned in advance and conducted systematically. • A number of software testing strategies have been proposed and it has the following generic characteristics: – To perform effective testing, you should conduct effective technical reviews. By doing this, many errors will be eliminated before testing commences. – Testing begins at the component level and works “outward” toward the integration of the entire computer-based system.

A Strategic Approach to Software Testing – Different testing techniques are appropriate for different software engineering approaches and at different points in time. – Testing is conducted by the developer of the software and (for large projects) an independent test group. – Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

Verification and Validation (V &V) • Verification refers to the set of tasks that ensure that software correctly implements a specific function • Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements • Verification: “Are we building the product right? ” • Validation: “Are we building the right product? ”

Software testing fundamentals • Set of characteristics that achieve the goal of finding the most errors with a minimum of effort • Operability - “The better it works, the more efficiently it can be tested. ” • Observability - “What you see is what you test. ” • Controllability - “The better we can control the software, the more the testing can be automated and optimized. ” • Decomposability - “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting. ”

Software testing fundamentals • Simplicity - “The less there is to test, the more quickly we can test it. ” • Stability - “The fewer the changes, the fewer the disruptions to testing. ” • Understandability - “The more information we have, the smarter we will test. ”

Test Characteristics • A good 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

Internal and external views of Testing Any engineered product (and most other things) can be tested in one of two ways: 1. Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational while at the same time searching for errors in each function. 2. Knowing the internal workings of a product, tests can be conducted to ensure that “all gears mesh, ” that is, internal operations are performed according to specifications and all internal components have been adequately exercised. The first test approach takes an external view and is called black-box testing. The second requires an internal view and is termed white-box testing

Black Box and White Box Testing • Black-box testing refers to tests that are conducted at the software interface. • A black-box test examines some fundamental aspect of a system with little regard for the internal logical structure of the software. • White-box testing of software is predicated on close examination of procedural detail. Logical paths through the software and collaborations between components are tested by exercising specific sets of conditions and/or loops.

White Box Testing

White Box Testing (Internal Testing) • White-box testing, 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.

White Box Testing (Internal Testing) Basic Path Testing 1. 2. 3. 4. Flow Graph Notation Independent Program Paths Deriving Test Cases Graph Matrices Control Structure Testing 1. Condition Testing 2. Data Flow Testing 3. Loop Testing

Basic Path Testing • Basis path testing is a white-box testing technique first proposed by Tom Mc. Cabe • The basis 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 • Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

Basic Path Testing- 1. Flow Graph Notation

Basic Path Testing- a. Flow chart, b. Flow graph

Basic Path Testing- a. Flow chart, b. Flow graph • Circle – Flow graph node, represents one or more procedural statements • Sequence of process boxes • Decision diamond • Edges or Links – Arrows on the flow graph • Region – Areas bounded by edges and nodes (Also include areas outside the graph as a region) • Compound logic (OR, AND, NOR) may be used • Predicate node – Contains conditions (2 or more edges emanating from it)

Basic Path Testing- Compound Logic

Basic Path Testing- 2. Independent Program Paths • An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. • When stated in terms of a flow graph, an independent path must move along at least one edge that has not been traversed before the path is defined

Basic Path Testing- 2. Independent Program Paths • • Path 1: 1 -11 Path 2: 1 -2 -3 -4 -5 -10 -1 -11 Path 3: 1 -2 -3 -6 -8 -9 -10 -1 -11 Path 4: 1 -2 -3 -6 -7 -9 -10 -1 -11 Paths 1 through 4 constitute a basis set for the flow graph Note that each new path introduces a new edge. The path • 1 -2 -3 -4 -5 -10 -1 -2 -3 -6 -8 -9 -10 -1 -11 – is not considered to be an independent path because it is simply a combination of already specified paths and does not traverse any new edges

Basic Path Testing- 2. Independent Program Paths • Every statement in the program will have been guaranteed to be executed at least one time and every condition will have been executed on its true and false sides • Cyclomatic Complexity – It is a software metric that provides a quantitative measure of the logical complexity of a program • The value computed for Cyclomatic complexity defines the 1. number of independent paths in the basis set of a program and provides you with an upper bound for the 2. number of tests that must be conducted to ensure that all statements have been executed at least once.

Basic Path Testing- 2. Independent Program Paths Cyclomatic complexity has a foundation in graph theory and provides you with an extremely useful software metric. Complexity is computed in one of three ways: 1. The number of regions of the flow graph corresponds to the cyclomatic complexity. 2. Cyclomatic complexity V(G) for a flow graph G is defined as V(G) = E – N + 2 – where E is the number of flow graph edges and N is the number of flow graph nodes. 3. Cyclomatic complexity V(G) for a flow graph G is also defined as V(G) = P + 1 – where P is the number of predicate nodes contained in the flow graph G.

Basic Path Testing- 2. Independent Program Paths Referring once more to the flow graph in last Figure, the cyclomatic omplexity Can be computed using each of the algorithms just noted: 1. The flow graph has four regions. 2. V(G) = 11 edges - 9 nodes + 2 = 4. 3. V(G) = 3 predicate nodes + 1 = 4.

Basic Path Testing- 3. Deriving Test cases • The basis path testing method can be applied to a procedural design or to source code. The following steps can be applied to derive the basis set: 1. Using the design or code as a foundation, draw a corresponding flow graph 2. Determine the cyclomatic complexity of the resultant flow graph 3. Determine a basis set of linearly independent paths 4. Prepare test cases that will force execution of each path in the basis set.

Basic Path Testing- PDL with nodes identified

Basic Path Testing- Flow graph for the PDL

Basic Path Testing- Flow graph for the PDL • • Path 1: 1 -2 -10 -11 -13 Path 2: 1 -2 -10 -12 -13 Path 3: 1 -2 -3 -10 -11 -13 Path 4: 1 -2 -3 -4 -5 -8 -9 -2 -. . . Path 5: 1 -2 -3 -4 -5 -6 -8 -9 -2 -. . . Path 6: 1 -2 -3 -4 -5 -6 -7 -8 -9 -2 -. . . nodes 2, 3, 5, 6, and 10 are predicate nodes

Basic Path Testing- 4. Graph Matrices • A data structure, called a graph matrix, can be quite useful for developing a software tool that assists in basis path testing • A graph matrix is a square matrix whose size (i. e. , number of rows and columns) is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node, and matrix entries correspond to connections (an edge) between nodes. • The graph matrix is nothing more than a tabular representation of a flow graph

Basic Path Testing- 4. Graph Matrices

Control Structure Testing • Basis path testing is simple and highly effective, it is not sufficient in itself other variations on control structure testing are discussed using control structure testing • It improves the quality of white-box testing

Control Structure Testing – 1. Conditional Testing A simple condition is a Boolean variable or a relational expression, possibly preceded with one NOT (¬) operator. A relational expression takes the form E 1 <relational-operator> E 2 where E 1 and E 2 are arithmetic expressions and <relationaloperator>. A compound condition is composed of two or more simple conditions, Boolean operators, and parentheses

Control Structure Testing – 2. Data Flow Testing • The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program • Assume each statement in a program is assigned a unique statement number and that each function does not modify its parameters or global variables • For a statement with S as its statement number, DEF(S) = {X | statement S contains a definition of X} USE(S) = {X | statement S contains a use of X}

Control Structure Testing – 3. Loop Testing • Loop testing is a white-box testing technique that focuses exclusively on the validity of loop constructs • Four different classes of loops can be defined: 1. 2. 3. 4. Simple loops, Nested loops, Concatenated loops and Un-structured loops

Control Structure Testing – 3. Loop Testing 1. Simple loops: 1. 2. 3. 4. 5. The following set of tests can be applied to simple loops, where n is the maximum number of allowable passes through the loop Skip the loop entirely. Only one pass through the loop. Two passes through the loop m passes through the loop where m < n. n - 1, n, n + 1 passes through the loop.

Control Structure Testing – 3. Loop Testing

Control Structure Testing – 3. Loop Testing 2. Nested loops: • If we were to extend the test approach for simple loops to nested loops, the number of possible tests would grow geometrically as the level of nesting increases. This would result in an impractical number of tests • The following approach that will help to reduce the number of tests 1. 2. 3. 4. Start at the innermost loop. Set all other loops to minimum values. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter (e. g. , loop counter) values. Add other tests for out-of-range or excluded values. Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values. Continue until all loops have been tested.

Control Structure Testing – 3. Loop Testing 3. Concatenated loops: • Concatenated loops can be tested using the approach defined for simple loops, if each of the loops is independent of the other. However, • If two loops are concatenated and the loop counter for loop 1 is used as the initial value for loop 2, then the loops are not independent. • When the loops are not independent, the approach applied to nested loops is recommended

Control Structure Testing – 3. Loop Testing 4. Un-structured loops: • Whenever possible, this class of loops should be redesigned to reflect the use of the structured programming constructs

Software Testing Strategy 1. 2. 3. 4. Unit Testing Integration Testing Validation Testing System Testing

Software Testing Strategy

Software Testing Steps

Strategic Issues • Specify product requirements in a quantifiable manner long before testing commences • State testing objectives explicitly • Understand the users of the software and develop a profile for each user category • Develop a testing plan that emphasizes “rapid cycle testing • Build “robust” software that is designed to test itself • Use effective technical reviews as a filter prior to testing • Conduct technical reviews to assess the test strategy and test cases themselves • Develop a continuous improvement approach for the testing process

Unit Testing module to be tested results software engineer interface local data structures boundary conditions independent paths error handling paths test cases 49

Unit Testing Considerations

Unit Testing Procedures

Integration Testing Strategies Options: • the “big bang” approach • an incremental construction strategy • Top Down, bottom-up, sandwich Integration 52

Integration Testing / Top-downapproach

Integration Testing/ Bottom-up approach

Integration Testing – Contd. . Regression Testing Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects The regression test suite (the subset of tests to be executed) contains three different classes of test cases: • A representative sample of tests that will exercise all software functions. • Additional tests that focus on software functions that are likely to be affected by the change. • Tests that focus on the software components that have been changed.

Integration Testing – Contd. . Smoke Testing • Smoke testing is an integration testing approach that is commonly used when product software is developed. It is designed as a pacing mechanism for timecritical projects, allowing the software team to assess the project on a frequent basis. In essence, the smoke-testing approach encompasses the following activities: 1. Software components that have been translated into code are integrated into a build. A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions. 2. A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “showstopper” errors that have the highest likelihood of throwing the software project behind schedule. 3. The build is integrated with other builds, and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.

Validation Testing • Validation testing begins at the culmination of integration testing, when individual components have been exercised, the software is completely assembled as a package, and interfacing errors have been uncovered and corrected Alpha and Beta Testing • The alpha test is conducted at the developer’s site by a representative group of end users • The beta test is conducted at one or more end-user sites. Unlike alpha testing, the developer generally is not present. Therefore, the beta test is a “live” application of the software in an environment that cannot be controlled by the developer

System Testing • System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. • Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions 1. 2. 3. 4. 5. Recovery Testing Security Testing Stress Testing Performance Testing Deployment Testing

Debugging • Debugging occurs as a 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.

Maintenance and Reengineering 60

Software Maintenance • Software is released to end-users, and – within days, bug reports filter back to the software engineering organization. – within weeks, one class of users indicates that the software must be changed so that it can accommodate the special needs of their environment. – within months, another corporate group who wanted nothing to do with the software when it was released, now recognizes that it may provide them with unexpected benefit. They’ll need a few enhancements to make it work in their world. • All of this work is software maintenance 61

Maintainable Software • Maintainable software exhibits effective modularity • It makes use of design patterns that allow ease of understanding. • It has been constructed using well-defined coding standards and conventions, leading to source code that is self-documenting and understandable. • It has undergone a variety of quality assurance techniques that have uncovered potential maintenance problems before the software is released. • It has been created by software engineers who recognize that they may not be around when changes must be made. – Therefore, the design and implementation of the software must “assist” the person who is making the change 62

Software Supportability • “the capability of supporting a software system over its whole product life. – This implies satisfying any necessary needs or requirements, but also the provision of equipment, support infrastructure, additional software, facilities, manpower, or any other resource required to maintain the software operational and capable of satisfying its function. ” [SSO 08] • The software should contain facilities to assist support personnel when a defect is encountered in the operational environment (and make no mistake, defects will be encountered). • Support personnel should have access to a database that contains records of all defects that have already been encountered—their characteristics, cause, and cure. 63

Reengineering Business processes IT systems 64 Reengineering Software applications

Business Process Reengineering • • • 65 Business definition. Business goals are identified within the context of four key drivers: cost reduction, time reduction, quality improvement, and personnel development and empowerment. Process identification. Processes that are critical to achieving the goals defined in the business definition are identified. Process evaluation. The existing process is thoroughly analyzed and measured. Process specification and design. Based on information obtained during the first three BPR activities, use-cases are prepared for each process that is to be redesigned. Prototyping. A redesigned business process must be prototyped before it is fully integrated into the business. Refinement and instantiation. Based on feedback from the prototype, the business process is refined and then instantiated within a business system.

Business Process Reengineering 66

BPR Principles • Organize around outcomes, not tasks. • Have those who use the output of the process perform the process. • Incorporate information processing work into the real work that produces the raw information. • Treat geographically dispersed resources as though they were centralized. • Link parallel activities instead of integrated their results. When different • Put the decision point where the work is performed, and build control into the process. • Capture data once, at its source. 67

Software Reengineering Forward engineering Data restructuring code restructuring 68 inventory analysis document restructuring reverse engineering

Inventory Analysis • build a table that contains all applications • establish a list of criteria, e. g. , – – – – name of the application year it was originally created number of substantive changes made to it total effort applied to make these changes date of last substantive change effort applied to make the last change system(s) in which it resides applications to which it interfaces, . . . • analyze and prioritize to select candidates for reengineering 69

Document Restructuring • • • Weak documentation is the trademark of many legacy systems. But what do we do about it? What are our options? Options … – Creating documentation is far too time consuming. If the system works, we’ll live with what we have. In some cases, this is the correct approach. – Documentation must be updated, but we have limited resources. We’ll use a “document when touched” approach. It may not be necessary to fully redocument an application. – The system is business critical and must be fully redocumented. Even in this case, an intelligent approach is to pare documentation to an essential minimum. 70

Reverse Engineering 71

Code Restructuring • Source code is analyzed using a restructuring tool. • Poorly design code segments are redesigned • Violations of structured programming constructs are noted and code is then restructured (this can be done automatically) • The resultant restructured code is reviewed and tested to ensure that no anomalies have been introduced • Internal code documentation is updated. 72

Data Restructuring • • • 73 Unlike code restructuring, which occurs at a relatively low level of abstraction, data structuring is a full-scale reengineering activity In most cases, data restructuring begins with a reverse engineering activity. – Current data architecture is dissected and necessary data models are defined. – Data objects and attributes are identified, and existing data structures are reviewed for quality. – When data structure is weak (e. g. , flat files are currently implemented, when a relational approach would greatly simplify processing), the data are reengineered. Because data architecture has a strong influence on program architecture and the algorithms that populate it, changes to the data will invariably result in either architectural or code-level changes.

cost Forward Engineering The 1. times the cost of initial development of that line. software architecture the 2. (program Redesign data and/or of structure), using modern design concepts, can greatly facilitate future maintenance. 3. Because prototype a the ofsoftware already exists, development productivity should be much higher than average. 4. experience has user now The software. the with. Therefore, new requirements and the direction of change can be ascertained with greater ease. 5. CASE tools for reengineering will automate some parts of the job. 6. complete A software configuration (documents, programs and data) will exist upon completion of preventive maintenance. 74