F26 系統應該被測試，想法應該被Review

系統應該被測試，然後除錯，以期望它能正常的運行
想法應該被review，然後修訂，以期望它能順利地實用

由於與同事討論程式設計的想法時，大多流落到局部面的思考，所以原本想藉這個Blog記錄對於開發系統時要有的全部想法，作為日後討論的依據。開始的時候試著用處理事情的思維加上軟體工程的角度寫短篇的文章，卻在不斷地思索之後慢慢發掘到更多要素的思維與影響。

雖然已儘量用主題表達方向，並使用簡短的文字帶出我的想法，不過我感覺只寫出心裡想法的四分之三左右；而更重要的是，雖然我覺得自己的想法說得通，但是不知實際上有沒有問題。於是幾天前在Java World @ TW論壇公開部落格的網址，讓自己的想法來接受檢驗並加以調整。不過一個沒考過SCJP認證又沒看過幾本書的人所說的話，理論上是不會有人進來多看的。

至今遇到過的人都還停留在“用程式做功能”的層面上，希望有那麼一天可以跟幾個理念接近的人共事，討論出實現軟體工廠的可行方式，並進而先“用程式做工具”讓很懂商業邏輯卻不大懂寫程式的人“用工具做功能”。等到那麼一天我們就可以有很強的競爭力了。

F25 客戶會在意系統開發的哪些方面？

在工作上一直都是廠商的角色，以公司的作法來滿足客戶的需求。用我現在的標準來衡量，如果我今天是需要採購一套電腦系統的客戶，我將會以下面幾項為出發點來審視：

首先是功能部分。系統最低限度是要滿足需求，除了由客戶提供功能清單之外，我將會檢視廠商如何記錄與控管所有的功能與流程的描述；尤其是需求規格書的內容。要是我可以決定測試標的內容，我一定會加上幾份重要功能的規格書審核。

接著是設計部分。我會檢查系統架構設計書上是否完整註明所有硬體與所用的技術？決策的過程是否有被記錄？當然設計規格書會是重頭戲，不過我著重的將會是Controller與Action的層次是否分明，另外看元件的層次是否整齊，系統的訊息是否獨立，功能上要求可以置換的地方是否採用夠彈性的設計。

測試將會是最看重的部分。測試的範圍必須與功能的設計相互呼應，藉此來保證所有功能都被完整測試；另外測試的時程與報告也是一定會看的重點。最後則是文件的內容是否切確地描述系統的安裝與如何使用所有的功能。

其實我覺得重點是在系統開始的時候，客戶就要用心投入系統的規劃，如此才能夠隨時隨地掌握住系統的狀況的內容。

F24 做事的方法(8)──做前三思，做後反省

生活裡總會遇到許許多多要作決策的事，之前提過做事要有目的與達成的步驟，但是在做之前還有個重要的決策：到底該不該做這件事？

在心裡快速地作沙盤推演可以是個有效的方法，把每個決定與作法都在心裡思考一下，整理出每個決策的優劣與影響並加以比較，如此將最有機會選擇到最好的決定。很快地作決定並不見得是好事，古人要我們三思而後行就是希望我們先確認再作最好的決策。

在學生時代寫考卷時，師長總會要求我們寫完要檢查；現在要問的是，要怎麼檢查才符合之前所提到的測試概念呢？每一個題目是需要寫答案的最小物件，所以在寫每一題的答案前應該先在心裡檢查一下對錯，這是Unit Test；每一個大題包含了該類型的所有題目，不過每一題間並沒有關係存在，這一層倒可以省略不用檢查；整張考卷會被批改並標註分數，於是把考卷視為系統再作一次檢查也是合理的要求。

做事前養成先想一下再做的習慣，一定會比先做下去再觀察反應的方式好上許多。這是在從事任何決定之前應該要有的習性。

F23 測試結果與對應文件裝訂在一起

需求被定義為功能，功能經由設計而實現，實現的程式藉著測試來保證運作的正常。不止是測試的結果，這一系列的相關文件具有演進的垂直關係，理應放置在一起以便查詢。

不過物件的位置與關係至少會是二維的，處於同一層次的物件彼此間會有相互使用的水平關係。像最開始會在功能裡使用其他功能，接著就影響到其下的設計與測試，都必須等待自己使用的功能完成後才能開始。這樣的關係也是必須在文件裡註明的。

