Some ideas about writing tests.
I had a dream about "Test Space".
My final year project was "The State Space representation of rectifier Systems" and it took me a term to understand the title.
A system has inputs and outputs. The outputs depend of the inputs and history. The history used could be a number of items and not just a simple one dimensional number, hence "space".
So for Test Case Sapce Analysis, you can write down lots of lists, each one could be a dimension in the Test Case Space Analysis.
Write down a list of test cases. What percentage have you done?
"Test Case Space" is like "State Space" but for testing.
So each test has a position in the Test Case Space which has a very rich range of dimensions.
A telephone service has an A-leg , a B-leg and a C-leg, and different call flows depending on number dialled.
The A-leg call can be made from one of a big list of device configurations.
The dialled number can also determin a call flow.
The B-leg can be a number of different outcomes, like busy, or answered by a voice device or modem.
My computer has a Part number made up of many fields. So a simple Model name may be appended by a string of letters to represent CPU speed, Disk size, and many other configurations terms.
Testcases are similar and can be titled similar to a part number.
ICs have complex part numbers as an IC can have a range of package types, speeds.
Integer numbers use positional notation so the number 123 is 1x100 + 2x10 + 3x1
Pre decimalization, the cost of an item was made of of pounds , shillings and pence. The positional notation used multiple bases. N^P where Nis not constant and P is the position.
price = pounds + shillings + pence , where 12 pence to a shilling and 20 shillings to a pound.
You can code the tests using a similar idea.
Some test dimensions are not integers, e.g. make a call and hold the call open for a finite time, the time is a real number, but may be quantized.
Sorting could be done like a number. You may want to report test results based on different parameters.
Some computer languages use positional parameters in functioanl calls, some allow lists of optional parameter_name=value
Sorting of test cases may need to be ordered by different parameters depending on what needs to be reported.
So the Test Case Space could have a very large number of test cases, which may be an infinite number of cases.
A test case may record a list of measurements, or repeated to get each measurement.
This all gets very complicated.
It may be that the test cases are randomly picked and recorded by automation analysis of test logs.
The tests capuld be plotted on a Test Case Space and tests added where there is a lack of results.
http://www.dougrice.plus.com/hp/Theory/Index.htm has this image.
For years I have been trying to work out how to list tests.
Using simple nested for next loops quickly became daunting and the test document became big.
The project managers say how many tests and what percentage have you done?
By using a random number, to pick a position in the Test Space.
Maybe use multiple random numbers, for different
Fuzz Testing is a technique using a "bad cop" and "good cop" tests and see which one breaks the system.
"Monti carlo" testing was a term used to simulate multiple Telephone connections and try and understand an envelope of results.
Dig a trench and see what you find. Have a list of asserts that you consider good behaviour to provide pass or fail.
My computer uses a file directory, which uses a tree structure. You could think of each folder as a dimensions.
When I started work, my organisation used a dot notatation to describe the position in the tree.
So the total number tests could be itterate through the list of tree nodes using a recursive search.
It gets big - too big. You only have a day to test, before the project has moved on.
Some thoughts, Using a random number to pick where to start, seems a good way.
![[Home]](../ipstats.gif)