+Megatest is free software released under the General Public License v2.0. Please see the file COPYING in the source distribution for details.
+
+
+
+
+
+Email: matt@kiatoa.com.
+
+
+Web: www.kiatoa.com/fossils/megatest
+
+
+
+
+
+This document is believed to be acurate at the time of writing but as with any opensource project the source code itself is the final arbiter of the softwares behaviour. It is the responsibility of the end user to validate that the code will perform as they expect. The author assumes no responsibility for any inaccuracies that this document may contain. In no event will Matthew Welland be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
+
+
+This document is a snapshot in time and the Megatest software has likely been changed since publication. This document and the product that it describes may be improved at any time, without notice or obligation.
+
+
+
+
+
+
+
+Megatest/document Revision History
+
+
+Notable revisions of the software are occasionally documented here.
+
+Megatest is intended to provide the minimum needed resources to make writing a suite of tests for software, design engineering or process control (via owlfs for example) without being specialized for any specific problem space. Megatest in of itself does not know what constitutes a PASS or FAIL of a test. In most cases megatest is best used in conjunction with logpro or a similar tool to parse, analyze and decide on the test outcome. A call to megatest can then be made to record the result.
+
+All data to specify the tests and configure the system is stored in plain text files. All system state is stored in an sqlite3 database. Tests are launched using the launching system available for the distributed compute platform in use. A template script is provided which can launch jobs on local and remote Linux hosts. Currently megatest uses the network filesystem to “call home” to your master sqlite3 database.
+
+Chicken scheme and a number of “eggs” are required for building megatest. See the file utils/installall.sh for an automated way to install the dependencies on Linux.
+
+Create the file megatest.config using the megatest.config template from the tests directory. At a minimum you need the following:
+
+
+
+
# Fields are the keys under which your test runs are organized
+[fields]
+field1 TEXT
+field2 TEXT
+
+[jobtools]
+# The launcher launches jobs to the local or remote hosts,
+# the job is managed on the target host by megatest,
+# comment out launcher to run local only. An example launcher
+# "nbfake" can be found in the utils directory.
+launcher nbfake
+
+# The disks section specifies where the tests will be run. As you
+# run out of space in a partition you can add additional disks
+# entries.
+# Format is:
+# name /path/to/area
+[disks]
+disk1 /tmp
+
+Note: Using csh is NOT recommended. Use bash, perl, ruby, zsh or anything other than csh. We use csh here because it is popular in the EDA industry for which Megatest was originally created.
+
+
+
+
#!/bin/tcsh -x
+
+# run the cpu1 simulation.
+# The step name is "run_simulation"
+# The commandline being run for this step is "runsim cpu1"
+# The logpro file to validate the output from the run is "runsim.logpro"
+
+$MT_MEGATEST -runstep run_simulation -logpro runsim.logpro "runsim cpu1"
+$MT_MEGATEST -test-status :state COMPLETED :status $?
+
+
+
+
+
+You can now run megatest and the created test directory will contain the new files “run_simulation.html” and “run_simulation.log”. If you are using the dashboard you can click on the run and then push the “View log” button to view the log file in firefox.
+
+To run multiple steps simply add them to the main.csh file. Here we add a step to test “cpu2”. The second step that tests cpu2 will only run after the step that tested “cpu1” completes.
+
+
+
+
#!/bin/tcsh -x
+
+# run the cpu1 simulation.
+# The step name is "run_simulation"
+# The commandline being run for this step is "runsim cpu1"
+# The logpro file to validate the output from the run is "runsim.logpro"
+
+$MT_MEGATEST -runstep run_simulation_cpu1 -logpro runsim.logpro "runsim cpu1" && \
+$MT_MEGATEST -runstep run_simulation_cpu2 -logpro runsim.logpro "runsim cpu2"
+$MT_MEGATEST -test-status :state COMPLETED :status $?
+
+
+
+
+
+5 Simple Test with Multiple Steps, Some in Parallel
+
+A good way to run steps in parallel within a single test, especially when there are following steps, is to use the Unix Make utility. Writing Makefiles is beyond the scope of this document but here is a minimal example that will run “runsim cpu1” and “runsim cpu2” in parallel. For more information on make try “info make” at the Linux command prompt.
+
+
+
+
# Example Makefile to run two steps in parallel
+
+RTLDIR=/path/to/rtl
+CPUS = cpu1 cpu2
+
+run_simulation_$(CPUS).html : $(RTLDIR)/$(CPUS)
+ $(MT_MEGATEST) -runstep run_simulation_$(CPUS) -logpro runsim.logpro "runsim $(CPUS)
+
+Sometimes a test depends on the output from a previous test or it may not make sense to run a test is another test does not complete with status “PASS”. In either of these scenarios you can use the “waiton” keyword in your testconfig file to indicate that this test must wait on one or more tests to complete before being launched. In this example there is no point in running the “system” test if the “cpu” and “mem” tests either do not complete or complete but with status “FAIL”.
+
+Use the -load-test-data switch to roll up arbitrary data from a test into the test_data table.
+
+
+
+
# Fields are:
+# category,variable,value,expected,tol,units,comment,status
+
+$MT_MEGATEST -load-test-data << EOF
+foo,bar,1.2,1.9,>
+foo,rab,1.0e9,10e9,1e9
+foo,bla,1.2,1.9,<
+foo,bal,1.2,1.2,<,,Check for overload
+foo,alb,1.2,1.2,<=,Amps,This is the high power circuit test
+foo,abl,1.2,1.3,0.1
+foo,bra,1.2,pass,silly stuff
+faz,bar,10,8mA,,,"this is a comment"
+EOF
+
+
+
+
+
+New entries are keyed on the category and variable. If a new record is inserted with a category and variable that have already been used the new record will replace the old record.
+
+
+Where value, expected and tol are specified the behavior is as follows.
+
+
+
+If value, expected and tol are numbers then status is calculated as PASS if (expected-tol) <= value <= (expected+tol)
+
+
+If value and expected are numbers and tol is >, <, >= or <= then value is compared with expected using the operator given by tol
+
+
+If status is specified its value overrides the above calculations.
+
+All keys must be specified and the runname is the name of the run that will be created. All paths are kept original inside the database. When -remove-runs is used to delete runs the data is not deleted if there are rollups that refer to the data.
+
+Pushing one of the buttons on the main dashboard will bring up the test specific dashboard. Values are updated in semi-real time as the test runs.
+
+
+
+
+
+
+8 Generating an OpenDocument Spreadsheet from the Database
+
+
+And OpenDocument multi-paned spreadsheet can be generated from the megatest.db file by running -extract-ods
+
+
+
+
megatest -extract-ods results.ods :runname %
+
+
+
+
+
+You can optionally specify the keys for your database to limit further the runs to extract into the spreadsheet. The first sheet contains all the run data and subsequent sheets contain data rolled up for the individual tests.
+
+The file named “filename” will be included as if part of the calling file. NOTE: This means no section can be named “include “ (with the whitespace).
+
+Use only if necessary, megatest will extract the location from where it used to launch and add append that to the PATH for test runs.
+
+
+
+
+
+
+
+
+runsdir
+
+
+full path to where the link tree to all runs will be created
+
+
+no
+
+
+Because your runs may be spread out over several disk partitions a central link tree is created to make finding all the runs easy.
+
+
+
+
+
+[fields]
+
+
+string of letters, numbers and underscore
+
+
+string of letters, numbers and underscore
+
+
+at least one
+
+
+
+
+
+
+
+
+[jobtools]
+
+
+launcher
+
+
+command line used to launch jobs - the job command (megatest -execute) will be appended to this
+
+
+no
+
+
+
+
+
+
+
+
+
+
+
+workhosts
+
+
+list of hostnames to run jobs on NOT SUPPORTED RIGHT NOW
+
+
+n/a
+
+
+
+
+
+
+
+
+[env-override]
+
+
+string of letters, numbers and underscore
+
+
+any string
+
+
+no
+
+
+These are set on the test launching machine, not the test running machine. Typical usage is to control the host or run queue for launching tests. These values will not be seen by the test when it runs.
+
+
+
+
+
+[disks]
+
+
+string of letters, numbers and underscore
+
+
+a valid path writable by the test launching process and by the test process
+
+
+yes
+
+
+The disk usage balancing algorithm is to choose the disk with the least space for each test run.
+
+variables set in this section will be available for all runs, defining the same variable in another section will override the value from the default section
+
+
+
+
+
+[field1value/field2value...]
+
+
+string of letters, numbers and underscore
+
+
+any
+
+
+no
+
+
+the values in this section will be set for any run where field1 is field1value, field2 is field2value and fieldN is fieldNvalue.
+
+
+
+
+
+
+
+
+Example: a test suite that checks that a piece of software works correctly for different customer configurations and locations each of which is done as a separate release regression run. The fields, CUSTOMER and LOCATION were chosen. The following runconfigs.config file would set some variables specific to runs for megacorp in India and femtocorp in the Cook Islands and New Zealand:
+
+The script must be executable and either provide the full path or put a copy at the top of your test directory
+
+
+
+
+
+[requirements]
+
+
+waiton
+
+
+list of valid test names
+
+
+no
+
+
+This test will not run until the named tests are state completed and status PASS
+
+
+
+
+
+[items]
+
+
+any valid
+
+
+list of values
+
+
+no
+
+
+The test will be repeated once for each item with the variable name set to the value. If there is more than one variable then the test will be run against all unique combinations of the values
+
-Megatest is free software released under the General Public License v2.0. Please see the file COPYING in the source distribution for details.
-
-
-
-
-
-Email: matt@kiatoa.com.
-
-
-Web: www.kiatoa.com/fossils/megatest
-
-
-
-
-
-This document is believed to be acurate at the time of writing but as with any opensource project the source code itself is the final arbiter of the softwares behaviour. It is the responsibility of the end user to validate that the code will perform as they expect. The author assumes no responsibility for any inaccuracies that this document may contain. In no event will Matthew Welland be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
-
-
-This document is a snapshot in time and the Megatest software has likely been changed since publication. This document and the product that it describes may be improved at any time, without notice or obligation.
-
-
-
-
-
-
-
-Megatest/document Revision History
-
-
-Notable revisions of the software are occasionally documented here.
-
-Megatest is intended to provide the minimum needed resources to make writing a suite of tests for software, design engineering or process control (via owlfs for example) without being specialized for any specific problem space. Megatest in of itself does not know what constitutes a PASS or FAIL of a test. In most cases megatest is best used in conjunction with logpro or a similar tool to parse, analyze and decide on the test outcome. A call to megatest can then be made to record the result.
-
-All data to specify the tests and configure the system is stored in plain text files. All system state is stored in an sqlite3 database. Tests are launched using the launching system available for the distributed compute platform in use. A template script is provided which can launch jobs on local and remote Linux hosts. Currently megatest uses the network filesystem to “call home” to your master sqlite3 database.
-
-Chicken scheme and a number of “eggs” are required for building megatest. See the file utils/installall.sh for an automated way to install the dependencies on Linux.
-
-Create the file megatest.config using the megatest.config template from the tests directory. At a minimum you need the following:
-
-
-
-
# Fields are the keys under which your test runs are organized
-[fields]
-field1 TEXT
-field2 TEXT
-
-[jobtools]
-# The launcher launches jobs to the local or remote hosts,
-# the job is managed on the target host by megatest,
-# comment out launcher to run local only. An example launcher
-# "nbfake" can be found in the utils directory.
-launcher nbfake
-
-# The disks section specifies where the tests will be run. As you
-# run out of space in a partition you can add additional disks
-# entries.
-# Format is:
-# name /path/to/area
-[disks]
-disk1 /tmp
-
-Note: Using csh is NOT recommended. Use bash, perl, ruby, zsh or anything other than csh. We use csh here because it is popular in the EDA industry for which Megatest was originally created.
-
-
-
-
#!/bin/tcsh -x
-
-# run the cpu1 simulation.
-# The step name is "run_simulation"
-# The commandline being run for this step is "runsim cpu1"
-# The logpro file to validate the output from the run is "runsim.logpro"
-
-$MT_MEGATEST -runstep run_simulation -logpro runsim.logpro "runsim cpu1"
-$MT_MEGATEST -test-status :state COMPLETED :status $?
-
-
-
-
-
-You can now run megatest and the created test directory will contain the new files “run_simulation.html” and “run_simulation.log”. If you are using the dashboard you can click on the run and then push the “View log” button to view the log file in firefox.
-
-To run multiple steps simply add them to the main.csh file. Here we add a step to test “cpu2”. The second step that tests cpu2 will only run after the step that tested “cpu1” completes.
-
-
-
-
#!/bin/tcsh -x
-
-# run the cpu1 simulation.
-# The step name is "run_simulation"
-# The commandline being run for this step is "runsim cpu1"
-# The logpro file to validate the output from the run is "runsim.logpro"
-
-$MT_MEGATEST -runstep run_simulation_cpu1 -logpro runsim.logpro "runsim cpu1" && \
-$MT_MEGATEST -runstep run_simulation_cpu2 -logpro runsim.logpro "runsim cpu2"
-$MT_MEGATEST -test-status :state COMPLETED :status $?
-
-
-
-
-
-5 Simple Test with Multiple Steps, Some in Parallel
-
-A good way to run steps in parallel within a single test, especially when there are following steps, is to use the Unix Make utility. Writing Makefiles is beyond the scope of this document but here is a minimal example that will run “runsim cpu1” and “runsim cpu2” in parallel. For more information on make try “info make” at the Linux command prompt.
-
-
-
-
# Example Makefile to run two steps in parallel
-
-RTLDIR=/path/to/rtl
-CPUS = cpu1 cpu2
-
-run_simulation_$(CPUS).html : $(RTLDIR)/$(CPUS)
- $(MT_MEGATEST) -runstep run_simulation_$(CPUS) -logpro runsim.logpro "runsim $(CPUS)
-
-Sometimes a test depends on the output from a previous test or it may not make sense to run a test is another test does not complete with status “PASS”. In either of these scenarios you can use the “waiton” keyword in your testconfig file to indicate that this test must wait on one or more tests to complete before being launched. In this example there is no point in running the “system” test if the “cpu” and “mem” tests either do not complete or complete but with status “FAIL”.
-
-Use the -load-test-data switch to roll up arbitrary data from a test into the test_data table.
-
-
-
-
# Fields are:
-# category,variable,value,expected,tol,units,comment,status
-
-$MT_MEGATEST -load-test-data << EOF
-foo,bar,1.2,1.9,>
-foo,rab,1.0e9,10e9,1e9
-foo,bla,1.2,1.9,<
-foo,bal,1.2,1.2,<,,Check for overload
-foo,alb,1.2,1.2,<=,Amps,This is the high power circuit test
-foo,abl,1.2,1.3,0.1
-foo,bra,1.2,pass,silly stuff
-faz,bar,10,8mA,,,"this is a comment"
-EOF
-
-
-
-
-
-New entries are keyed on the category and variable. If a new record is inserted with a category and variable that have already been used the new record will replace the old record.
-
-
-Where value, expected and tol are specified the behavior is as follows.
-
-
-
-If value, expected and tol are numbers then status is calculated as PASS if (expected-tol) <= value <= (expected+tol)
-
-
-If value and expected are numbers and tol is >, <, >= or <= then value is compared with expected using the operator given by tol
-
-
-If status is specified its value overrides the above calculations.
-
-All keys must be specified and the runname is the name of the run that will be created. All paths are kept original inside the database. When -remove-runs is used to delete runs the data is not deleted if there are rollups that refer to the data.
-
-Pushing one of the buttons on the main dashboard will bring up the test specific dashboard. Values are updated in semi-real time as the test runs.
-
-
-
-
-
-
-8 Generating an OpenDocument Spreadsheet from the Database
-
-
-And OpenDocument multi-paned spreadsheet can be generated from the megatest.db file by running -extract-ods
-
-
-
-
megatest -extract-ods results.ods :runname %
-
-
-
-
-
-You can optionally specify the keys for your database to limit further the runs to extract into the spreadsheet. The first sheet contains all the run data and subsequent sheets contain data rolled up for the individual tests.
-
-The file named “filename” will be included as if part of the calling file. NOTE: This means no section can be named “include “ (with the whitespace).
-
-Use only if necessary, megatest will extract the location from where it used to launch and add append that to the PATH for test runs.
-
-
-
-
-
-
-
-
-runsdir
-
-
-full path to where the link tree to all runs will be created
-
-
-no
-
-
-Because your runs may be spread out over several disk partitions a central link tree is created to make finding all the runs easy.
-
-
-
-
-
-[fields]
-
-
-string of letters, numbers and underscore
-
-
-string of letters, numbers and underscore
-
-
-at least one
-
-
-
-
-
-
-
-
-[jobtools]
-
-
-launcher
-
-
-command line used to launch jobs - the job command (megatest -execute) will be appended to this
-
-
-no
-
-
-
-
-
-
-
-
-
-
-
-workhosts
-
-
-list of hostnames to run jobs on NOT SUPPORTED RIGHT NOW
-
-
-n/a
-
-
-
-
-
-
-
-
-[env-override]
-
-
-string of letters, numbers and underscore
-
-
-any string
-
-
-no
-
-
-These are set on the test launching machine, not the test running machine. Typical usage is to control the host or run queue for launching tests. These values will not be seen by the test when it runs.
-
-
-
-
-
-[disks]
-
-
-string of letters, numbers and underscore
-
-
-a valid path writable by the test launching process and by the test process
-
-
-yes
-
-
-The disk usage balancing algorithm is to choose the disk with the least space for each test run.
-
-variables set in this section will be available for all runs, defining the same variable in another section will override the value from the default section
-
-
-
-
-
-[field1value/field2value...]
-
-
-string of letters, numbers and underscore
-
-
-any
-
-
-no
-
-
-the values in this section will be set for any run where field1 is field1value, field2 is field2value and fieldN is fieldNvalue.
-
-
-
-
-
-
-
-
-Example: a test suite that checks that a piece of software works correctly for different customer configurations and locations each of which is done as a separate release regression run. The fields, CUSTOMER and LOCATION were chosen. The following runconfigs.config file would set some variables specific to runs for megacorp in India and femtocorp in the Cook Islands and New Zealand:
-
-The script must be executable and either provide the full path or put a copy at the top of your test directory
-
-
-
-
-
-[requirements]
-
-
-waiton
-
-
-list of valid test names
-
-
-no
-
-
-This test will not run until the named tests are state completed and status PASS
-
-
-
-
-
-[items]
-
-
-any valid
-
-
-list of values
-
-
-no
-
-
-The test will be repeated once for each item with the variable name set to the value. If there is more than one variable then the test will be run against all unique combinations of the values
-
-Megatest is free software released under the General Public License v2.0. Please see the file COPYING in the source distribution for details.
-
-
-
-
-
-Email: matt@kiatoa.com.
-
-
-Web: www.kiatoa.com/fossils/megatest
-
-
-
-
-
-This document is believed to be acurate at the time of writing but as with any opensource project the source code itself is the final arbiter of the softwares behaviour. It is the responsibility of the end user to validate that the code will perform as they expect. The author assumes no responsibility for any inaccuracies that this document may contain. In no event will Matthew Welland be liable for direct, indirect, special, exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
-
-
-This document is a snapshot in time and the Megatest software has likely been changed since publication. This document and the product that it describes may be improved at any time, without notice or obligation.
-
-
-
-
-
-
-
-Megatest/document Revision History
-
-
-Notable revisions of the software are occasionally documented here.
-
-Megatest is intended to provide the minimum needed resources to make writing a suite of tests for software, design engineering or process control (via owlfs for example) without being specialized for any specific problem space. Megatest in of itself does not know what constitutes a PASS or FAIL of a test. In most cases megatest is best used in conjunction with logpro or a similar tool to parse, analyze and decide on the test outcome. A call to megatest can then be made to record the result.
-
-All data to specify the tests and configure the system is stored in plain text files. All system state is stored in an sqlite3 database. Tests are launched using the launching system available for the distributed compute platform in use. A template script is provided which can launch jobs on local and remote Linux hosts. Currently megatest uses the network filesystem to “call home” to your master sqlite3 database.
-
-Chicken scheme and a number of “eggs” are required for building megatest. See the file utils/installall.sh for an automated way to install the dependencies on Linux.
-
-Create the file megatest.config using the megatest.config template from the tests directory. At a minimum you need the following:
-
-
-
-
# Fields are the keys under which your test runs are organized
-[fields]
-field1 TEXT
-field2 TEXT
-
-[jobtools]
-# The launcher launches jobs to the local or remote hosts,
-# the job is managed on the target host by megatest,
-# comment out launcher to run local only. An example launcher
-# "nbfake" can be found in the utils directory.
-launcher nbfake
-
-# The disks section specifies where the tests will be run. As you
-# run out of space in a partition you can add additional disks
-# entries.
-# Format is:
-# name /path/to/area
-[disks]
-disk1 /tmp
-
-Note: Using csh is NOT recommended. Use bash, perl, ruby, zsh or anything other than csh. We use csh here because it is popular in the EDA industry for which Megatest was originally created.
-
-
-
-
#!/bin/tcsh -x
-
-# run the cpu1 simulation.
-# The step name is "run_simulation"
-# The commandline being run for this step is "runsim cpu1"
-# The logpro file to validate the output from the run is "runsim.logpro"
-
-$MT_MEGATEST -runstep run_simulation -logpro runsim.logpro "runsim cpu1"
-$MT_MEGATEST -test-status :state COMPLETED :status $?
-
-
-
-
-
-You can now run megatest and the created test directory will contain the new files “run_simulation.html” and “run_simulation.log”. If you are using the dashboard you can click on the run and then push the “View log” button to view the log file in firefox.
-
-To run multiple steps simply add them to the main.csh file. Here we add a step to test “cpu2”. The second step that tests cpu2 will only run after the step that tested “cpu1” completes.
-
-
-
-
#!/bin/tcsh -x
-
-# run the cpu1 simulation.
-# The step name is "run_simulation"
-# The commandline being run for this step is "runsim cpu1"
-# The logpro file to validate the output from the run is "runsim.logpro"
-
-$MT_MEGATEST -runstep run_simulation_cpu1 -logpro runsim.logpro "runsim cpu1" && \
-$MT_MEGATEST -runstep run_simulation_cpu2 -logpro runsim.logpro "runsim cpu2"
-$MT_MEGATEST -test-status :state COMPLETED :status $?
-
-
-
-
-
-5 Simple Test with Multiple Steps, Some in Parallel
-
-A good way to run steps in parallel within a single test, especially when there are following steps, is to use the Unix Make utility. Writing Makefiles is beyond the scope of this document but here is a minimal example that will run “runsim cpu1” and “runsim cpu2” in parallel. For more information on make try “info make” at the Linux command prompt.
-
-
-
-
# Example Makefile to run two steps in parallel
-
-RTLDIR=/path/to/rtl
-CPUS = cpu1 cpu2
-
-run_simulation_$(CPUS).html : $(RTLDIR)/$(CPUS)
- $(MT_MEGATEST) -runstep run_simulation_$(CPUS) -logpro runsim.logpro "runsim $(CPUS)
-
-Sometimes a test depends on the output from a previous test or it may not make sense to run a test is another test does not complete with status “PASS”. In either of these scenarios you can use the “waiton” keyword in your testconfig file to indicate that this test must wait on one or more tests to complete before being launched. In this example there is no point in running the “system” test if the “cpu” and “mem” tests either do not complete or complete but with status “FAIL”.
-
-Use the -load-test-data switch to roll up arbitrary data from a test into the test_data table.
-
-
-
-
# Fields are:
-# category,variable,value,expected,tol,units,comment,status
-
-$MT_MEGATEST -load-test-data << EOF
-foo,bar,1.2,1.9,>
-foo,rab,1.0e9,10e9,1e9
-foo,bla,1.2,1.9,<
-foo,bal,1.2,1.2,<,,Check for overload
-foo,alb,1.2,1.2,<=,Amps,This is the high power circuit test
-foo,abl,1.2,1.3,0.1
-foo,bra,1.2,pass,silly stuff
-faz,bar,10,8mA,,,"this is a comment"
-EOF
-
-
-
-
-
-New entries are keyed on the category and variable. If a new record is inserted with a category and variable that have already been used the new record will replace the old record.
-
-
-Where value, expected and tol are specified the behavior is as follows.
-
-
-
-If value, expected and tol are numbers then status is calculated as PASS if (expected-tol) <= value <= (expected+tol)
-
-
-If value and expected are numbers and tol is >, <, >= or <= then value is compared with expected using the operator given by tol
-
-
-If status is specified its value overrides the above calculations.
-
-All keys must be specified and the runname is the name of the run that will be created. All paths are kept original inside the database. When -remove-runs is used to delete runs the data is not deleted if there are rollups that refer to the data.
-
-Pushing one of the buttons on the main dashboard will bring up the test specific dashboard. Values are updated in semi-real time as the test runs.
-
-
-
-
-
-
-8 Generating an OpenDocument Spreadsheet from the Database
-
-
-And OpenDocument multi-paned spreadsheet can be generated from the megatest.db file by running -extract-ods
-
-
-
-
megatest -extract-ods results.ods :runname %
-
-
-
-
-
-You can optionally specify the keys for your database to limit further the runs to extract into the spreadsheet. The first sheet contains all the run data and subsequent sheets contain data rolled up for the individual tests.
-
-The file named “filename” will be included as if part of the calling file. NOTE: This means no section can be named “include “ (with the whitespace).
-
-Use only if necessary, megatest will extract the location from where it used to launch and add append that to the PATH for test runs.
-
-
-
-
-
-
-
-
-runsdir
-
-
-full path to where the link tree to all runs will be created
-
-
-no
-
-
-Because your runs may be spread out over several disk partitions a central link tree is created to make finding all the runs easy.
-
-
-
-
-
-[fields]
-
-
-string of letters, numbers and underscore
-
-
-string of letters, numbers and underscore
-
-
-at least one
-
-
-
-
-
-
-
-
-[jobtools]
-
-
-launcher
-
-
-command line used to launch jobs - the job command (megatest -execute) will be appended to this
-
-
-no
-
-
-
-
-
-
-
-
-
-
-
-workhosts
-
-
-list of hostnames to run jobs on NOT SUPPORTED RIGHT NOW
-
-
-n/a
-
-
-
-
-
-
-
-
-[env-override]
-
-
-string of letters, numbers and underscore
-
-
-any string
-
-
-no
-
-
-These are set on the test launching machine, not the test running machine. Typical usage is to control the host or run queue for launching tests. These values will not be seen by the test when it runs.
-
-
-
-
-
-[disks]
-
-
-string of letters, numbers and underscore
-
-
-a valid path writable by the test launching process and by the test process
-
-
-yes
-
-
-The disk usage balancing algorithm is to choose the disk with the least space for each test run.
-
-variables set in this section will be available for all runs, defining the same variable in another section will override the value from the default section
-
-
-
-
-
-[field1value/field2value...]
-
-
-string of letters, numbers and underscore
-
-
-any
-
-
-no
-
-
-the values in this section will be set for any run where field1 is field1value, field2 is field2value and fieldN is fieldNvalue.
-
-
-
-
-
-
-
-
-Example: a test suite that checks that a piece of software works correctly for different customer configurations and locations each of which is done as a separate release regression run. The fields, CUSTOMER and LOCATION were chosen. The following runconfigs.config file would set some variables specific to runs for megacorp in India and femtocorp in the Cook Islands and New Zealand:
-
-The script must be executable and either provide the full path or put a copy at the top of your test directory
-
-
-
-
-
-[requirements]
-
-
-waiton
-
-
-list of valid test names
-
-
-no
-
-
-This test will not run until the named tests are state completed and status PASS
-
-
-
-
-
-[items]
-
-
-any valid
-
-
-list of values
-
-
-no
-
-
-The test will be repeated once for each item with the variable name set to the value. If there is more than one variable then the test will be run against all unique combinations of the values
-
+
+
+
+