SlideShare ist ein Scribd-Unternehmen logo
1 von 88
SOFTWARE TESTİNG
Content ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
INTRODUCTION TO SOFTWARE TESTING ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Why Do Bugs Occur? ,[object Object]
The Cost of Bugs
Cost of Software Engineering
Budget Saving
What Does a Software Tester Do? ,[object Object],[object Object],[object Object]
Ontologies for Software Engineering and Software Technology ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Ontologies for Software Engineering and Software Technology ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
SOFTWARE TESTING TECHNIQUES ,[object Object],[object Object],[object Object],[object Object],[object Object]
Software Testing Prinpicles ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Testability ,[object Object],[object Object],[object Object],[object Object]
Testability (Cont.)‏ ,[object Object],[object Object],[object Object]
Test Case Design ,[object Object],[object Object],[object Object],[object Object]
Control Structure Testing ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
SOFTWARE TESTING STRATEGIES ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
SOFTWARE TESTING STRATEGY ,[object Object],[object Object],[object Object],[object Object]
SOFTWARE TESTING STRATEGY ,[object Object],[object Object]
VERIFICATION And VALIDATION ,[object Object],[object Object]
ORGANIZING FOR SOFTWARE TESTING ,[object Object]
SOFTWARE TESTING STRATEGY
SOFTWARE TESTING STRATEGY
SOFTWARE TESTING STRATEGY ,[object Object],[object Object],[object Object],[object Object]
CRITERIA FOR COMPLETION OF TESTING ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
STRATEGIC ISSUES ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
UNIT TESTING
UNIT TESTING ,[object Object],[object Object],[object Object],[object Object],[object Object]
What errors are commonly found during unit testing? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Potential errors while error handling is evaluated ,[object Object],[object Object],[object Object],[object Object],[object Object]
Unit Test Procedures
Unit Test Procedures ,[object Object],[object Object],[object Object],[object Object]
INTEGRATION TESTING ,[object Object],[object Object],[object Object],[object Object]
Top-down Integration ,[object Object],[object Object]
Top-down Integration ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Bottom-up Integration
Bottom-up Integration ,[object Object],[object Object],[object Object],[object Object],[object Object]
Regression Testing ,[object Object],[object Object],[object Object],[object Object]
Regression Testing The regression test suite (the subset of tests to be executed) contains three different classes of test cases: •  A representative sample of tests that will exercise all software functions. •  Additional tests that focus on software functions that are likely to be affected by the change. •  Tests that focus on the software components that have been changed.
Smoke Testing ,[object Object],[object Object],[object Object]
Smoke Testing ,[object Object],[object Object],[object Object],[object Object]
Comments on Integration  Testing ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Integration Testing Document ,[object Object],[object Object],[object Object]
Validation Testing ,[object Object],[object Object],[object Object]
Validation Testing Criteria ,[object Object],[object Object],[object Object],[object Object]
Configuration Review ,[object Object]
Alpha and Beta Testing ,[object Object],[object Object],[object Object]
System Testing ,[object Object],[object Object],[object Object],[object Object]
Recovery Testing ,[object Object],[object Object],[object Object]
Security Testing ,[object Object]
Stress Testing ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Performance Testing ,[object Object],[object Object],[object Object],[object Object]
Debugging ,[object Object]
Why is debugging so difficult? 1. The symptom and the cause may be geographically remote. That is, the symptom may appear in one part of a program, while the cause may actually be located at a site that is far removed.  2. The symptom may disappear (temporarily) when another error is corrected. 3. The symptom may actually be caused by nonerrors (e.g., round-off inaccuracies). 4. The symptom may be caused by human error that is not easily traced. 5. The symptom may be a result of timing problems, rather than processing problems.
6. It may be difficult to accurately reproduce input conditions (e.g., a real-time application in which input ordering is indeterminate). 7. The symptom may be intermittent. This is particularly common in embedded systems that couple hardware and software inextricably. 8. The symptom may be due to causes that are distributed across a number of tasks running on different processors [CHE90].
When I correct an error, what questions should I ask myself? ,[object Object],[object Object]
When I correct an error, what questions should I ask myself? ,[object Object],[object Object]
When I correct an error, what questions should I ask myself? ,[object Object],[object Object]
SOFTWARE TESTING TOOLS ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Borland SILKTEST ,[object Object],[object Object],[object Object],[object Object]
SILKTEST
SAMPLE SCRIPT FOR SILKTEST Browser.LoadPage ("mail.yoo.com")‏ Sign In YahooMail.SetActive ()‏ SignIn Yahoo.Mail.objSingIn YahooMail.SignUp.Now.Click()‏ Sleep (3)‏ WelcomeTo Yahoo.Set Active Welcome To yahoo.objWelcomeToYahoo.LastName.SetText("lastname")‏ Welcome To Yahoo.objWelcomeToYahoo.LanguageContent.Select(5)‏ WelcomeTo Yahoo.objWelcome ToYahoo.ContactMeOccassionally About.Click ()‏ Welcome To Yahoo.objWelcome To Yahoo.Submit ThisForm.Click()‏ If Registration Success.Exists ()‏ Print ("Test Pass")‏ else logerror ("Test Fail")‏
HP QuickTest Professional TM  - E-business functional testing LoadRunner® - Enterprise load testing  TestDirector TM  – Integrated test management  WinRunner® - Test automation for the enterprise
HP QUICKTEST
HP LOADRUNNER
Unit Testing – C# – NUnit namespace bank { public class Account { private float balance; public void Deposit(float amount)‏ { balance+=amount; } public void Withdraw(float amount)‏ { balance-=amount; } public void TransferFunds(Account destination, float amount)‏ { } public float Balance { get{ return balance;} } } } namespace bank { using NUnit.Framework; [TestFixture] public class AccountTest { [Test] public void TransferFunds()‏ { Account source = new Account(); source.Deposit(200.00F); Account destination = new Account(); destination.Deposit(150.00F); source.TransferFunds(destination, 100.00F); Assert.AreEqual(250.00F, destination.Balance); Assert.AreEqual(100.00F, source.Balance); } } }
Software Testing Environments ,[object Object]
CLASSICAL TESTING MISTAKES ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
CLASSICAL TESTING MISTAKES ,[object Object],[object Object],[object Object],[object Object]
GOOD SOFTWARE TESTING ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Test Documentation ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
References ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
More Resources
Basis Path Testing ,[object Object]
Basis Path Testing ,[object Object]
Basis Path Testing ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Basis Path Testing ,[object Object],[object Object],[object Object],[object Object],[object Object]
Basis Path Testing
Basis Path Testing V(G) = 6 regions V(G) = 17 edges  13 nodes + 2 = 6 V(G) = 5 predicate nodes + 1 = 6 path 1: 1-2-10-11-13 path 2: 1-2-10-12-13 path 3: 1-2-3-10-11-13 path 4: 1-2-3-4-5-8-9-2-. . . path 5: 1-2-3-4-5-6-8-9-2-. . . path 6: 1-2-3-4-5-6-7-8-9-2-. . .
Basis Path Testing Path 1 test case: value( k) = valid input, where k < i for 2 ≤ i ≤ 100 value( i) = 999 where 2 ≤ i ≤ 100 Expected results: Correct average based on k values and proper totals. Note: Path 1 cannot be tested stand-alone but must be tested as part of path 4, 5, and  6 tests. Path 2 test case: value(1) = 999 Expected results: Average = 999; other totals at initial values. Path 3 test case: Attempt to process 101 or more values. First 100 values should be valid. Expected results: Same as test case 1. Path 4 test case: value( i) = valid input where i < 100 value( k) < minimum where k < i Expected results: Correct average based on k values and proper totals. Path 5 test case: value( i) = valid input where i < 100 value( k) > maximum where k <= i Expected results: Correct average based on n values and proper totals. Path 6 test case: value( i) = valid input where i < 100 Expected results: Correct average based on n values and proper totals.
Basis Path Testing Graph Matrices
Control Structure Testing
Black-Box Testing Error Categories (1) incorrect or missing functions (2) interface errors (3) errors in data structures or external database access (4) behavior or performance errors (5) initialization and termination errors
Graph-Based Testing
Behavioral Testing Models Transaction flow modeling:  The nodes represent steps in some transaction (e.g., the steps required to make an airline reservation using an on-line service), and the links represent the logical connection between steps (e.g.,  flight.information.input  is followed by   validation/availability.processing). Finite state modeling:  The nodes represent different user observable states of the software  and the links represent the transitions that occur to move from state to state (e.g.,  order-information  is verified during inventory- availability look-up and is followed by  customer-billing-information input).  Data flow modeling:  The nodes are data objects and the links are the transformations that occur to translate one data object into another. For example, the node  FICA.tax.withheld (FTW)  is computed from  gross.wages (GW)  using the relationship,  FTW = 0.62  GW.  Timing modeling:   The nodes are program objects and the links are the sequential connections between those objects. Link weights are used to specify the required execution times as the program executes.
Equivalance Partitioning area code —blank or three-digit number prefix —three-digit number not beginning with 0 or 1 suffix —four-digit number password —six digit alphanumeric string commands —check, deposit, bill pay, and the like area code:  Input condition,  Boolean—the area code may or may not be  present. Input condition,  range—values defined between 200 and 999, with  specific exceptions. prefix:  Input condition,  range—specified value >200 Input condition, value—four-digit length password:  Input condition,  Boolean—a password may or may not be present. Input condition,  value—six-character string. command:  Input condition,  set—containing commands noted previously. ............ -2 -1  0 1 ............ 12  13 14 15 .....  invalid partition 1  valid partition  invalid partition 2
Boundary Value Analysis Guidelines for BVA 1. For input  ranges  bounded by  a  and  b , test cases should include values  a  and  b  and just above and just below  a  and  b  respectively. 2. If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits. 3. Apply guidelines 1 and 2 to output conditions.  4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.
Cause-Effect Graphing ,[object Object],[object Object],[object Object],[object Object],[object Object]