另外也要記得同種類物件的清單必須產生，這是各個層次物件的快速索引表。如果有能力的話，水平追溯表與垂直追溯表還是做出來會比較方便查出所有的關聯；但是如何與真實物件間的關係作同步的修改，將會是日後需要多花資源的地方。

總之，讓同一個功能之下所有項目的資料都放在一起，這是符合聚合並封裝概念的作法。

F22 追溯關係(4)──Use Case vs. Test Case

Use Case應該與Test Case作好關聯的追溯。我們可以藉由測試過哪些Test Case來達到保證某特定Use Case可以正確執行的結論。

不管是因為什麼原因更動了程式碼，最基本的就是那個Class必須重作Unit Test；其次再依序往上，一層層地對使用到這個Class的Class作Unit Test，並依此原則遞迴測試所有最終會用到該Class的所有程式。

接著需要分析的是剛才所有重新作過Unit Test的Class，各自被包含到哪些Use Case的範圍內；有包含那些Class的Use Case對應的Test Case都必須重新進行測試。如果更動的是很多Use Case所使用的核心Class，那麼重新測試耗費的資源會是很可觀的。

要能根除“改過這裡之後要測試哪些東西才能再度保證系統是可以正常運作的？”這樣的問題，唯有作好對應功能、設計與相關測試的追溯關係方有終點。

F21 測試錯誤的處理(3)──迴歸測試（Regression Test）

如果問題單提出的內容的確是系統的錯誤，那麼系統理應針對這個問題作修正。程式的任何變動都會造成程式所在方法的改變，進而影響到呼叫該方法的所有地方。為了保證一段程式被修正後，其他使用它的方法同樣運作正常，我們必須再重新測試過這些方法所對應的測試項目（即使修改前已經全部測試通過）。

由此可見，程式的變動是需要審慎從事的。在國外的專案裡，每一行程式的變動，客戶都會詢問是為什麼而改，同時會影響哪些範圍，因為錯誤的解決方法會讓系統如同骨牌傾倒般到處出現連帶的問題。有時邏輯上的問題造成兩個地方糾纏不清，Ａ改好Ｂ就有問題，去改了Ｂ時Ａ又壞掉，這樣的Side Effect是任何人都沒法忍受的。

前面提到程式的追溯最好是到方法層級，這是因為方法內部的改變只要往上追溯使用該方法的地方；如果追溯的程度使用的是類別，那會使得追溯出來的範圍過大且不正確。涵蓋了一堆沒有使用關係的方法，會測試到一堆本來就正確的地方（因為沒用到改變的地方），比起在設計時去追溯方法的關係，將會浪費更多的測試資源。

F20 測試錯誤的處理(2)──用Defect System記錄

問題單應該統一開立在一個地方，至少可以使用一個Excel存放；但是最理想的方式還是使用Defect System。後者的好處是可以集中存放，多人同時使用與編輯，而且在與自己有關的問題單改變時，會主動發出郵件通知（Event）而不用時常進入系統查看。

把開立的問題單視為資料庫，我們可以在特定時間點統計開立問題單的數量、退回數量、解決數量、未解決數量、重開問題數量……等等的統計與百分比，這些數據的統計範圍除了整個系統之外，也可以針對各個定義的範圍（模組或功能）統計出各個部件的問題單狀況。

另一個好處是，任何時候遇到系統上的問題都可以先到Defect System上查詢以前是否發生過同樣的狀況，如果有的話先參考之前是如何解決或是如何正確使用的，如果沒有就能放心地開立新的問題單而不用擔心會有重覆的狀況。

類似的系統在系統出版本後，可以應用在FAQ（答客問）的方面，使用者遇到問題或是不會使用的狀況，都能找到一個集中管理類似問題的資料庫搜尋想要的資訊或提問讓系統維護人員回答。

F19 測試錯誤的處理(1)──概略的流程

F18 Unit Test(4)──測試Component Interface

表面上Component Interface要測試Interface，但是事實上同樣是要測試實作Interface的所有Class。

測試時每個實作Class生成一個測試類別，每個Component Interface方法都對應一個測試方法，這與Interface的測試策略相同。從Class到Interface到Component Interface逐步的測試，代表的是由組成單位往上組裝成元件的測試，經由一層一層的設計與測試確認，我們得到的將會是穩定度很高的元件。

