Assignment 6: Category-Partition
This individual assignment has two parts. For Part I, you must generate test case
specifications for the version of the encode utility, whose specs are provided below, using
the category-partition method. For Part II, you will demonstrate how some of your test
frames may be used, by developing test cases that implement them.
Concise Specification of the encode Utility
encode – encodes words in a file.
encode OPT <filename>
where OPTcan be zero or more of
(-r | -k) <string>
COMMAND-LINE ARGUMENTS AND OPTIONS
filename>: the file on which the encode operation has to be performed.
a:if specified, the utility will encode all alphabetic (a-z, A-Z) characters by
capitalization is preserved), so ‘a’ and ‘A’ would be encoded as ‘z’ and ‘Z’, while ‘y’
and ‘Y’ would be encoded as ‘b’ and ‘B’. This option is always applied last.
-r|-k) <string>:if specified, the utility will remove(-r) or keep (-k) only the
alphabetic characters (capitalization insensitive) in the file which are included in the
required <string>. All non-alphabetic characters are unaffected. -r and -k are
c <string>:if specified, the encodeutility will reverse the capitalization (i.e.,
lowercase to uppercase, and uppercase to lowercase) of all the occurrences, in the
file, of the characters specified in the required <string>argument.
If none of the OPT flags is specified, encode will default to applying -c to all
While the last command-line parameter provided is always treated as the
filename, OPT flags can be provided in any order; no matter the order of the
parameters, though, option -awill always be applied last.
EXAMPLES OF USAGE
where the content of the file is “abcXYZ”)
Reverses the capitalization of all letters. (resulting in “ABCxyz”).
encode -r aZ file1.txt
Removes all instances of a, A, z and Z from the file.
encode -c “aeiou” -k “aeiouxyz” file1.txt
Changes all occurrences of characters ‘a’, ‘e’, ‘i’, ‘o’ and ‘u’ to uppercase, and all
occurrences of characters ‘A’, ‘E’, ‘I’, ‘O’ and ‘U’ to lowercase. Then, removes all
letters other than ‘a’, ‘e’, ‘i’, ‘o’, ‘u’, ‘x’, ‘y’, ‘z’, ‘A’. ‘E’, ‘I’, ‘O’, ‘U’, ‘X’, ‘Y’ and ‘Z’.
encode -a -k abc file1.txt
Removes all letters that are not ‘a’, ‘b’, ‘c’, ‘A’, ‘B’, or ‘C’. Then, encodes ‘a’ to ‘z’, ‘b’ to
y’, and ‘c’ to ‘x’ (and the corresponding capitalized equivalents.)
Generate between 40 and 80 test-case specifications (i.e., generated test frames),
inclusive, for the encode utility using the category-partition method presented in lesson
P4L2. Make sure to watch the lesson and the included demo before getting started.
When defining your test specifications, your goal is to suitably cover the domain of the
application under test. Make sure to use constraints (error and single), selector
expressions (if) and properties appropriately, rather than eliminating choices, to
keep the number of test cases within the specified thresholds. This also should
include relevant erroneous inputs and input combinations. Just to give you an
example, if you had to test a calculator, you may want to cover the case of a division by
zero. Do not manually generate combinations of inputs as single choices. Use
multiple categories and choices with necessary constraints to cause the tool to generate
combinations of the inputs. Using the calculator example, you would not offer choices of
add.”, “multiply.”, and also “add and multiply.” in a single category.
Note that the domain is constrained to the java application under test, and not the
arguments are parsed by the shell and may assume that anything the command line would
reject will not reach the application. The command line will not validate input according to
the application’s requirements. However, it will take care of problems such as enclosing
strings in quotation marks and will not allow null as an input argument. So, you must test
for invalid input arguments, but do not need to test for errors parsing the input
arguments themselves before they are sent to the java application. The sample tests
in Part II will demonstrate how input arguments would be sent to your application, for
Please also keep in mind that you are only required to specify test inputs, but you do not
have to also specify the expected outcome for such inputs in Part I. It is therefore OK if you
don’t know how the system would behave for a specific input. Using the same calculator
example, you could test the case of a division by zero even if you do not know how exactly
the calculator would behave for that input.
Tools and Useful Files
You will use the tsltool to generate test frames starting from a TSL file, just like we did in
the demo for lesson P4L2. A version of the tsltool for Linux, Mac OS X, and Windows,
together with a user manual, are available at:
We are also providing the TSL file for the example we saw in the lesson, cp-example.txt, for
These are command-line tools, which means that you have to run them from the
command line, as we do in the video demo, rather than by clicking on them.
On Linux and Mac systems, you may need to change the permissions of the files to
make them executable using the chmod utility. To run the tool on a Mac, for
instance, you should do the following, from a terminal:
chmod +x TSLgenerator-mac
/TSLgenerator-mac <command line arguments>
You can run the tsltool as follows:
<tool> [–manpage] [-cs] infile [-o outfile]
Where <tool>is the specific tool for your architecture, and the command-line flags
have the following meaning:
-manpage Prints the man page for the tool.
Reports the number of test frames that would
generated, but does not actually produce them.
Outputs to standard output.
o outfile Outputs to file outfile, unless the -s
option is also used.
If you encounter issues while using the tool, please post a public question on Piazza
and consider running the tool on the VM provided for the class or on a different
platform (if you have the option to do so).
Instructions to commit Part I
Create a directory “Assignment6” in the personal GitHub repo we assigned to you.
Add to this new directory two text files for Part I:
catpart.txt: the TSL file you created.
catpart.txt.tsl: the test specifications generated by the tsltool when
run on your TSL file.
Commit and push your files to GitHub. (You can also do this only at the end of Part II,
but it is always safer to have intermediate commits.)
To demonstrate how your test frames resulting from the category partition may be used to
cover the domain of the application with appropriate tests, and validate your work in Part
I, you will use your test specifications and a provided interface to prepare 15 actual JUnit
tests (as discussed in the lesson on the category-partition method, each test frame is a test
spec that can be instantiated as a separate concrete test case). To do so, you should
perform the following steps:
Download archive Assignment6.tar.gz
Unpack the archive in directory “Assignment6”, which you created when completing
Part I of the assignment. Hereafter, we will refer to this directory as <dir>. After
unpacking, you should see the following structure:
This is a skeleton of the Main class of the encode utility, which is provided so
that the test cases for encode can be compiled. It contains an empty main
method and a method usage, which prints on standard error a usage message
and should be called when the program is invoked incorrectly. In case you
wonder, this method is provided for consistency in test results.
This is a test class with a few test cases for the encode utility that you can use
as an example and that correspond to the examples of usage of encode that
we provided. In addition to providing this initial set of tests, class MainTest
also provides some utility methods that you can leverage/adapt and that may
help you implement your own test cases:
Creates a File object for a new temporary file in a platform
Examples of how to create, leveraging method createTmpFile,
input files with a given content as inputs for your test cases.
String getFileContent(String filename)
Returns a Stringobject with the content of the specified file, which
is useful for checking the outcome of a test case.
This is an empty test class in which you will add your test cases, provided for
Use 15 different test frames from Part I to generate 15 additional JUnit test cases for
the encode utility and put them in the test class MyMainTest(i.e., do not add your
test cases to class MainTest). For ease of grading, please name your test cases
encodeTest1, encodeTest2, and so on. Each test should contain a concise
comment that indicates its purpose and which test frame the test case implements.
Use the following format for your comments, before each test:
// Purpose: <concise description of the purpose of the test>
// Frame #: <test case number in the catpart.txt.tsl of Part I>
Each test should obviously suitably implement a unique referenced test frame.
Your test frames should contain enough clear information to create relevant test
cases whenever a test creator uses input that fulfils the criteria in the test frame. If
you cannot implement your test frames as useful JUnit tests, or find yourself
needing to add information or edge cases, you should revisit Part I. Extending
the calculator example, if your test specified a numerical input, and you decided that
you need both negative and positive numbers in your test cases, you should make
sure that is reflected in your test cases from Part I, rather than assuming that a
tester would, on their own, use negative numbers in some cases and positive in
If you are uncertain what the result should be for a test, you may make a
reasonable assumption on what to use for your test oracle. While you should
include a test oracle to clarify your intended test, and your tests must clearly reflect
the input specifications in your test frames, we will not grade the accuracy of the
test oracle itself.
Feel free to reuse and adapt, when creating your test cases, some of the code we
provided in the MainTestclass (without copying the provided test cases verbatim,
of course, which also implies that you should not implement test frames that
correspond exactly to the test cases we provided). Feel also free to implement your
test cases differently. Basically, class MainTestis provided for your convenience
and to help you get started. Whether you leverage class MainTestor not, your test
cases should assume (just like the test cases in MainTest do) that the encode utility
will be executed from the command line, as follows:
java -cp <classpath> edu.gatech.seclass.encode.Main <arguments>
Important: Do not implement the encode utility, but only the test
cases for it. This also means that most, if not all of your test cases
will fail, which is fine.
Instructions to commit Part II and submit the assignment
Commit and push your code (i.e., the Java files in directory <dir>/encode) to the
main branch of your assigned individual repository.
Paste only the single, final commit ID for your submission on Canvas, as usual.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: [email protected] 微信:itcsdx