If you follow my blog you know that I use Parasoft SOAtest for Web Service testing. If you don’t…well now you know. The new 5.0 version of SOAtest has been released and it has a pretty large set of new features and improvements.
Parasoft SOAtest 5.0 features the following key new capabilities:
Testing through multiple layers of complex applications: Instantly translate a functional scenario from a test suite into a language that the developers understand: JUnit.
Policy Management: Provides SOA architects the ability to create and manage policies that are enforced during design and development.
Performance QoS (Quality of Service): Defines and enforces QoS metrics that are important for setting and measuring SLAs (Service Level Agreements) during development and QA.
Enhanced Server Emulation: Enhanced intelligence of server stubs allows you to more accurately emulate application behavior.
Other Miscellaneous features
Get the entire list of new features and their details here.
Personally, I’m looking forward to working with the GUI overhaul. There are so many things going on in SOAtest and the GUI can be a real pain to work with. Painful outside of the typical Java GUI pains such as lack of keyboard shortcuts and lack of right click context menuing! I won’t go there though.
A new version of SWEA has been released that supports Ajax. Alex has kept me up to date on his developing and testing progress with this new feature and I can tell you that he has put a lot of time and hard work to get this feature out the door. As Alex said to me on several occassions “their are many ways to do Ajax, supporting them all is a lot of work”. Webius is really dedicated to making automation and screen scraping easy for you and the new Ajax feature only adds to the long list of things the software is capable of.
Download the latest version of SWExplorerAutomation (SWEA) here.
Well I’m still testing InstallShield installers today and thought I’d add another interesting and cryptic issue to the blog that I saw when an uninstaller removes performance counters (or fails to for that matter). The error described below is not InstallShield’s fault, but instead corruption in the Performance Counter Registry that is encountered during an uninstall. However, since it occurs on uninstall it will certainly bubble up in you related installer logs. As I posted last night, the best way to troubleshoot InstallShield errors is to search the Internet; so I hope this post can help someone out. Below is the complete description and fix that worked for me and a few others: Error Event Uninstall of application
Error Message 1. InstallError.Log details: Error in Installer: System.ComponentModel.Win32Exception: The configuration registry key is invalid
at System.Diagnostics.PerformanceCounterLib.RegisterFiles(String machineName, String arg0, Boolean unregister) at System.Diagnostics.PerformanceCounterLib.UnregisterCategory(String machineName, String categoryName) at System.Diagnostics.PerformanceCounterCategory.DeleteCategory(String categoryName, String machineName) at System.Diagnostics.PerformanceCounterCategory.Delete(String categoryName) at Service.ConfigureService.RemovePerformanceCounters()
2. Event Viewer item 1 detail: Unloading the performance counter strings for service appnamehere (app name here) failed. The Error code is the first DWORD in Data section.
Event Viewer item 2 detail: The performance strings in the Performance registry value is corrupted when process Performance extension counter provider. BaseIndex valuefrom Performance registry is the first DWORD in Data section, LastCountervalue is the second DWORD in Data section, and LastHelp value is thethird DWORD in Data section.
I spend a large part of my time testing InstallShield installers and I kid you not, I’d rather eat worms. Breakfast, lunch, and dinner. ..Midnight snack too. Worm smoothies, worms on toast, worms as a mixer with gin, Worm Cordon Bleu. For a week.
The complexity is mind boggling, confusing and frustrating. InstallShield is not easy for the developer or the test engineer. The development application is very error prone.
Recently we were perplexed with an InstallShield fatal error that failed to log anything to the InstallShield log file. Perusing the Web for related information to the error number we were getting (which sadly is the best way to troubleshoot InstallShield issues) I found that Windows has an installer logging service built in. When I enabled this service, I was able to get more detail of what was going on down in the guts of the underlying msi.
Partly for your knowledge and partly for mine (because I’ll forget how at some point), I’m going to document how to enable the Window’s Installer Logging Service here:
Open/run regedit and navigate to the following path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Add the following string value to the Installer directory: Logging
Add the following data/value to the Logging string value: voicewarmup
The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter’s actual function is as follows for MSI version 1.1: v – Verbose output o – Out-of-disk-space messages i – Status messages c – Initial UI parameters e – All error messages w – Non-fatal warnings a – Start up of actions r – Action-specific records m – Out-of-memory or fatal exit information u – User requests p – Terminal properties + – Append to existing file ! – Flush each line to the log
Your completed registry entry will look like this:
Once the registry change is made your new installer logging will show up in your Temp directory (temp is defined by the temp system variable). The log in the directory will have a name that starts with the letters MSI and will be followed a random number.
Today the Portland area was blessed with a fairly decent coating of snow and under that a thin base of ice. With all things coated in white, clean and pretty looking, a defect loomed…
This morning I braved the weather and set out to the streets armed with a 2007 Ford Fusion (front wheel drive with traction control), ice and snow driving skills (which a large amount of Portland motorists don’t have), and defensive driving skills taken to the next level (from riding a street motorcycle).
Danger after danger I went around, turned around from & back-tracked, and chuckled at due to the foolishness. My snow-driven cheery mood could not be swayed by danger and foolishness! Two blocks from work I pulled up to the last light that I would encounter on my harrowing journey. With the destination in sight, my mind was at ease and I patiently waited for that green go light. and waited. and waited. AND WAITED.
About 2 minutes into it the lady in the turn lane next to me had enough and started to renegotiate her car’s position trying to trip the traffic light’s magnetic induction loop inside the road. Watching her, I started to second guess my position since everything was buried in snow. Looked good to me, it all lined up in my mind. Even if we didn’t trip the magnetic induction loop, the signal would default to a standard set amount of time per light/direction right? Right!? Wrong. We were screwed. No green for us. Denied by ODOT. Denied by a defect. I can’t believe this is the case everywhere, but it sure was at this stoplight.
Three minutes later I looked both ways and went for it. Unscathed I am. Don’t try this at home.
Rumor has it that the 2008 Ford F150 to be released in August is going to get 60 Miles Per Gallon using their Hydraulic Hybrid technology.
A while back the wife and I decided that our next vehicle purchase was going to be an F150 SuperCab. We need a truck bed for hauling things around and we also need the optional 6 seats. Add 60 MPG to that and I’m sold. 60 MPG in a truck ? Crazy! I hope it’s true. We’ll see come August.
Rob over at Cockeyed.com has shown us how incredibly insecure it is to rip up those credit card offers you get in the mail. Rob took an application he received in the mail, ripped it up, taped it back together, filled it out using a different address (his father’s), using his cell phone as a phone number, and submitted it. A few weeks later his Dad received the credit card.
Is that messed up or what? I can just picture some underpaid worker at Chase opening the envelope and entering the data into the system without giving one rip why the app was torn up and re-taped. Sad, oh so sad. Learn a lesson from this folks!
Just in case you don’t get it:
If you rip up your credit card offers and throw them away (or even worse, don’t rip them up at all), a thief can fish them out of the garbage, tape it back together, fill it out with his/her address and phone number and receive that card at his/her address, and then go shopping.
My advice: SHRED ALL CREDIT APPLICATIONS YOU RECEIVE IN THE MAIL