ACE Frameworks Streamline More Than Just Testing
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.
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.
The UI has three primary objectives:
- Provide access to system indicator data
- Enable real-time control of test agentsDisplay an agent-history log