Understanding and Testing the Athena Customer Service System: Architecture, Behavior Trees, and Test Strategies

Author: Tian Xixi

Preface

This article uses the Zhaozhuan customer‑service Athena system as a case study, offering an external view of the whole system to help readers quickly grasp a business system and identify testing key points. Internally it aids understanding of Athena’s operation and R&D testing; externally it provokes thought on how to rapidly understand a business system and locate testing focus.

It is a practical piece; a follow‑up will discuss how to quickly understand various business systems and capture their essentials.

1. What does the system do? – What is Athena?

Athena enables users to interact with an IM (instant messaging) channel; the IM forwards data to Athena, which returns a reasonable response.

Athena generates a response by combining user behavior with business data, using configured information to produce a unique result.

Illustrative example

A user holding order A in state A' sends a text to the IM; Athena recognizes the text, consults its configuration, and either suggests an answer or routes the request to a human agent.

In reality the flow is more complex, e.g., user in state A' performs behavior B (send message or click a recommended question) repeatedly N times, after which the IM returns response C.

In summary, Athena resembles a behavior‑tree system.

When a user in state A initiates behavior A', the system yields result B; after receiving B, the user may trigger behavior B'', leading to result E. This overall view constitutes Athena.

From a testing perspective, if a product changes the description of result G, testers should construct a path A → A'' → C → C' → G to verify G meets expectations. Similarly, changes to result B affect multiple paths such as B → B' → D, B → B'' → E, and B → B''' → F.

Athena’s actual behavior tree is more intricate, resembling a directed graph because business descriptions can contain cycles (e.g., behavior H' returns the user to node C) or repeated actions (e.g., behavior I' repeated N times yields result J, otherwise the system keeps returning I).

2. What is Athena’s system architecture? How is it implemented?

User commands are sent to the IM; part of the request goes directly to Athena, while another part is first processed by an NLP module before reaching Athena. Athena computes the response using code logic and configuration, returns it to the IM, and finally to the user.

Athena is a long‑standing system; not all knowledge resides in configuration—some resides in code. Consequently, the behavior tree described in section 1 is only partially stored in a database, with the remainder embedded in code, making full reconstruction from the system alone impossible.

Therefore, a manual effort is required to map the behavior tree, and the product team should also preserve a complete representation to avoid knowledge loss during iteration.

3. Are there better architectural solutions?

An ideal architecture would separate the engine from configuration: treat the behavior tree as a graph‑modeling language (similar to a complex state machine) and store the tree as configuration, delegating execution to an engine.

For example, when the interface com.bj58.zhuanzhuan.***.***.getOrder() returns order.status = 3 and the user sends a message, Athena invokes com.bj58.zhuanzhuan.***.*** to produce a clear response. The simplest data structure could be: pre‑condition + user behavior + result handling (a concept inspired by state‑machine database design).

Advantages: the entire behavior tree can be restored from configuration, turning system development into configuration management; product changes to a node become traceable.

Disadvantages: higher integration leads to higher complexity; insufficient samples may cause design flaws. Not all scenarios (e.g., order processing) can be fully configuration‑driven without thorough research.

4. How should the system be tested?

The key quality metric is whether the IM receives the correct response. A correct response results from user behavior + code logic + configuration. When a product modifies a configuration or logic, locate the affected node in the behavior tree, trace all paths to that node (see section 2), and supplement with UI, interaction, and exception cases to ensure basic coverage.

5. Future improvements

Following the test‑case design method in section 4, a large number of upstream nodes can make test cases extremely complex, inflating authoring and execution costs.

Reduce authoring cost: if the behavior tree can be reconstructed or manually drawn and stored in Neo4j, Dijkstra’s single‑source shortest‑path algorithm can automatically generate test cases.

Reduce execution cost: automate test cases based on the behavior tree and perform gray‑scale online validation for experimental configurations.

Conclusion

When understanding a system, adopt a top‑down approach: first identify the system’s purpose and the problem it solves, then trace data sources, processing steps, and final outputs. Finally, map a concrete requirement onto this understanding to quickly engage with related system work.