UNITII PATH TESTING Path Testing It is White

UNIT-II PATH TESTING Path Testing: It is White Box testing technique proposed by Tom Mccabe. Definition: A sequence of statements starts at an entry and ends at exit by passing all existing junctions, Decisions etc. is known as path. Control Flow Graph: A Graphical representation of a program’s control structure. Elements in Control Flow Graph: üProcess Blocks üDecisions üJunctions

Process Blocks • A process block is a sequence of program statements uninterrupted by either decisions or junctions. (i. e. , straight-line code). • A process has one entry and one exit. • A program does not jump into or out of a process

Decision and Junction A decision [2 output links]: It is a program point at which the control can diverge. (E. g. , if and case statements). A junction[2 Input links]: It is a program point where the control flow can merge. (E. g. , end if, end loop, goto label)

Path Testing Criteria 3 Different Path testing strategies 1. Path Testing: Deals with execution of paths. Test all available paths. 2. Statement Testing: Execution of all statements inside a program atleast once. 3. Branch Testing: Execution of all branches inside a program.

Path Selection Rules: • Select a set of paths by considering path Selection criteria. • Statement coverage (Assignment Statements, Conditional Statements) • Branch coverage (True/False) • All paths

PPpppx

Loops: : Path Testing 3 Types 1. Nested Loops 2. Concatenated Loops 3. Horrible Loops Nested Loops: Loop within another loop ü ü Quite Complicated Very expensive to test path because of its complexity How to Overcome: ü ü Begin test from internal loop, move towards outer loop. Test all internal loop values Conduct test on outer loop Move to other nested loop, once tested all loops.

Concatenated Loops: ü Two adjacent loops on the same path ü Exit of one loop serves as entry of other loop. Horrible Loops: ü Complicated among all 3 loops. ü Very difficult to test. ü May involve Nested loops, Cross connected loops, Intersecting loops, all in one structure. ü Design of test cases are difficult. ü Try to avoid Horrible loops.

Effectiveness of Path Testing • Unit testing is stronger than Path testing • Bug capture Overall Structure: Unit Tesing : : 65% Path Testing : : 35%

Path Testing Limitations • All paths may not cover if bug occurs • Specification errors cannot be caught. • Missed functions can’t be identified during path testing. • Unit-level path testing may not catch interface errors among routines • Data base and data flow errors may not be caught. • Not all initialization errors are caught by path testing.

Definitions Predicate ü The logical function evaluated at a decision is called predicate : : True or False. ü The direction taken at a decision depends on the value of decision variable ü Some examples are: A>0, x + y >= 90 Path Predicate: ü A predicate associated with a path is called path predicate Example: "X is greater than zero" is true AND "X + Y >=90" is false AND "W is either negative or equal to 10" is true

Predicate Expressions ü A collection of expressions, that must be fulfilled in order to achieve desired path. Predicate Coverage: ü The process of testing all truth values related to specific path in all possible ways. (i. e 100% Predicate Coverage) ü Stronger than branch coverage.

Path Sensitizing: To find set of solutions to the path predicate expressions. It’s the act of finding a set of solutions to the path predicate expression. Path Instrumentation: Techniques used for identifying whether the outcome of a test is achieved through the desired path(or)wrong path.

Application of Path Testing ü Path testing methods are mainly used in unit testing. ü However to create an environment in order to provide required inputs and also to receive the outputs from such units, we need to do test harness in order to create environment with required test stubs and test drivers.

Transaction Flow Testing Transaction Definition: A transaction is a unit of work seen from a system user's point of view. Steps in Transaction: Every transaction executed in dataflow manner with 12 steps 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Accept input (tentative birth) Validate input (birth) Transmit acknowledgment to requester Do input processing Search file Request directions from user Accept input Validate input Process request Update file Transmit output Record transaction in log and clean up (death)

Applications of Transaction Flows • • Online Systems ATM Systems Air Traffic Control Systems : Airline Reservation System

Birth of New Transactions ü In many systems the transactions can give birth to others, and transactions can also merge. ü Births: There are three different possible interpretations of the decision symbol or nodes with two or more out links. It can be a – Decision, – Biosis – Mitosis.

Figure: Transaction Flow Junctions and Mergers

