unit-8.pptx

*Unit 8

Software Testing Strategies

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Software TestingTesting is the process of exercising aprogram with the specific intent of findingerrors prior to delivery to the end user.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

Reliability is a measure of successSoftware Reliability is the probability that a software system will not cause system failure for a specified time under specified conditionsFailure is any deviation of the observed behavior from the specified behavior.Testing is the systematic attempt to find faults in a planned way in the implemented software.These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*What Testing Showserrorsrequirements conformanceperformancean indicationof quality


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Who Tests the Software?developerindependent testerUnderstands the system

but, will test "gently"

and, is driven by "delivery"Must learn about the system,

but, will attempt to break it

and, is driven by quality


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Testing Strategyunit testintegrationtestvalidationtestsystemtest


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Testing Strategy

We begin by testing-in-the-small and move toward testing-in-the-large

For conventional softwareThe module (component) is our initial focusIntegration of modules follows


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Strategic IssuesState 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 itselfUse effective formal technical reviews as a filter prior to testingConduct formal technical reviews to assess the test strategy and test cases themselves. Develop a continuous improvement approach for the testing process.


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Unit Testingmoduleto betestedtest casesresultssoftwareengineer


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Unit Testinginterface

local data structures

boundary conditions

independent paths

error handling pathsmoduleto betestedtest cases


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Unit Test EnvironmentModulestubstubdriverRESULTSinterface

local data structures

boundary conditions

independent paths

error handling pathstest cases


Drivers/StubsThese courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*

Sl.NoDriversStubs1Driver is a piece of software that drives (invokes) the Unit being tested. I.e. A piece of code that passes test cases to another piece of codeStub is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual uniti.e. A piece of code that simulates the activity of missing components2A driver creates necessary Inputs required for the Unit and then invokes the UnitA Stub works as a Stand-in for the subordinate unit and provides the minimum required behavior for that unit3Driver is called componentStubs is calling Component4.Used in the Bottom Up Test strategyUsed in the Top Down Testing Strategy


Test CasesA test case is a set of input data and expected results that exercises a component with the purpose of causing failures and detecting faults.A test case has five attributes:1.Name:It allows the tester to distinguish between different test cases. Name given should be meaningful.Ex: If you are testing a use case Deposit() ,we can name it as Test_Deposit.2.Location :Full path of executable3.Input: Input data or commands4.Expected test results5.log:Output produced by the test(time stamped test results)



Test Case PreparationOnce the test condition is identified and the expectation out of it is provided, it is important to understand the condition correctly so that you proceed with all validationsteps which are important part of your condition.Thing to remember while creating test case _ Check for the request and response of each interacting application_ Validate the same case with large amount of test data and also different data_ Check for the value what the integrating application/interfacing application should haveversus what it is currently having. Is that correct? Sometimes the interfacing applicationsinterpret the request in different way and respond wrong but do not fail. Be careful!_ In case you have database validation, check for the columns which are affecting with thedifferent data. Dont ignore any of the tables which are impacting the transaction/flow_ Check for the error logs. Sometimes there are error logged even though the transaction isflown correctly in the interfacing application_ Provide the proper description of the test case with the changes in the interfacingapplication, this helps to understand the flow at a higher level_ If different data respond differently for the same test condition, provide that and dontforget to test that. Think Out of the Box to break the system_ Last but not least, when data flows from one application to another test immediatelywhen you are expecting the data to flow. Dont think that it could be tested later. Themore active you are with the data flow validation, more defects you have in your bucket



Test cases are classified into blackbox tests and whitebox tests.Blackbox testing: Focus on input/output behavior of the component. Blackbox tests do not deal with the internal aspects of the component, nor with the structure of the component.Whitebox testing focus on the internal structure of the component.Unit Testing combines both testing techniques:



Test stubs and driversStubs and drivers are written after the component is completed.A test driver passes the test inputs identified in the test case analysis to the component and displays results.If the interface of a component changes, the corresponding drivers and stubs must change as well.



These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Integration Testing StrategiesOptions:the big bang approachan incremental construction strategy


Big bang testing strategy assumes that all components are first tested individually and then tested together as a single system.Big bang testing is expensive.2 types of Integration testing:Bottom up and top down testingBottom up testing strategy first test each component of the bottom layer individually.In Top down testing strategy unit tests the components of the top layer first n then integrates the components of the next layerThese courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Top Down Integrationtop module is tested with stubsstubs are replaced one at a time, "depth first"as new modules are integrated, some subset of tests is re-runABCDEFG


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Bottom-Up Integrationdrivers are replaced one at a time, "depth first"worker modules are grouped into builds and integratedABCDEFGcluster


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Sandwich TestingTop modules aretested with stubsWorker modules are grouped into builds and integratedABCDEFGcluster


