Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
17Activity
0 of .
Results for:
No results containing your search query
P. 1
Test Case Design Methods

Test Case Design Methods

Ratings:

5.0

(1)
|Views: 675|Likes:
Published by Amit Rathi

More info:

Published by: Amit Rathi on Dec 03, 2008
Copyright:Attribution Non-commercial

Availability:

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

06/22/2011

pdf

text

original

 
divineQA Testing
2 Test Case Design Methods
2.1Introduction
A rich variety of test case design methods have evolved for software. Thesemethods provide the developer with a systematic approach to testing moreimportant, method provide a mechanism that can help to ensure the completenessof tests and provide the highest likelihood for uncovering errors in software.Any engineered product can be tested in one of the two ways: (1) Knowing thespecified function that a product has been designed to perform,tests can becondcuted that demonstrated each function is fully opertational while at the sametime searching for errors in each function; (2)Knowing the internal workings of aproduct tests can be condcuted to ensure that " all gears mesh",that is internaloperations are performed accrosding to specifications and all internal componentshav been adquetaely excersied .the first test approach is called black box testingand the second white box testing .Black box tests are conducted at the software interface level.Although they aredesigned to unc over errors,black boc tests are used to demonstrated that softwarefunctions are operational, that input is properly accepted and output is correctly produced and the integrity of external information is maintained.A black box testexamines some fundamaental aspect of a system with little regard for the internallogic structure of the software.Black box testing is also called behavioural testing.It foucses on the functional requirements of the software.White box testing of software involves close examination of procedural detail.logical paths through thesoftware are tested by providing test cases that exercise specific sets of conditionsand for loops.The "status of the program" may be examined at various points todetermine if the expected or asserted status corresponds to the actual status.The attribuets of both black box and white box testing can be combined to providean approach that validates the software interface and selectively ensures that theinternal workings of the software are correct.
2.2Test Specifications
Test designs specifications defines the approach for testing, test techniques to beused, test case design methods to be used, test environment, etc. Testspecifications are documented in the test plan.A test suite is a framework that provides for a way of grouping test cases. A testsuite may consist of test cases to test a specific functionality. For instance a testcase for testing a specific user interface (or web page) can be grouped together toform a test suite. Each test suite and its test cases should be uniquely identifiable.
Page 1 of 13
 
divineQA Testing
A test case contains a description of the test that needs to be conducted on asystem. A test case is reusable and may be included in one or more test suites.Test case description typically includes the following:
Test case identifier:
A unique name or number 
Purpose:
What features, path etc are being tested?
Reference:
Reference to specifications and design documents should be provided
Input:
Input consists of input data and/or input actions. Input datamay include or data items to be entered online or datarecords in a file or database to be set up or data items to beinput from the interface of some other software systems.Input actions include keyboard or mouse actions/commandsfor navigation and control necessary for online interaction.
Output:
Output consists of output data and/or outcome. Output dataconsists of messages, reports, etc., that would be output oncompletion of the test case. Outcome describes reaching aspecific state, for instance successful completion of atransaction.
Environment:
List specific hardware, software and network configurationthat needs to be set up for the test.
Procedure:
Test procedure describe the steps for the test setup, teststarting, test executions, results logging, recordingmeasurements, test stopping, and contingency (what to dowhen it all goes wrong). Test steps may also describe howand where to restart a test after a shut down.
Constraints:
Any constraints on performing the test cases.
Dependencies:
What tests have to be executed before this on and what if the program fails them?
Feature pass/Fail:
A criteria that describes under what circumstances a featurecan be considered as "passed"(Test has failed) or "failed"(Test has succeeded) some tines we may describe a"partial pass" criteria also.Depending on the complexity of the software system and the level of testing(Unit, Integration, System and Acceptance) some or all of the items stated abovecould be included in a test case template for recording test case design.
2.3Test Case Template
Depending on testing requirement and the level of testing (Unit, Integration,System and Acceptance) one of the following test case templates may be used for the test case design. 
Page 2 of 13
 
divineQA TestingType 1:Test case Name:
Mnemonic identifier 
Test Id:
 Numeric identifier 
Test suite Id:
Test suite(s) identifier (numeric)
Feature:
System/application feature being tested
Priority:
Priority assigned to the test
Environment:
Hardware and software required
Duration:
Test schedule
Effort:
Person hours
Set up:
List steps needed to set up test
Test step:
Test steps and sub test steps for starting; conducting andstopping the test. For each test step the following itemsshall be defined<Test step No.> < Step description > < Input/Input action><Output/Out come> <Result> <Bug identification Id>
Feature Pass/Fail:
Pass: Output and out come expected for complete passFail: Output and outcome expected for failurePartial pass: Output and out come expected for partial pass
Type 2:Test case Name:
Mnemonic identifier 
Test case Id:
Numeric identifier 
Test suite Id:
Test suite(s) identifier 
Purpose:
What feature it tests
Priority:
Priority assigned to the test
Input:
Data input/input actions
Output:
Output and outcome expected (Pass/Fail/Partial Pass)
Environment:
Hardware and software required
Procedure:
<Set up procedure><Test steps><Test stop and wrap up steps>
Constraints:
Any constraint associated with the test
Dependencies:
Inter dependency with the other test cases
Type 3:Test case Id:
Numeric identifier 
Test suite Id:
Test suite(s) identifier 
Purpose:
What feature it tests
Priority:
Priority assigned to the test
Input:
Data input/input actions
Output:
Output and outcome expected (Pass/Fail)
Test step:
Test steps and sub test steps for starting, conductingand stopping the test
Constraints:
Constraints on the testThe environment requirement and test setup procedure are described at test suite level only
Page 3 of 13

Activity (17)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Larry Garcia liked this
suneelsohal liked this
atulsinghchouhan liked this
qaswedfrt45 liked this
Romariosun liked this
sasikalamsc2007 liked this
swatiqa liked this

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)//-->