Decision: Here the transaction will take one alternative or the other alternative but not both Biosis: Here the transaction gives birth to a new transaction, and both transaction continue on their separate paths, and the parent retains it identity. Mitosis: Here the parent transaction is destroyed and two new transactions are created.

Transaction flow Testing Strategies 1. Inspections: ü It is a methodology that human can do and computers can’t. ü Done by developers/ Programmers ü Cost effective quality process ü Inspection can be done in phases like design, coding, testing and debugging Eg: Checking Syntax errors Referring the program: Cross check undeclared variables, uninitialized values and tabled. Violating rules: Comparison of code: Coding sheet compares character by character Referencing code: Check errors for dataflow and control flow. Comparing flow graph:

2. Reviews: To Check the meaning of a document Phases in Review: Review Planning Review document information Prepare review meeting Objectives of review meeting Review Scheduling Feasibility Review: Review depends on logical flow. Requirement Review: Review depends on attributes of the document.

3. Walkthroughs: ü Way of finding defects in written document ü Tester come with a set of inputs to walked through the logic flow of the program.

Path selection in Transaction Flow Testing ü Select a set of covering paths (c 1+c 2) using the criteria that were 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 longest, strangest path from the entry to the exit of the transaction flow.

Data Flow Testing DATA FLOW MACHINES: There are two types of data flow machines with different architectures. (1) Von Neumann Machines (2)Multi-Instruction, Multi-data Machines (MIMD).

Von Neumann Machine ü Most computers today are von-neumann machines. ü In this architecture storage of instructions and data in the same memory units. ü The Von Neumann machine Architecture executes one instruction at a time in the following, micro instruction sequence: – – – – Fetch instruction from memory Interpret instruction Fetch operands Process or Execute Store result Increment program counter GOTO 1

Multi-instruction, Multi-data machines (MIMD) Architecture: ü It is a parallel mechanism. ü These machines can fetch several instructions and objects in parallel. ü They can also do arithmetic and logical operations simultaneously on different data objects.

Data Object State and Usage: Data Objects have 3 states. Data Objects can be created, killed and used. ü The following symbols denote these possibilities: – Defined: d - defined, created, initialized etc – Killed or undefined: k - killed, undefined, released etc – Usage: u - used for something (c - used in Calculations, p - used in a predicate)

1. Defined (d): ü Data appears on the left hand side of the assignment statement is known as defined object. ü It is also referred as a file has been opened. ü Defined object is dynamically allocated and pushed on to the stack.

2. Killed or Undefined (k): – When an object is released and is no longer in use, then it is known as killed objects. – Killed objects are similar to undefined objects. – An object that is not available in the statement is known as undefined object. – An assignment statement can kill and redefine immediately. – For example, if A had been previously defined and we do a new assignment such as A : = 17, we have killed A's previous value and redefined A. 3. Usage (u): – A variable is used for computation (c) when it appears on the right hand side of an assignment statement. – Usage variables used both in predicate and computational purposes. – It is used in a Predicate (p) , if z>0, evaluate the flow of control.

DATA FLOW ANOMALIES: ü An anomaly is denoted by a two-character sequence of actions. ü Define Anamaly: An anomaly is a situation or condition where an object is defined but not used. Eg: ü ku means that the object is killed and then used, where as dd means that the object is defined twice without an intervening usage. ü What is an anomaly is depend on the application.

ü There are 9 possible two-letter combinations for d, k and u. some are bugs, some are suspicious, and some are okay. Anomaly States are Bug State Suspicious State Normal State ü ü ü – – – – – dd : - Suspicious(Danger) State dk : - Bug State. du : - Normal State kd : - Normal State kk : - Bug State ku : - Bug State ud : - Suspicious(Danger) State uk : - Normal State uu : - Normal State

Data. Flow Anomalies: : Example If Z>0 Then x=1 Else X=-1 Z=0 Z=A+B Here object Z is defined twice to Zero. Hence an Anomaly occurs

DFT Strategies 1. 2. 3. 4. 5. 6. 7. All-du-Paths All Uses: Reduce No. of Test Cases All-P-Uses(or) Some-C-Uses(APU+C) All-C-Uses(or) Some-P-Uses(ACU+P) All- Definitions (AD): Weaker than 3&4 All-P-Uses All-C-Uses

