The concept of structural testing is used in two main contexts. Although different in nature, the root concept or idea behind structure testing is arguably the same in both cases.

Structure Testing of Code Internals

The older reference and perhaps more established use of the term "structure testing" relates to testing the internal structure of the software source code. Most often, this form of structure testing is performed as a "static" as opposed to a "dynamic" test, in that the software itself is not executed to perform the test. Diagnostic tools parse the source code, looking for structural errors and weaknesses, typically providing a list to enable subsequent corrective action to be taken. This type of test and evaluation is conducted by developers, rather than system testers.

Structure Testing of Web Sites

Web-based applications-those employing Internet application technology-are increasingly more prevalent. This movement has been encouraged by the fact that this software development and deployment method offers organizations the ability to take advantage of several technology-enabled business benefits, such as:

• Developed audience of customers, prospects, and business partners without sending out a single piece of software or paper. Anyone with a browser and access to the "net" (Internet or Intranet) can simply point their browser to the published URL and immediately run the application.
• Centralized control and maintenance. The "thin-client/fat-server" model of Web-based applications places the application components and logic on the Web server, which centralizes and simplifies control and maintenance. This also enables developers to distribute the software automatically. Once the application is on the server, it is immediately available for all users.

Although this offers advantages to those who employ this technology, Web-based applications increase the demands of testing. Testing these Web-based applications, like their non-Web counterparts (client/server, legacy, and so forth), requires testing to address the function and performance characteristics of the applications. In addition, Web-based applications have the added need for tests that focus on the structure of the application, ensuring it's well-formed and that all links are valid.

Typically Web-based applications are constructed using a series of documents (both HTML text documents and GIF/JPEG graphics) connected by many static links and a few active, or program-controlled, links. These applications may also include "active content", such as forms, Java scripts, plug-in-rendered content, or Java applications. Frequently this active content is used for output only, such as for audio or video presentation. However, it may also be used as a navigation aid, to help the user navigate the application (Web site). The freeform nature of the Web-based applications (through its links) is a great strength, but it's also a tremendous weakness because structural integrity can be easily damaged.

Structure testing is implemented and executed to verify that all links (static or active) are properly connected. These tests include:

• Verifying that the proper content (text, graphics, and so on) for each link is displayed. Different types of links are used to reference target-content in Web-based applications, such as bookmarks, hyperlinks to other target content (in the same or different Web site), or hot spots. Each link needs to be verified to ensure that the correct target-content is presented to the user.
• Ensuring there are no broken links. Broken links are those links for which the target content cannot be found. Links may be broken for many reasons, including moving, removing, or renaming the target-content files. Links may also be broken because of improper syntax use, including missing slashes, colons, or letters.
• Verifying there is no orphaned content. Orphaned content are those files for which there is no "inbound" link in the current Web site; that is, there is no way to access or present the content. Care must be taken to investigate orphaned content to determine the cause:
  • Is it orphaned because it is truly no longer needed?
  • Is it orphaned due to a broken link?
  • Or is it accessed by a link external to the current Web site?

Once determined, the appropriate action should be taken, such as remove the content file, repair the broken link, or ignore the orphan, respectively.