元件是用來組成系統的最大單位，在元件之上就是系統使用它們的控制流程；測試控制流程的部分就進入到Use Case相關的功能測試與整合測試。參考系統架構設計的圖，單元測試主要是保證的是右下角元件的正常運作，整合測試、功能測試與使用者測試則是針對其他與專案相關的層次加以測試。

註：專案層級裡所有程式同樣也需要通過單元測試，先保證每個Class的方法都正確後才可以進行更上層的測試。

F17 Unit Test(3)──測試Interface

在元件內部的設計層次我們的架構留了幾個介面的存在，介面之下的實作少則一個Class，多的話也有可能超過十個。無論如何，Class測試通過後就要往再上一層的元件內部介面進行測試。

每一個元件內的介面，其往下的實作Class會生成一個測試類別，每一個介面裡定義的方法都生成測試方法加以測試。測試的原則同樣以在時程允許下寫出最多的測試內容為理想作法。這裡進行的已經是小規模的Class整合，有時明明每個Class都測試通過，但是放在一起就是沒法全部測過。就像有時社會裡明明每個人都守分地只做自己應做的事，但是整個社會還是會莫名其妙地產出問題。

Interface層級的測試，是把它之下從實作的Class起的使用關係都視為封裝的組件，測試通過保證這一部分的程式都沒有問題後，才允許再往上一層的元件使用這些層級來組合達成元件預期提供的功能。

註：Class與Interface的測試都要依據使用關係，從沒有使用其他Class或Interface的開始測試起，依序照著使用關係往上測試。

F16 Unit Test(2)──測試Class

Class是系統組成的最小單位，因而同樣也是單元測試的最小單位。設計時讓每個Class都各如其分地負責自己的工作，測試時則確保每個Class都能正常運作，這麼一來採用這個Class組成的大小組件就不會出現基本層面的問題。

一個Class會有一個對應的測試類別，生成的同時應針對public、package與protected的方法產生對應的測試方法，每個測試方法裡依設計規格產生輸入用的資料後，呼叫該方法並驗證傳回值是否正常或是否如預期般拋出例外。public的方法是必測的，package與protected的方法如果可以測試會更理想，然而因為後兩者在包裝層次與元件時可由外部測試來涵蓋相當大的部分，要是時間不夠的時候略過也無妨。

能夠針對規格裡提到的所有狀況都寫出一段測試程式是最理想的，因為測試涵蓋度越大就越不容易有問題，不過測試時大多都只會挑選一些重要的規格，省略測試功能的結果就是有可能讓小問題在未來因為相互影響而成為更大的問題。

註：測試Class的範圍包含static APIs但不包含Abstract Class。

F15 Unit Test(1)──基礎的單元測試

程式的實作都在Class裡完成，元件與系統都是由Class所組成。確保Class提供給外部使用方法運作的正確，就是單元測試所要提供的保證。

程式實作的過程會根據Coding Standard來review所有的程式碼，寫作的風格也有檢查的工具，只要依希望的程式風格設定參數檔後，工具就會依設定檢查程式並條列出不合規定的所有地方。由於改變程式就會有影響，所以在測試之前應先進行review與調整到符合規定的穩定程度再進行單元測試。

Unit Test有測試工具可以使用，對於Class來說會有一個測試用的Class裡面有每個方法對應的測試方法，我們在初始化方法定義每個測試方法之前的動作後，即可在測試方法裡寫下所有的測試動作。工具允許把Class依所屬關係集合起來一次執行，並在結果上註明有哪些測試的動作沒有得到預期的傳回值。

Class本身的方法、元件層次Interface的定義、封裝元件的Interface、系統層次的Interface，由下往上組合而成的各個組件，每一層在測試時都會被視為獨立的黑箱，由Unit Test工具進行所有方法的結果檢查。

F14 Use Case測試(3)──系統整合測試（System Integration Test）

在主要功能（由客戶指定哪些是重要的）的各個層次做好且通過單元測試後，我們必須把這些層次的程式放置在系統架構上，以驗證這些程式放在一起時能否正常運作。

