 |
» |
|
|
|
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 remove 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 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 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