Applications of DFT ü To develop Web Applications ü Mobile Platforms ü Embedded Devices ü Automobile Computer Systems ü DFT uses practical applications rather than Mathematical Applications ü Solve DFG anomalies ü UR-Anamoly (Undefined/killed, Read/Used) ü DD-Anomaly (Variable defined twice) ü DU-Anomaly(Defined variable becomes invalid)

Objective of DFT ü ü Performance Error Reduction Memory Optimization Slicing: It provides a convenient way of filtering out irrelevant code in a program.

UNIT-III TEST CASE DESIGN STRATERGIES ALPHA AND BETA TESTS

TEST CASE DESIGN STRATERGIES ü Black box testing test case design ü Two techniques – üEquivalence Partitioning & üBoundary Value Analysis testing techniques is used ü In Equivalence Partitioning, first you divide a set of test condition into a partition that can be considered. ü In Boundary Value Analysis you then test boundaries between equivalence partitions

Example 1: Equivalence and Boundary Value

Ticket values 1 to 10 are considered valid & ticket is booked. While value 11 to 99 are considered invalid for reservation and error message will appear, "Only ten tickets may be ordered at one time

Here is the test condition ü Any Number greater than 10 entered in the reservation column (let say 11) is considered invalid. ü Any Number less than 1 that is 0 or below, then it is considered invalid. ü Numbers 1 to 10 are considered valid ü Any 3 Digit Number say -100 is invalid.

ü We cannot test all the possible values because if done, the number of test cases will be more than 100. ü To address this problem, we use equivalence partitioning where we divide the possible values of tickets into groups

The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only one value from each partition for testing.

Boundary Value Analysis- in Boundary Value Analysis, you test boundaries between equivalence partitions

• In our earlier example instead of checking, one value for each partition you will check the values at the partitions like 0, 1, 10, 11 and so on. As you may observe, you test values at both valid and invalid boundaries. Boundary Value Analysis is also called range checking.

Example 2: Equivalence and Boundary Value üSuppose a password field accepts minimum 6 characters and maximum 10 characters üThat means results for values in partitions 0 -5, 6 -10, 11 -14 should be equivalent Test Scenario # Test Scenario Description Expected Outcome 1 Enter 0 to 5 characters in password field System should not accept 2 Enter 6 to 10 characters in password field System should accept 3 Enter 11 to 14 character in password field System should not accept

Examples 3: Input Box should accept the Number 1 to 10 Here we will see the Boundary Value Test Cases Test Scenario Description Expected Outcome Boundary Value = 0 System should NOT accept Boundary Value = 1 System should accept Boundary Value = 2 System should accept Boundary Value = 9 System should accept Boundary Value = 10 System should accept Boundary Value = 11 System should NOT accept

Why Equivalence & Boundary Analysis Testing ü This testing is used to reduce very large number of test cases to manageable chunks. ü Very clear guidelines on determining test cases without compromising on the effectiveness of testing. ü Appropriate for calculation-intensive applications with large number of variables/inputs

Random Testing • Random testing is a black-box software testing technique where programs are tested by generating random, independent inputs. • Results of the output are compared against software specifications to verify that the test output is pass or fail.

üRandom testing gives us an advantage of easily estimating software reliability from test outcomes. Time to use RT • If we have a lot time and we want to more reliability product. • If we don’t have enought time to testing product, but we must to test it.

Why we use RT ? • Random testing gives us an advantage of easily estimating software reliability from test outcomes. • Test inputs are randomly generated according to an operational profile, and failure times are recorded

Random Testing Steps Random Testing can be summarized as a four-step procedure 1. The input domain is identified 2. Test inputs are selected independently from the domain. 3. The system under test is executed on these inputs. 4. The results are compared to the system specification. 5. The test is a failure if any input leads to incorrect results; otherwise it is a success.

Benefits: ü If the domain is well-structured, automatic generation can be used, ü allowing many more test cases to be run than if tests are manually generated. Weakness: ü They are not realistic ü Many of the tests are redundant and unrealistic ü You will spend more time analyzing results ü You cannot recreate the test if you do not record what data was used for testing ü There is no measure of risk

What is Requirements based Testing? ü Requirements-based testing is a testing approach in which test cases, conditions and data are derived from requirements. ü It includes functional tests and also nonfunctional attributes such as performance, reliability or usability.

