Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Doc 21 Test Techniques & Levels

Doc 21 Test Techniques & Levels

Ratings:

4.67

(3)
|Views: 204 |Likes:
Published by Kapildev

More info:

Published by: Kapildev on Nov 29, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC or read online from Scribd
See more
See less

07/15/2014

 
Syntel CQA Forum Test Techniques and Levels CQADoc No 211 Test Techniques
 This section describes techniques andstrategies for testing. Techniques coverdifferent ways testing can be accomplished. These are combined together with eachother and with the levels of testingdescribed in the next section to create testplans that meet the needs of each uniqueproject.
1.1 Preparation1.1.1 Formal Testing
 Testing performed with a plan, documentedset of test cases, etc that outline themethodology and test objectives. Testdocumentation can be developed fromrequirements, design, equivalencepartitioning, domain coverage, errorguessing, etc. The level of formality andthoroughness of test cases will dependupon the needs of the project. Someprojects can have rather informal ‘formaltest cases’, while others will require ahighly refined test process. Some projectswill require light testing of nominal pathswhile others will need rigorous testing of exceptional cases.
1.1.2 Informal Testing
Ad hoc testing performed without adocumented set of objectives or plans.Informal testing relies on the intuition andskills of the individual performing thetesting. Experienced engineers can beproductive in this mode by mentallyperforming test cases for the scenariosbeing exercised.
1.2 Execution1.2.1 Manual Testing
Manual testing involves direct humaninteraction to exercise softwarefunctionality and note behavior anddeviations from expected behavior.
1.2.2 Automated Testing
 Testing that relies on a tool, built-in testharness, test framework, or other automaticmechanism to exercise softwarefunctionality, record output, and possiblydetect deviations. The test cases performedby automated testing are usually defined assoftware code or script that drives theautomatic execution.
1.3 Approach1.3.1 Structural Testing
Structural testing depends upon knowledgeof the internal structure of the software.Structural testing is also referred to aswhite-box testing.
Data-flow Coverage
Data-flow coverage tests paths from thedefinition of a variable to its use.
Control-flow Coverage
Statement Coverage
Statement coverage requires that everystatement in the code under test has beenexecuted.
Branch Coverage
Branch coverage requires that every pointof entry and exit in the program has beenexecuted at least once, and every decisionin the program has taken all possibleoutcomes at least one.
Condition Coverage
Condition coverage is branch coverage withthe additional requirement that “everycondition in a decision in the program hastaken all possible outcomes at least once.”
Multiple
Multiple condition coverage requires that allpossible combinations of the possibleoutcomes of each condition have beentested.
Modified 
Modified condition coverage requires thateach condition has been testedindependently.
1.3.2 Functional Testing
Functional testing compares the behavior of the test item to its specification withoutknowledge of the item’s internal structure.Functional testing is also referred to asblack box testing.
Requirements Coverage
Requirements coverage requires at leastone test case for each specifiedrequirement. A traceability matrix can beused to insure that requirements coveragehas been satisfied.
Input Domain Coverage
Input domain coverage executes a functionwith a sufficient set of input values from thefunction’s input domain (the set of values itcan take as input parameters). The notionof a sufficient set is not completelydefinable, and complete coverage of theinput domain is typically impossible. Therefore the input domain is broken intosubsets, or
equivalence classe
s, suchthat all values within a subset are likely toreveal the same defects. Any one valuewithin an equivalence class can be used torepresent the whole equivalence class. Inaddition to a generic representative, each
 
Syntel CQA Forum Test Techniques and Levels CQADoc No 21
extreme value within an equivalence class(e.g. the minimum and maximum in anumeric range) should be covered by a testcase. Testing the extreme values of theequivalence classes is referred to as
boundary value
testing.
Output Domain Coverage
Output domain coverage executes afunction in such a way that a sufficient setof output values from the function’s outputdomain (the set of values it can return) isproduced. Equivalence classes andboundary values (see Input DomainCoverage) are used to provide coverage of the output domain. A set of test cases that“reach” the boundary values and a typicalvalue for each equivalence class isconsidered to have achieved output domaincoverage.
2 Test Levels
 This section captures the different types orlevels of testing. Testing levels capture acombination of what, why, how, and whensomething is tested. Testing levels arecombined with the techniques of theprevious section to creation test plans thatmeet the unique needs of each project.Although many testing levels tend to becombined with certain techniques, there areno hard and fast rules. Some types of testing imply certain lifecycle stages,software deliverables, or other projectcontext (e.g., system testing). Other typesof testing are general enough to be donealmost any time on any part of the system(e.g., bench testing). Some require aparticular methodology (e.g., single steptesting). When appropriate commonutilizations of a particular testing type willbe described. The project’s test plan will normally definethe types of testing that will be used on theproject, when they will be used, and thestrategies they will be used with. Test casesare then created for each testing type.
2.1 Unit Testing
A unit is an abstract term for the smallestthing that can be conveniently tested. Thiswill vary based on the nature of a projectand its technology but usually focuses atthe subroutine level. Unit testing is thetesting of these units. Unit testing is oftenautomated and may require creation of aharness, stubs, or drivers.
2.2 Component Testing
A component is an aggregate of one ormore components (units may be consideredthe lowest level atomic test components onany project). Component testing expandsunit testing to include called componentsand data types. Component testing is oftenautomated and may require creation of harness, stubs, or drivers.
2.3 Single Step Testing
Single step testing is performed by steppingthrough new or modified statements of code with a debugger. Single step testing isnormally manual and informal.
2.4 Bench Testing
Bench testing is functional testing of acomponent after the system (or a verticalslice of the system that includes the new ormodified component) has been built in alocal environment. Bench testing is oftenmanual and informal.
2.5 Developer Integration Testing
Developer integration testing is functionaltesting of a component after thecomponent has been released and thesystem has been deployed in a standardtesting environment. Special attention isgiven to the flow of data between the newcomponent and the rest of the system.
2.6 Smoke Testing
Smoke testing determines whether thesystem is sufficiently stable and functionalto warrant the cost of further, more rigoroustesting. Smoke testing may alsocommunicate the general disposition of thecurrent code base to the project team.Specific standards for the scope or formatof smoke test cases and for their successcriteria may vary widely among projects.
2.7 Feature Testing
Feature testing is functional testing directedat a specific feature of the system. Thefeature is tested for correctness and properintegration into the system. Feature testingoccurs after all components of a featurehave been completed and released bydevelopment.
2.8 Integration Testing
Integration testing focuses on verifying thefunctionality and stability of the overallsystem when it is integrated with externalsystems, subsystems, third partycomponents, or other external interfaces.
2.9 System Testing
System testing occurs when all necessarycomponents have been released internallyand the system has been deployed onto astandard environment. System testing isconcerned with the behavior of the wholesystem. When appropriate, system testingencompasses all external software,

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->