Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Riyad Parvez, profile picture
Uploaded byRiyad Parvez
PDF, PPTX8,908 views

Input Space Partitioning

Input domain partitioning involves dividing the set of all possible inputs for a program into equivalence classes. This allows proving correctness by testing a finite number of test cases rather than all possible inputs. Key steps are identifying the input domain, equivalence classes, and combining classes while removing infeasible combinations. Interface-based and functionality-based input parameter modeling identify testable components, parameters, and partitions. Boundary value analysis targets errors at partition boundaries. The classification tree method generates test cases by combining representative classes from aspects of interest using combination rules.

Engineering◦Technology◦Business◦
Download as PDF, PPTX
Input Space Partitioning Riyad Parvez
Input Domain ● Consists of all possible inputs (valid and invalid) that could be taken by the program. ● Could be infinite. ● Program correctness can be proved by testing all possible input values. ● But we can only test limited set of inputs (known as test cases). ● How can we prove correctness only testing finite number of test cases?
(Answer): Input Domain Partitioning ● Also known as Equivalence Class Partitioning. ● Input or output data is grouped or partitioned into sets of data that we expect to behave similarly using an Equivalence relation. ● A strong equivalence relation will result in optimal and useful test cases. ● A partition must cover the entire domain. ● All the members in an equivalence class contribute to fault detection in the same way.
Space Partitioning ● The process of dividing a space (usually a Euclidean space) into two or more disjoint subsets. ● Divides a space into non-overlapping regions. ● Any point in the space can then be identified to lie in exactly one of the regions.
Major Steps 1. Identify the input domain ● Read the requirements carefully and identify all input and output variables, any conditions associated with their use. 2. Identify equivalence classes ● Partition the set of values of each variable into disjoint subsets, based on the expected behavior. 3. Combine equivalence classes ● Use some well-defined strategies to avoid potential explosion 4. Remove infeasible combinations of equivalence classes
Input Parameter Modelling ● Identify testable components, which could be a method, a use case, or the entire system. ● Identify all of the parameters that can affect the behavior of a given testable component. ○ Input parameters, environment configurations, state variables. ○ For example, insert(obj) typically behaves differently depending on whether the object is already in a list or not. ● Identify characteristics, and create partitions for each characteristic. ● Select values from each partition, and combine them to create tests.
Input Parameter Modelling ● Interface-based IPM: using the input space directly. ○ Easier to perform, but may miss some important semantic information. ● Functionality-based IPM: using a functional or behavioural view of the program. ○ More challenging, but can be very effective in many cases. ● Some believe that functionality-based approach yields better test cases than the interface-based approach because the input domain models include more semantic information. ● Boundary value analysis considers values both at and near boundaries.
Interface-Based IPM ● The main idea is to identify parameters and values, typically in isolation, based on the interface of the component under test. ● Advantage: Relatively easy to identify characteristics ● Disadvantage: Not all information is reflected in the interface, and testing some functionality may require parameters in combination.
Interface-Based IPM ● Range: one class with values inside the range, and two with values outside the range. ○ For example, let speed ∈ [60 .. 90]. Then, we generate three classes {{50}, {75}, {92}}. ● String: at least one containing all legal strings and one containing all illegal strings. ○ For example, let fname: string be a variable to denote a first name. Then, we could generate the following classes: {{ε}, {Sue}, {Sue2}, {Too long a name}}.
Interface-Based IPM ● Enumeration: Each value in a separate class. ○ For example, consider auto_color ∈ {red, blue, green}. The following classes are generated, {{red}, {blue}, {green}}. ● Array: One class containing all legal arrays, one containing only the empty array, and one containing arrays larger than the expected size ○ For example, consider int[] aName = new int [3]. The following classes are generated: {{[]}, {[-10, 20]}, {[-9, 0, 12, 15]}.
Functionality-Based IPM ● The main idea is to identify characteristics that correspond to the intended functionality of the component under test. ● Advantage: Includes more semantic information, and does not have to wait for the interface to be designed. ● Disadvantage: Hard to identify characteristics, parameter values, and tests.
Functionality-Based IPM ● Preconditions explicitly separate normal behavior from exceptional behavior ○ For example, a method requires a parameter to be non-null. ● Postconditions indicates what kind of outputs may be produced ○ For example, if a method produces two types of outputs, then we want to select inputs so that both types of outputs are tested. ● Relationships between different parameters can also be used to identify characteristics. ○ For example, if a method takes two object parameters x and y, we may want to check what happens if x and y point to the same object or to logically equal objects
Equivalent Class Testing Types 1. Weak Normal Equivalence Class Testing 2. Strong Normal Equivalence Class Testing 3. Weak Robust Equivalence Class Testing 4. Strong Robust Equivalence Class Testing
Weak Normal Equivalence Class Testing ● Based on single fault assumption: an error is rarely caused as a result of two or more faults occurring simultaneously. ● Only takes one variable from each equivalence class
Strong Normal Equivalence Class Testing ● Based on the multiple assumption that errors will result in a combination of faults. ● Tests every combination of elements formed as a result of the Cartesian product of the Equivalence relation
Weak Robust Equivalence Class Testing ● Test for one variable from each Equivalence Class and invalid values as well. ● Based on the single fault assumption a test case will have one invalid value and the remaining values will all be valid.
Strong Robust Equivalence Class Testing ● Produces test cases for all valid and invalid elements of the Cartesian product of all the equivalence classes.
Boundary Value Analysis A test selection technique that targets faults in applications at the boundaries of equivalence classes. ● Many errors (including security vulnerabilities) occur on the boundary of the domain: integer overflow, buffer overflow. ● Partition the input domain. ● Identify the boundaries for each partition. ● Select test data such that each boundary value occurs in at least one test input as well as a normal input from the domain. ● Straightforward test case generation.
Classification Tree Method ● A black-box test design technique. ● Test cases are designed to execute combinations of representatives of input and/or output domains. ● Test cases are described by means of a classification tree. ● Based on the functional specification of the test object. ● Help for easy generating and maintaining test cases.
Classification Tree
Aspects of Interest ● Identifying aspects of interest ○ The first activity performed for each testing problem when applying the technique of classification trees testing ○ Represent a collection of things that are supposed to interact in some interesting way ■ Things, which combinations the tester wants to test ■ E.g., blocks
Defining the Combination Rules ● In order to derive test cases we need to define rules for combining the classifications in a tree ○ Do we want pairs of all factors? ○ Triples of some factors? ○ Are there exclusions, i.e., classes that can't combine? ○ Etc.
Generating Test Cases ● Once the combination rules are defined – test cases can be generated ● Test cases can be defined by combining classes from different classifications ● A "leaf" is selected for each base classification ● Classes that belong to the same classification are non combinable ● Classification Tree specifies test cases, but it does not specify test data