像Client與Server間收送的模組、Context、Flow Engine等與系統架構有關的必定屬於最重要的功能，這絕對是需要優先整合完成的；系統架構沒有問題後，才能把重要功能的程式放上去進行它們的功能測試。整合測試與功能測試要檢查的都是系統執行的正確性，但整合測試時主要是強調系統架構是否可以讓功能的執行順暢且無誤，而不在於功能的內容是否全部正確。

因此整合測試的內容通常會先列出系統架構上的測試項目，接著會基於幾個重要功能裡足以驗證可以被正常執行的項目。不過我們通常會要求重要功能裡的所有測試項目都要通過，因為幾個重要功能可以在架構上完全正常執行，大多代表著其他功能不會因架構問題而產生錯誤。

F13 Use Case測試(2)──功能測試（Functional Test）

正常執行所有的功能是系統最低的要求，也因此通過所有的功能測試是最低的要求。雖然測試功能是非常重要的，但是不要誤以為客戶只注重這個測試而跳過其他底層的測試，因為底層幾個交錯的小小錯誤，很可能讓問題在功能之間相互影響而難以根除──除非重新設計。

功能測試我會分為兩個層次來進行：第一次由測試人員依使用者測試的步驟操作，一方面準備執行的資料，一方面可以藉此先找出操作介面上的基本問題。在輸入好全部的資料執行功能的一開始，用一個暫放的小程式把Context的內容儲存下來，往後測試人員在進行這個功能的測試時，可以使用Hot Key叫出以前的測試值直接重現，可以省卻許多重覆輸入的時間。當然這樣的小工具在功能測試結束時一定要移除。

一邊輸入資料，一邊觀察系統反應，執行功能後再確認執行結果的所有內容都是符合測試項目所描述的。所有的功能都測試成功，就至少符合系統的基本需求。

F12 Use Case測試(1)──使用者測試（User Acceptable Test）

Use Case基於系統架構作完設計後，應該把該功能從頭到尾的使用者操作動作記為測試的內容，並與預期的系統反應比較是否正確。

測試的內容以如何進入這個功能為起點，接著開始一步一步地註明要如何操作系統輸入，有時夾雜一些錯誤的操作以證明系統能夠有正確的反應。藉由逐步操作準備好輸入的資料後便執行功能（功能測試要先完成），同時觀察系統的輸出是否與規格書相同；如果需要再進一步的操作則同樣記錄並加以測試。

每個功能的每個步驟都應該測試正確，在提供給使用者作真正的User Test之前，專案人員當然必須先行測試過讓排除掉顯而易見的問題；沒有使用者會希望給自己測試的系統連立即可見的錯
誤都還有一大堆的。幸好這在功能測試時大多都會被發現。

對於可以正常執行功能的各個步驟與系統反應要稍加註記，因為使用手冊裡的操作步驟會由這些內容依序匯集而成。另外在使用者測試進行到一定程度，確定系統架構足夠穩定、功能可以順利執行且操作介面沒有大礙之後，可以增加同時進行測試的人員數量，藉此開始測試系統在多個使用者操作時的穩定性。

F11 系統整體測試(3)──組態設定測試（Configuration Test）

在設計各個元件與功能時，會有許多設定拉出到允許使用者設定的層級，這些設定的內容都需要加以逐一驗證與測試。

通常的測試都會一一將各個設定檔內容加以調整再進行測試，逐一驗證系統的行為模式。我覺得可以使用兩段式的測試方法：首先先測試設定檔是否可以正常被讀取為Properties；再來就只要寫測試程式去改變系統內部的Properties內容並呼叫對應的測試方法去測試特定的功能即可。這樣一來就可以讓系統一次測試所有的設定檔內容以比對結果。

如果設定檔改變的是顯示時的外觀，必須另外分開使用人力來測試，因為外觀的改變必須要由人來判斷正確與否。如果影響的操作的動作，我們像前面那樣完全由人來測試、錄下使用者的操作或是使用Robot程式來模擬使用者的操作行為，並在關鍵時暫停由人來判斷結果。

組態設定的檔案、內容、測試使用的值與對應的結果正常與否都要詳加記錄的。通常這會在系統測試的最後階段進行。

F10 系統整體測試(2)──壓力測試（Stress Test）

為了保證系統在多個使用者時可以穩定執行，客戶應該都會要求Server必須在多少不同的使用者同時執行任意功能多久時間之下，不能有任何的系統錯誤。

