1. 引言

半导体 FT 测试(Final Test，也称为 FT)是对已制作完成的半导体元件施行结构及电内功能明确承认，以保障半导体元件合乎系统的需要[1]。半导体行业是典型的技术密布型科学技术制作行业，与信息化的公司级

应用软件相接合对增长出产速率至关关紧，而其复杂多变的测试流程则对应用软件的预设提出了更高的要求。

制作执行系统 MES (Manufacture Execution System)是一种以优化整个儿出产过程为目的，实时使聚在一起和处置出产过程中的数值，同时与规划层和扼制层维持双向通信并从上、下两层收缴相应数值、反馈处置

最后结果和出产指令的公司级应用软件[2]。MES 是半导体测实行试试业常见的应用软件，自上百年八十时代初在 美国公司界兴起后已经变成制作业信息化中成熟的系统。MES 为扼制涵盖物料、设施、担任职务的人、流程指令和设备在内的全部工厂资源，供给了一个一统的平台，对提居高不下业出产速率、增长产质量量、减低耗费方遮挡面部的东西有关紧的效用[3]。依据客户的需要制定灵活可变的测试流程是半导体测试 MES 的中心功能之一，一点 MES 预设者将其称之为 PRP (Process Planning)板块[1]。

不一样的芯片出产者对芯片的测试流程及测试步骤有不一样的要求，因为这个测试厂商的 MES 应该能够依据芯片出产者的要求在软件系统中树立组装出一条完整的测试流程。在这条测试流程中应该里面含有客户要求

的各个测试步骤及顺着次序，而各个测试步骤中则应该里面含有本测试步骤的测试最后结果以及特别指定的业务思维规律。如何施行类预设满意上面所说的需要并在不可缺少时能够迅速研发扩展现新门类的测试步骤变成 MES 软件的预设中需求重点解决的问题。

2. 功能需求

2.1. 行业术语定义

为描述方便，特对行业术语解释如下：

 来料：指从客户处得到的、未经过测试的封装后芯片；

 产品：指经过测试、可以发货返还给客户的芯片；

 生产：指质量检测过程，使得来料转变为产品。

 PE：Process Engineer。流程工程师，负责在系统中为产品制定对应的测试流程。

 OP：Operator。操作员，负责在测试生产线上工作，并同步在 MES 中维护相应信息，如保存测试数据、继续下一步测试等。

2.2. 测试流程及测试步骤

一条完整的 FT 测试流程由许多个测试步骤组成，每个测试步骤应当记录其自身的测试结果数据并具有特定的业务逻辑(如在何种情况下需要继续、暂停测试等等)。有一类特殊的测试步骤称为测试制程，一个测试制程可以包括一个或多个子步骤，是 FT 测试的核心步骤。

FT 测试的测试步骤有如下 9 类：

 IQC (Incoming Quality Control)：来料质量控制，意为对刚刚进入生产线的来料进行质量检测，一般为整个流程的第一个步骤。

 Baking：烘烤，意为对来料进行烘烤处理，为接下来的测试步骤做准备。

 GuTest：机台测试，令机台对标准件进行检测，从而校准机台设置。

 Test：测试制程，使用测试机台对来料进行检测，是 FT 测试的核心步骤，可包括多个子测试步骤，子测试步骤统称为 FT。测试制程执行后来料转变为未包装的产品。

 Finish：测试完成站，一般在该步骤对测试后的产品进行装盘。

 FVI (Final Visual Inspection)：最终光检，对产品进行可视化检查。

 FQC (Final Quality Control)：最终质量控制，在装箱前进行最后检查。

 Packing：装箱，对装盘完成的产品进行装箱。

 OQC (Output Quality Control)：出货品质控制，对装箱后产品进行出货前的检查。

以上 9 类测试步骤是目前业内较为通用的测试步骤，大多数客户对测试流程的要求可通过对以上各类测试步骤进行重复、排列、组合而建立起来。值得说明的是，半导体行业还处于高速发展阶段，以上提到的 9 类测试步骤必然无法长期满足日益增长的客户需求，因此能够允许开发人员快速扩展出新的测试步骤类也是重要需求之一。

2.3. 流程定制功能

对于每一批来料，首先由 PE 针对客户的要求进行流程定制，再由生产线上的 OP 根据已制定的测试流程依次执行测试步骤对来料进行测试，如图 1 所示。

例如，某客户向 FT 测试厂商寄送出一批来料，并要求对该批来料依次进行如下步骤的测试：IQC- > Baking- > Test(FT1- > FT2)- > Finish- > OQC。其中，Test 为测试制程，包含两个子测试步骤：FT1、FT2。 当测试厂商收到客户的要求后，PE 就会根据客户的要求在 MES 中建立一套包含以上所有测试步骤的测试流程记录表，生产线上的 OP 就会根据此表依次执行各个步骤，并将测试结果记录在表中，示意图如图 2 所示。当有另外一个客户向测试厂商提出不同的测试流程要求时，PE 会根据客户要求在 MES 中建立不同的流程步骤与流程记录表，因此 OP 也会执行不同的操作步骤，得出不同的测试结果数据。多样化的客户需求要求 MES 必须具有灵活定制测试流程的功能，以及快速开发扩展的能力。

