0% found this document useful (0 votes)
59 views

Software Testing Question Paper

Uploaded by

VIMAL
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
59 views

Software Testing Question Paper

Uploaded by

VIMAL
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 33
University of Madras B.Sc. (CS) April 2011 SO419/SAZ6CISERG Time: Three hours Maximum: 75 mike tk: SECTION A- (10x 2=20 marks) Answer any TEN questions. All questions carry equal marks, Define Software. Give the purpose of testing. Why bug arises? What is meant by a graph? How to prepare the format for the test plan? Define test cases. Mention the types of testing. Why testing is difficult? Give the expansion of SQA. 10. Define Path 11. How error differs from a bug? 12. Give any two importances of decision tables, pen ar eer SECTION B (5 x5=25 marks) Answer any FIVE questions, All questions carry equal marks 13. How to maintain the quality in software? 14. Explain the technique of creating design style. 15. What is meant by path instrumentation? 16. Explain the concept of path testing. 17. Give the importance of domain testing. 18. Explain the concept of structural metrics. 19. How decision stables can be used for logic testing? SECTION C (3 x 10= 30 marks) Answer any THREE questions All questions carry equal marks 20. What is Bug? Discuss its types. 21, Discuss on transaction flow testing techniques. 22, How data flow testing strategies can be strengthened? 23. With an example, show how syntax testing is done. 24. Discuss the following: (@) Transaction Testing (b) State Testing. 4 Question Papers g yt a lt of fuarat Andra . se University of Madras so 188e. (C8) soa SEE 7 TACISEESBISEUGG 13. 14. 15. 16. 17. 18, 19. 2 a. 22. 23. m4. ). Lisl Maxitourn: 75 marks SECTION A- (102020 marks) “Answer any TEN questions All questions carry equal marks, ppefine Quality in olive, what do you mean by Bug! what are the various testing styles? pefin fow graph ; phat is called Transactions? Mention the various testing strategies, Define Path rite note on syntax testing, What is 4 path expression? 1 out the various formats of testing, ‘What are the contents in decision table? Define State Graph. SECTION B (5 75=25 marks) “Answer any FIVE questions All. questions carry equal marks Compare and contrast the functions of testing and debugging. Discuss in brief about types of bugs. Deseribe about transaction system properties. Write short notes on Domain Testing, Explain in brief about path expression and path products. Discuss in brief about logic based testing. Write notes on Transition testing. SECTION C (3 »10= 30 marks) “Answer any THREE questions All questions carry equal marks Write an overview about the following: (a) Model for Testing. (b) Consequence of Bugs. Explain in detail about application of path testing. Describe about dataflow testing strategies. Discuss about structural metric and linguistic metric. Write a detailed note on state testing. April 2011 Time: Three hours 1 4, 5. University of Madras B.Sc. (CS) 50419/SAZ6CISEESBISEUGG Maximum: 75 marks SECTION A- (10 x2=20 marks) Answer any TEN questions. All questions carry equal marks, Define Software, The logical components of a computer are called software, Or, a collection of programs is called software. A set of programs is also called software. Give the purpose of testing, © Testing consumes atleast half of the time and efforts Tequired to produce a functional program. © MYTH: Good Programmers write code without any bugs, (It’s wrong!!!) History says that even well written programs still have 1-3 bugs per hundred statements, Why bug arises? Most bugs arise from mistakes and errors made by people in cither a program's source code or its design, and a few are caused by compilers producing incorrect code, What is meant by a graph? A graph is a pictorial representation of a Program and not the program itself, just as a topographic map. How to prepare the format for the test plan? A test plan is a document detailing a systematic approach to testing a system such as amachine or software. The plan typically contains ‘a detailed understanding of what the eventual workflow will be. Define test cases, A test case it in software engineering is a set of conditions or variables under eS which a tester will determine whether an application or software systems is working correctly or not. Ne ith Answve Unie 2 Fe ay 7, Mention the types of esting e Functionality testing 2 Forced error testing © Compatibility testing © Performance testing 2 Scalability testing Stress testing 2 Usability testing ® Application security testing 3. Why testing is difficult? Software testing is probably the Most complex task in the software development cycle. It often takes longer to test a software than it does to vite the code. The problems discovered during the software testing phase add more time onto the coding phase, resulting in further delays in the product's release and so this vicious yele goes 9, Give the expansion of SQA, SQA- Software Quality Assurance 19, Define Path, Path is a sequence of statements Starting at an entry, junction or decision and ending at another, or Possibly the same junction or decision oran exit point, 11, How error differs from a bug? Usually an "error" refers to some bit of program. it may not conform to the language tuntime error (ex: division by zero). A "bug" programmer which causes the program to act was not designed to act. 12. Give any two importances of decision tables, ° illegal code in your grammar, or it might be a is a mistake made by the in a manner for which it Decision tables, especially when coupled with the use of adomain-specific language, allow developers and policy experts to work from the same information, the decision tables themselves, Decision tables have proven to be easier to understand and review than code, and have been used extensively and Successfully to produce specifications for complex systems. SECTION BS « 5=25 markyy Answer any FI ! questions All questions carry equal marks 13. How to maintain the quality in software? e In production of consumer goods and other prod, manufncturing stage is subjected to quality contro} iy Very from component to final stage, Ml testing + If flaws are discovered at any stage, the produ discarded or eyeled back for rework and coment Sither ¢ Productivity is measured by the sum Of the eo: material, the rework, and the di cost of quality assurance and tes MS Of the } Sand they! isearded component ing, © There is a tmdeofl between quality assurance com manufacturing costs: ficient time is not spent in i assurance, the rejection rate will be high and so will be cost. If inspection is good and all errors are ¢ occur, inspection costs will dominate, and apai will suffer. quality the net © Testing and Quality assurance costs for ‘manu can be as low as 2% in consumer products or products such as space-ships, nuclear reactor: factured' items high as 80% in * ae f and aircraft, where failures threaten life. Whereas the manufacturing cost of software is trivial. © The biggest part of software cost is the cost of bugs: the cost of detecting them, the cost of correcting them, the cost of 16 designing tests that discover them, and the cost of running those tests. © For software, quality and productivity are indistinguishable because the cost of a software copy is trivial. 14, Explain the technique of creating design style. 15, What is meant path instrumentation? The outcome of a test is what we expect to happen as a result of the test. Path instrumentation is what we have to do to confirm that the outcome was achieved by the intended path. Co-incidental Correctness ‘When expected and actual outcomes match, © Necessary conditions for test to pass are met. © Conditions met are probably not sufficient (the expected outcome may be achieved due to a wrong reason) 4g Gener™ he types gated Serre 16. 1 strategy / Path Instrumentation Methods methods include: of instrumentation n sive Trace Program ‘An interpretive trace program is one that executes every statement in order and records the intermediate values of all calculations, the statement labels traversed ete. ted routine under a trace, then we have all the information we need to confirm the outcome and, furthermore, to confirm that it was achieved by the intended path. ¢ with traces is that they give us far more information than we need. In fact, the typical trace program provides so much information that confirming the path from its massive output dump jnvolves more work than simulating the computer by hand to confirm the path. Explain the concept of path testing, n to a family of test techniques based on judiciously selecting a set of test paths through the program. I the set of paths are properly chosen then we have achieved some measure of test thoroughness. For example, pick enough paths to ‘assure that every source statement has been executed at least once. Idest_ of all structural test if we run the test ‘The troubl Path Testing is the name giver Path testing techniques are the ol techniques. Path testing is most applicable to new software for unit a structural technique. testing. It is It requires complete knowledge of the programs structure. en used by programmers to unittest their own code, he size of Itis most oft “The effectiveness of path testing rapidly deteriorates as 1 the software aggregate under test increases. 17. Give the importance of domain testing, a © Domain: In mathematics, domain is a set of possible values of independent variable or the variables of a function, ice © Programs as input data classifiers: domain testing attempts determine whether the classification is correct or not. ° Domain testing can be based on specifications or equivalent implementation information. > If domain testing is based on specifications, it is a functional test technique. ‘2 If domain testing is based implementation details, it is a structural test technique. «For example, you're doing domain testing when you check extreme values of an input variable, All inputs to a program can be considered as if they are numbers. For example, a character string can be treated as a number by concatenating bits and looking at them as if they were a binary integer. This is the view in domain testing, which is why this strategy has a mathematical flavor. 48. Explain the concept of structural metrics. MeCabe’s Cyclomatic Complexity + Determines the logical complexity of a graph — typically the graph is a flow graph of a function or procedure — — Itcan also be a graphical representation of an FSM. = Independent path: any path that introduces at least one new set of statements or a new condition; must move along at least one edge that has not been traversed before. Basis Set: a set of independent paths Example: set of independent paths which comprise a basis following flow graph: set for the pst university Question Papers with Answers AS patil: Lf pati oot + a,b, & £ patrt:a Bier Boes £ ptt: & BG BOE Alternate methods to calculate V(G): _ V(G)=#of_predicate_nodes + 1 _ V(G)=4of edges ~ #of nodes +2 Note: in previous graph node ‘a’ has an out degree of 3, thus it counts as 2 predicate nodes. ‘The previous graph could also have been drawn as: +A predicate node is a node in the graph with 2 or more outgoing ares, «In the general case, for @ collection of C control graphs with k connected components, the complexity is equal to the summation of their complexities. That is V(G)= 2G) Information Flow Metric * By Henry and Kafura: — attempts to measure the measuring the flow of information from on another in terms of fan-ins and fan-outs. — fancin: number of local flows into @ procedure plus the ‘number of global structures read by the procedure. * fan-out: number of local flow from a procedure plus the number of global structures updated by the procedure. complexity of the code by e procedure to c AT 19. 20. Flows represent: the information flow into a procedure via the ar lists and Samet — Flows from the procedure due to return values of funeti calls. i Thus, the complexity of the procedure, p, is given by Cp = (fan-in x fan-out)? How decision tables can be used for logic testing? ‘The first task is to identify a suitable function or subsystem Which reacts according to a combination of inputs or events. The system should not contain too many inputs, otherwise the number of combinations will become unmanageal le. Tt is better to deal with large numbers of conditions by dividing them into subsets and dealing with the subsets one at a time. Once you have identified the aspects that need to be combined, then you put them into a table listing all the combinations of true and false for each of the aspects, SECTION C (3 x 10= 30 marks) Answer any THREE questions All questions carry equal marks 20. What is Bug? Discuss its types. ‘Asoftware bugis an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. The major categories are: (1) Requirements, Features and Functionality Bugs (2) Structural Bugs (3) Data Bugs (4) Coding Bugs (5) Interface, Integration and System Bugs (6) Test and Test Design Bugs. Requirements, features and functionality bugs The various categories in Requirements, Features and Functionality bugs include: e Requirements and Specifications Bugs e Feature Bugs e Feature Interaction Bugs ivertily, Question Papers with Answer At remount and Speelfientiony Rugs: joa" selfieath K equrenenls ant eciicont developed fiom them enn be |e incomplete ambignots, OF nell-contidletory, They ean be rood or impossible (und nigunders ind, ications that don't have flaw in them may chanpe while the ‘tho sper thief The features are added, movified and deleted, signi i POE des jentare BUR gpecification problems usually create corresponding, feature problems. A feu purpos wrong, feat Removing, the features might complicate the software, consume more and foster more bugs. ature can be wrong, missing, oF superfluous (serving no useful ). A missing, Feature oF case is easier fo detect and corsect. A sre could have deep design implications, reso -e Interaction Bugs correct, clear, implementable and testable feature lated features, The features of each Features usually come in groups oF 1 within the group are usually well group and the interaction of features tested. 11, Diseuss on transact Got the Transactions Flows @ Complicated systems that process a Jot of different, complicated transactions should have explicit representations of the transactions flows, or the equivalent. 1 flow testing techniques, © Transaction flows are like control flow graphs, and consequently we should expect to have them in increasing levels of detail. © The system's design documentation should contain an overview section that details the main transaction flows. © Detailed transaction flows are a mandatory pre requisite to the rational design ofa system's functional test. Inspections, Reviews and Walldhroughs Start From Preliminary Design |. Conducting Walkthroughs © Discuss enough ‘Transaction Types (98% Transactions) © User needs and functional terms (Design independent) . Traceability to requirements. 2, Design Testsfor C1 + C2 coverage 3, Additional Coverage (> C1+C2) Paths with loops, extreme values, domain boundaries 4, Design Test cases for Tr. Splits and mergers 5, Publish Selected Test Paths early 6, Buyer’s Acceptance — functional and acceptance tests Path Selection ° ve Me i ee ee e Select a covering set of paths based on functionally sensible transactions as you would for control flow graphs. © Try to find the most tortuous, longest, strangest path from the ent to the exit of the transaction flow. a Path Sensitization e Most of the normal paths are very easy to sensitize-80% - 95% transaction flow coverage (c1+c2) is usually easy to achieve, e The remaining small percentage is often very difficult, © Sensitization is the act of defining the transaction. If there are sensitization problems on the easy paths, then bet on either a bug in transaction flows or a design bug. Path Instrumentation Instrumentation plays a bigger role in transaction flow testing than in unit path testing. The information of the path taken for a given transaction must be kept with that transaction and can be recorded by a central transaction dispatcher or by the individual processing modules. e Insome systems, such traces are provided by the operating systems or arunning log. 22. How data flow testing strategies can be strengthened? The structural test strategies discussed below are based on ee program's control flowgraphs. They differ in the extent to which er et, uses and/or computational uses of variables are included in the test set 7° ing order of their Various types of data flow testing strategies in decreas! effectiveness are 1. All - du Paths (ADUP) 2. All Uses Strategy (AU) 3. All p-uses/some c-uses strategy (APU+C) ry py univers» Question Papers with Answer Al0 4 All c-uses/some p-uses strategy (ACU+P) _ All Definitions Strategy (AD) ¢all Predicate Uses (APU), All Computational Uses (ACU) Strategies 33. with an example, show how syntax testing is done, Syntax Testing in Software Testing means it is widely used sfiware testing term. Itis done in White Box Testing by using some tools or ‘manually depending on the nature of the Project. As we know, Syntax esting is used in White Box Testing and hence it is obviously done by developers. Not in all the situations, it can be performed by developers, it can also be done by the testers. Skilled testers mean white box testers, As developers do this testing, they should be responsible for running a syntax check before releasing their code to QA team. In this testing, we test the syntax of the programming languages. As the syntax of the every programming language is very different so is the criteria for doing Syntax Testing on these programming languages. Syntax Testing in Software Testing Example —php language Given below is the cxample of Syntax Testing, which explains what syntax testing is and what we should look for while testing it. For example, let us assume we are doing the Syntax Testing of php language. Then here we check whether the syntax is proper or not by checking the starting and ending tag syntax of php language. As you know starting tag of php is <2php and ending tag is ?>. So in this case we check whether the starting tag () is also OK or not. So, this is the Syntax Testing of php language has done by developers and testers. And in the same way we can test the Syntax of Asp language also which is given below. Swntax Testing Example — Asp language In the above example, you can see the Syntax Testing of php language now we move towards Asp means how to test the Syntax of the Sp language, ' As we know Starting tag of Asp is : here we can test whether the starting and ending ag Syntax of Asp is OK Tol. So this is the Syntax Testing done by us on ASP language. An Software Testing 24, Discuss the following: (a) Transaction Testing (b) State Testing. (a) Transaction Testing Transaction testing generally refers to the testing of individual loans and is also known as account testing, account sampling, or transaction-leve] testing. Transaction testing is generally performed as part of each full scope cxamination of a bank engaged in credit card lending and is sometimes incorporated into target examinations or visitations when helpful in analyzing the areas slated for review. According to the Expanded Guidance for Evaluating Subprime Lending Programs, transaction testing should be completed at each regularly-scheduled examination of banks engaged in subprime lending. Transaction testing is one of the best techniques to unearth the true quality of card portfolios and loan administration practices, Reasons for Conducting Transaction Testing ‘Transaction testing is used to determine whether: * Individual loans adhere to policy, underwriting, risk selection, and pricing standards. ° Management, board, and regulatory reports are accurate and timely. Loan accounting and servicing meet appropriate standards, including those for account management. * Key risk controls and control processes are adequate and functioning as intended. Some examinations have revealed that even when written policies and procedures appear satisfactory, system settings or other devices might be allowing activity that is contrary to the policies and/or that does not meet applicable guidance and laws. © Roll-rates and other loss forecasting methods used to determine that the Joss allowance levels are accurate and reliable. » Lending practices exist that may appear unsafe, unsound, abusive, or unfair. y versity Question Papers with Answers | past us University of Madras B.Sc. (CS) | goveber 2015 50419/SAZ6CISEESB/SEUGG | ine: Tee hows Maximum: 75 marks SECTION A- (10x2=20 marks) Answer any TEN questions. All questions carry equal marks, 4, Define Quality in software. requirements ifit is to be considered to be ofa good quality. 2, What do you mean by Bug? change our notion of what a bug is, 4, What are the various testing styles? » Functionality testing Forced error testing © Compatibility testing © Performance testing © Scalability testing ¢ Stress testing © Usability testing | © Application security testing 4, Define Flow graphs. A flow graph Gis defined as a finite set N of nodes a finite set E of directed edges. An edge (i, directed from itoj, connects nodes nj an vite G= (N,B) to denote a flow graph G with nodes in Nand edges in E, 5. What is called Transaction? .) in E, with an arrow dyin N, We often Al2 A Sofware must conform to explicit and implicit Bugs are more insidious (deceiving but harmful) than ever we expect them to be. An unexpected test result may lead us to ind a © A transaction is a unit of work seen from a system user's point of view, 9. ue. A transaction consists of a sequence of operations, Some of which are performed by a system, persons or devices that are outside the system. Transaction begins with Birth — that is they are created as a result of some external act. Mention the various testing strategies. Top-Down Testing Bottom-Up Testing Thread Testing Stress Testing Back- to Back Testing Define Path. Path is a sequence of statements starting at an entry, junction or decision and ending at another, or possibly the same junction or decision or an exit point. Write note on syntax testing. System inputs must be validated. Internal and external inputs must conform to formats: a. Textual format of data input from users. b. File formats. c. Database schemata. What is a path expression? The Path expression is a representation of a set of all possible paths between two nodes. List out the various formats of testing. Performance testing Security testing Exploratory Testing Mutation Testing Smoke Tests. ‘What are the contents in decision table? Define State Graph. State Graphs are very useful for describing the behaviors of individual objects over a full set of use cases that affect those objects. State Graph is a combination of states and transitions. eo ay Question Papers wilh Answers SHCTION 1h (5 + 5#26 marta) Answer any FIVE questions, All questions carry equal marks mensLilf and contrast the functions of texting ant debuggsng, 13. compare ais willy kno uses predefined yredictable ions, eondit a hres an as proce utc ing can and should be designed and planned sehoduled. ‘Tes error or apparent correclnes rating # demonstration of Debugging, Debugging, starts from prossibly unknown initial conditions and the end cannot he predicted except statistically, duration — of be Procedure — and debugging cannot constrain i proves a programme's fie. : Festing, as executed, should srive to be predictable, dull, rigid and constrained, inhuman. IggIng the programmer's vindication (Justificatio | Debugging — dema leaps, experimentation and freedom. Testing can be done without ‘much design knowledge. Debugging is impossible without detailed design knowledge. Testing can often be done by an outsider. Much of test execution and design can be automated. St ‘Automated debugging is still a Debugging must be done by af insider. dream. 14, Diseu The major categories are: (1) Requirements, jef about types of bugs. Features and Functionality Bugs | (2) Structural Bugs (3) Data Bugs (4) Coding Bugs (5) Interface, Integration and System Bugs Fy (6) Test and Test Design Bugs. _ “uirements, features and functionality bugs The various categories in Requirements, Features and Functionality Sues include: © Requirements and Specifications Bugs ai Soft Testing e Feature Bugs e Feature Interaction Bugs Requirements and Specifications Bugs «Requirements and specifications developed from them can he incomplete ambiguous, or self-contradictory. They can be misunderstood or impossible to understand. «The specifications that don't have flaws in them may change while the design is in progress. The features are added, modified and deleted, Feature Bugs e — Specification problems usually create corresponding feature problems, © A feature can be wrong, missing, or superfluous (serving no useful purpose). A missing feature or case is easier to detect and correct. A wrong feature could have deep design implications. iB ign imp e Removing the features might complicate the software, consume more resources, and foster more bugs. Feature Interaction Bugs e Providing correct, clear, implementable and testable feature specifications is not enough. Features usually come in groups or as related features. The features of, each group and the interaction of features within the group are usually well tested. 15. Describe about transaction system properties. 16. Write short notes on Domain Testing. Domain testing can be used to perform functional testing and also, structural testing. An entire domain testing effort focuses on identifying a set of domains in a program and appropriate set of input values corresponding to each domain so identified. Following this, input values will be supplied and the behavior of the program is checked to ensure whether it is as expected. It is important to notice that domain testing will be effective only with a domains which are linear, complete, systematic, orthogonal, consistently closed, connected, and convex. Domain testing will be ineffective with o y domains that have ill-defined boundaries which are non-linear, wich oe ambiguities and contradictions, and have problems related to vow a close Without simplification and rectifying problems related ae pals closure, domain testing on uely domains would result in nacht ee since it is not possible to choose appropriate input values. BY "S04 and eanae es such as Boundary Value Analysis ae fewer Equivalent Pastiions (EP) are devised which would allow (0 oro peo S to carry out effective testing, In addition, there js ane es AI6 and coordinate tran; i formations in ord sing, appropriate input domains, cre in el In mathematics, d 4 in: In mathematics, domain is a se ‘1 ¢ Dammains Tn mat 7 nalicss domain is a set of possible values of an | independent variable or the Variables ofa function, |, Programs as input dala classifiers: domain testing attempts to determine whether the classification is correct or not. Domain testing can be based on specifications or equivalent implementation information. If domain testing is based on specifications, it is a functional test technique. ¢ Ifdomain testing is based implementation details, it is a structural | test technique. ‘For example, you're doing domain testing when you check extreme values of an input variable. All inputs to a program can be considered as if they are mumbers. For example, a character string can be treated as a number by concatenating | fits and looking al them as if they were a binary integer. This is the view in ing, which is why this strategy has a mathematical flavor. brief about path expression and path products. Path Expressions Consider a pair of nodes in a graph and the set of paths between those nodes. Denote that set of paths by Upper case letter such as X,Y. From Figure 5.lc, the members of the path set can be listed as follows: ac, abe, abe, abbbe, abbbbc... Alternatively, the same set of paths can be denoted by : actabe+abbetabbbe+abbbbe- . ‘The + sign is understood to mean or" between the two nodes of interest, paths ac, or abe, or abbe, and so on can be taken. Any expression that consists of path names and "OR"s and which denotes a set of paths between two nodes is called a "Path Expression." Path Products The name of a path that consists of two successive path segments is conveniently expressed by the ‘concatenation or Path Product of the ‘segment names. For example, if X and Y are defined as X=abede, Y=fehij,then the path corresponding to X followed by Y is denoted by AIT Software Testing a XY=abcdefghij © Similarly, - YX=fghijabcde aX=aabede Xa=abcdea XaX=abcdeaabede e IfX and Y represent sets of paths or path expressions, their Product represents the set of paths that can be obtained by following every element of X by any element of Y in all possible ways, For example, X=abe + def + ghi Y=uw+z Then, XY = abcuvw + defuvw + ghiuvw + abez + defz + ghiz e Ifa link or segment name is repeated, that fact is denoted by an exponent, The exponent's value denotes the number of repetitions: al = a; a? = aa; a? = aaa; an = aaa... n times. Similarly, if X= abcde then X!= abcde X? = abedeabede = (abcde)? X? = abedeabcdeabede = (abcde)2abede = abede(abede)?= (abede)? © The path product is not commutative (that is XY!=YX). © The path product is Associative. RULE 1: A(BC)=(AB)C=ABC where A,B,C are path names, set of | path names or path expressions. ° The zeroth power of a link name, path product, or path expression is also needed for completeness. It is denoted by the numeral "I" and denotes the "path" whose length is zero - that is, the path that doesn't have any links, ad=1 Xx0=1 y past university Question Papers with Answers AMS sg iseuss ° about logic based test ‘The functional requirements of many programs can be specified by decision tables, which provide a useful basis for program and test design. Consistency and completeness can be analyzed by using boolean algebra, which can also be used as a basis for test design. Boolean algebra is trivialized by using Kamnaugh-Veitch charts. "Logic" is one of the most often used words in programmers’ vocabularies but remains as one of their Jeast used techniques. Boolean algebra is to logic as arithmetic is to mathematics. Without it, the tester or programmer is cut off from many test and design techniques and tools that incorporate those techniques. Logic has been, for several decades, the primary tool of hardware logic designers. Many test methods developed for hardware logic can be adapted to software logic testing, Because hardware testing automation is 10 to 15 years ahead of software testing automation, hardware testing methods and its associated theory are a fertile ground for software testing methods, As programming and test techniques have improved, the bugs have shifted closer to the process front end, to requirements and their specifications. These bugs range from 8% to 30% of the total and because they're first-in and last-out, they're the costliest of all. ‘The trouble with specifications is that they're hard to express. Boolean algebra (also known as the sentential calculus) is the most basic of all logic systems. Higher-order logic systems are needed and used for formal specifications. Much of logical analysis can be and is embedded in tools. But these tools incorporate methods to simplify, transform, and check specifications, and the methods are to a large extent based on boolean algebra. 20. Write notes on Transition testing. | Get the Transactions Flows Complicated systems that process a lot of different, complicated transactions should have explicit representations of the transactions flows, or the equivalent. Transaction flows are like control flow graphs, and consequently We should expect to have them in increasing levels of detail. Softyare ny 's design documentation should cont s Hi AN Overyiey ion that details the main transaction flows, © Detailed transaction Hows are a mandatory pre requisite to the rational design of a sys functional test, and Wallthroughs Inspections, Review: Start From Preliminary De 1. Conducting Walkthroughs gg ° enough Transuetion Types (98% Transactions) © User needs and functional terms (Design independeny © Traceability to requirements, ign Tests for C1 + C2 coverage 3. Additional Coverage (> CH+€2) © Paths with loops, cxtreme values, domain boundaries 4, Design Test cases for Tr, Splits and mergers 5. Publish Selected Test Paths early 6. Buyer’s Acceptance ~ functional and acceptance ests Path Selection ® Select a set of covering paths (cl-+c2) using the analogous criteria you used for structural path testing. © Select a covering set of paths based on functionally sensible transactions as you would for control flow graphs. © Try to find the most tortuous, longest, strangest path from the entry to the exit of the trans Path Sensi © Most of the normal paths are very casy to sensitize-80% - 95% transaction flow coverage (c1-+c2) is usually casy to achieve. © The remaining small percentage is often very difficult, ° tization is the act of defining the transaction. If there are ‘ation problems on the easy paths, then bet on either a bug in transaction flows or a design bug, Path Instrumentation ¢ Instrumentation plays a bigger role in transaction flow testing than in unit path testing, © The information of the path taken for a given transaction must e kept with that transaction and can be recorded by a central transaction dispatcher or by the individual processing modules. SECTION CG ~10=30 marks) Answer any THREE questions All questions carry equal marks gp. Write an overview about the following (a) Mode for Test Q sting. tudes three models: «< a model of testing process. It inch nd a model of the A model of the environment, a model of the program 2 expected bugs. Environment and software required to ‘A Program's environment is the hardware i a SF The environment may, include communication lines, other systems, terminals and operators. The environment also includes all programs that interact with and are used to create the program under test \s, linkage editor, joader, compiler, utility routines. = such as 0} Because the hardware and fi blame the environment for bugs. irmware are stable, it js not smart (0 Program too complicated Most programs are 100 sified in 0 concept of the program js to be simplitie! jor, we MAY of the rogram does ot explain te UnexPEE behavior, modify that model to include more facts may have to modify the progran A2l ftware Tes Bugs Bugs are more insidious (deceivin; them to be. An unexpected test result may lead us to change our Noti what a bug is and our model of bugs. Some optimistic neuen ea of programmers or testers have about bugs are usually unable to test ef and unable to justify the dirty tests most pro; ffectively : ctively Optimistic Notions about Bugs Benign Bug Hypothesis: The belief that bugs are nice, tae ma logical. (Benign: Not Dangerous) Bug Locality Hypothesis: The belief that a bug discovered within A component affects only that component's behavior. Control Bug Dominance: The belief that error in the contol structures (if, switch ete) of programs dominate the bugs. Code / Data Sep. of code and data. Lingua Salvatore Est.: semantics (c.g. Structured Coding, Corrections Abide: remains corrected. but harmful) than we expest aration: The belief that bugs Tespect the separation The belief that the language syntax and , Strong typing, etc) eliminates most bugs. The mistaken belief that a corrected bug Silver Bullets: The mistaken belief that X (Language, Design method, representation, environment) grants immunity from bugs. Sadism Suffices: The common belief (especially by independent tester) that a sadistic streak, low cunning, and intuition are sufficient to climinate most bugs. Tough bugs need methodology and techniques. Angelic Testers: The beliefs that testers are good at test design than the programmers are at code design. Tests Tests are formal procedures, Inputs must be prepared, eee should predict, tests should be documented, commands need to be execute: and results are to be observed. All these are subjected to errors. Testing and Levels We do three distinct kinds of testing on a typical software syste™ They are: © Unit / Component Testing © Unit Testing © Integration Testing: rey Question Papers: with Anwners iv nivel component Tel nit he snallnt Wesley of ettvene tak can ts nomblud, linked, loaded ets, A unit is usually the wore of ones {consist of several hundred or fewer lines of oe, a “yy “in Mm hal ‘peat It eating comprises the sot of bak patie by aii pilor to jntepration Wustrated tito » larger system. This niet rn init lo | Coline. | & » Unit Teating > Irteygaion Sesing | pebupeine particular function or are rates. I is posto ete of tefing, he developer canes ort eta nde i the pour ele or unit of wks is working Sine Unit ti, fan at he very ae evel i is ari oe, When he ont ofthe t Phin tenting, bs used to te «J or a particular functionality id built. init texting requiren detailed Knweruledge of the interral | popram din ad code, i is generally perfirmed ty the payers aad wi by ily done, as it requires well designed | chitecture of application with tight wie, Integration Texting A proup of dependent components are tested together to ensure Iheir quality of their intepyation unit, ‘The objectives id to take unit tested components and build a program structure that has been dictated by software design. The focus of integration tenting is to uncover errors in: © Design and construction of woftware architecture, © Integrated functions or operations at sub-ryraern level * Interfaces and interactions between ther. * Resource integration and/or environment integration System Texting Wietieg men tes ing ae on testing the complete systems with System het eee and nee - a ing involves two kinds of activities: © Integration texting and * Acceptance testing i Rar ve f if Ter ' ¥ Wires } a ‘| i : t 1 | a} il su that Which mo the onter in which ars execution of Finstion tt be measured in terms of humans 0 seal of one to ten esthetically (gently); a misspelled is dehumanizing, Eg Tegal) transactions. ed invalid n itself but transaction ite s lost Go the wrong transactions to another account ‘ s oF too fee transaetb® xd of sporadic infrequent) oF and occu a e corruption of the database °° ig ation is 8° idera the corruption is not easily Shutting the system down. Catastrophic: The dec’ the system fails. discovered. Serious consi pecs? s taken out of our hans to shut dow ive) Quetig > What cay gelloven though jy ita] net HAL ei tng 1H deta ayy Coverag My Mainly wait Uw an Tea ga one company gym (jub-outne) subroutines, it + Un reality, Stubs- may be gui auibroutin, To achiev Clacdey + Pre ne sub a + Senin eg + Sele uh cons fw Code Do Path Tests frGl Coot Use the proces) using a mecha A path ‘ockelunnet When a bug oot Maintenance Path testing ish) Use the procedi but without wsill Select paths wh Never anil mitt in maintenam Sofware Application” | ersity Question Papers with Answers A24 9st ! igus: What can ‘be worse than a failed system? One that corrupts other jet ough it doesnot fl in isl; that erodes the social physica ee nent that melts nuclear reactors and starts war. ean in det about appction of path esting 21 BY on, Coverage, and Paths in Called Components fc ss ; 10 inly used in Unt testing, espeielly new software. In an Idealistic bottom-up integration test process — integrating ‘one component at a time. Use stubs for lower level component (Gubstoutines), test interfaces and then replace stubs by real subroutines. «In reality, integration proceeds in associated blocks of components. Stubs may be avoided. Need to think abdut paths inside the | subroutine. To achieve CI or C2 coverage: | + Predicate interpretation may require us to treat a subroutine as an in-line-code. | + Sensitization becomes more difficult. + Selected path may be unachievable as the called | components’ processing may block it. | New Code + Do Path Tests for Cl + C2 coverage + Use the procedure similar to the idealistic bottom-up integration testing, using a mechanized test suite, + Apath blocked o not achieved could mean a bug. + When a bug occurs the path may be blocked. Maintenance * Path testing is applied first to the modified component. * Use the procedure similar to the idealistic bottom-up integration testing, but without using stubs. Select paths to achieve C2 over the changed code. Newer and more effective strategies could emerge to provide coverage M maintenance phase. Rehosting Path testing wi i itive with Cl + C2 coverage is a powerful tool for rehosting old Software i Ware is rehosted as it’s no more cost effecti “lication on A fective to support the a A25 Soft «Use path testing in conjunction with automatic op 8 structural test generators. Semiautomat c Process of path testing during rehosting + A translator from the old to the new environment is creat Rehosting process is to catch bugs in the translator soften and tested, + A complete Cl + C2 coverage path test suite is created software, Tests are run in the old environment, The ute forthe old the specifications for the rehosted software. ‘Mes become + Another translator may be needed to adapt the tests & out new environment. + The cost of the process is high, but it avoids the risks as. rewriting the code + Once it runs on new environment, it can be optimi; ia , tH can be optimized or enhanced fop + Functionalities (which were not possible in the od environment) 22. Describe about dataflow testing strategies, : a Various types of data flow testing strategies in decreasing order of their effectiveness are 1. All - du Paths (ADUP) 2. All Uses Strategy (AU) 3. All p-uses/some c-uses strategy (APU+C) 4, All c-uses/some p-uses strategy (ACU+P) 5. All Definitions Strategy (AD) 6. All Predicate Uses (APU), All Computational Uses (ACU) Strategies 1, All - du Paths (ADUP): The all-du-paths (ADUP) strategy is the strongest data-flow testing strategy discussed here. It requires that every du path from every definition of every variable to every use of that definition be exercised under some test. For variable X and Y: (Pl. refer to figure 6.6 in page 80): Because variables X and Y are used only on link (1,3), any test that starts at the entry satisfies this criterion (for variables X and Y, but not for all variables as required by the strategy). For variable Z: The situation for variable Z (PI. refer to figure 6.7 in page 81) is more complicated because the variable is redefined in many places For the definition on link (1,3) we must exercise paths that include spats (1,3,4) and (1,3,5). The definition on link (4,5) is covered by any path includes (5,6), such as subpath (1,3,4,5,6, ..). The (5,6) definition ren" paths that include subpaths (5,6,7,4) and (5,6,7,8). Comes to the sociated with wee mae 4h iy = SESH ees Bae iable V: Variable V (Pl refer to figure 6.8 in page 81): is defined port ce on link (1,3). Because V has a predicate use at node 12 and the ol eal path to the end must be forced for both directions at node 12, the ibs” ths strategy for this variable requires that we exercise all loop-free er paths and at least one path that includes the loop caused by (11,4) ee «we must test paths that include both subpaths (3,4,5) and (3,5) even vote either of these has V definitions. They must be included because tho yovide alternate du paths to the V use on link (5,6). Although (7,4) is ased in the test set for variable V, it will be included in the test set that ot oe the predicate uses of array variable V() and U: : ‘The all-du-paths strategy is a strong criterion, but it does not take as y tests as it might seem at first because any one tesi simultaneously ary the criterion for several definitions and uses of several different

You might also like