Forum Discussion
Colin_McCrae
11 years agoCommunity Hero
I have script extensions for reading in Excel sheets, outputting results to Excel and logging.
Along with a shell project containing a driver script and a few generic script modules (for tasks that are not application specific) this effectively forms our framework.
I use a couple of global variables as switches to control local/network runs, standalone testing/debug mode.
The read in Excel sheets are user populated with each line being a function written for the project in question, it's input parameters (if any), it's expected result (if any) and a few optional control characters giving the user some basic conditional control of the flow of the script. So the automation developers put together the functions then give them to the testers to create test packs with them. I refer to it as "test lego".
The script extensions then write out excel sheets with high level results. A log file with much more detailed information. At the end of the run a summary spreadsheet is generated, stored on a network drive (or local if desired) and also e-mailed out to a user defined mailing list if required. Each spreadsheet contains file links to drill down further into the results and logs. If run as part of nightly build it also generates an HTML file which is picked up by the build process and given to the user as the results for that nights run. You can drill down from this as well.
All file locations and URL's in use are derived from either the user or the project location so the whole thing is also fully portable.
Works well.
Along with a shell project containing a driver script and a few generic script modules (for tasks that are not application specific) this effectively forms our framework.
I use a couple of global variables as switches to control local/network runs, standalone testing/debug mode.
The read in Excel sheets are user populated with each line being a function written for the project in question, it's input parameters (if any), it's expected result (if any) and a few optional control characters giving the user some basic conditional control of the flow of the script. So the automation developers put together the functions then give them to the testers to create test packs with them. I refer to it as "test lego".
The script extensions then write out excel sheets with high level results. A log file with much more detailed information. At the end of the run a summary spreadsheet is generated, stored on a network drive (or local if desired) and also e-mailed out to a user defined mailing list if required. Each spreadsheet contains file links to drill down further into the results and logs. If run as part of nightly build it also generates an HTML file which is picked up by the build process and given to the user as the results for that nights run. You can drill down from this as well.
All file locations and URL's in use are derived from either the user or the project location so the whole thing is also fully portable.
Works well.
Related Content
- 4 years ago
- 2 years ago
- 4 years ago
- 14 years ago
Recent Discussions
- 4 days ago
- 5 days ago