Stages in Requirements based Testing: • Defining Test Completion Criteria - Testing is completed only when all the functional and non-functional testing is complete. • Design Test Cases - A Test case has five parameters namely the initial state or precondition, data setup, the inputs, expected outcomes and actual outcomes. • Execute Tests - Execute the test cases against the system under test and document the results. • Verify Test Results - Verify if the expected and actual results match each other. • Verify Test Coverage - Verify if the tests cover both functional and non-functional aspects of the requirement. • Track and Manage Defects - Any defects detected during the testing process goes through the defect life cycle and are tracked to resolution. Defect Statistics are maintained which will give us the overall status of the project.

Compatibility Testing Need for Compatibility Testing ü Software applications released should be of high quality and compatible with all hardware, software, OS, platforms, etc. which is achieved through opting for compatibility testing.

Types of Compatibility Testing: ü There are two types of compatibility testing: Forward compatibility testing and Backward compatibility testing. ü Forward Compatibility Testing: This type of testing verifies that the software is compatible with the newer or upcoming versions, and is thus named as forward compatible. ü Backward Compatibility Testing: ü This type of testing helps to check whether the application designed using the latest version of an environment also works seamlessly in an older version. ü It is the testing performed to check the behavior of the hardware/software with the older versions of the hardware/software.

Compatibility Testing can be performed for the following: ü Operating systems: testing across OS like Linux, Mac OS, and Windows etc. ü Databases: testing across databases like Oracle, SQL Server etc. ü Browsers: testing across browsers like IE, Chrome, Firefox, Mozilla, Safari, etc. ü Other System software: testing web server, networking, messaging tools etc. ü Mobile applications: testing across different mobile platforms, devices, networks etc.

Documentation Testing ü Documentation testing can start at the very beginning of the software process and hence save large amounts of money, since the earlier a defect is found the less it will cost to be fixed. ü This is one of the most cost effective approaches to testing. ü If the documentation is not right: there will be major and costly problems. ü The documentation can be tested in a number of different ways to many different degrees of complexity. ü These range from running the documents through a spelling and grammar checking device, to manually reviewing the documentation to remove any ambiguity or inconsistency.

Alpha & Beta Testing

Alpha Testing ü Alpha testing is conducted within the organization. ü In Alpha testing, developer is present there while testing. ü When the development of software is near to completion stage, Alpha testing is conducted. ü In Alpha testing, developer is present while testing so he records all the problems and errors encountered during testing. ü Alpha testing is conducted within the organization and tested by representative group of end users at the developer’s side and sometimes by Independent team of testing.

Alpha Testing ü Before launching of a software product, an organization conducts testing in two phases known as Alpha Testing phase and Beta Testing phase. ü Alpha Testing is done before the launch of software product into the market whereas Beta Testing is done at the time of software product marketing. ü Alpha Testing is conducted by a team of highly skilled testers at development site. ü Alpha Testing is not open to the market and public. ü It is always performed in Virtual Environment. ü Alpha Testing is done for software application, project and product.

ü It is always performed within the organization. ü It comes under the category of both White Box Testing and Black Box Testing. Example: ü Whenever firms like Microsoft or IBM launch their software product in market, it undergoes both Alpha and Beta Testing before it is available for end user.

Beta Testing ü Beta Testing is conducted at the client’s place i. e. outside the organization. ü In Beta testing, developer is not present while testing as it is tested at client’s side ü Beta Testing is always a black box testing or functional testing. ü After passing Alpha testing and before the final launching or releasing the software, Beta testing is conducted. ü In Beta Testing, customer records all the errors and other issues encountered during this testing and reports to the developer. ü Beta testing is conducted by the end users or other persons and they are not programmers, software engineers or testers.

ü This testing is conducted in real time or live environment. ü This testing is open for public ü Bug identified during Beta Testing are known as software beta version bugs. ü which are assigned back to development team for their fixes and after the bug fix, again software product enters into alpha and Beta Testing cycle with new software version number.

Advantages of beta testing ü You have the opportunity to get your application into the hands of users prior to releasing it to the general public. ü Users can install, test your application, and send feedback to you during this beta testing period. ü Your beta testers can discover issues with your application that you may have noticed, such as confusing application flow, and even crashes. ü Using the feedback you get from these users, you can fix problems before it is released to the general public. ü Having a higher-quality application when you release to the general public will increase customer satisfaction.