| Profilo di JamesJames McCaffreyBlogElenchi |  Strumenti  Guida |
|
31 marzo ULSTA Web App UI Test Automation with PowerShellI like Windows PowerShell a lot. PowerShell is Microsoft's new command shell and scripting language which you can think of as a replacement for the old cmd.exe shell and .bat files. I've discovered that PowerShell has essentially created an entirely new type of software test automation category that I call ULSTA (for Ultra Lightweight Software Test Automation). For example, suppose you have a Web aplication. Manual testing is slow, error-prone, inefficient, and just plain boring. But writing UI test automation for Web applications can be very, very difficult. However, I've done some experiments which have shown me that it is possible to write a tiny library of Web app UI cmdlets (basic PowerShell functions) which in turn allow you to write quick and easy UI Web application test automation. See the image below. I plan to write up the technique and publish it soon -- perhaps in MSDN Magazine but I already have probably too many PowerShell-related test automation articles in the MSDN Magazine publication queue, or maybe TechNet Magazine, but more likely a non-Microsoft magazine such as the .NET Developer's Journal. 24 marzo Ultra Lightweight HTTP Request-Response Testing with PowerShellI've been deep-diving into the concept of using Windows PowerShell for ultra lightweight software test automation (ULSTA). PowerShell is Microsoft's new command shell and scripting language, and is available as a free, standalone install from http://www.microsoft.com/powershell. The most basic form of Web testing is HTTP request-response testing; you write a harness which programmatically sends an HTTP request to your Web application, the Web server constructs and ends back an HTTP response, which you then examine for an expected result of some sort. It turns out that PowerShell works very well for this testing task. I've written up the details for an MSDN Magazine article which may be published later this year. Ultra lightweight software test automation ULSTA is characterized by being quick to create (under two hours), script-based, short (under two pages), and disposable by design (roughly a two week lifespan). PowerShell and ULSTA work very well together. 18 marzo Ultra Lightweight UI Testing with Windows PowerShellOne of my main areas of interest is practical software test automation. Much test automation is impractical in the sense that the automation requires too much time and effort to create relative to the automation's value in helping to produce a better software system. I've been looking at Windows PowerShell (Microsoft's new command shell and scripting language) a lot lately and have found that PowerShell is very well suited to what I call ultra lightweight software test automation (ULSTA). ULSTA is characterized by being quick to create (under two hours), script-based (PowerShell), short (under two pages), and disposable by design (roughly a two to four week lifespan). One interesting ULSTA with PowerShell use is UI automation for .NET based form applications. See the screenshot image below. I've tackled the problem ultra lightweight UI testing with Windows PowerShell and have written up the details for an MSDN Magazine article which will be published later this year. Windows PowerShell ships with approximately 130 useful meta functions called cmdlets. The heart of my technique involves writing a tiny library of custom PowerShell cmdlets and then using that library to write very easy UI automation. 11 marzo Managing Exchange Server 2007, Part IIIn my last blog entry I described some of my initial impressions of Exchange Server 2007, in particular the impact of the 64-bit machine requirement. Now let me share a couple of thoughts about managing Exchange Server 2007 using Windows PowerShell. PowerShell is Microsoft's new command shell and scripting language -- essentially a major upgrade to the old cmd.exe shell and .bat file scripts. Exchange Server management is based on PowerShell. By that I mean you can perform all kinds of Exchange tasks from the command line. In fact there some Exchange 2007 tasks which must be done using command-line statements in Windows PowerShell. Although Exchange Server 2007 still has a GUI-based Exchange Management Console (EMC) for quick and easy tasks, you will spend a lot of time in the Exchange Management Shell (EMS) which is basically a customized PowerShell. For example, suppose you want to create a new network user with an e-mail account. With old versions of Exchange, you would create a user in Active Directory Users and Computers (ADUC) which would automatically invoke a GUI tool to create a mailbox for the user, and then if you wanted to configure Outlook Web Access you'd go to IIS. With Exchange Server 2007, to create a new network user with a mailbox you either a.) first create a new user with ADUC and then create the mailbox for the user with GUI-based EMC, or b.) create the user and mailbox simultaneously using the command-line based Exchange Management Shell. Here's an example of using the PowerShell-based EMS:
C:\> new-mailbox -userPrincipalName user002@TEST.local
-name user002 -database "First Storage Group\Mailbox Database" -organizationalUnit Users -resetPasswordOnNextLogon $true The shell will prompt you for an initial password and then create the user and mailbox which you can verify by using the GUI-based EMC or by entering the command "get-user". The EMS is Windows PowerShell, which includes 129 basic cmdlets (such as "set-location") plus an additional 381 cmdlets for Exchange (such as "new-mailbox"). Luckily, you only need to know how to use a handful of all these cmdlets. You can get a list of all 510 cmdlets by entering the command:
C:\> get-command | more
Or you can filter along the lines of:
C:\> get-command new-* | more
Once you zero-in on the cmdlet you want to use (for example, the new-mailbox cmdlet), you can get help like this:
C:\> get-help new-mailbox -detailed | more
So what's the bottom line if you are currently an Exchange administrator, or recruit or hire Exchange administrators? Managing Exchange Server 2007 is quite a bit different from managing previous versions of Exchange and will require quite a bit of new command-line and scripting skills on your part, as well as a significant mind-set change. 04 marzo Managing Exchange Server 2007, Part IHere are some of my initial impressions about the brand new Exchange Server 2007. Context: I manage several small but very sophisticated Windows-based networks. These networks are used for training classes for software engineers working at Microsoft's Redmond, WA campus (see http://www.vteOnline.com for example). The networks are also used to evaluate beta versions of Microsoft software and to create white papers and articles for Microsoft (see http://msdn.microsoft.com/msdnmag/issues/07/03/TestRun/ for example). My networks are all currently running Exchange Server 2003 so I wanted to explore the upgrade path to Exchange Server 2007. The two most significant facts I've discovered are: 1.) Exchange Server 2007 requires a 64-bit machine, and 2.) managing Exchange Server 2007 requires using Windows PowerShell. Let me briefly talk about these two issues and their potential impact on you. First, Exchange Server 2007 requires a 64-bit machine. This fact has been well-publicized by Microsoft but still comes as a bit of a shock. If you are running a small network like I am, you are probably using non-leading edge hardware. In my case I have lots of old (circa 2002) Dell desktops which are working just fine as domain controllers, SharePoint servers, SQL servers and so on, including Exchange (2003) servers. So to upgrade to Exchange Server 2007 I am immediately faced with trying to find new hardware -- and this means buying outright instead of piecing together a server from old client machines. I suspect that the 64-bit machine requirement will tend to slow the adoption of Exchange Server 2007 among small and mid-sized companies. This in turn will slow the demand for Exchange Server 2007 skills. This isn't to say that there won't be demand, but rather the demand for Exchange Server 2007 may not explode like it did for Exchange 2003, Exchange 2000, and Exchange 5.5 (1997-98). The story will possibly be quite different for large companies where the 64-bit machine requirement will not have as much impact. For example, as I write this blog, Volt is delivering a class on Exchange Server 2007 to a full house with a long class wait list -- Microsoft already has a steady demand for engineers with Exchange Server 2007 knowledge. I'll discuss the PowerShell requirement in my next blog. |
|
|