Weitere ähnliche Inhalte

Was ist angesagt?

Software Testing Fundamentals
Software Testing FundamentalsSoftware Testing Fundamentals
Software Testing FundamentalsChankey Pathak
 
Testing concepts [3] - Software Testing Techniques (CIS640)
Testing concepts [3] - Software Testing Techniques (CIS640)Testing concepts [3] - Software Testing Techniques (CIS640)
Testing concepts [3] - Software Testing Techniques (CIS640)Venkatesh Prasad Ranganath
 
Software testing.ppt
Software testing.pptSoftware testing.ppt
Software testing.pptKomal Garg
 
Software Testing Introduction
Software Testing IntroductionSoftware Testing Introduction
Software Testing IntroductionArunKumar5524
 
Introduction to software testing
Introduction to software testingIntroduction to software testing
Introduction to software testingHadi Fadlallah
 
SOFTWARE TESTING UNIT-4
SOFTWARE TESTING UNIT-4  SOFTWARE TESTING UNIT-4
SOFTWARE TESTING UNIT-4 Mohammad Faizan
 
Types of Software Testing | Edureka
Types of Software Testing | EdurekaTypes of Software Testing | Edureka
Types of Software Testing | EdurekaEdureka!
 
Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...
Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...
Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...Ankit Prajapati
 