Figure 1. Flowchart: process planning

图 1. 流程定制业务流程图

Figure 2. An example of process planning business

图 2. 流程定制业务举例示意图

对于 PE，MES 流程定制功能应满足以下需求：

1. 可选择一个或多个测试步骤加入到测试流程中；

2. 同一类测试步骤可重复添加；

3. 可利用子测试步骤组装出新的测试制程，并可选的加入至测试流程；

4. 可记录流程中的测试步骤顺序，对顺序敏感；

对于 OP，应满足以下需求：

1. 可在测试过程中对每个步骤的测试结果数据进行录入和保存；

2. 可执行开始步骤、结束步骤、暂停、返工等相关流程操作。对于开发人员，类设计应当符合“开放–封闭原则”[4]，具有优良的扩展性，能够在必要时灵活扩展出新的测试步骤类。

3. 抽象建模与类设计

3.1. UML

UML (Unified Modeling Language，统一建模语言)是面向对象软件的标准化建模语言[5]。UML 因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。

本文将使用 UML 对抽象建模和类设计的过程进行描述。

3.2. 基于传统方法的抽象建模与类设计

3.2.1. 抽象建模

小节 1.3 中所描述的流程定制功能需求中主要涉及了三个对象：测试流程、测试步骤以及包含在测试制程中的子测试步骤。首先尝试以传统的树形结构对上述三个对象进行抽象，如图 3 所示。其中，Process对应测试流程、Node 对应普通测试步骤、ComplexNode 对应特殊的测试步骤——测试制程、Test 对应测试制程中的子测试步骤；Node 与 ComplexNode 为 Process 的叶子节点、Test 为 ComplexNode 的叶子节点。通过建立这样的树形结构可完整的描述出不同的测试流程。

3.2.2. 流程类与测试步骤基类的设计

由于 1.2 小节中所述的 9 类测试步骤拥有共同的属性与操作，因此可抽象出一个基类与流程类建立联系。根据抽象模型以及功能需求可得出流程类与测试步骤基类的设计如图 4 所示。其中，Process 为测试流程类，包含两个成员变量以及三个方法：lot 变量用于与来料批次绑定；nodes变量是 Node 对象的列表，用于保存当前测试流程所包括的测试步骤及其顺序信息；以 String 为参数的构造方法通过解析包含流程信息的字符串创建Process对象；endCurrentNode()方法用于结束当前测试步骤，

Figure 3. Abstract model based on tree structure

图 3. 基于“树形”结构的抽象模型

Figure 4. Class of process and base class of test step

图 4. 流程类与测试步骤基类

即首先找到当前正在进行的测试步骤 Node 类型实例，然后执行该实例的 end()方法；startNextNode()方法用于进入下一个测试步骤，该方法中首先执行 endCurrentNode()方法，然后根据步骤列表寻找到下一个步骤的 Node 类型实例，并执行该实例的 start()方法。

Node 为测试步骤基类，包含四个成员变量以及四个方法：name 变量为当前测试步骤的名称；state变量为当前测试步骤的状态(未开始、已开始、已结束等)；result 变量为 Result 类型，用于保存当前测试步骤的测试结果数据(如各个 Bin 类所包含的数量等)；start()方法用于进入当前步骤；end()方法用于结束当前步骤；setResult(Result)、getResult()方法分别用于设置、获取当前步骤的测试结果，是成员变量 result的普通 get、set 方法。

3.2.3. 测试步骤子类及子测试步骤的设计

测试步骤除了共同的属性与操作，还拥有自身特有的属性。如 IQC 有重量、标记等特殊属性，Baking有烤箱温度、烤箱编号等属性需要存储。因此，各类测试步骤均继承 Node 基类并建立自己的子类。详细类设计如图 5 所示：IQC 类为 IQC 测试步骤的抽象，成员变量 mark、netWeight 存储了重量与标记数据；Baking 类为 Baking 测试步骤的抽象，成员变量 ovenNumber 与 timeLimit 记录了烤箱编号以及烘烤时间限制数据；GuTest 类为 GuTest 测试步骤的抽象，由于测试结果的格式不确定，以字符串变量 record 的形式记录了该测试步骤的测试结果；测试制程类命名为 ComplexTest，并持有子测试步骤类 Test 的列表，用于记录子测试步骤的信息；Test 类为子测试步骤 Test 的抽象，成员变量 name、note、result、state、turn分别记录了步骤名称、备注、测试结果、测试状态、步骤顺序等信息；FVI、FQC、OQC 较为相似，统一抽象为 PassNode 类，以字符串的形式记录结果数据；Packing 与 Finish 相似，统一抽象为 Finish 类，其中 createReelcodes()方法为创建 Reel 盘实例的方法，由于涉及到本文范围以外的类，不再赘述。

