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 檢測結果數據的錄入及保存界面