UNrT-VI Seely UNIT — VI; SOFTWARE TESTING ives for testing estion 1; State and explain Primary objecti ($-14/W-14/S-15/S-16/W-16/6M/7y) (W-14/6m) | Question 2: Explain with Testing in detail. 1. Software Testing Fundamentals Software testing is a critical element of software quality assurance and represents iy ultimate review of specification, design and coding. a) Testing Objectives ‘According to Glen Myers the testing objectives are 1. Testing is a process of executing a program with the intend of finding an error. 2. A good test case is one that has high probability of finding an undiscovered error, 3. A successful test is one that uncovers an as-yet undiscovered error. The major testing objective is to design tests that systematically uncover types of ens ‘with minimum time and effort. The purpose of software testing is to ensure whether the software functions appear to be working according to specifications and performance requirements. If testing is eondute! successfully, it will uncover errors in the software: In addition, data collected as testts ® conducted provide a good indication of software reliability and some indication of softs" quality as a whole. b) Testing Principles Every software engineer must apply following testing principles while ~— 4 software testing. : 1. All tests should be traceable to customer requirements, 2. Tests should be planned long before testing begins. _ 3, The Pareto principle can be applied to software testing ~ 80% of al aon ws during testing will likely be traceable to 20% of all program modules. i should begin “in the small” and progress toward testing "in the large” Software Engincering/Software Project Mexhaustive testing is not possible. UNIT-VI Jo be most effective, testing should be conducted by an independent third party. gestability software testability is how easily a computer program can be tested or how much the ire is testable, Sometimes programmers are willing to do things that will help the testing _os and a checklist of possible design points, features, etc. can be useful in negotiating with ‘There are metrics that could be used to measure testability in most of its aspects. metimes, testability is used to mean how adequately a particular set of tests will cover the jue. I's also used by the military to mean how easily a tool ean be checked and repaired in field. The checklist that follows provides a set ‘of characteristics that lead to testable software. ) Operability: "The better it works, the more efficiently it can be tested.” yverhead to the test process). |. The system has few bugs (bugs add analysis and reporting 0 2. No bugs block the execution of tests. ultaneous development and testing). 3. The product evolves in functional stages (allows simi what you see is what you test.” ii) Observability: generated for each input 1. Distinet output is and variables are visible or queriable during execution. past system states and variables are visible or queriable (¢-8 transaction logs). System states ‘All factors affecting the output are visible. output is easily identified. y detected through self-testing mechanisms. Internal errors are automatically 2 3. 4. 5, Incorrect 6. i ically reported. 8. ,frware, the more the testing can be "The better we can control the sol ili) Controllability snd opie.” Jn some combination of input. aut 1. All possible ‘outputs can be generated throug) ——, Engineering/Software Project Management 2052. All code is executable through some combination of input: 3. Software and hardware states and variables can be controlled directly | oy engineer. 4, Input and output formats are consistent and structured. 5. Tests can be conveniently specified, automated, and reproduced. iv) Decomposability: "By controlling the scope of testing, we can more q problems and perform smarter retesting." 1. The software system is built from independent modules. 2. Software modules can be tested independently. v) Simplicity: "The less there is to test, the more quickly we can test it." 1. Functional simplicity 2, Structural simplicity 3. Code simplicity vi) Stability: “The fewer the changes, the fewer the disruptions to testing,” 1. Changes to the software are infrequent, 2. Changes to the software are controlled. 3. Changes to the software do not invalidate existing tests, 4. ‘The software recovers well from failures. 1. The design is well understood. : 2. Dependencies between internal, external, and shared components are well | a 3. Changes to the design are communicated, 4. ‘Technical documentation is instantly accessible, is, Technical documentation is well organized, ‘ ‘Technical documentation is specific and detailed, documentation is accurate,ts in which the then part has no definition of any In this situation, the else branch of the if statement is not ‘useful for selecting test paths of a program containing this, consider the application of DU testing to select testin the same manner as simple loop tests. But, if two xr for loop is used as the initial value for loop, then the Jed for unstructured loops. Hence these types of: Boundary value analysis is a test case design technique that complements eq! partitioning technique, ines for boundary value analysis technique are If the input condition specified the range bounded by values x and y, then test cases should be designed with values x and y. Also test cases should he with the values above and below x andy. ut condition specifies the number of values then the test cases should be ened with minimum and maximum values as well as with the values that are just ‘and below the maximum and minimum should be tested output condition specified the range bounded by values x and y, then test cases jgned with values x and y. Also fest cases should be with the values ¥. : of values then the test eases should be ‘as with the values that are just Engineering/Software Project Managementtrol to the module undergoing testing, Driver ae Module tobe tested pe Tet Figure: Unit test environment Drivers and software's represent operating cost. That is, both are software that must be ten but that is not delivered with the final software product. If drivers and software are kept actual overhead is relatively low. components cannot be adequately unit tested with "simple" overhead software. In test step. Unit testing is jon is designed, When only. one function is iced and errors can be more easily