Figure 5. Base class of test step and derived classes

图 5. 测试步骤基类与各测试步骤子类

如上所述的设计虽然可以满足基本的功能需求，但却不具备灵活的扩展性。例如：要建立单独的 Test子测试步骤，就必须先建立 ComplexTest 测试步骤；要在 ComplexTest 测试步骤中添加 IQC 等步骤，或者要求 ComplexTest 测试步骤中再包含其他测试步骤，就必须修改 ComplexTest 类代码。上述的一系列问题均可通过“组合”设计模式来解决。

class MES

IQC

- mark: String

- netWeight: String

ComplexTest

- tests: List

Baking

- ovenNumber: String

- timeLimit: String

GuTest

- record: String

Finish

+ createReelcodes(): List

PassNode

- result: String

Test

- name: int

- note: String

- result: Result

- state: int

- turn: int

Node

- name: String

- state: int

- result: Result

- process: Process

+ start(): void

+ end(): void

+ setResult(Result): void

+ getResult(): Result

-tests

3.3. 基于组合设计模式的改进类设计

3.3.1. “组合”设计模式

设计模式是一种可以被反复使用，经过分类编目的代码设计经验的总结。使用设计模式可以保证代码的可靠性，提高代码的可维护性，使其可重复利用[6]。

组合模式允许将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。组合模式的类图如图 6 所示。其中，Component 类为抽象类，Leaf类与 Composite类均继承 Component 类；Leaf 类是 Component 类的叶子节点(即单一元件)，Composite 类是 Component类的根节点(即复合元件)。Composite 类回旋持有 Component 对象列表，将其作为自身的子元件，即可方便的实现树形结构[7]。

3.3.2. 抽象建模

基于 2.2.1 小节所述的基本树形结构，在保持测试流程与测试步骤的一对多关系、测试制程与子测试步骤的一对多关系保持不变的同时，增加两个抽象对象：“叶子(Leaf)”与“组合(Composite)”。其中非测试制程的测试步骤与子测试步骤在树状结构中为叶子节点，因此归属于“叶子”；测试制程由于可以包含更多的子测试步骤，是根节点，因此归属于“组合”。以此为基础建立模型并应用组合设计模式。

3.3.3. 改进的测试步骤类设计

将组合模式应用至测试步骤类的设计中，得到的类设计如图 7 所示。其中，将 Node 设计为抽象基类，并创建 LeafNode 与 CompositeNode 两个抽象子类。Node 抽象基类作为 CompositeNode 类的元件，使得

CompositeNode 类可持有 Node 基类所有的子类，包括所有叶子节点和根节点，ComplexTest 类即为测试制程类。这样的类设计与 2.2 小节中所描述的类设计的显著不同在于：2.2 小节中基于传统方法的类设计

只能构建出既定的三层树状结构，而本小节中应用组合设计模式的类设计可通过 CompositeNode 类的不断嵌套构造出无穷多层的树状结构，极大的提高了可扩展性。

图 5 中所有原本直接继承 Node 基类的测试步骤类更改为继承 LeafNode 类，如图 8 所示。需要说明的是，原本孤立的 Test 类现在继承了 LeafNode 基类，因此既可以作为独立的测试步骤被编排入测试流程，也可以作为子测试步骤编排入 ComplexTest 测试制程。同样，IQC、Baking 等步骤也可以方便的组成新的测试步骤，大大提高了类设计的可扩展性。

Figure 6. Class diagram of composite pattern

图 6. 组合模式类图

Figure 7. Application of composite pattern on test step classes

图 7. 测试步骤类中的组合模式应用

Figure 8. Classes derived from LeafNode class

图 8. 继承 LeafNode 类的测试步骤类

4. 功能运行结果

系统功能采用 B/S 架构，使用 Java Web 相关技术[8]，以 Spring、JPA 作为后台开发框架，以 MySQL作为数据库具体实现。开发完成后通过 JDK 工具生成 war 包，部署在服务器的 tomcat 容器中运行。流程组装界面如图 9 所示。其中流程明细一栏通过点选左右两侧站点的名称以及上下左右的操作按钮来添加、删除站点以及调整站点顺序，点击保存后生成字符串传递给服务器端生成所需要的存储结构。IQC 录入以及保存检测站点数据的界面如图 10 所示，其余站点的界面类似。经测试，流程定制所需各项功能均已完成，运行稳定可靠。

Figure 9. User interface of process assembly

图 9. 流程组装界面

Figure 10. User interface of test result data input and save for IQC

图 10. IQC 检测结果数据的录入及保存界面