测试工序：让架构设计真正落地的关键机制

测试工序：让架构设计真正落地的关键机制

一、什么是测试工序

工序是完成特定任务所需的一系列步骤或程序。在软件开发中，工序由测试策略定义——测试策略制定了我们在完成架构中不同组件的开发与集成过程中，测试所需完成的任务。因此，软件开发中的工序也叫测试工序。

以三层架构（HTTP Interface / Application Logic / Persistent）为例，一套典型的测试工序包含四个步骤：使用 Fake 数据库测试 Persistent 层组件；通过 Stub Persistent 层组件测试 Application Logic 层；通过 Stub Application Logic 层组件测试 HTTP Interface 层；最后使用独立测试数据库进行功能测试。

这套工序对任何需求都适用。以"按 SKU 查询商品"为例，针对"商品存在时返回商品"和"商品不存在时返回 404"两个场景，每个场景都按照上述四个工序逐步分解：先测 DAO（工序 1），再测 Service（工序 2），再测 API（工序 3），最后功能测试（工序 4）。

关键点在于：工序不是由架构直接决定的，而是由测试策略决定的。同样的三层架构，如果因为测试成本或框架限制改变了测试策略（比如将 HTTP Interface 层和 Application Logic 层合并测试），工序就会随之改变，从四个工序变为三个工序。架构组件没变，但工序变了。

二、可测试性是进程内架构最重要的属性

为什么工序要依赖测试策略而不是直接依赖架构？因为可测试性是进程内架构最重要的属性，大部分进程内架构模式的引入，本质上都是对可测试性的改进。

以前端开发为例，MVC 架构下，Controller 是挂在 HTML DOM 上的事件处理逻辑，DOM 和事件都难以测试。实际情况是很多团队选择不测试 View 和 Controller，Q1 测试只覆盖 Model，而 Q2 的功能测试成本高（运行慢、不稳定），整体测试投资回报率很低。

引入 MVP 架构后，Controller 被替换为 Presenter，Presenter 封装了交互逻辑，可以通过 Stub 或 Fake Model 独立测试。这样 Q1 测试从只覆盖 Model 扩展到覆盖 Presenter，缩小了没有 Q1 测试覆盖的组件范围（从 View+Controller 缩小到只剩 View），测试投资回报率显著提升。

进一步，当引入 React Testing Library、Storybook Component Test 等工具后，View 也可以被测试，Q1 测试可以覆盖 View 和 Presenter，甚至可以替代部分功能测试，投资回报率进一步提高。

这个演进过程说明：单从可测试性角度，就能判断哪种架构模式更优，不需要考虑那些虚妄的可扩展性等属性。架构选型的一个重要依据，就是它能支撑什么样的测试策略，进而产生什么样的测试工序。

三、测试工序是架构落地的重要手段

架构设计在高层次上定义了系统结构和组件关系，但要使架构真正生效，需要通过具体步骤将其落地到开发过程中。测试工序正是实现这一目标的关键手段。

工序将抽象的架构设计转化为具体的开发任务和工作流程：每个工序对应一类组件的测试方式，每个需求按照工序分解为有序的任务列表，开发团队按照任务列表逐步完成代码，每一步都有测试验证。这个过程保证了架构设计的理念和原则得以贯彻执行。

没有工序，架构就只是一张图纸。开发人员可能写出功能正确但不符合架构要求的代码——比如跳过某一层直接调用、在错误的层引入业务逻辑、测试替身使用不当导致测试无法独立运行。这些问题早晚会导致返工。

四、测试工序与 LLM 辅助开发的结合

测试工序为 LLM 辅助开发提供了精确的约束框架。当我们向 LLM 提出代码生成请求时，如果只给出功能需求，LLM 会生成功能正确但架构随意的代码。而当我们将测试工序编码到提示词中，LLM 就能按照工序要求，生成符合架构约束的测试代码和实现代码。

具体做法是：将测试工序转化为 CoT（Chain of Thought）提示词模板，在模板中明确每一层的测试替身策略和技术要求，然后针对每个需求让 LLM 先生成任务列表，再按任务列表逐步生成代码。这样，LLM 生成的代码天然符合测试工序的要求，也就符合了架构的要求。

测试工序是连接架构设计与 LLM 代码生成的桥梁：架构师定义工序，工序编码为提示词模板，开发人员（或 LLM）按模板执行。这使得架构知识从少数人的不可言说知识，变成了可以被团队复用的显式流程。