UNIT TESTING PPT
UNIT TESTING PPTUNIT TESTING PPT
UNIT TESTING PPTsuhasreddy1
 
Non Functional Testing
Non Functional TestingNon Functional Testing
Non Functional TestingNishant Worah
 
Software testing & Quality Assurance
Software testing & Quality Assurance Software testing & Quality Assurance
Software testing & Quality Assurance Webtech Learning
 
What is Integration Testing? | Edureka
What is Integration Testing? | EdurekaWhat is Integration Testing? | Edureka
What is Integration Testing? | EdurekaEdureka!
 

Was ist angesagt? (20)

Software Testing Fundamentals
Software Testing FundamentalsSoftware Testing Fundamentals
Software Testing Fundamentals
 
Software testing ppt
Software testing pptSoftware testing ppt
Software testing ppt
 
Types of testing
Types of testingTypes of testing
Types of testing
 
Testing concepts [3] - Software Testing Techniques (CIS640)
Testing concepts [3] - Software Testing Techniques (CIS640)Testing concepts [3] - Software Testing Techniques (CIS640)
Testing concepts [3] - Software Testing Techniques (CIS640)
 
Software testing.ppt
Software testing.pptSoftware testing.ppt
Software testing.ppt
 
Software Testing Introduction
Software Testing IntroductionSoftware Testing Introduction
Software Testing Introduction
 
Manual testing ppt
Manual testing pptManual testing ppt
Manual testing ppt
 
Introduction to software testing
Introduction to software testingIntroduction to software testing
Introduction to software testing
 