假使系統的要求是一百位不同使用者同時執行功能，通常我們會選用十台電腦，每一台都用不同的Thread執行十個系統同時執行指定的功能，藉此來模擬一百個使用者同時上線的狀況。雖然與真正的情況有點小差距，但是要同時找上百台電腦可是件困難的事情，所以這是個可以通融的測試方式。

壓力測試有時會與效能測試的規格一同定義，比如說單機執行功能時要在三秒內完成，在一百位使用者同時使用的情況下，每位使用者都要在十秒內完成功能之類的要求。效能測試與壓力測試有時會因為瞬間的因素而不準確，因而會多測幾次，剔除絕對不合理的數值後再求得平均值。

或許我們可以像奧運裁判那樣測試七次，忽略最好與最壞的一個只取中間的五次來計算平均值。

F09 系統整體測試(1)──效能測試（Performance Test）

需求收集並加以分析之後，首先要決定的是系統的架構。在設計系統的同時，我們會參考客戶偏好的方式並顧及到非功能需求裡要求的項目。通常可以看到的是客戶會指定一些重要的功能，要求執行時間必須在某個限制之內；還有就是要求處理功能時電腦之間傳送的資料，必須在多少頻寬之內。

要如何加快執行時間與降低系統頻寬是設計時要注重的內容。對於測試來說，速度的測試會在功能執行的開始用Log記錄開始的時間，並在結束時記錄結束的時間，再用個函數求得執行的時間；這樣的測試若能使用程式準備好測試資料執行，同時收集每次執行的結果是最理想的。

在上面的測試裡，於發動傳送的程式點記錄下傳送出去的資料量與接收回來的資料量，會有助於知道頻寬的使用量。雖然網路傳送時會加上封包的大小，但大致上可以求得差距不多的大小，因為我認為這方面做到可以自動測試會比要求完全的準確重要那麼一點點。

F08 最好可以快速地重覆測試

一個系統動不動就上百個功能、近千個類別且上萬個方法，即使已經有所取捨，但是撰寫測試內容所花費的資源還是很多；當然實際測試時投入的資源一樣不少，也因此在求快型的專案中決策的人有很多決定只粗略地進行測試工作。

首先要注意的是要建立起系統項目與測試項目的關連，先建立起明確的關係才能在需要測試時立即知道進行哪些項目就能保證那些產出運作正常。在第一次測試時測出的問題會經過修正，修正時會進行影響評估得知另外改變了哪些模組，所有改變模組的測試項目都應該要重新進行測試。

沒有建立起關係追溯的系統就會在這個時候開始失衡，因為沒有辦法判斷出改變設計時的影響，也沒有辦法得知改變影響後相關的測試項目，甚至連對應的測試項目都不存在。這樣多改個幾次之後，整個系統就開始混亂。

為了避免重覆測試時投入過多的資源，最好是選擇可以自動重覆測試的工具與方法以節省測試時投入的資源。在具有自動測試比對的工具裡，需要重新測試模組的時候只要點個開始，就可以等著得到該模組甚至整個系統的最新測試結果報表。這應該是最理想的結果了。

F07 測試計畫、項目、步驟與結果都要留下記錄

測試相關的內容是基於功能與設計的結果而決定的，範圍的取捨與項目的決定會被列成清單來表示，最好在清單裡記錄著所有應測試的項目再註記哪些項目因為什麼樣的原因而在此不作測試。

在功能的測試方面，有測試工具可以管理所有的測試項目。每個測試項目對應到一個測試劇本，劇本裡可以編輯測試步驟的內容與順序，另外在需要檢查的步驟之下可以插入一個結果描述，測試的時候操作完該步驟後就核對是否與結果描述相同並加以記錄。經由測試工具管理的測試結果，可以依不同的需求產生出測試報表。

在程式的測試方面，有單元測試工具來管理所有類別方法的測試項目。定義好要測試的類別與其方法，在測試的方法裡用不同的參數內容呼叫要測試的方法並核對結果，依此作為測試是否正確的依據。在單元測試工具裡，可以一次測試所有的測試內容來判斷現在版本的系統是否運作正常。

把所有的測試作記錄，我們才能明白每個功能各有哪些測試、測試了什麼項目、用什麼方式測試與所有測試的結果。由於測試與各層次的產出都有關聯，這也是需要另外再記錄下來的關係。