Automating Screen Captures
When I first started at Microsoft I worked on the Windows 95 international test team. Not only did we focus on globalization testing, but we also did a lot of the localization testing for the East Asian language versions (Japanese, Korean, Simplified Chinese, and Traditional Chinese). Localization is the adaptation of software to a particular target market. Translation of resource strings is one of the most visible parts of the localization process, and in those days part of our testing effort was spent on translation validation (e.g. checking the strings for appropriate translation). (In retrospect, I now think it is a huge waste of time and resources to use professional testers to validate the translation “quality.”) During our localization testing cycles it was common practice to take screen shots of issues we found during localization testing. These screen shots often help put things in context for the localization engineers, and helped them troubleshoot the issue. Of course, there were other times when we took screen shots to put other anomalies in context.
I am generally not a big fan of just attaching screen images to bug reports carte blanche. Joe Strazzere has an excellent post describing why a screen shot doesn’t always add value in bug reports. But, I also know that there are times when screen shots of the desktop can be of value. When we are testing using pre-defined tests or exploratory approaches we are physically there to see anomalies as they occur. But, (hopefully) nobody is babysitting the machines our automated GUI test scripts are running on. So, when an unexpected anomaly occurs with automated GUI test scripts is might sometimes be beneficial to capture the desktop state as an image. This screen capture might provide some clues as to the state of the desktop at the time of unexpected automated test case failures resulting in an indeterminate automated test script result.
There are several 3rd party tools that some testers use to capture the desktop image and save it to a file. Automated test frameworks should also have methods that test developers can call to capture screen shots at important points during the execution of an automated test script, or when an anomaly occurs. But, if not, here is a simply method that will take a snapshot of the desktop and save a jpeg file of the desktop state.
1: using System.Drawing;
2: using System.Drawing.Imaging;
3: using System.Windows.Forms;
4:
5: ...
6:
7: public static void GetDesktopImage(string imageFilePath)
8: {
9: // Declare a structure for the width and height of the desktop
10: Rectangle rect = Screen.GetBounds(Point.Empty);
11:
12: // Declare a new instance of the bitmap class
13: Bitmap image = new Bitmap(rect.Width, rect.Height);
14:
15: // Capture the desktop
16: using (Graphics desktopImage = Graphics.FromImage(image))
17: {
18: desktopImage.CopyFromScreen(Point.Empty, Point.Empty, rect.Size);
19: }
20:
21: // Save the image to the specified path & filename
22: image.Save(imageFilePath, ImageFormat.Jpeg);
23: }
I would not capture tons of images during a test run; they just aren’t that valuable. And, I do not advocate capturing images to use as oracles…they are just too unreliable in my opinion. But, there are times when a screen capture of the desktop might add value and provide some context for the tester or the developer in troubleshooting issues.
Nice post!
I completely agree with you that, particularly in the context you have presented (automated, unattended tests that generate an unexpected condition) an image capture can often make diagnosis and debugging far easier. I use a test framework that does exactly that. too.
The captured image, along with well-chosen words can often make for a very effective bug report.
Joe Strazzere
4 Sep 10 at 8:40 AM
[...] рассказывает о снятии снимков экрана с помощью кода на [...]
OpenQuality.ru | Качество программного обеспечения
21 Feb 11 at 8:53 AM