Find out what command-line arguments your applications support and leverage those arguments as much as possible in your batch files. Some applications expose a lot of their functionality in command-line switches. However, even if you need to test functionality that can be entered only by hand in a graphical interface, you're not out of luck. The keystrokes.vbs script that Web Listing 3 shows demonstrates how to use the SendKeys() method to send keystrokes to a graphical application. Pay attention to the commands you type as you test a GUI program—don't forget that the Alt key can be used to pull down menus—then have your script enter the same commands.
As you can see in keystrokes.vbs, the AppActivate("App Title>") method gives the application with App Title in its title bar the input focus to ensure that the correct application receives the script's keystrokes. The Sleep(Milliseconds) method helps the application keep up with the script by causing the script to wait the specified number of milliseconds before continuing to execute. Comments in keystrokes.vbs spell out the keystrokes for special and frequently used keys and key combinations. With a little trial-and-error debugging, you can coax most graphical applications into running hands-free.
You can use other scripts to stress services remotely. To do so, run applications on remote systems that interact with the service that you want to test on the target lab machine. For alphabetical listings of available tools and their descriptions, see the Help files that accompany the Support Tools and Microsoft resource kits. To test IIS servers, investigate load simulators such as Application Center Test (ACT), which the Microsoft article "INFO: Application Center Test (ACT) Tests Your Web Applications by Simulating Load" (http://support.microsoft.com/?kbid=307492) describes.
When you run your batch files and other scripts to give your services a workout, some errors, such as a blue screen of death or a frozen mouse pointer, will be easy to spot. But some malfunctioning services will just silently record their errors in one or more of your logs. Reviewing these logs manually is too tedious and error-prone to be practical. Instead, search the logs with tools or scripts that can automatically extract errors, warnings, and other interesting tidbits.
Text-file logs are the easiest to search. The Windows findstr.exe utility extracts from files lines that match patterns you specify, including basic regular expressions. To begin, examine the text logs typically produced by the service you're testing and identify all the strings (such as Fail, Error, or 500) that indicate problems. Save these strings, one per line, in a text file named signatures.txt. (You'll have a separate signatures file for each type of log you regularly search.) Then, use the command
findstr.exe /g:signatures.txt
logfile.log > output.txt
to search a text log for all the lines that have at least one of these patterns and redirect them to an output file. If the output.txt file is larger than 0 bytes, you have a hit and you need to investigate the problem. For more information about findstr.exe, see the Command Line Reference in Windows Help. For a regular-expressions tutorial and tools that are much more powerful and user-friendly than findstr.exe, go to http://www.regular-expressions.info/tutorial.html.
Convert the binary Windows event logs to plain text and also search them with findstr.exe. The Microsoft Windows 2000 Resource Kit's dumpel.exe utility converts event-log data into tab-delimited text that you can pipe into findstr.exe. For example, dumplog.bat, which Web Listing 4 shows, contains the commands to extract only the error and warning messages from the Application and System logs and only the audit failures from the Security log. The /R switch in the script indicates that the weird-looking search string is a regular expression. You can also use XP's built-in EventQuery.vbs to dump just the errors and warnings, or just the failure audits, as Web Listing 5 shows. Be aware that if you enable Group Policy debug logging (as I mentioned earlier), you might get a lot of error events from the Userenv source in the Application log, so you might want to turn debug logging off or at least filter out those entries. Also, remember to change your default Windows Script Host (WSH) from wscript.exe to cscript.exe when working extensively in command windows; to do so, type the command
cscript.exe //h:cscript
//nologo //s
Shai August 30, 2004 (Article Rating: