stub driver

7
[email protected] WR testing Process - 6 steps WR running the scripts 3 types WR recording modes WR GUI map 2 types WR Checkpoints 3 types(in detail) WR Exception Handlings 2 types (i hope, object & bitmap) WR Break Points WR Commands WR File comparision, srting comparision, string in a file comparision WR data driven wizard & comments inserted due to this WR commands for clicking button, editing the text, selecting the list items, status of buttons (enable, disable, focussed, non focussed) WR Scripting for verifying an image (Use Case: enter the path/select from the list, image is displayed on the same window, verify the image) WR Advantages & disadvantages WR running a script - 3 ways step, step in, step out WR Test results, format WR database- connecting, fetching a row, counting rows/columns, closing the connection, 2 types of db (ODBC & Data Junction) WR printing the messages WR Testing Concepts Testing techniques 2 type and explain them in brief Testing types - unit, integration, system, smoke, performance...etc SDLC min 3 type & 1 to explain in detail(Waterfall, spiral, V model)

Upload: banhi

Post on 10-Apr-2015

523 views

Category:

Documents


7 download

TRANSCRIPT

Page 1: stub driver

[email protected]

WR testing Process - 6 stepsWR running the scripts 3 typesWR recording modesWR GUI map 2 typesWR Checkpoints 3 types(in detail)WR Exception Handlings 2 types (i hope, object & bitmap)WR Break PointsWR CommandsWR File comparision, srting comparision, string in a file comparisionWR data driven wizard & comments inserted due to thisWR commands for clicking button, editing the text, selecting the list items, status of buttons (enable, disable, focussed, non focussed)WR Scripting for verifying an image (Use Case: enter the path/select from the list, image is displayed on the same window, verify the image)WR Advantages & disadvantagesWR running a script - 3 ways step, step in, step outWR Test results, formatWR database- connecting, fetching a row, counting rows/columns, closing the connection, 2 types of db (ODBC & Data Junction)WR printing the messagesWR

Testing ConceptsTesting techniques 2 type and explain them in briefTesting types - unit, integration, system, smoke, performance...etcSDLC min 3 type & 1 to explain in detail(Waterfall, spiral, V model)Bug life cycleCMM Level in briefUsability

Page 2: stub driver

Hello Vidya...

Thanks for excellent reply.

The example given really precise the definition.

Will be grateful if you can clear bit more on this. Actually i have somecontradict queries.Can i ping you in id (You need to give me) to clear my doubts.

My ID: [email protected]

Best RegdsManas Patra

vidya kulkarni <[email protected] To: [email protected] m> cc: Sent by: Subject: RE: [TESTINGKINGS] [Help] Difference between stubs and Testingkings@yahoo drivers....ASAP groups.com

08/02/2006 06:27 AM Please respond to Testingkings

Hi,

While doing integration testing,if we do not have all the modules availablewhich are required for testing then we use stubs and drivers.

Basically stubs and drivers are the piese of code that simulate theactivity of missing modules.

For eg: If you have module X and calls functions from module Y and Z.Andyou asked to test module X but Yand Z modules are not available to you.

Then you need to come up with some sort of dummy code to mimick module YandZ.This dummy piece of code is called stub.

So stubs are "called functions" used in Top-Down Integration Testing.

Page 3: stub driver

Similar to above example,Now if you have Y and Z modules are available ButX module is not availble and asked to test Yand Z modules.

Now you need to come up with some dummy code to drive Yand Z.This piece ofcode is called driver.

So drivers are "calling functions" used in Bottom -Up integration Testing.

RgdsVidya

"Gunasekaran, Sureshkumar" <[email protected]> wrote:

Hi,

Stubs

In Top? Down integration testing we use dummy modules to do theintegration testing. Those dummy modules are called as stubs

Drivers

In Bottom? Down integration testing we use dummy modules to do theintegration testing. Those dummy modules are called as drivers.

For more detail

Stubs and DriversA software application is made up of a number of 'Units', where outputof one 'Unit' goes as an 'Input' of another Unit. e.g. A 'Sales OrderPrinting' program takes a 'Sales Order' as an input, which is actuallyan output of 'Sales Order Creation' program.Due to such interfaces, independent testing of a Unit becomesimpossible. But that is what we want to do; we want to test a Unit inisolation! So here we use 'Stub' and 'Driver.A 'Driver' is a piece of software that drives (invokes) the Unit beingtested. A driver creates necessary 'Inputs' required for the Unit andthen invokes the Unit.A Unit may reference another Unit in its logic. A 'Stub' takes placeof such subordinate unit during the Unit Testing. A 'Stub' is a pieceof software that works similar to a unit which is referenced by theUnit being tested, but it is much simpler that the actual unit. A Stubworks as a 'Stand-in' for the subordinate unit and provides theminimum required behavior for that unit.Programmer needs to create such 'Drivers' and 'Stubs' for carrying outUnit Testing.

Page 4: stub driver

Both the Driver and the Stub are kept at a minimum level ofcomplexity, so that they do not induce any errors while testing theUnit in question.Example - For Unit Testing of 'Sales Order Printing' program, a'Driver' program will have the code which will create Sales Orderrecords using hard coded data and then call 'Sales Order Printing'program. Suppose this printing program uses another unit whichcalculates Sales discounts by some complex calculations. Then call tothis unit will be replaced by a 'Stub', which will simply return fixdiscount data.

Integration testing is to test the data flow between the two modules,If the data flow between the two modules is ok than integration test pass.Types of integration 1.Top down2.Bottom-up3 Umberila approach (Big-Bang Approach)

Do u have the description of Big-Bang Approach?No. But it’s nothing but combination of Top down& Bottom up approach....Where all the modules are integrated at a time... & tested....

Test Life Cycle: - 1.Understding Requirement (SRS, BRS, BDD etc) 2.Writing the Test cases. 3.Review the Test Cases 4.Execute the Test Cases 5.Defect Tracking 6.Regression Testing 7.Test Report.