Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Software Distributor Administration Guide: HP-UX 11i v1, 11i v2, and 11i v3 > Chapter 11 Using Control Scripts

Testing Control Scripts

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

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).

  1. 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.

  2. 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.”

  3. 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.

  4. 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.

  5. 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.)

  6. 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.)

  7. 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).

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Note that configure and unconfigure scripts are never run unless the ${SW_ROOT_DIRECTORY} is /. However, verify scripts are run in both cases.

  7. 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.)

  8. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.)

  5. 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.)

  6. 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
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1997, 2000-2003, 2006, 2007, 2008 Hewlett-Packard Development Company, L.P.