想像一個情況，你需要管理上百個功能測試項，它們名稱相似、邏輯複雜。每次修改參數或撰寫邏輯時，都像在考驗眼力與耐心，這正是我的客戶當時遇到的「日常情況」。
最初，這位Test Engineer(簡稱TE)找到我只是希望優化某個 Flow 的測試時間。但在深入分析現有架構後，我發現真正的問題，在於整個流程對使用者來說「太難用」。一個 Flow 中有上百個功能驗證測試項，以及數十個控制參數的 Flag，不僅撰寫邏輯容易出錯，查找測項更是耗時費力。
雖然挑戰巨大，但我主動提出了一個「減法設計」的改善建議：在不困擾使用者的前提下，透過徹底重構架構來解決這個根本問題。
最終，成功透過修改底層Java三個核心的架構，讓整個 Flow 執行時間節省了約 16%，且徹底簡化了工程師的參數設定與 Debug 流程。
在本文中，我將詳細拆解這三個改動的思考邏輯、實作方向，以及我從中深化體悟到的觀念：什麼才是工程師真正該思考的「好用」設計？
痛點分析： 上百個相似測項如何讓團隊陷入低效？
Flow架構大概是這樣: 上半部是定義區，下半部則是執行區。上半定義了12345，執行區定義34512，實際執行就會根據34512的順序執行。
而這個Flow中有100多個測試項在上半定義區，下半執行區不僅包含這100多個測試項的執行，還包含了數十個參數用於控制測試時的條件，讓晶片可以順利在不同測試條件下執行這些測試項。
這些測試項雖然是簡單的基本功能驗證，但有100多個測項其實對TE來說仍是一個負擔，即便大量的測試項可以透過程式生成，下方的參數變化邏輯仍要靠人力設定撰寫。而100多個測項名稱都相當接近，在撰寫邏輯時容易眼花搞錯或是找名稱找很久。因此要想辦法幫TE解決這個使用上的問題。
減法設計思維： 我用三個核心改動重構流程
理解整個流程跟需求後，我大概花了一個下午的時間思考整個架構怎麼樣做，會「更方便使用者使用」以及「結果更清楚」，讓後續TE更簡單去控制參數以及Debug。我參考了一些過去修改過的Java以及確認自己大概會需要用到的API，便開始著手撰寫prototype。
主要修改方向有三個:
1.整合大量測試項，把相同測試條件的測項放進同個測項中。
此項改動讓一百多個測試項整合成十多個測試項，並且上方定義區更加清晰簡潔。使用者能一目瞭然知道目前這個測試項是在哪個條件下進行測試。
這項改動不僅是為了美觀，在測試項切換上也能減少一些測試時間。
2.為方便TE設定邏輯，同樣把邏輯整合進測項，讓下方執行區不再需要手動定義複雜邏輯。
此項改動則是在每個測試項都做一個「調整接口」，讓測試項具備自己的執行邏輯判斷，接口可以接收原本判斷邏輯用的變數。從而達到執行這個測試項過程中，底層的Java會直接判斷這一項測試項需不需要執行。
這項改動雖不是TE原始需求，但在討論後TE覺得這會讓，他們更輕鬆工作，我就覺得是好的改動。
3.新增自動繪圖功能，程式將根據測試項設定自動化匯出電流趨勢圖。
在各項測試條件下的測試項不僅僅是執行，TE還需要觀察電壓趨勢圖，而原本TE需要手動額外設定繪製條件再次執行才能看到圖。在改動中把這項功能修正，執行過程中可以直接看見趨勢圖且不用額外手動設定。這項改動同樣是為了減少TE工作中繁瑣的步驟，使其更加清晰簡化。
在Prototype完成後便實際上機測試，而在上機過程中也遇到一些邏輯或使用上問題，這恰好也是測試的重點，不實際測試功能根本不知道做出來的東西能不能動、行不行得通。
成果展現與反思： 節省 16% 時間的背後，工程師該有的「用戶導向」
在不斷來回、上機測試之後終於將測試項從無到有開發完成。整體來說程式經過優化不僅僅整個Flow節省大約16%測試時間，還針對了TE觀察趨勢圖或構建邏輯時的操作時間，以此完成了客戶TE的需求，同時也為自己有所貢獻感到開心。
最後針對這次開發的經驗，在撰寫Java的過程中也不斷跟TE溝通，確保自己的方向與目標跟客戶一致，而不是閉門造車。更加強化並深入了「無論是寫程式還是做Script Tool，都要確保別人覺得好用、可以用，而不是自己覺得好用就好。」的觀念。
雖說在我離開之後也許這Jvava不一定會持續被使用，但這對我來說是一個寶貴的經驗，從理解、構思、研發到實際應用都是我個人參與。
我也會持續思考:如何針對一個系統、工具及流程改善，幫助他人更有效率完成工作?
