So I’ve done the obvious analysis of the performance testing process.
- 1. Pre-Test Criteria
- 2. Test Execution
- 3. Post-Test Results
Clearly that lends itself to a least one form for the run details and a second form for the post-run details.
I believe a single table might be the easiest approach – in any case a single primary key of run id will be used – it will be autoassigned within my database. I will also have a test timestamp and a test name but the run id will be the only key.
The Pre-Test information shall consist of, but not be limited to:
- A test run id
- A test timestamp
- A test name
- environment
- scripts, run_time setting, vusers
- test purpose
EDIT 23/07/2013 :
I’ve re-visited this list – today – I’m not sure how best to track the scripts included and the run time settings – it’s a pain to enter that stuff into a form by hand – ideally i’d steal it from the scenario details. Failing that I just won’t include that information directly
I’ve started work on a variety of pages and the database itself. I have a form that accepts some of the inputs mentioned above, I have a working script for uploading and unpacking a zip file. I have a page that will pull the results in a structured (tabular) format. That looks AWFUL in this particular wordpress template though.
I’ve basically been pressing on with learning PHP and how best to structure this into a single validated page. I’ll post all of the source code on here in the next few posts. Once I’ve sanitised them.