ACE Frameworks Streamline More Than Just Testing

Part two in a series on test environment management offers tips for developing your own test framework

Part two in a series on test environment management offers tips for developing your own test framework

(Note: This is the second part of a two-part series. Part one appeared in the May issue.)

In part one of this series ("A Framework for Test Environment Management") we defined the requirements and architecture for a flexible, platform-independent test framework used by the IBM* System i* Final System Test (FST) team. This agent control engine (ACE) framework provides a single interface for real-time control of test applications and display of system indicators across multiple test systems. In this article we'll describe the high-level design of the framework in sufficient detail for readers to easily develop similar frameworks.

To recap part one, the FST is an independent test group that conducts the final test phase in the IBM i5/OS* release process. Its mission is to test each new release of i5/OS in a customer-like environment before it's available externally. Testing simulates an enterprise environment with a network of systems, including CPU-intensive applications and interactive computing. The ACE test framework was developed to better manage FST's evolution to more complex, varied and demanding testing. ACE manages agents - which are test applications focused on one system area - within FST. However, to ACE, an agent is any application that can be externally controlled. This is one facet of ACE's generic design that could make it useful outside the test environment and extensible to other platforms.

This article provides an overview of the ACE user interface, describes the high-level design used for data collection and display of system indicators, and explains the design used for controlling agents and logging agent history.

User Interface

A well-designed UI must be intuitive, easy to use and able to provide all of the information a user may demand in a well-organized manner. Additionally, a UI should minimize the prerequisites and maintenance (e.g., installing fixes, etc.) required by the end user. To address these requirements, we chose to implement the ACE UI as a Java* 2 Platform, Enterprise Edition (J2EE) Web application. This had several benefits.

From an administrator's perspective, there are two key advantages. The ACE UI works on any platform running a J2EE-compliant Web application server. Thus, it runs on i5/OS, IBM AIX*, Linux* and others. Additionally, because the source code is written in Java, it doesn't need to be recompiled to run from one platform to another.

The J2EE decision also has some key advantages for ACE users. Most significantly, a Web browser is the only prerequisite to use the ACE UI. There's no client code to download and maintain. Since there's no client application consuming resources (e.g., memory, CPU, etc.), the UI footprint is small on a user's workstation.

Implementing the ACE UI as a Web application posed some challenges that wouldn't affect a typical client-server implementation. The biggest challenge is that a Web application is stateless. For example, a client request to a Web application may be the result of a user entering a URL into a browser, clicking a link or button in a Java Server Page or clicking the Back button. As a result, a Web application must protect itself by making no assumptions regarding the state of the client. To address this, the ACE UI uses request and session attributes to maintain users' states and process their requests accordingly. Another challenge is the limited functionality available in a Web UI when compared with that available in a typical Java client GUI. To address this, the ACE UI uses frames, style sheets and JavaScript to provide common Java GUI features (see Figure 1).

The UI has three primary objectives:

  • Provide access to system indicator data
  • Enable real-time control of test agentsDisplay an agent-history log

Matt Teigen is a staff software engineer on the IBM System i Software FST team in Rochester, Minn. He has 10 years of test experience, with expertise in Web applications and tools development

Roger Guderian is a staff software engineer in Rochester, Minn., and is a tester and testware developer for the System i Software FST Team. He has three years' experience in software testing and more than 15 years' experience in the system hardware-testing field.



2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


Going Mobile With DB2 Web Query

Directing i

How to enable IBM i for management by IBM Systems Director

Putting the "V" in Virtualization

IBM eServer line delivers on the promise of virtualization

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters