Last post was about Rainbow testing. So that's old news, and I
lost count of the number of bugs it found, and have been fixed.
Probably 30+ crashes.
Now, I have to put together all these odds & ends of code I
wrote disparately over the last 18 months into a single
collection to enable complete end-to-end testing.
I have now got roughly the following:
o) random table maker
o) query maker based on any tables, (using predefined
rules)
o) data generator for any tables
o) complete charset collection for each valid character
o) database of mysql functions, data types
o) multi-threaded testing environment for any queries
o) query results comparer for any queries
o) rainbow, which will provide help in making good coverage of
functions, etc.
What's needed still? Well, I would like 56 hours in a day ...
More posts later when v0.001 of the integrated …
I thought of a brilliant QA plan. Create sql rainbow tables! Just
trust me, this system of QA will be very powerful in bug finding.
Especially important will be the comparison of old/new versions
of mysql. Writing a prototype now, on my day off.
Just during prototype development, I've discovered a handful of
bugs. I'm testing all functions that are documented in the
manual. This is alot that I've written up:
[Read more]
mysql> select count(*),category from func group by category;
+----------+--------------+
| count(*) | category |
+----------+--------------+
| 6 | arithmetic |
| 7 | bit |
| 60 | casting |
| 47 | comparison |
| 52 | datetime |
| 18 | encryption |
| 127 | geometry |
| 17 | information |
| 7 | logical |
| 32 | mathematical |
| 9 | misc |
| …
I've been thinking about this today. My attempts thus far to
write random queries which stress various parts of the server
have worked, and served a purpose - but have been rather huge and
clumsy.
For example a 5 union select, each comprising of 7 joins did have
it's value.. The problem with huge random queries is simply that
the results cannot be verified as easily as they were constructed
(unless you run the same on various DBMS). These huge tests are
mostly only good for checking if the server crashes.
Now, I wish to try write testcases that have these
properties:
- small
- results are self-verified
- each test is random, but reproducible given a seed
value
Tonight I'll throw together a code-generator to do simple
insert/select and post any interesting results here later.