System TestingFunctional Testing: is also called requirement testing.Is a black box testingTest cases are derived from the use case model.Performance Testing: Finds the differences between the design goals selected during system design and the system. Stress Testing : Checks if the system can respond to many simultaneous requests. Volume Testing: Find faults associated with large amounts of data Security Testing:Testing team break into the system using their experience and knowledge of security flaws. Timing Testing: attempts to find behaviors that violate timing constraints described by the nonfunctional requirements. Recovery Tests evaluates the ability of the system to recover from erroneous states, such as the unavailability of resources, a hardware failure,network failure



System Testing ContinuedPilot Testing : is also called field test. Pilot tests are useful when a system is built without a specific set of requirements or without a specific customer in mindAlpha test is a pilot test with users exercising the system in the development environment.Beta test , the acceptance test performed by a limited number of end users in the target environment.Stress Testing: Stress testing executes a system in a manner that demands resources in abnormal quantity.Ex:Special tests may be designed that generate ten interrupts per second, when one or two are the average rates.These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*


Acceptance Testing:

The client prepares a set of test cases that represent typical conditions under which the system should operate.After the acceptance testing the client reports to the project manager which requirements are not satisfied.

Installation Testing:After the system is accepted , it is installed in the target environment. A good testing plan allows the easy configuration of the system from the development envi to target environmentThese courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*


Validation TestingValidation testing begins at the culmination(result) of integration testingTesting focuses on user visible actions and user recognizable output from the systemValidation succeeds when software functions in a manner that can be reasonably expected by the customerA SRS contains a section called validation criteria. Information contains in that section forms the basis for validation testing.



Validation Test criteriaSoftware validation is achieved through a series of tests that demonstrate conformity with requirementsA test plan outlines the classes of tests to be conducted.Test procedure defines specific test cases.All functional,behavioral,performance requirements has to be satisfied.Documentation is checkedUsability ( transportability, compatibility, error recovery) are met after validation testing

*

Validation Testing Continued..Configuration Review:An important element of the validation process is configuration review.The intent of this review is to ensure that all elements of the software configuration have been properly developed.The configuration review is sometimes called as auditAlpha and Beta Testing:Alpha test is conducted at the develops site by the end users.Beta testing is conducted at end users sites. The developer is not present during the beta testing. Therefore beta testing is like a live application of the software .

*

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*What is a Good Test?A good test has a high probability of finding an errorA good test is not redundant.A good test should be best of breed A good test should be neither too simple nor too complex


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Software TestingMethodsStrategieswhite-boxmethods black-box methods


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*White-Box Testing... our goal is to ensure that all statements and conditions have been executed at least once ...


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Basis Path TestingBasis path testing is white box testing

Here the test cases are derived to exercise the every statement in the program at least one time during testing. 1) V(G) = E N + 2 = 11-9+2 2) V(G)= No. Predicate nodes +1 =3+1

In both the cases, V(G) = 4First, we compute the cyclomatric Complexity V(G)


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Cyclomatic ComplexityA number of industry studies have indicated that the higher V(G), the higher the probability or errors.V(G)modulesmodules in this range are more error prone


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Basis Path TestingNext, we derive the independent paths:Since V(G) = 4,there are four pathsPath 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8Finally, we derive testcases to exercise these paths.


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Basis Path Testing Notes


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Control Structure TestingCondition testing a test case design method that exercises the logical conditions contained in a program module. Test cases are designed using boolean operators, parenthesis, relational operators(=,>,

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Loop TestingNested LoopsConcatenated Loops Unstructured LoopsSimple loop


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Loop Testing: Simple LoopsMinimum conditionsSimple Loops1. skip the loop entirely

2. only one pass through the loop

3. two passes through the loop

4. m passes through the loop m < n

5. (n-1), n, and (n+1) passes through the loopwhere n is the maximum number of allowable passes


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Loop Testing: Nested LoopsStart at the innermost loop. Set all outer loops to their minimum iteration parameter values.

Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their minimum values.

Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until the outermost loop has been tested.If the loops are independent of one another

then treat each as a simple loop

else* treat as nested loops

endif*

for example, the final loop counter value of loop 1 is used to initialize loop 2.Nested LoopsConcatenated Loops


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Black-Box Testingrequirementseventsinputoutput


These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005*Black-Box TestingHow is functional validity tested?How is system behavior and performance tested?What classes of input will make good test cases?Is the system particularly sensitive to certain input values?How are the boundaries of a data class isolated?What data rates and data volume can the system tolerate?What effect will specific combinations of data have on system operation?


unit-8.pptx

Documents