 |
» |
|
|
|
The following testing
suggestions do not cover all test scenarios. There may still be
problems with a control script even after doing this testing. For
example, you may test installing/removing individual filesets. But there
might be some interactions that are discovered only after all the filesets
are installed on or removed from the system. Similarly, you may test the control scripts on a fully loaded
system and miss a problem when you execute a command in your script
that is not part of the base (or core) system. If your target system
does not contain the particular command, your script may fail. Testing
Installation Scripts | |
For checkinstall,
preinstall, and postinstall scripts you should perform at least
these tests. All tests can be performed on the local system (that
is, by doing local installs). The basic test: Run swinstall to install the full
product (that is, all the filesets). To avoid testing the configure
script(s), either do not include any in the product, or set the defer_configure option
to "true." After the installation completes, check the <${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the scripts or the
format/contents of the messages generated by the scripts. Study the resulting file system to see if the scripts
performed the expected actions. Re-run the test by re-installing the same product.
If you want to avoid the time spent loading files,
then set the reinstall_files option to "false" and
the reinstall_files_use_cksum option to "false." If a previous version of the product can be updated
to this version, then re-run the test by updating this product where
the previous version has been installed. If your checkinstall script can generate error or
warning conditions based on the current activity or configuration
of the target system, then enable those conditions to ensure that
the checkinstall script correctly detects them. Re-run the test by installing into an alternate
root directory (swinstall -r) instead of the primary root directory ("/").
Make sure that the scripts perform all of their operations (if any)
within the alternate root directory. (This verifies the correct
use of ${SW_ROOT_DIRECTORY} by your scripts.) If your product is locatable (that is, it can be
installed into a different location), then re-run the tests by installing
the product into a different location (swinstall product:new_location). Make sure that the scripts perform all of their operations
in the new location, and not the default location. (This verifies
the correct use of $SW_LOCATION by your scripts.) If you have a complex script, run additional tests
for your product that you feel will give you confidence your product
has been installed correctly on the system. For example, only install
certain subsets of your product instead of the full product.
Testing
Configuration Scripts | |
For configure,
verify, and unconfigure scripts you should perform at least these
tests. All tests can be performed on the local system (that is,
by doing local installs). Run swinstall to install the full product (that is, all the
filesets). Let the installation process perform the configuration
task (and run your configure script(s)). After the installation and configuration
completes, check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the configure script
or the format/contents of the messages generated by it. Study the resulting file system to see if the configure
script performed the expected actions. Test the product itself to see if the necessary
configuration tasks were performed such that the product is ready
to use.
Run swremove to remove the configured product. After the unconfiguration and removal
completes, check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the unconfigure script
or the format/contents of the messages generated by it. Study the resulting file system to see if the unconfigure
script performed the expected "undo" actions.
Run swinstall to install the full product again.
Set the defer_configure option to "false" to avoid executing
the configure scripts. After the installation completes,
run swconfig to configure your product. Study the resulting file system to see if the configure
script performed the expected actions. Test the product itself to see if the necessary
configuration tasks were performed such that the product is ready
to use. Now run swconfig -u to unconfigure your product. Study the resulting file system to see if the unconfigure
script performed the expected "undo" actions. Run swconfig again to re-configure your product. Study the resulting file system to see if the configure
script performed the expected actions.
Run swverify to execute the verify script(s). After the verification completes,
check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the verify script or
the format/contents of the messages generated by it.
If a previous version of the product can be updated
to this version, then re-run the first test by updating this product
to a system where the previous version has been installed and configured. Note that configure and unconfigure scripts are
never run unless the ${SW_ROOT_DIRECTORY} is /. However, verify scripts are run in both cases. If your product is locatable (that is, it can be
installed into a different location), then re-run the tests by installing
and configuring the product in a different location. Make sure that
the scripts perform all their operations in the new location, and
not the default location. (This verifies the correct use of $SW_LOCATION by your scripts.) If you have a complex script, run additional tests
for your product that you feel will give you confidence your product
has been installed correctly on the system. For example, only install
certain subsets of your product instead of the full product.
Testing
Removal Scripts | |
For checkremove,
preremove, and postremove scripts you should perform at least these
tests. All tests can be performed on the local system (that is,
by doing local installs). There is no value gained by testing your scripts
by installing to remote target systems. Run swinstall to install the full product (that is, all the
filesets). Avoid configuration by setting the defer_configure option to false. Run swremove to removed the unconfigured
product. After the removal completes, check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the removal scripts
or the format/contents of the messages generated by the scripts. Study the resulting file system to see if the removal
scripts performed the expected actions.
Run swinstall to install the full product (that
is, all of the filesets). Let the installation process perform the
configuration task (and run your configure script(s)). Run swremove to removed the configured
product. After the unconfiguration and removal completes,
check the ${SW_ROOT_DIRECTORY}var/adm/sw/swagent.log file for any problems, either in the removal scripts
or the format/contents of the messages generated by the scripts. Study the resulting file system to see if the removal
scripts performed the expected actions.
If your checkremove script can generate error or
warning conditions based on the current activity or configuration
of the target system, then enable those conditions to ensure that
the checkremove script correctly detects them. Re-run the first test by installing into an alternate
root directory (swinstall -r) instead of the primary root directory ("/").
Make sure that the scripts perform all of their operations (if any)
within the alternate root directory. (This verifies the correct
use of ${SW_ROOT_DIRECTORY} by your scripts.) If your product is locatable (that is, it can be
installed into a different location), then re-run the tests by installing
the product into a different location. When removing the product,
make sure that the removal scripts perform all of their operations
in the new location, and not the default location. (This verifies
the correct use of $SW_LOCATION by your scripts.) If you have a complex script, run additional tests
for your product that you feel will give you confidence your product
has been installed correctly on the system. For example, only install
certain subsets of your product instead of the full product, then
perform the remove operations. (Or only remove subsets of the fully
installed product.)
|
Printable version
