back

Tips for testing a Flash-based interface

by Kristopher Schultz

Many people assume that testing a Flash-based interface is simply a matter of applying the same techniques and success criteria they are accustomed to for HTML interfaces. This often results in an interface that works exactly as expected during testing but exhibits buggy behavior when accessed by real-world users.

This article presents four best practices you should follow when testing a Flash-based interface and describes the issues these best practices are designed to expose. If you follow these guidelines faithfully, you can ensure your Flash-based interfaces perform consistently and provide a better user experience for your visitors.

Best practice 1: Test over multiple connection speeds

This test exposes the following:

It is essential to test Flash interfaces over multiple connection speeds. Traditional HTML developers often dismiss this because testing HTML interfaces in this manner accomplishes only one purpose: confirming that download performance is acceptable for all users. With Flash, testing over various connection speeds reveals much more than just download performance problems.

If you test only from your local hard drive — or a web server on your local network — you are in danger of masking problems that might occur only under real-world connection conditions. When you test locally, things like server communication, image loading, and SWF streaming happen almost instantaneously. Under these conditions, it is easy to inadvertently write code that relies on this instant response time without realizing it.

For example, if you use the statement gotoAndPlay(20) on the first frame of your movie's timeline, it will likely work as expected when testing locally or even over broadband. However, if you test the same file over a modem connection, your movie will probably not behave correctly because the streaming nature of Flash content allows the code on the first frame to run before the later frames of your timeline have finished loading. An attempt to send the playhead to a frame that hasn't loaded will fail.

Accessing the Simulate Download feature screenshot

Figure 1: Accessing the Simulate Download feature

One way around this problem is to make frequent use of the built-in Simulate Download feature in Flash, which you can find in the View menu of the SWF window that appears after choosing Control > Test Movie (see Figure 1). Because the Simulate Download feature enables you to preview the performance of your movie over various connection speeds, you can often spot speed-related problems early.

However, the Simulate Download feature isn't perfect; you still need to test your movie over real connections of various speeds. The most important thing to remember is that bugs related to connection speed are far easier to address if you find them early. The mantra "Test early, test often" is particularly relevant for Flash.

Best practice 2: Test across browsers

This test exposes the following:

Just as cross-browser testing is essential with traditional HTML, it is also important for Flash content, but for different reasons. Cross-browser testing with HTML reveals page-display and client-side scripting problems. Because Flash Player handles both of these aspects for Flash-based interfaces, the browser has no influence over them.

The browser does, however, influence the way Flash content is embedded in the page. Different browsers require different HTML markup code in order to load and display Flash files. Additionally, the way Flash Player resolves relative URLs when attempting to load external assets like images and XML data — or when jumping to new web locations using getURL() — varies from browser to browser.

Testing across various browsers confirms that Flash content has been embedded properly on the page and that all URLs embedded in the Flash file are working consistently across all browsers. Of course, if your Flash interface communicates with the browser using JavaScript, cross-browser testing is also necessary to expose any differences between the way various browsers handle this form of communication.

Note: For tips on avoiding relative URL problems, see the Flash TechNote entitled Using relative URLs with the getURL action.

Best practice 3: Test across Flash Player versions

This test exposes the following:

Because Flash Player handles nearly all aspects of the display and functionality of a Flash-based interface, you will need to test your interface in various versions of Flash Player. It is usually adequate to test in just two versions: the version of the player that you've defined as your minimum required version and the version of the player that preceded the required version.

For example, if your interface requires Flash Player 6, then you should test in the earliest release of that version (Flash Player 6r21) and in any release of the previous version (Flash Player 5r30). If your interface requires a specific later release of a particular version — for example, Flash Player 6r65 — then you should still test in the versions mentioned previously as well as the required release.

In our example, this would mean testing in Flash Player versions 5r30, 6r21, and 6r65. By testing across Flash Player versions, you will be able to expose any publishing mistakes (such as publishing for Flash 7 when you meant to publish for Flash 6) as well as any problems with any Flash Player detection functionality you may be using.

Note: You can find an archive of old player versions in the Flash TechNote entitled Archived Macromedia Flash Players available for testing purposes.

Best practice 4: Test on weak machines

This test exposes the following:

Displaying traditional HTML pages takes very little computer power. As a result, web developers have rarely needed to consider how the power of the end user's computer influences the quality of the user's web experience. This is not the case with Flash content, which behaves much more like a CD-ROM or video game. The user's hardware — processor, RAM, and video card — impacts the experience significantly.

Much like CD-ROMs and video games, Flash-based interfaces should be designed with a specific minimum hardware requirement in mind. As you design and build your interface, repeatedly check the performance of your work on a machine that matches the minimum specification to ensure you are not overtaxing the hardware with your graphics, animation, or coding choices.

Note: For useful information on improving code and graphic performance, see the "Optimizing FLA Files for SWF Output" section of Jen deHaan's article Flash 8 Best Practices. For detailed instructions on how to use Flash 8 bitmap caching to improve performance, see Guy Watson's article, Using Bitmap Caching in Flash.

Where to go from here

By following these four important testing practices, you can ensure that the Flash-based interfaces you build for yourself or your clients provide the user experience you intended.

For more information about Flash Player, visit the Flash Player Developer Center and read up on the latest best practices, detection scripts, security tips, and more.


Sorry, this page is not available

This URL does not exist. Adobe checks periodically for any 404 errors but they do occur occasionally so we apologize for the inconvenience

このURLは存在しません。

Error returned: 404

You may wish to try one of the following links: