某甲問道：「測試做太多的話，會不會使得bug解不完？」
某乙回答：「還不簡單。只要不做測試，就沒有bug。」
上述對話，反應出許多軟件工作人員對於測試的想法。對多數軟件開發人員而言，測試大概是僅次於維護之外，最令人討厭的工作。對軟件研發主管來說，測試是必要之惡：做得不夠後患無窮，做得過多又增加成本，延誤商機。因此，如何能夠規畫與執行一個最經濟有效的測試工作，當是軟件研發主管們須研究的一個課題。
軟件測試的困難，在於它不僅是產品的測試，更是產品設計程序的檢驗。由於關乎設計的測試，準則不易尋找，經驗未必得以再用，他山之石也有應用的侷限性，因此難度頗高。欲提高測試的效益，有賴全盤的規畫，確實的執行，與事後的檢討改進動作。許多小型軟件研發單位，對於軟件測試並不重視，但從許多稍具規模的軟件公司均配置常設測試人員，乃至於測試品保部門來看，測試工作顯然有其學問與價值的。
測試工作沒有最佳方法可依循，是因爲不同的軟件所需的測試手段不同。譬如小型軟件與大型系統的做法不同；訂製軟件與軟件包的要求不同；系統軟件的測試往往無法採用應用軟件所使用的技巧；遊戲軟件與庫存系統有其各自需面對的測試標的。因此，測試人員必須因應軟件的特性與資源的限制，加上過去相關的經驗，規畫最適合的測試方式。並隨着經驗的累積，不斷改進作法，才能找出最佳的測試方法。
由此可知，要做好有效的測試，不只是埋頭苦幹而已，它需要良好的管理，使整件工作獲致最佳的成果。關於測試的管理工作，可從組織、規畫、執行與檢討幾個角度來探討。以下謹就筆者粗淺的經驗野人獻曝一番，希望提供讀者基本的協助。
測試組織之設計
由於人性總自認爲自己的最好最正確，完全由軟件開發人員兼任測試人員，並不值得推薦。實務上往往因軟件開發單位的經濟規模不夠，使得開發人員經常兼任測試人員。但若可行，研發單位應儘可能配置專任的測試人員，尤其是獨立於開發小組之外的測試負責人員。儘管是否應設置獨立測試小組業界仍有爭議，許多人甚至以爲保障軟件品質唯有從改進軟件開發的程序做起，但大部份美國的軟件公司均設有獨立測試或品保人員乃至於部門，這說明了獨立測試仍有其不可搖撼的地位。
許多的軟件研發單位將測試視爲次等的工作，從而配置次等人員負責相關工作。如此一來，優秀人員無從參與，也缺乏意願參與測試工作。結果軟件品質不易度量，研發的成果常常被不佳的品質抵銷，實爲令軟件開發人員泄氣之事。主管是否能體認到軟件測試的重要性，通常是成功的關鍵。軟件測試固然是支持性工作，仍應配置合理的資源，以獲取整體之成效。在當前的環境下，給予測試人員較多的關注，毋寧是必要的作法。
測試工作規畫
測試工作的規畫，至少包含兩項要點：測試目標的訂定與測試資源的配置。攻擊需要目標，測試亦然。測試的目的在於找出軟件的問題，提供改進之參考。目標若不明，測試人員即不知如何着手。
測試目標的訂定，最重要的在於軟件通過的準則，亦即測試何時方可結束。常見的情形是：軟件開發的進度不斷落後，最後剩餘的時間僅有兩個星期，於是測試人員的目標就是把最後兩週用完，盡人事聽天命。究竟測試多完整，隱藏的多少錯誤，測試工作的生產力如何？皆一概不知。反正產品賣出去或上線後有的是時間改進。然而產品銷售後再改進，成本往往大幅增高，甚至原有開發人員離職他調，連亡羊補牢都倍感困難。經驗一再顯示，事前的測試除錯絕對比事後維護省時省錢，唯有賣不出去或不能用的軟件例外。
對於測試的要求可簡單區分爲二：一種是通過目標所訂之軟件品質；一種是在既定資源內達到最佳成效。前者要求山頭一定要攻下，不達目的絕不停止。譬如目標爲單位測試時間的錯誤發現率須低於某數字，若超過了就得延長測試。此種方式適用於品質要求較高的軟件。至於後者則是上市時間已宣佈，無法更改者，其目標着重於剷除最嚴重的錯誤。此種測試較着重測試的準備、經常對測試執行與除錯設定時限與數量要求，其中最容易遵循的準則即爲：重要功能永遠先測。這兩類測試的需求不同，足以影響到測試的計劃、測試的順序與關心的重點。讀者不可不察。
至於測試資源配置適當性，則是評估測試目標能否達成的重要參考指標。測試人員需要合理的測試資源，譬如要求總研發人力的20%以上。總時程的1/3以上。人力不足，測試流於形式，時程過短，找到錯誤也來不及除錯，均不可取。除了測試在研發的比重，也需注意測試工作本身在規畫管理、規格個案訂定、測試執行、迴歸測試、訓練準備工作的人力分配。人員的訓練與設備的安排尤其容易輕忽，需加以注意。不同階段測試的資源配置，也必須加以考量，如此可避免測試集中於功能測試，忽略系統測試。這些工作的適切安排，有助於協助測試工作時時都執行最重要，也最有效的測試。
測試執行與管理
測試工作執行在管理上，首先需使測試與開發人員瞭解輕重緩急。測試人員常常不考慮測試的效果，而只依照測試的方便性來進行測試。譬如軟件有十大模塊，每一模塊有50個測試個案，於是他從第一個模塊的第一個個案開始測，測完一整個模塊，再進行第二個模塊的測試，執行全部完成或無法進行爲止。事實上，測試應從重要且常用的項目測起。
開發人員的除錯，則往往從好改的改起。於是100個錯誤改了90個，系統主要的缺陷仍爲克服。測試管理人員需特別注意此事，確保測試工作的效率。
進行測試管理的好處在於隨時可掌握狀況，並因應需求及時調整測試策略。譬如測試一段時間後，發現某子系統的問題特別多，即可調整人力，增強該部份的測試。或是某些人的測試績效較差，則可調整工作之分配，以求整體效果。當然，這些數據的取得有賴相關信息的蒐集，包括數量與時間之信息。如果可行，可記錄不同測試工作耗用的人力時數，計算耗用成本，以便未來進行測試規劃時擁有更精確的參考數據。
進行相關資料的統計與分析，最好運用工具來幫忙，以節省人力並增進效果。如果市面已有的測試管理工具符合需求，也可徑行採用。測試結果的統計資料，不妨公佈在大家的眼前，使得測試成果可爲大家瞭解，亦能促進工作同仁求取更佳的成績。附圖所顯示爲一簡單的統計圖表，顯示每週的測試成果、除錯成果，與產品殘存的問題量，可協助主管決定測試終止及發行產品的時間。
測試結果分析與改進
當(階段)測試結束後，測試管理人員可以進行測試成果的分析。有關預定目標與實際執行結果的差異，可作爲下一版軟件測試檢討改進的依據。譬如預定開立的測試個案數是否達成目標，執行與通過數是否可接受？投入的測試甚至除錯人力是否足夠？均可視狀況計算依標準工作量，作爲未來執行測試工作之預估標準。經由分析軟件錯誤的生命週期，可以研究縮短的方法，例如加速除錯與重測週期，或在分析設計階段減少錯誤發生的機率，以縮短測試時程。
由測試結果可分析出不同測試的效益，與應改進之處。以下表爲例。單元測試耗用大部份的人力，可能使整合與系統測試不完全。再以發現的錯誤數觀之，整合測試發現一個錯誤的成本遠低於另兩項。由此可見在有限的人力時間下測試，單元測試做得太多，整合測試又太少。此意謂着對於單元測試所需耗用的人力資源過度樂觀，或是在測試工作的配置不盡理想，應予改進。
測試人力時數 測試人力分佈比率 錯誤個數 錯誤分佈比率 平均時數/錯誤數
單元測試 227.104 58.6% 49 39.51% 4.635
整合測試 87.212 23.3% 54 43.55% 1.615
系統測試 70.184 18.1% 21 16.94% 3.342
合計 384.5 100% 124 100% 3.2
除了以上的測試成效分析。如行有餘力時應再對錯誤發生的原因加以分析，力求從問題的根源加以解決。這包含測試工作的改進與開發工作的流程改進。以前者而言，可考慮對測試人員施以較充分的訓練，避免測試工作因準備不周浪費寶貴的人力與時間。測試標準程序的建立，也有助於測試工作效率的提升。至於後者，可由錯誤發生的原因研究預防之道。例如對需求變更未確實記載，導致設計錯誤的問題發生，或是軟件的設計未加充分的考慮再撰寫程序，導致設計不良造成的大量錯誤，均應加以預防，如此可望從根本解決軟件的問題。
結語
欲提升軟件品質與生產力，得先掌握現況。測試工作既是必要之惡，就需擬定最好的方法來面對。有關軟件測試方法論的書籍文章爲數固然不少，在應用上仍須因應自身的情形加以調整。品管大師戴明認爲：獲得好品質不能靠檢驗，而是來自改善工作流程。因此，測試工作只是一項起步。如何藉由測試工作，瞭解改善軟件品質與生產力之道，纔是我們追求的目標。願祝各位軟件品質的捍衛者，在工作崗位順利前進，爲測試工作贏得榮耀，更爲你們的成功產品喝采。
某乙回答：「還不簡單。只要不做測試，就沒有bug。」
上述對話，反應出許多軟件工作人員對於測試的想法。對多數軟件開發人員而言，測試大概是僅次於維護之外，最令人討厭的工作。對軟件研發主管來說，測試是必要之惡：做得不夠後患無窮，做得過多又增加成本，延誤商機。因此，如何能夠規畫與執行一個最經濟有效的測試工作，當是軟件研發主管們須研究的一個課題。
軟件測試的困難，在於它不僅是產品的測試，更是產品設計程序的檢驗。由於關乎設計的測試，準則不易尋找，經驗未必得以再用，他山之石也有應用的侷限性，因此難度頗高。欲提高測試的效益，有賴全盤的規畫，確實的執行，與事後的檢討改進動作。許多小型軟件研發單位，對於軟件測試並不重視，但從許多稍具規模的軟件公司均配置常設測試人員，乃至於測試品保部門來看，測試工作顯然有其學問與價值的。
測試工作沒有最佳方法可依循，是因爲不同的軟件所需的測試手段不同。譬如小型軟件與大型系統的做法不同；訂製軟件與軟件包的要求不同；系統軟件的測試往往無法採用應用軟件所使用的技巧；遊戲軟件與庫存系統有其各自需面對的測試標的。因此，測試人員必須因應軟件的特性與資源的限制，加上過去相關的經驗，規畫最適合的測試方式。並隨着經驗的累積，不斷改進作法，才能找出最佳的測試方法。
由此可知，要做好有效的測試，不只是埋頭苦幹而已，它需要良好的管理，使整件工作獲致最佳的成果。關於測試的管理工作，可從組織、規畫、執行與檢討幾個角度來探討。以下謹就筆者粗淺的經驗野人獻曝一番，希望提供讀者基本的協助。
測試組織之設計
由於人性總自認爲自己的最好最正確，完全由軟件開發人員兼任測試人員，並不值得推薦。實務上往往因軟件開發單位的經濟規模不夠，使得開發人員經常兼任測試人員。但若可行，研發單位應儘可能配置專任的測試人員，尤其是獨立於開發小組之外的測試負責人員。儘管是否應設置獨立測試小組業界仍有爭議，許多人甚至以爲保障軟件品質唯有從改進軟件開發的程序做起，但大部份美國的軟件公司均設有獨立測試或品保人員乃至於部門，這說明了獨立測試仍有其不可搖撼的地位。
許多的軟件研發單位將測試視爲次等的工作，從而配置次等人員負責相關工作。如此一來，優秀人員無從參與，也缺乏意願參與測試工作。結果軟件品質不易度量，研發的成果常常被不佳的品質抵銷，實爲令軟件開發人員泄氣之事。主管是否能體認到軟件測試的重要性，通常是成功的關鍵。軟件測試固然是支持性工作，仍應配置合理的資源，以獲取整體之成效。在當前的環境下，給予測試人員較多的關注，毋寧是必要的作法。
測試工作規畫
測試工作的規畫，至少包含兩項要點：測試目標的訂定與測試資源的配置。攻擊需要目標，測試亦然。測試的目的在於找出軟件的問題，提供改進之參考。目標若不明，測試人員即不知如何着手。
測試目標的訂定，最重要的在於軟件通過的準則，亦即測試何時方可結束。常見的情形是：軟件開發的進度不斷落後，最後剩餘的時間僅有兩個星期，於是測試人員的目標就是把最後兩週用完，盡人事聽天命。究竟測試多完整，隱藏的多少錯誤，測試工作的生產力如何？皆一概不知。反正產品賣出去或上線後有的是時間改進。然而產品銷售後再改進，成本往往大幅增高，甚至原有開發人員離職他調，連亡羊補牢都倍感困難。經驗一再顯示，事前的測試除錯絕對比事後維護省時省錢，唯有賣不出去或不能用的軟件例外。
對於測試的要求可簡單區分爲二：一種是通過目標所訂之軟件品質；一種是在既定資源內達到最佳成效。前者要求山頭一定要攻下，不達目的絕不停止。譬如目標爲單位測試時間的錯誤發現率須低於某數字，若超過了就得延長測試。此種方式適用於品質要求較高的軟件。至於後者則是上市時間已宣佈，無法更改者，其目標着重於剷除最嚴重的錯誤。此種測試較着重測試的準備、經常對測試執行與除錯設定時限與數量要求，其中最容易遵循的準則即爲：重要功能永遠先測。這兩類測試的需求不同，足以影響到測試的計劃、測試的順序與關心的重點。讀者不可不察。
至於測試資源配置適當性，則是評估測試目標能否達成的重要參考指標。測試人員需要合理的測試資源，譬如要求總研發人力的20%以上。總時程的1/3以上。人力不足，測試流於形式，時程過短，找到錯誤也來不及除錯，均不可取。除了測試在研發的比重，也需注意測試工作本身在規畫管理、規格個案訂定、測試執行、迴歸測試、訓練準備工作的人力分配。人員的訓練與設備的安排尤其容易輕忽，需加以注意。不同階段測試的資源配置，也必須加以考量，如此可避免測試集中於功能測試，忽略系統測試。這些工作的適切安排，有助於協助測試工作時時都執行最重要，也最有效的測試。
測試執行與管理
測試工作執行在管理上，首先需使測試與開發人員瞭解輕重緩急。測試人員常常不考慮測試的效果，而只依照測試的方便性來進行測試。譬如軟件有十大模塊，每一模塊有50個測試個案，於是他從第一個模塊的第一個個案開始測，測完一整個模塊，再進行第二個模塊的測試，執行全部完成或無法進行爲止。事實上，測試應從重要且常用的項目測起。
開發人員的除錯，則往往從好改的改起。於是100個錯誤改了90個，系統主要的缺陷仍爲克服。測試管理人員需特別注意此事，確保測試工作的效率。
進行測試管理的好處在於隨時可掌握狀況，並因應需求及時調整測試策略。譬如測試一段時間後，發現某子系統的問題特別多，即可調整人力，增強該部份的測試。或是某些人的測試績效較差，則可調整工作之分配，以求整體效果。當然，這些數據的取得有賴相關信息的蒐集，包括數量與時間之信息。如果可行，可記錄不同測試工作耗用的人力時數，計算耗用成本，以便未來進行測試規劃時擁有更精確的參考數據。
進行相關資料的統計與分析，最好運用工具來幫忙，以節省人力並增進效果。如果市面已有的測試管理工具符合需求，也可徑行採用。測試結果的統計資料，不妨公佈在大家的眼前，使得測試成果可爲大家瞭解，亦能促進工作同仁求取更佳的成績。附圖所顯示爲一簡單的統計圖表，顯示每週的測試成果、除錯成果，與產品殘存的問題量，可協助主管決定測試終止及發行產品的時間。
測試結果分析與改進
當(階段)測試結束後，測試管理人員可以進行測試成果的分析。有關預定目標與實際執行結果的差異，可作爲下一版軟件測試檢討改進的依據。譬如預定開立的測試個案數是否達成目標，執行與通過數是否可接受？投入的測試甚至除錯人力是否足夠？均可視狀況計算依標準工作量，作爲未來執行測試工作之預估標準。經由分析軟件錯誤的生命週期，可以研究縮短的方法，例如加速除錯與重測週期，或在分析設計階段減少錯誤發生的機率，以縮短測試時程。
由測試結果可分析出不同測試的效益，與應改進之處。以下表爲例。單元測試耗用大部份的人力，可能使整合與系統測試不完全。再以發現的錯誤數觀之，整合測試發現一個錯誤的成本遠低於另兩項。由此可見在有限的人力時間下測試，單元測試做得太多，整合測試又太少。此意謂着對於單元測試所需耗用的人力資源過度樂觀，或是在測試工作的配置不盡理想，應予改進。
測試人力時數 測試人力分佈比率 錯誤個數 錯誤分佈比率 平均時數/錯誤數
單元測試 227.104 58.6% 49 39.51% 4.635
整合測試 87.212 23.3% 54 43.55% 1.615
系統測試 70.184 18.1% 21 16.94% 3.342
合計 384.5 100% 124 100% 3.2
除了以上的測試成效分析。如行有餘力時應再對錯誤發生的原因加以分析，力求從問題的根源加以解決。這包含測試工作的改進與開發工作的流程改進。以前者而言，可考慮對測試人員施以較充分的訓練，避免測試工作因準備不周浪費寶貴的人力與時間。測試標準程序的建立，也有助於測試工作效率的提升。至於後者，可由錯誤發生的原因研究預防之道。例如對需求變更未確實記載，導致設計錯誤的問題發生，或是軟件的設計未加充分的考慮再撰寫程序，導致設計不良造成的大量錯誤，均應加以預防，如此可望從根本解決軟件的問題。
結語
欲提升軟件品質與生產力，得先掌握現況。測試工作既是必要之惡，就需擬定最好的方法來面對。有關軟件測試方法論的書籍文章爲數固然不少，在應用上仍須因應自身的情形加以調整。品管大師戴明認爲：獲得好品質不能靠檢驗，而是來自改善工作流程。因此，測試工作只是一項起步。如何藉由測試工作，瞭解改善軟件品質與生產力之道，纔是我們追求的目標。願祝各位軟件品質的捍衛者，在工作崗位順利前進，爲測試工作贏得榮耀，更爲你們的成功產品喝采。