SOFTWARE TESTING UNIT-4
SOFTWARE TESTING UNIT-4  SOFTWARE TESTING UNIT-4
SOFTWARE TESTING UNIT-4
 
STLC
STLCSTLC
STLC
 
Software testing
Software testing Software testing
Software testing
 
Types of Software Testing | Edureka
Types of Software Testing | EdurekaTypes of Software Testing | Edureka
Types of Software Testing | Edureka
 
Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...
Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...
Software Testing - Part 1 (Techniques, Types, Levels, Methods, STLC, Bug Life...
 
Agile testing
Agile testingAgile testing
Agile testing
 
UNIT TESTING PPT
UNIT TESTING PPTUNIT TESTING PPT
UNIT TESTING PPT
 
Non Functional Testing
Non Functional TestingNon Functional Testing
Non Functional Testing
 
Software testing & Quality Assurance
Software testing & Quality Assurance Software testing & Quality Assurance
Software testing & Quality Assurance
 
3.software testing
3.software testing3.software testing
3.software testing
 
What is Integration Testing? | Edureka
What is Integration Testing? | EdurekaWhat is Integration Testing? | Edureka
What is Integration Testing? | Edureka
 
Introduction & Manual Testing
Introduction & Manual TestingIntroduction & Manual Testing
Introduction & Manual Testing
 

Ähnlich wie Basic software-testing-concepts (20)

Chapter 9 Testing Strategies.ppt
Chapter 9 Testing Strategies.pptChapter 9 Testing Strategies.ppt
Chapter 9 Testing Strategies.ppt
 
Software testing
Software testingSoftware testing
Software testing
 
softwaretestingppt-120810095500-phpapp02 (1).pdf
softwaretestingppt-120810095500-phpapp02 (1).pdfsoftwaretestingppt-120810095500-phpapp02 (1).pdf
softwaretestingppt-120810095500-phpapp02 (1).pdf
 
Software testing
Software testingSoftware testing
Software testing
 
Software Testing - SDLC Model
Software Testing - SDLC ModelSoftware Testing - SDLC Model
Software Testing - SDLC Model
 
Testing ppt
Testing pptTesting ppt
Testing ppt
 
Testing and Mocking Object - The Art of Mocking.
Testing and Mocking Object - The Art of Mocking.Testing and Mocking Object - The Art of Mocking.
Testing and Mocking Object - The Art of Mocking.
 
Software Testing
Software TestingSoftware Testing
Software Testing
 
Software testing
Software testingSoftware testing
Software testing
 
Testing
TestingTesting
Testing
 
Object Oriented Testing
Object Oriented TestingObject Oriented Testing
Object Oriented Testing
 
Software testing basic
Software testing basicSoftware testing basic
Software testing basic
 
Blackbox
BlackboxBlackbox
Blackbox
 
Testing strategies in Software Engineering
Testing strategies in Software EngineeringTesting strategies in Software Engineering
Testing strategies in Software Engineering
 
Software testing
Software testingSoftware testing
Software testing
 
softwaretestingppt-FINAL-PPT-1
softwaretestingppt-FINAL-PPT-1softwaretestingppt-FINAL-PPT-1
softwaretestingppt-FINAL-PPT-1
 
Testing strategies
Testing strategiesTesting strategies
Testing strategies
 
Software test proposal
Software test proposalSoftware test proposal
Software test proposal
 
Software testing2
Software testing2Software testing2
Software testing2
 
Software testing
Software testingSoftware testing
Software testing
 

Mehr von medsherb

Unknown facts about sanitary pads
Unknown facts about sanitary padsUnknown facts about sanitary pads
Unknown facts about sanitary padsmedsherb
 
Qtp 9.2 examples
Qtp 9.2 examplesQtp 9.2 examples
Qtp 9.2 examplesmedsherb
 
Severity & priority in software testing
Severity & priority in software testingSeverity & priority in software testing
Severity & priority in software testingmedsherb
 
Qtp with descriptive programming
Qtp with descriptive programmingQtp with descriptive programming
Qtp with descriptive programmingmedsherb
 
Using correlation in loadrunner 80
Using correlation in loadrunner 80Using correlation in loadrunner 80
Using correlation in loadrunner 80medsherb
 
Qtp 9.2 tutorials
Qtp 9.2 tutorialsQtp 9.2 tutorials
Qtp 9.2 tutorialsmedsherb
 
Load runner 8.0
Load runner 8.0Load runner 8.0
Load runner 8.0medsherb
 
Loadrunner presentation
Loadrunner presentationLoadrunner presentation
Loadrunner presentationmedsherb
 
Testcase training
Testcase trainingTestcase training
Testcase trainingmedsherb
 
Unit testing
Unit testingUnit testing
Unit testingmedsherb
 
Qtp 8.0 basic
Qtp 8.0 basicQtp 8.0 basic
Qtp 8.0 basicmedsherb
 

Mehr von medsherb (11)

Unknown facts about sanitary pads
Unknown facts about sanitary padsUnknown facts about sanitary pads
Unknown facts about sanitary pads
 
Qtp 9.2 examples
Qtp 9.2 examplesQtp 9.2 examples
Qtp 9.2 examples
 
Severity & priority in software testing
Severity & priority in software testingSeverity & priority in software testing
Severity & priority in software testing
 
Qtp with descriptive programming
Qtp with descriptive programmingQtp with descriptive programming
Qtp with descriptive programming
 
Using correlation in loadrunner 80
Using correlation in loadrunner 80Using correlation in loadrunner 80
Using correlation in loadrunner 80
 
Qtp 9.2 tutorials
Qtp 9.2 tutorialsQtp 9.2 tutorials
Qtp 9.2 tutorials
 
Load runner 8.0
Load runner 8.0Load runner 8.0
Load runner 8.0
 
Loadrunner presentation
Loadrunner presentationLoadrunner presentation
Loadrunner presentation
 
Testcase training
Testcase trainingTestcase training
Testcase training
 
Unit testing
Unit testingUnit testing
Unit testing
 
Qtp 8.0 basic
Qtp 8.0 basicQtp 8.0 basic
Qtp 8.0 basic
 

Basic software-testing-concepts

  • 2.
  • 3.
  • 4.
  • 5. The Cost of Bugs
  • 6. Cost of Software Engineering
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 24.
  • 25.
  • 26.
  • 28.
  • 29.
  • 30.
  • 32.
  • 33.
  • 34.
  • 35.
  • 37.
  • 38.
  • 39. Regression Testing The regression test suite (the subset of tests to be executed) contains three different classes of test cases: • A representative sample of tests that will exercise all software functions. • Additional tests that focus on software functions that are likely to be affected by the change. • Tests that focus on the software components that have been changed.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
  • 45.
  • 46.
  • 47.
  • 48.
  • 49.
  • 50.
  • 51.
  • 52.
  • 53.
  • 54. Why is debugging so difficult? 1. The symptom and the cause may be geographically remote. That is, the symptom may appear in one part of a program, while the cause may actually be located at a site that is far removed. 2. The symptom may disappear (temporarily) when another error is corrected. 3. The symptom may actually be caused by nonerrors (e.g., round-off inaccuracies). 4. The symptom may be caused by human error that is not easily traced. 5. The symptom may be a result of timing problems, rather than processing problems.
  • 55. 6. It may be difficult to accurately reproduce input conditions (e.g., a real-time application in which input ordering is indeterminate). 7. The symptom may be intermittent. This is particularly common in embedded systems that couple hardware and software inextricably. 8. The symptom may be due to causes that are distributed across a number of tasks running on different processors [CHE90].
  • 56.
  • 57.
  • 58.
  • 59.
  • 60.
  • 62. SAMPLE SCRIPT FOR SILKTEST Browser.LoadPage (&quot;mail.yoo.com&quot;)‏ Sign In YahooMail.SetActive ()‏ SignIn Yahoo.Mail.objSingIn YahooMail.SignUp.Now.Click()‏ Sleep (3)‏ WelcomeTo Yahoo.Set Active Welcome To yahoo.objWelcomeToYahoo.LastName.SetText(&quot;lastname&quot;)‏ Welcome To Yahoo.objWelcomeToYahoo.LanguageContent.Select(5)‏ WelcomeTo Yahoo.objWelcome ToYahoo.ContactMeOccassionally About.Click ()‏ Welcome To Yahoo.objWelcome To Yahoo.Submit ThisForm.Click()‏ If Registration Success.Exists ()‏ Print (&quot;Test Pass&quot;)‏ else logerror (&quot;Test Fail&quot;)‏
  • 63. HP QuickTest Professional TM - E-business functional testing LoadRunner® - Enterprise load testing TestDirector TM – Integrated test management WinRunner® - Test automation for the enterprise
  • 66. Unit Testing – C# – NUnit namespace bank { public class Account { private float balance; public void Deposit(float amount)‏ { balance+=amount; } public void Withdraw(float amount)‏ { balance-=amount; } public void TransferFunds(Account destination, float amount)‏ { } public float Balance { get{ return balance;} } } } namespace bank { using NUnit.Framework; [TestFixture] public class AccountTest { [Test] public void TransferFunds()‏ { Account source = new Account(); source.Deposit(200.00F); Account destination = new Account(); destination.Deposit(150.00F); source.TransferFunds(destination, 100.00F); Assert.AreEqual(250.00F, destination.Balance); Assert.AreEqual(100.00F, source.Balance); } } }
  • 67.
  • 68.
  • 69.
  • 70.
  • 71.
  • 72.
  • 74.
  • 75.
  • 76.
  • 77.
  • 79. Basis Path Testing V(G) = 6 regions V(G) = 17 edges 13 nodes + 2 = 6 V(G) = 5 predicate nodes + 1 = 6 path 1: 1-2-10-11-13 path 2: 1-2-10-12-13 path 3: 1-2-3-10-11-13 path 4: 1-2-3-4-5-8-9-2-. . . path 5: 1-2-3-4-5-6-8-9-2-. . . path 6: 1-2-3-4-5-6-7-8-9-2-. . .
  • 80. Basis Path Testing Path 1 test case: value( k) = valid input, where k < i for 2 ≤ i ≤ 100 value( i) = 999 where 2 ≤ i ≤ 100 Expected results: Correct average based on k values and proper totals. Note: Path 1 cannot be tested stand-alone but must be tested as part of path 4, 5, and 6 tests. Path 2 test case: value(1) = 999 Expected results: Average = 999; other totals at initial values. Path 3 test case: Attempt to process 101 or more values. First 100 values should be valid. Expected results: Same as test case 1. Path 4 test case: value( i) = valid input where i < 100 value( k) < minimum where k < i Expected results: Correct average based on k values and proper totals. Path 5 test case: value( i) = valid input where i < 100 value( k) > maximum where k <= i Expected results: Correct average based on n values and proper totals. Path 6 test case: value( i) = valid input where i < 100 Expected results: Correct average based on n values and proper totals.
  • 81. Basis Path Testing Graph Matrices
  • 83. Black-Box Testing Error Categories (1) incorrect or missing functions (2) interface errors (3) errors in data structures or external database access (4) behavior or performance errors (5) initialization and termination errors
  • 85. Behavioral Testing Models Transaction flow modeling: The nodes represent steps in some transaction (e.g., the steps required to make an airline reservation using an on-line service), and the links represent the logical connection between steps (e.g., flight.information.input is followed by validation/availability.processing). Finite state modeling: The nodes represent different user observable states of the software and the links represent the transitions that occur to move from state to state (e.g., order-information is verified during inventory- availability look-up and is followed by customer-billing-information input). Data flow modeling: The nodes are data objects and the links are the transformations that occur to translate one data object into another. For example, the node FICA.tax.withheld (FTW) is computed from gross.wages (GW) using the relationship, FTW = 0.62 GW. Timing modeling: The nodes are program objects and the links are the sequential connections between those objects. Link weights are used to specify the required execution times as the program executes.
  • 86. Equivalance Partitioning area code —blank or three-digit number prefix —three-digit number not beginning with 0 or 1 suffix —four-digit number password —six digit alphanumeric string commands —check, deposit, bill pay, and the like area code: Input condition, Boolean—the area code may or may not be present. Input condition, range—values defined between 200 and 999, with specific exceptions. prefix: Input condition, range—specified value >200 Input condition, value—four-digit length password: Input condition, Boolean—a password may or may not be present. Input condition, value—six-character string. command: Input condition, set—containing commands noted previously. ............ -2 -1 0 1 ............ 12 13 14 15 ..... invalid partition 1 valid partition invalid partition 2
  • 87. Boundary Value Analysis Guidelines for BVA 1. For input ranges bounded by a and b , test cases should include values a and b and just above and just below a and b respectively. 2. If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits. 3. Apply guidelines 1 and 2 to output conditions. 4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.
  • 88.