Testing Scripts

  • Article

Microsoft® Windows® 2000 Scripting Guide

When you buy a new car, you have some assurance that you will not turn the key and have the back end of the car burst into flames. This is because cars are thoroughly tested before they are placed into production and before they are sold to consumers. No car maker would last long if it simply slapped a new car together and then sold it to consumers on a "use at your own risk" basis.

Admittedly, it is unlikely that any of your scripts will burst into flames the first time they are run. On the other hand, scripts are powerful tools for system administration; this means they can do a number of good things if written correctly, and a number of bad things if written incorrectly. To make sure your scripts are working properly, and to make sure there are no surprises when you use them in a production environment, always test your scripts before deploying them. Although a complete guide to software testing is beyond the scope of this chapter, you can benefit from following these general guidelines:

  • Test in iterative fashion. Do not wait until your script is finished before you begin testing it. For example, suppose you have a script that:

    • Reads in a Microsoft Excel spreadsheet containing information about new users in your domain.

    • Creates new user accounts based on that information.

    • Creates new Microsoft Exchange mailboxes based on that information.

    • Adds the new users to the appropriate security groups.

    • Creates custom logon scripts based on the security groups the users belong to.

    If the script is written in this same order, you should test the code as soon as the procedure to read the Excel spreadsheet is written. If that procedure does not work, the rest of the script fails as well. After you have written and debugged the procedure for reading in the Excel spreadsheet, move on to the procedure for creating new user accounts.

    In addition, test any new statements added to your script before the script is released. Never assume that the new statements work and thus require no testing.

  • Cover all possibilities when testing. Always test whether the script can be made not to work. For example, suppose your script requests that the user enter an ID number. What happens if the user enters an ID number that does not exist, or an ID number that contains an invalid character? What happens if the user doesn't even enter an ID number but merely presses ENTER? What happens if the user clicks Cancel instead? Make sure your testing accounts for all these possibilities.

  • Verify that the output you receive is correct. Sometimes the problem with a script is subtle and difficult to detect. For example, suppose you have a script that retrieves user information from Active Directory. You enter a user name, and the script responds by showing you the person's address, phone number, and job title. Do not assume that the script is working just because you received information of some kind; what if the script returns the address, phone number, and title of someone other than the person requested? Double-check the returned information against some other source, such as the form originally filled out by the employee.

  • Have someone else test your script. As much as possible, you should avoid testing scripts that you write, simply because you know what kind of input the script expects at any given time. As a result, you tend to do the expected. If the script requires you to enter a drive letter, you are likely to type a valid drive letter using a valid format (for example, C:). Someone who does not know how the script works might type something else, perhaps an invalid drive (6:), or the wrong format (C). This provides a more realistic test of how the script will actually be used.

  • Test your scripts on multiple platforms. You should test your scripts on each platform used in your organization. For example, the Microsoft® Windows XP® family includes a different version of WSH than the version that shipped with Windows 2000. Unless you upgrade WSH on the Windows 2000-based computers, you might discover that scripts that work on Windows XP development computers do not work anywhere else. Likewise, there are differences between WMI on Microsoft® Windows NT® and WMI on Windows 2000 or the Windows XP family. Do not assume that just because each of these platforms contains a WMI class named Win32_OperatingSystem the properties and methods of these classes are identical. Because of differences between platforms, a script that works on one platform might not work on others.

    Because of such differences, you might need to design scripts only for a specific platform. In that case, your script should include code that verifies that it is running on the correct platform. The WMI script shown in Listing 18.4 retrieves the operating system platform.

Listing 18.4 Retrieving the Operating System Platform

   
1
2
3
4
5
6
7
8

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colOS = objWMIService.ExecQuery _
 ("SELECT * FROM Win32_OperatingSystem")
For Each objOS in colOS
 Wscript.Echo objOS.Caption & ", " & objOS.Version
Next

If you do not have WMI installed on all the computers in your organization, the VBScript shown in Listing 18.5 can query the registry and return the operating system.

Listing 18.5 Querying the Registry and Returning the Operating System

   
1
2
3
4
5
6
7
8
9

Set WshShell = WScript.CreateObject("WScript.Shell")
Set WshSysEnv = WshShell.Environment("SYSTEM")
strOS = WshSysEnv("OS")
strVersionNumber = WshShell.RegRead("HKLM\Software\Microsoft\" _
 & "Windows NT\CurrentVersion\CurrentVersion")
strBuildNumber = WshShell.RegRead("HKLM\Software\Microsoft\" _
 & "Windows NT\CurrentVersion\CurrentBuildNumber")
strActualOS = strOS & ", " & strVersionNumber & ", " & strBuildNumber
Wscript.Echo strActualOS

  • Test your scripts on all relevant computers. If your script must run on computers with different hardware, make sure you test it on each of those hardware platforms. Depending on the task you are trying to perform, differences in computer hardware, such as processor speed, memory, hard disk speed, and network adapters can affect the operation of the script. Scripts typically do not depend on hardware, but it is better to test for the exceptional situation.

  • Record problems you encounter and their resolution. Keep track of common coding problems and how they are resolved; it is likely that someone else might encounter this same problem. Methods of recording this information range from the formal, such as storing problems and solutions in a database, to the informal, such as creating a Frequently Encountered Problems Web page.