1 / 80

Software Testing Techniques (STT)

Software Testing Techniques (STT). Unit 3 – Transaction Flow & Data Flow testing. Sudhakar yadav. Compiled with reference from: Software Testing Techniques: Boris Beizer Craft of Software Testing: Brain Marrick. Transaction-Flow Testing. U2.

dcash
Télécharger la présentation

Software Testing Techniques (STT)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Testing Techniques (STT) Unit 3 – Transaction Flow & Data Flow testing Sudhakar yadav Compiled with reference from: Software Testing Techniques: Boris Beizer Craft of Software Testing: Brain Marrick

  2. Transaction-Flow Testing U2 • We will see in this part of Unit 2: • Concepts of Transaction flows • Transaction-flow testing ref boris beizer

  3. Transaction-Flow Testing U2 • Contents • Definitions of Transaction, Transaction flow, Transaction flow graph • It’s representation, implementation architecture in an O.S. & implementation in a system • A perspective of TFG model. View wrt DFG, CFG • Handling cases – decisions, biosis, mitosis, transactional junction, absorption & conjugation • TFG is not structured - Reasons • Transaction Flow Testing Techniques • Building transaction flows • Inspections, Reviews, and walkthroughs • Path selection • Path sensitization • Instrumentation • Test data bases • Test Execution • Transaction-flow implementation & testing related comments • Translation based systems • Hidden languages ref boris beizer

  4. Definitions of Transaction,Transaction-flow, TFG U2 • Transaction-flow • Transaction-flow represents a system’s processing. Functional testing methods are applied for testing T-F. • Transaction-flow Graph • TFG represents a behavioral (functional) model of the program (system) used for functional testing by an independent system tester. • Transaction • is a unit of work seen from system’s user point of view. • consists of a sequence of operations performed by a system, persons or external devices. • is created (birth) due to an external act & up on its completion (closure), it remains in the form of historical records. ref boris beizer

  5. A Simple Transaction U2-B Example: the sequence of steps in a transaction in an online information retrieval system 1. accept inputs 7. Accept Inputs 2. Validate inputs (Birth of tr.) 8. Validate inputs 3. Transmit ack. to the user 9. Process the request 4. Process input 10. Update file 5. Search file 11. Transmit output 6. Request direction from user 12. Record transaction in log & cleanup (Closure) Users View of a transaction: Single step Systems view : Sequence of many operations ref boris beizer

  6. cancel Request Type User Begin Request order from CPU Accept Order from CPU Process Form order B help Y More Fields? Transmit Page to terminal Accept Input Field Transmit To CPU B C D User wants Review? More Pages ? Valid ? Y CPU- Accept Confirm N N Done D Set up Review Transmit Diagnostic to Terminal C Example of a Transaction flow (diagram) U2 User (terminal) Terminal controller CPU ref boris beizer

  7. Definitions U2 • Transaction-flow Graph : a scenario between users & computer • Transaction-flow : an internal sequence of events in processing a transaction • Uses of Transaction-flow • Specifying requirements of big, online and complicated systems. • Airline reservation systems, air-traffic control systems. • Loops are less as compared to CFG. Loops are used for user input error processing ref boris beizer

  8. D Input S A S B S C S S Output E S : Scheduler A, B, C, D, E : Processes Implementation of Transaction-Flow (in a system) U2 • Implicit in the design of system’s control structure & associated database. • No direct one-to-one correspondence between the “processes” and “decisions” of transaction-flow, and the corresponding program component. • A transaction-flow is a path taken by the transaction through a succession of processing modules. • A transaction is represented by a token. • A transaction-flow graph is a pictorial representation of what happens to the tokens. ref boris beizer

  9. Output Queue Input Queue Front End EXECUTIVE SCHEDULER - AND / OR OPERATING SYSTEM DISPATCHER Output Module Process Queues A Processor B Processor C Processor D Processor E Processor Application Processes Executive / Dispatcher Flowchart (a sample sequence) Do All B’s Disc Reads Do All C’s Tape Writes Do All B’s Disc Writes 1 2 Do All D’s Disc Reads Do All A’s Tape Reads Do All E’s Disc Writes 2 1 Implementation of Transaction-Flow U2 System Control Structure (architecture of the implementation) : ref boris beizer

  10. Implementation of Transaction-Flow U2 • System control structure • System is controlled by a scheduler … • A Transaction is created by filling in a Transaction Control Block (TCB) by user inputs and by placing that token on input Q of Scheduler. • Scheduler examines and places it on appropriate process Q such as A. When A finishes with the Token, it places the TCB back on the scheduler Q. • Scheduler routes it to the next process after examining the token : • It contains tables or code to route a token to the next process. • It may contain routing information only in tables. • Scheduler contains no code / data. Processing modules contain code for routing. ref boris beizer

  11. Implementation of Transaction-Flow U2 • Transaction Processing System (simplified): • There are many Tr. & Tr-flows in the system. • Scheduler invokes processes A to E as well as disk & tape read & writes. • The order of execution depends on priority & other reasons. • Cyclic structure like in this example is common in process control & communication systems. •  The criteria for implementation mechanism depends on performance and resource optimization. ref boris beizer

  12. A perspective of Transaction-Flow U2 • Transaction-flow testing is a block box technique. (as we assumed nothing regarding computer, communications, environment, O.S., transaction identity or structure or state.) • TFG is a kind of DFG. • TFG has tokens, & DFG has data objects with history of operations applied on them. • Many techniques of CFG apply to TFG & DFG • Decision nodes of TFG have exception exits to the central recovery process. • So, we ignore the effect of interrupts in a Transaction-flow. ref boris beizer

  13. Alternative 2 Alternative 1 Parent Daughter Tr. Parent Parent Daughter Tr. Daughter Tr. U2-B • Splits of transactions (Births) • A decision point in TFG Transaction Flows – splitting & merging decisions • Biosis • Mitosis ref boris beizer

  14. Path 1 Continue Path 2 Daughter Tr. • Absorption Predator Predator • Conjugation Parent Daughter Parent U2 • Mergers of transactions • Junction Transaction Flows – splitting & merging decisions ref boris beizer

  15. U2 • NOTES: • Multiple meanings now for decision and junction symbols in a TFG. • Simple TFG model is not enough to represent multi-processor systems & associated coordination systems. • Petrinetmodel uses operations for all the above. But Petrinets are applied to H/W, N/W protocol testing – but not Software. TFG – splitting, merging Transactions ref boris beizer

  16. U2 • Simplify TFG model • Add New Tr-Flows for Biosis, Mitosis, Absorption, Conjugation • Problems for programmer, designer & test designer. • Need to design specific tests – possibility of bugs. Simplified TFG model ref boris beizer

  17. U2-B • Reasons for Unstructuredness • Processes involve Human Users • 2. Part of Flow from External Systems • 3. Errors, Failures, Malfunctions & Recovery Actions • 4. Transaction Count, Complexity. Customer & Environment Transaction-flow Structure ref boris beizer

  18. U2-B • Reasons for Unstructuredness … • New Transactions, & Modifications • Approximation to Reality • Attempt to Structure Transaction-flow Structure ref boris beizer

  19. U2-B • First, Build / Obtain Transaction Flows • Represent Explicitly • Design details the Main Tr-Flows • Create From PDL • HIPO charts & Petrinet Representations • Objective – Trace the transaction Transaction - Flow Testing - Steps ref boris beizer

  20. U2-B • Inspections, Reviews & Walkthroughs • Start From Preliminary Design • Conducting Walkthroughs • Discuss enough Transaction Types (98% Transactions) • User needs & Functional terms (Design independent) • Traceability to Requirements Transaction - Flow Testing - Steps ref boris beizer

  21. U2-B • Inspections, Reviews & Walkthroughs … • Design Tests for C1 + C2 coverage • Additional Coverage (> C1+C2) • Paths withloops, extreme values, domain boundaries • Weird cases, long & potentially troublesome Tr. • Design Test cases for Tr. Splits & mergers • Publish Selected Test Paths early • Buyer’s Acceptance – functional & acceptance tests Transaction - Flow Testing - Steps ref boris beizer

  22. U2-B • Path Selection • Covering Set (C1+C2) of Functionally Sensible Tr. • Add Difficult Paths • Review with designers & implementers • Exposure of interface problems & duplicated processing • Very few Implementation bugs may remain • Transaction-flow Path Covering Set belongs in • System Feature Tests Transaction - Flow Testing Techniques ref boris beizer

  23. U2-B • Sensitization • Functionally Sensible Paths – Simple • Error, Exception, External Protocol Interface Paths - Difficult • Testing Tr.–Flows with External Interfaces • Use patches & break points, mistune, and break the rules, Transaction - Flow Testing Techniques ref boris beizer

  24. U2-B • Instrumentation • Link Counters are not Useful. • Need • Trace • Queues on which Tokens resided • Entries to & Exits from Dispatcher • A Running Log • Make Instrumentation as part of System Design Transaction - Flow Testing Techniques ref boris beizer

  25. U2-B • Test Data bases • Design & Maintenance of a Test Data base - Effort • Mistakes • Unawareness about design of a centrally administered test DB • Test DB design by Testers • Using one DB for all tests (need 4 to 5) • Need experienced System & Test Designers Transaction - Flow Testing Techniques ref boris beizer

  26. U2-B • Test Execution • Use Test Execution Automation • Have to do a large # of Tests for C1+C2 coverage Transaction - Flow Testing Techniques ref boris beizer

  27. U2-B • Transaction based systems • TCB • Centralized, Common Processing Queues • Just O(n) Queues for Links of O(n2) • Transaction Dispatcher • Uses tables & Finite State Machines • Recovery & Other Logs • Key events in Tr – Flow • Self-Test Support • Privileged modes in Transaction control tables Transaction - Flow Testing - Implementation ref boris beizer

  28. U2-B • Hidden Languages (flow control language) • Transaction Flows based on control codes in TCB or DB • Undeclared. Syntax & Semantics are not debugged. • Possibility of bugs Transaction - Flow Testing - Caution ref boris beizer

  29. Software Testing Methodology U2 To Unit 3 : Data flow testing … ref boris beizer

  30. Data - Flow Testing - Basics U2 • We will see in this part of Unit 2: • Concepts of Data flows • Data-flow testing strategies ref boris beizer

  31. Data - Flow Testing - Basics U2 • Contents • Synopsis • Basics • Intro to Data flow, data flow graphs • Motivation & Assumption • Data flow model • Data Flow Testing Strategies • General strategy • Definitions • Strategies: • Slicing, Dicing, Data flow, Effectiveness • Application of DFT, Tools & Effectiveness ref boris beizer

  32. Data - Flow Testing - Basics U2 • Anomaly • Unreasonable processing on data • Use of data object before it is defined • Defined data object is not used • Data Flow Testing (DFT) uses Control Flow Graph (CFG) to explore dataflow anomalies. • DFT Leads to testing strategies between P and P1 / P2 ref boris beizer

  33. Data - Flow Testing - Basics U2 • Definition: • DFT is a family of test strategies based on selecting paths through the program’s control flow in order to explore the sequence of events related to the status of data objects. • Example: • Pick enough paths to assure that every data item has been initialized prior to its use, or that all objects have been used for something. ref boris beizer

  34. Data - Flow Testing - Basics U2 • Motivation • Confidence in the program • Data dominated design. Code migrates to data.. • Source Code for Data Declarations • Data flow Machines vs Von Neumann’s • Abstract M I M D • Language & compiler take care of parallel computations ref boris beizer

  35. a = n+m b=p+q c=a+b d=a-b e=c*d Data - Flow Testing - Basics - Motivation U2 • Program Control flow with Von Neumann’s paradigm • Given m, n, p, q, find e. • e = (m+n+p+q) * (m+n-p-q) • a := m + n • b := p + q • c := a + b • d := a - b • e := c * d • Multiple representations of control flow graphs possible. ref boris beizer

  36. Data - Flow Testing - Basics - Motivation U2 • Program Flow using Data Flow Machines paradigm • BEGIN • PAR DO • READ m, n, n, p, q • END PAR • PAR DO • a := m+n • b := p+q • END PAR • PAR DO • c := a+b • d := a-b • END PAR • PAR DO • e := c * d • END PAR • END p q m n a := m+n b := p+q c := a+b d := a-b e := c * d • The interrelations among the data items remain same. ref boris beizer

  37. Data - Flow Testing - Basics - Motivation U2 • Control flow graph • Multiple representations • Data Flow Graph • A spec. for relations among the data objects. • Covering DFG => Explore all relations under some test. ref boris beizer

  38. Data - Flow Testing - Basics U2 • Assumptions • Problems in a control flow • Problems with data objects ref boris beizer

  39. Data - Flow Testing - Basics U2 • Data Flow Graphs (DFG) • It is a graph with nodes & directed links • Test the Von Neumann way - • Convert to a CFG • Annotate : program actions (weights) ref boris beizer

  40. Data - Flow Testing - Basics U2 • Data Object State & Usage • Program Actions (d, k, u): • Defined (created) - explicitly or implicitly (d) • Killed (released) - directly or indirectly (k) • Used - (u) • In a calculation - (c) • In a predicate - directly or indirectly (p) ref boris beizer

  41. Data - Flow Testing - Basics U2 • Data Flow Anomalies • A Two letter sequence of Actions (d, k, u) • dd : harmless, suspicious • dk : probably a bug. • du : normal • kd : normal • kk : harmless, but probably a bug • ku : a bug • ud : normal. Redefinition. • uk : normal • uu : normal A Action ref boris beizer

  42. Data - Flow Testing - Basics - Motivation U2 • Program Flow using Data Flow Machines paradigm • BEGIN • PAR DO • READ m, n, n, p, q • END PAR • PAR DO • a := m+n • b := p+q • END PAR • PAR DO • c := a+b • d := a-b • END PAR • PAR DO • e := c * d • END PAR • END p q m n a := m+n b := p+q c := a+b d := a-b e := c * d • The interrelations among the data items remain same. ref boris beizer

  43. Data - Flow Testing - Basics – Data Flow Anomalies U2 • Actions on data objects • - no action from START to this point • From this point till the EXIT • - d normal • - u anomaly • - k anomaly • k- normal • u - normal - possibly an anomaly • d - possibly anomalous ref boris beizer

  44. Data - Flow Testing - Basics U2 • Data Flow Anomaly State graph • Data Object State • K, D, U, A • Processing Step • k, d, u ref boris beizer

  45. K k, u d u d, k U D A u d d, k, u Data - Flow Testing - Basics U2 • Data Flow Anomaly State graph • Object state • Unforgiving Data flow state graph Undefined Anomalous Defined Used ref boris beizer

  46. Data - Flow Testing - Basics U2 • Data Flow Anomaly State graph • Forgiving Data flow state graph u A  DD, DK, KU k u KU K k u k DK d k d u k U D d u d DD u d ref boris beizer

  47. Data - Flow Testing - Basics U2 • Data Flow State Graphs • Differ in processing of anomalies • Choice depends on Application, language, context ref boris beizer

  48. Data - Flow Testing - Basics U2 • Static vs Dynamic Anomaly Detection • Staticanalysis of data flows • Dynamic analysis • Intermediate data values ref boris beizer

  49. Data - Flow Testing - Basics U2 • Insufficiency of Static Analysis (for Data flow) • Validation of Dead Variables • Validation of pointers in Arrays • Validation of pointers for Records & pointers • Dynamic addresses for dynamic subroutine calls • Identifying False anomaly on an unachievable path • Recoverable anomalies & Alternate state graph • Concurrency, Interrupts, System Issues ref boris beizer

  50. Data - Flow Testing - Basics U2 • Data Flow Model • Based on CFG • CFG annotated with program actions • link weights : dk, dp, du etc.. • Not same as DFG • For each variable and data object ref boris beizer

More Related