James's profileJames McCaffreyBlogLists Tools Help

Blog


    April 24

    PowerShell Command Line Usage Quirks

    I am a very big fan of Windows PowerShell, Microsoft's new command shell and scripting language. I have found PowerShell useful in software testing and many other areas too. I am delivering a PowerShell talk and facilitating some hands-on PowerShell Lab sessions next week at the Microsoft Management Summit (see http://www.mms-2008.com/ ). MMS is Microsoft's premier IT event and it's very interesting. Anyway, as always, the hardest part about learning or teaching any new programming language or technology is getting over the initial hurdles and quirks. The screenshot below demonstrates some of the PowerShell command line usage quirks. I wrote a custom startup script so that each command would be numbered. My first command:
     
    PS(1) C:\> write-host -object "hi" -backgroundcolor "red"
    hi
     
    demonstrates a relatively verbose usage example. The write-host cmdlet can accept an -object parameter, which is what to print, and an optional -backgroundcolor parameter, which is, of course, the background color to use. My second command:
     
    PS(2) C:\> write-host "hi"
    hi
     
    shows that some (but not all) parameters can be passed by position and therefore the parameter name is optional, as in the case of the -object parameter. Optional parameters are general the first or second parameter(s) and are usually omitted simply to save typing. My third command:
     
    PS(3) C:\> write-host -obj "hi"
    hi
     
    shows that PowerShell is very intelligent about parsing your command line input, and can accept partial parameter nsames as long as the meaning is unambiguous. My fourth command:
     
    PS(4) C:\> write-host 'hi'
    hi
     
    illustrates that PowerShell strings can use either double-quotes or single-quotes. The difference (not illustrated in this example) is that strings inside single-quotes are literals; but certain characters inside double-quotes will be evaluated (such as `n for a newline). My fifth command is:
     
    PS(5) C:\> write-host hi
    hi
     
    and shows you that PowerShell will do its best to infer a type. Here PowerShell correctly believes that "hi" is intended to be a string. In general I prefer to be explicit about putting quotes on strings but that's just a matter of personal preference. My sixth command:
     
    PS(6) C:\> "hi"
    hi
     
    is quite strange and shows you that PowerShell really tries to infer what you mean. Here, the default behavior for a string is to display it. Quite unusual! My seventh command is:
     
    PS(7) C:\> hi
    The term 'hi' is not recognized as a cmdlet, function, operable program, or script file.
    At line:1 char:2
    + hi <<<<
     
    and shows that PowerShell can't read your mind. My next two commands are:
     
    PS(8) C:\> write-host "hi" -nonewline
    hiPS(9) C:\> write-host "bye" -fore "yellow"
    bye
     
    Some PowerrShell cmdlet parameters (in fact many) do not accept any values. These are called switch parameters in PowerShell terminology. Here I tell write-host to print "hi" but then do not print the default newline. My last command again illustrates that PowerShell only needs enough of a parameter name (-fore instead of the full -foregroundcolor) to unambiguously determine what to do.
    These few examples should help get you over the initial quirks of using PowerShell on the command line if you're new to PowerShell. Be sure to check out the MMS 2008 Web site. This year's event is sold out but keep an eye out for next year's event.
     
    PowerShellCommandLineQuirks
    April 18

    PowerShell and Software Testing

    Windows PowerShell is Microsoft's new command shell and scripting language. You can think of PowerShell as a replacement for the old cmd.exe shell and .bat files. I have found that PowerShell is extremely useful in a software testing environment. I will be presenting a PowerShell talk and three hands-on labs at the upcoming 2008 Microsoft Management Summit (https://www.mms-2008.com/public/home.aspx) from April 28 - May 2 in Las Vegas. I've spoken at MMS before and it is a huge and intersting conference and has all kinds of useful information related to Microsoft based IT topics. This year is already sold out but you mighgt want to consider attending next year. Anyway, here's a brief snippet from part of my PowerShell talk where I describe how PowerShell makes it much easier to inteact with WMI.
     
    Windows PowerShell provides you with a great interface to WMI functionality. WMI (Windows Management Instrumentation) is the Microsoft implementation of the CIM (Common Information Model) standard. IT administrators can use WMI to retrieve and manipulate a wide range of information about the hardware and software resources on a computer network. Working with WMI using Windows PowerShell is generally quite a bit easier than using than older scripting technologies. In this Lab Exercise you will learn how to access and control Windows services using the get-wmiobject cmdlet. The screenshot below illustrates the key ideas in this exercise.
     
    1. Enter the commands:
     
    (default directory)> set-location \
    PS C:\> get-wmiobject -list | more
     
    The key to working with WMI in Windows PowerShell is the get-wmiobject cmdlet. If you supply a -list switch, the get-wmiobject cmdlet will list all the WMI classes available to you -- typically over 1,000 of them. Many Windows-related WMI class names begin with "Win32_" so if you pipe the output of "get-wmiobject -list" to "select-string Win32_" you can view just those classes. Notice that in this special case, you pipe to the select-string cmdlet rather than the more usual select-object cmdlet.
     
    2. Enter the commands:
     
    PS C:\> $s = get-wmiobject -class win32_service
    PS C:\> $s.count
     
    The WMI class which is most often used to control Windows services is the Win32_Service class. The command above fetches information about all the services on your host machine and stores them into a collection named $s. As a general rule of thumb, when you issue a command using the get-wmiobject cmdlet, you will get either a single object (for example, with the Win32_SystemTimeZone class), or a collection of objects (as with the Win32_Service class). You can use the Count property to determine how many objects you have. Note that Windows PowerShell has a built-in get-service cmdlet you can use to control services on a host machine. However, the get-wmiobject cmdlet can access remote machines as well as local machines. For example, the command "get-wmiobject -class win32_service -computername Hercules" will fetch information about all services running on a machine named Hercules.
     
    3. Enter the commands:
     
    PS C:\> $a = get-wmiobject -class win32_service -filter "name='alerter'"
    PS C:\> $a
     
    In most situations you want to get a reference to one particular WMI object -- in this case we want a reference to the Alerter service. The command above shows a Windows PowerShell idiom to do this. The -filter switch parameter of the get-wmiobject cmdlet can select just a particular object from a WMI class with multiple objects.
    (etc.) PowerShellAndWMI
    April 13

    Risk Analysis in Software Testing

    At the upcoming Better Software Conference & Expo (http://www.sqe.com/BetterSoftwareConf/) I will be delivering a 4-hour tutorial titled "Quantitative Techniques in Software Management". One of the topics in the tutorial shows attendees exactly how to perform risk analysis. One of the most important activities in software testing is Risk Management. Risk Management has three phases: Risk Identification, Risk Analysis, and Risk Control. Risk Identification is where you list things that can go wrong with your software testing effort. Risk Analysis is where you determine how likely each risk is, estimate the impact of each risk, and compute a priority for each risk. Risk Control is where you plan what to do for each risk. Here's a simplified example from the tutorial. Suppose you identify three risks: Risk A, Risk B, Risk C. You decide to categorize risk likelihood on a three-point scale (low, medium, high). You decide to categorize risk impact on a two-point scale (low, high). Suppose you determine that Risk A has high likelihood but low impact. Risk B has low likelihood but high impact. Risk C has medium likelihood and high impact. What are the normalized priorities for each risk? Using Rank Sum Weights, Risk A has normalized priority = 0.5000 * 0.3333 = 0.1667. Risk B has priority 0.1667 * 0.6667 = 0.1111. Risk C has priority 0.3333 * 0.6667 = 0.2222. Therefore Risk C has the highest priority, followed by Risk A, then Risk B. The Better Software Conference & Expo runs from June 9 - 12, 2008, in Las Vegas. There are many excellent speakers and topics this year; check it out.
    April 04

    The Triangular Distribution in Software Testing

    A very simple and useful quantitative technique in software testing is using the Triangular Distribution for estimation in situations with very limited data (as few as two data points). Here's an example from a half-day tutorial "Quantitative Techniques for Software Management" I am presenting at the Better Software Conference and Expo (http://www.sqe.com/bettersoftwareconf/) from June 9-12, 2008 in Las Vegas, Nevada.
    Suppose you are managing an internal software project and it is ready to ship. You wish to estimate how many undiscovered bugs your system will ship with. Your system has 100 main modules. You thoroughly examine just 4 of the modules (because the process is very time-consuming and costly) and discover one module has 6 bugs, two modules have 18 bugs, and one module has 24 bugs.
     
    a.  Use the Triangular distribution to determine a point estimate of the number of bugs your system will ship with.
     
    a = smallest value = 6
    b = largest value = 24
    c = most common value = 18
    mean = (a+b+c)/3 = 48/3 = 16.0 bugs

    b.  Compute the Triangular variance and recast your point estimate to a 70% confidence interval (z = 1.04) estimate.
     
    variance = (a2 + b2 + c2 - ab - ac - bc) / 18
             = (36 + 576 + 324 - 144 - 108 - 432) / 18
             = 14
    std dev = sqrt of variance = 3.7 bugs
     
    Therefore, we estimate that the system will ship with 16.0 plus or minus 3.9 bugs. The Better Software Conference has a lot of interesting talks and tutorials related to software project management. Check it out at http://www.sqe.com/bettersoftwareconf/.