Explore BrainMass
Share

Equivalence Class Partitioning and Boundary Value Analysis

This content was STOLEN from BrainMass.com - View the original, and get the already-completed solution here!

Hi,
I need assistance in the following problem please.

Many functions have an almost infinite number of input values. Testing all of these values is not possible in most cases, and doesn't necessarily tell us more than testing a few values. How do you choose the best values to test? Equivalence class partitioning can be used to divide the test inputs into classes so that each class contains the same kinds of input (in another word, you may only need to test one input from each class), thus reducing the number of test cases to a manageable size. For example, if the specification of one program is: "Design a program that accepts inputs of ASCII strings (arbitrary long) and breaks the input into lines of 60 characters". The requirement for the testing group is to generate a three test cases for test this program. OK, then you can generate the following two inputs: the first input with 40 ASCII characters and the second input with 30 characters. Now you want to design the third input, how long should it be? 16 characters or 100 characters? If you do not use partition method, you may feel it is better to generate a 100 character input for testing. But it is not systematic. A systematic approach will generally divide the input space for the above program into three "equivalence" classes:

1. inputs with less than 60 characters
2. the input with 60 characters
3. inputs with more than 60 characters

Furthermore, you may further divide the third classes into more classes: inputs whose length is long than 60 but less than 120, inputs whose length is long than 120 but less than 180, etc...
Thus the general rule for partition testing is:

1. Partition testing separates the input space into classes whose union is the entire space, but the classes may not be disjoint
2. Uniformly chooses one or more test from each class
3. Generate testing cases with Cartesian product by eliminating illegal inputs. This may still lead to huge amount of test cases. For example, if you got 5 inputs (each in a separate partitioned class, for each input/classes, you decide to have 6 values, then you will still get 65=7776 test cases.

My task for this exercise is to use Equivalence Class partitioning and Boundary Value Analysis (which means to test the input at the boundary of the equivalence class partition) to analyze the valid and invalid inputs for Microsoft WinWord or any other software package that you have installed on your computer. If you choose to test different software than WinWord, please make sure that the software has several functions for user input (e.g., the zoom menu that needs user input or the search/replace menu).
As an example (or beginning point), you may use the following divided categories for WinWord "Find" and "Format Font" function.

Thanks & Best Regards,

https://brainmass.com/computer-science/files/equivalence-class-partitioning-and-boundary-value-analysis-159528

Solution Summary

This solution presents a sample case in which equivalence class partitioning and boundary value analysis are dealt in detail.

\$2.19
Similar Posting

Equivalence Class Partitioning and Boundary Value Analysis..

Overview
Many functions have an almost infinite number of input values. Testing all of these values is not possible in most cases, and doesn't necessarily tell us more than testing a few values. How do you choose the best values to test? Equivalence class partitioning can be used to divide the test inputs into classes so that each class contains the same kinds of input (in another word, you may only need to test one input from each class), thus reducing the number of test cases to a manageable size. The task is to use Equivalence Class partitioning and Boundary Value Analysis (which means to test the input at the boundary of the equivalence class partition) to analyze the valid and invalid inputs for Microsoft WinWord or any other software package that you have installed on your computer. If you choose to test different software than WinWord, please make sure that the software has several functions for user input (e.g., the zoom menu that needs user input or the search/replace menu).
Identify categories
First you need to identify a list of function/menus that you need to test. For each function, identify one or more input categories that apply to it. Please focus on functions that require input values.
Define valid and invalid classes
For each input category identified, define the valid and invalid equivalence classes. Do not specify a test case or specific test input value for the equivalence classes; specify the entire equivalence class.
Define sub classes
If appropriate, divide each valid equivalence class into sub-classes based on how the software interface handles the input.
Identify boundaries
For equivalence (sub-)classes that have boundaries, identify boundary values for the boundaries between valid and invalid classes, or between valid sub-classes.
For lower bounds, specify a set {first invalid, lowest valid}; for upper bounds, specify a set {highest valid, first invalid}.
Do not specify a test case; just specify the boundary values as shown.

Document results
Document your results in a table, as follows and submit it to the hand in assignment folder by the deadline: Note: please follow this table format, to facilitate evaluation and ensure the grader has a favorable attitude toward your work.
Input Input Type Valid Equivalence (Sub-)Class Invalid EC Lower Bounds Upper Bounds
switch enum {-s, -n, -c} not {-s, -n, -c} N/A N/A
number of switches card [0, 1] [2, infinity] {N/A, 0} {1, 2}
time_t range [0, 2^^32] [-infinity, 0], [2^^32, infinity] {-1,0} {2^^32, 2^^32+1}
time_t before millennium range [0, 946713599] (sub-class) {N/A,0} [946713599, 946713600]
time_t after millennium range [946713600,2^^32] (sub-class) {946713599, 946713600} [2^^32, 2^^32+1]
date string constraint conforms to parsedate(3) spec complement of valid N/A N/A
Notes:
• Indent sub-classes from their parent. Also, mark the invalid column ``(sub-class)'' for sub-classes: sub-classes do not have an associated invalid class, because by definition all sub-classes are valid.
• Use ``N/A'' to indicate that a column does not apply.
• The examples shown above are only intended to illustrate the table format to use; they are not exhaustive (or necessarily correct).

Appendix: Equivalence Class and Boundary Value Analysis
1. Terminology
Test Case
Specification of
1. environment
2. inputs
3. expected results
Test or Test Procedure
Test case(s) plus instructions for running them:
1. set-up
2. execution
3. evaluation
4. tear-down
Implementation of one or more test cases.
Test Suite
Collection of tests. We make a distinction between tests and test suites because of shadowing and granularity.
2. Design Issues
• B depends on results of A and A fails.
• B follows A and A corrupts the environment somehow.
Granularity
This is a measure of how many test cases a test contains.
• Valid input tests should be large to reduce overhead: we expect them to succeed.
• Invalid input tests should have one case, as we expect the system under test to report an error at least, perhaps halt or fail gracefully.
Strategy
Requirements-based
Black box testing, cases derived from requirements specification.
Function-based
Black box testing, cases derived from functional specification.
Internals-based
White box testing, cases derived from design or code.
Coverage
A measure of test suite completeness, in terms of
• requirements tested;
• functions tested;
• code statements, branches, conditions, paths executed.
3. Test Case Development Methods
• Happy Path
Input values chosen from those known or expected to work.
• Equivalence Class Partitioning
Divide the input into equivalence classes.
1. Identify equivalence classes for each input type.
 Range - one valid, two invalid classes.
Year between 1902 and 2038
 Number of inputs (two to four args) - one valid, two invalid classes.
Recurring type entries shall have exactly three fields.
 Set (enumeration) - one valid class (the set), one invalid class (the set complement).
Weekly, Monthly, Quarterly type.
 Exists/constraint (must be) - one valid class (input satisfying constraint), one invalid class (input not satisfying constraint).
Start date must precede End date.
 Sub-classes - an equivalence class should be divided into sub-classes if we believe (or suspect) elements of a given EC are handled differently by the program.
2. Write test cases to cover each valid equivalence. Combine these into as few tests as possible.
3. Write test cases to cover each invalid equivalence class. Specify a separate test for each of these.
• Boundary value analysis
1. (Optional) Define output ECs, according to the criteria above
2. Define test cases for the boundaries of each EC:
 Range, Cardinality
Test case one before, at, one after boundary.
 Set, Constraint
No boundaries, so choose a representative from each.
• Error Guessing
Test designer uses skill and experience to devise test cases to uncover errors.
o null input.
o long input.
o random input.
o almost correct input.
 spaces in strings.
 quoted strings.
 all CAPS.
o negative numbers.
4. Deriving Test Cases from Test Outline
Following outline paths from major nodes to leaves, define test cases for each leaf:
• Id
• Outline leaf number
• Input state
dateconv: command line switches: "+1 -5"
• Input data
dateconv: "12:59:59 GMT Dec 31, 1999 The Eve of the Millenium"
• Expected results
dateconv: "946645199"
• Actual results
dateconv: "12:59:59GMTDec31,1999 The Eve of the Millenium"

View Full Posting Details