軟件測試設計屬于“近憂”；軟件測試件管理屬于“遠慮”。測試團隊應同時做好這兩方面工作，以使測試工作更加高效。

　　針對某個特定的軟件項目而言，測試團隊應該如何合理地統籌安排軟件測試工作？測試團隊在完成一定數量的軟件項目測試工作后又該如何快速提升下一軟件項目測試工作的水平？這兩個問題對于成立不久的軟件測試團隊而言是很棘手也是很現實的。

　　做好軟件測試設計，排除“近憂”

　　過度測試會造成測試成本上升，而測試不夠又會造成項目中遺留某些重要缺陷。但針對于某個特定的軟件項目量身定做相應的軟件測試方案是需要足夠的技術能力和實戰經驗的。在軟件測試活動的生命周期中，測試設計實際上是對前面所做測試計劃進行進一步細化、具體化從而形成針對特定項目的測試策略、測試方案及測試用例的過程。

　　測試策略設計

　　測試策略要解決的問題是根據測試需求、資源配備及工程環境，因地制宜剪裁測試技術，形成測試工作的技術路線。對于一個小項目做大測試是得不償失的，同樣，對一個大項目做小測試也是不負責任的。通常，對于工作量小于5個人月的普通商用軟件，重點應該抓系統測試（包括功能測試、性能測試及GUI測試等）及驗收測試，而不宜鋪排開來，面面俱到。而對于一個工作量接近30個人月的中型商用軟件而言，一般應該認真完成需求驗證、設計驗證、單元測試、集成測試、系統測試及驗收測試，而不宜只關注系統測試。但這并不絕對，譬如，用戶希望軟件有好的人機交互界面，這時，就應該考慮采用快速原型生成工具來進行用戶界面設計的確認測試;又如用戶希望軟件有較好的健壯性，這時，就應該考慮進行相應的負載測試和可恢復性測試。

　　一個好的測試策略設計應能清楚地回答下列問題：是否在測試成本與測試預期效果之間達到了最佳平衡？是否在測試需求與測試活動安排之間達到了最佳平衡？策略設計形成的技術路線是否在工程實際與企業質量承諾之間達到了最佳平衡？策略設計形成的技術路線是否具有可行性？有無設計依據？

　　測試方案設計

　　測試方案是對測試策略設計形成的技術路線的進一步細化。如某一技術路線規定了某小型軟件項目測試工作要重點圍繞“功能測試與驗收測試”展開。那么測試方案設計階段就必須具體定義哪些功能需要被測試到，以及如何去測試，哪些部分需要做驗收，以及采用什么形式做。

　　測試方案的設計除了要明確定義各個測試活動的對象、執行人員、測試進度、放行標準等一系列屬性外，還要充分考慮到成本與技術可行性。一個好的測試方案總是遵循以下設計原則：測試成本與測試工作產生的效益處于最佳比值; 各具體測試活動描述清晰，目標明確，內容完備; 測試手段是可行的; 測試產生的結果是可以用于指導產品質量改進的。

　　在進行測試方案的具體設計時，常常也暴露出來一些難題和障礙。最常見的就是角色安排多，測試人員少。解決這一問題的根本途徑是招募測試人才，建設高效測試團隊。然而，遠水解不了近渴。那么，就需要考慮一下變通之策：外包和外協都是不錯的處理辦法。另外，建議適當考慮自動測試工具，某些工具的確能減少工作壓力。除了人手的問題，了解測試團隊各成員的專業技能也是很重要的，避免無人擔當相應角色。除此之外，設計人員還應多多參考軟件開發管理類文檔，在測試的時間進度安排上與開發保持同步，如果開發進度有變動，應及時調整相應的測試進度安排。

　　測試用例設計

　　測試用例設計是對測試方案實現技術部分更為細致描述，相關設計技術已經相對成熟（見表1）。本文選取了幾個有代表性的方法進行介紹。

　　其中，黑盒測試中常用的等價類劃分方法是先把程序的輸入域劃分成若干區間，然后從每個區間中選取少數代表性數據當作測試用例（由于數量太大，窮舉測試一般情況下不可能實現）。在使用等價類劃分方法時，通常會涉及到兩種等價類：有效等價類和無效等價類。顧名思義，有效等價類就是對程序的規格說明是有意義的合理的輸入數據集; 無效等價類就是對程序規格說明書不合理或無效的輸入數據集。我們在設計測試用例時，要兼顧這兩種情況。同時要注意一個測試用例只能覆蓋一個無效等價類。這樣便于錯誤定位，防止一個錯誤表征掩蓋了另一個錯誤。例如，程序的規格說明中規定了“……每類科技圖書10至50冊，……”，若一個測試用例為“小說5冊”，在測試中很可能只檢測出書的類型錯誤（小說不是科技類圖書），而忽略了書的冊數錯誤（5不在10至50之間）。

　　黑盒測試中另一個常用的測試用例設計方法是邊界值分析，它是一種補充等價類劃分的測試用例設計技術，它選擇一組測試用例檢查邊界值是否符合相應規格說明。因為輸入域的邊界比中間更加容易發生錯誤，所以引進了邊界值分析方法往往能發現更多的軟件缺陷和錯誤。

　　而不管黑盒測試多么全面，它都可能忽略類似于邏輯性錯誤、潛在破壞性執行流程、冗余程序代碼乃至于簡單打字錯誤等，而白盒測試則可以進一步發現它們，查找出代碼層次的錯誤和缺陷。白盒測試用例設計包括的門類也相當繁多，這里限于篇幅不再贅述。

　　做好軟件測試件管理，消除“遠慮”

　　測試件泛指一切手工測試和自動測試活動中必須受控或值得納入測試團隊知識庫的所有輸入和輸出數據，包含團隊自主開發的測試自動化工具。如何有效地管理好測試件，是影響測試團隊效率與整體水平的重要因素之一。在待測項目規模小、功能點少的情況下，測試工作或許能正常進行。但如果測試團隊要同時測試多個項目，各項目規模都相對較大，涉及的測試人員較多時，測試工作的效率可能會大為降低。除此之外，測試件管理對于團隊的整體水平提高亦具有不可估量的長遠意義，將有代表的測試用例、測試方案等積累起來，可避免團隊長時間在一個較低水平上徘徊。

　　在表2所示測試件中，除了測試用例自動化管理、測試缺陷（報告）跟蹤管理已經有較好的自動化管理工具外，其他測試件目前尚未發現有對應的專用管理工具，筆者建議采用配置管理工具（如CVS）。（由于測試缺陷跟蹤管理在上期已有詳細的論述，這部分內容本文從略）

　　測試用例管理系統

　　測試用例設計人員需要了解目前已經設計了哪些模塊或部件的測試用例，還需要完成哪些設計工作，而測試執行人員需要被明確地告知今天要測試什么，需要執行多少個測試用例。基于這些需求，人們開發了測試用例管理系統，其目的是為了對項目的測試用例的設計、執行及執行結果進行統一管理，提高測試活動的效率。

　　測試用例管理系統市面上有很多（如微創測試用例管理系統等）。典型的工作流程如下：設置基本參數→登錄系統→選擇項目→新增模塊節點→新增需求→新增測試用例→審核測試用例→新增測試組→新增測試計劃→執行測試→測試結果查看→統計分析。該流程涉及到的角色包括測試組長、測試設計人員、測試執行人員、系統管理員、測試評審員等。其中，測試設計人員擁有寫入測試用例的權限，測試執行人員負責測試用例的執行，二者是測試用例管理系統的主體。

　　配置管理

　　除測試用例、測試缺陷報告之外的測試件均可以使用配置管理的方式進行管理。這里有兩個可選擇的配置管理方式。一是將測試件的邏輯集合（稱為測試件組）作為配置項保存在配置庫中。每個測試件組有自己的版本信息，而組成測試件組的各個測試件沒有自己的版本信息。測試人員可以根據需要隨時從配置庫中取出任何版本的測試件組（包含已修改的和未修改的測試件）。由于其操作簡單，且出現版本錯誤的可能性較小，所以適用于配置管理體系不成熟的情況。

　　另一種方式是把單個的測試件作為配置項，每個測試件有自己的版本信息。這種方式需要在測試件組或多個測試件組上進行基線化。通過基線化操作，方便測試人員能取出對應于不同版本系統的所有測試件。這種方式如果使用不當，可能導致使用的測試件版本錯誤，所以其適用于有較完善的配置管理體系的情況。

不管采用哪種方式，都要注意控制測試件的更新，但要避免兩個或更多的人同時試圖修改同一配置項。關于測試件的存放，需要注意的是，必須規定好各測試件在配置庫中的物理位置。

　　測試件的復用與遷移

　　測試件管理工作的另一個更為重要的價值就在于測試件可以被復用，測試件蘊含的經驗和知識可以被后來者獲取并遷移到當前項目中。測試團隊的整體水平的提高很大程度上在于團隊內部知識傳遞的充分有效。由于測試件管理庫記載了各個項目采用的測試技術以及獲得的經驗教訓，這對于團隊中的新手而言，是很寶貴的資源，即便是對于從業多年的老手來說，也應該多多參考這個知識庫，因為測試件的復用能有效規避重復勞動。另外，建議測試團隊負責人通過多種方式，讓團隊成員多多了解、學習和利用測試件庫，鼓勵團隊成員對測試件提出改進意見。

　　針對某個特定的軟件項目而言，測試團隊應該如何合理地統籌安排軟件測試工作？測試團隊在完成一定數量的軟件項目測試工作后又該如何快速提升下一軟件項目測試工作的水平？這兩個問題對于成立不久的軟件測試團隊而言是很棘手也是很現實的。

　　做好軟件測試設計，排除“近憂”

過度測試會造成測試成本上升，而測試不夠又會造成項目中遺留某些重要缺陷。但針對于某個特定的軟件項目量身定做相應的軟件測試方案是需要足夠的技術能力和實戰經驗的。在軟件測試活動的生命周期中，測試設計實際上是對前面所做測試計劃進行進一步細化、具體化從而形成針對特定項目的測試策略、測試方案及測試用例的過程。

　　測試策略設計

　　測試策略要解決的問題是根據測試需求、資源配備及工程環境，因地制宜剪裁測試技術，形成測試工作的技術路線。對于一個小項目做大測試是得不償失的，同樣，對一個大項目做小測試也是不負責任的。通常，對于工作量小于5個人月的普通商用軟件，重點應該抓系統測試（包括功能測試、性能測試及GUI測試等）及驗收測試，而不宜鋪排開來，面面俱到。而對于一個工作量接近30個人月的中型商用軟件而言，一般應該認真完成需求驗證、設計驗證、單元測試、集成測試、系統測試及驗收測試，而不宜只關注系統測試。但這并不絕對，譬如，用戶希望軟件有好的人機交互界面，這時，就應該考慮采用快速原型生成工具來進行用戶界面設計的確認測試;又如用戶希望軟件有較好的健壯性，這時，就應該考慮進行相應的負載測試和可恢復性測試。

　　一個好的測試策略設計應能清楚地回答下列問題：是否在測試成本與測試預期效果之間達到了最佳平衡？是否在測試需求與測試活動安排之間達到了最佳平衡？策略設計形成的技術路線是否在工程實際與企業質量承諾之間達到了最佳平衡？策略設計形成的技術路線是否具有可行性？有無設計依據？

　　測試方案設計

　　測試方案是對測試策略設計形成的技術路線的進一步細化。如某一技術路線規定了某小型軟件項目測試工作要重點圍繞“功能測試與驗收測試”展開。那么測試方案設計階段就必須具體定義哪些功能需要被測試到，以及如何去測試，哪些部分需要做驗收，以及采用什么形式做。

　　測試方案的設計除了要明確定義各個測試活動的對象、執行人員、測試進度、放行標準等一系列屬性外，還要充分考慮到成本與技術可行性。一個好的測試方案總是遵循以下設計原則：測試成本與測試工作產生的效益處于最佳比值; 各具體測試活動描述清晰，目標明確，內容完備; 測試手段是可行的; 測試產生的結果是可以用于指導產品質量改進的。

　　在進行測試方案的具體設計時，常常也暴露出來一些難題和障礙。最常見的就是角色安排多，測試人員少。解決這一問題的根本途徑是招募測試人才，建設高效測試團隊。然而，遠水解不了近渴。那么，就需要考慮一下變通之策：外包和外協都是不錯的處理辦法。另外，建議適當考慮自動測試工具，某些工具的確能減少工作壓力。除了人手的問題，了解測試團隊各成員的專業技能也是很重要的，避免無人擔當相應角色。除此之外，設計人員還應多多參考軟件開發管理類文檔，在測試的時間進度安排上與開發保持同步，如果開發進度有變動，應及時調整相應的測試進度安排。

　　測試用例設計

　　測試用例設計是對測試方案實現技術部分更為細致描述，相關設計技術已經相對成熟（見表1）。本文選取了幾個有代表性的方法進行介紹。

　　其中，黑盒測試中常用的等價類劃分方法是先把程序的輸入域劃分成若干區間，然后從每個區間中選取少數代表性數據當作測試用例（由于數量太大，窮舉測試一般情況下不可能實現）。在使用等價類劃分方法時，通常會涉及到兩種等價類：有效等價類和無效等價類。顧名思義，有效等價類就是對程序的規格說明是有意義的合理的輸入數據集; 無效等價類就是對程序規格說明書不合理或無效的輸入數據集。我們在設計測試用例時，要兼顧這兩種情況。同時要注意一個測試用例只能覆蓋一個無效等價類。這樣便于錯誤定位，防止一個錯誤表征掩蓋了另一個錯誤。例如，程序的規格說明中規定了“……每類科技圖書10至50冊，……”，若一個測試用例為“小說5冊”，在測試中很可能只檢測出書的類型錯誤（小說不是科技類圖書），而忽略了書的冊數錯誤（5不在10至50之間）。

　　黑盒測試中另一個常用的測試用例設計方法是邊界值分析，它是一種補充等價類劃分的測試用例設計技術，它選擇一組測試用例檢查邊界值是否符合相應規格說明。因為輸入域的邊界比中間更加容易發生錯誤，所以引進了邊界值分析方法往往能發現更多的軟件缺陷和錯誤。

　　而不管黑盒測試多么全面，它都可能忽略類似于邏輯性錯誤、潛在破壞性執行流程、冗余程序代碼乃至于簡單打字錯誤等，而白盒測試則可以進一步發現它們，查找出代碼層次的錯誤和缺陷。白盒測試用例設計包括的門類也相當繁多，這里限于篇幅不再贅述。

　　做好軟件測試件管理，消除“遠慮”

　　測試件泛指一切手工測試和自動測試活動中必須受控或值得納入測試團隊知識庫的所有輸入和輸出數據，包含團隊自主開發的測試自動化工具。如何有效地管理好測試件，是影響測試團隊效率與整體水平的重要因素之一。在待測項目規模小、功能點少的情況下，測試工作或許能正常進行。但如果測試團隊要同時測試多個項目，各項目規模都相對較大，涉及的測試人員較多時，測試工作的效率可能會大為降低。除此之外，測試件管理對于團隊的整體水平提高亦具有不可估量的長遠意義，將有代表的測試用例、測試方案等積累起來，可避免團隊長時間在一個較低水平上徘徊。

　　在表2所示測試件中，除了測試用例自動化管理、測試缺陷（報告）跟蹤管理已經有較好的自動化管理工具外，其他測試件目前尚未發現有對應的專用管理工具，筆者建議采用配置管理工具（如CVS）。（由于測試缺陷跟蹤管理在上期已有詳細的論述，這部分內容本文從略）

　　測試用例管理系統

　　測試用例設計人員需要了解目前已經設計了哪些模塊或部件的測試用例，還需要完成哪些設計工作，而測試執行人員需要被明確地告知今天要測試什么，需要執行多少個測試用例。基于這些需求，人們開發了測試用例管理系統，其目的是為了對項目的測試用例的設計、執行及執行結果進行統一管理，提高測試活動的效率。

　　測試用例管理系統市面上有很多（如微創測試用例管理系統等）。典型的工作流程如下：設置基本參數→登錄系統→選擇項目→新增模塊節點→新增需求→新增測試用例→審核測試用例→新增測試組→新增測試計劃→執行測試→測試結果查看→統計分析。該流程涉及到的角色包括測試組長、測試設計人員、測試執行人員、系統管理員、測試評審員等。其中，測試設計人員擁有寫入測試用例的權限，測試執行人員負責測試用例的執行，二者是測試用例管理系統的主體。

　　配置管理

　　除測試用例、測試缺陷報告之外的測試件均可以使用配置管理的方式進行管理。這里有兩個可選擇的配置管理方式。一是將測試件的邏輯集合（稱為測試件組）作為配置項保存在配置庫中。每個測試件組有自己的版本信息，而組成測試件組的各個測試件沒有自己的版本信息。測試人員可以根據需要隨時從配置庫中取出任何版本的測試件組（包含已修改的和未修改的測試件）。由于其操作簡單，且出現版本錯誤的可能性較小，所以適用于配置管理體系不成熟的情況。

　　另一種方式是把單個的測試件作為配置項，每個測試件有自己的版本信息。這種方式需要在測試件組或多個測試件組上進行基線化。通過基線化操作，方便測試人員能取出對應于不同版本系統的所有測試件。這種方式如果使用不當，可能導致使用的測試件版本錯誤，所以其適用于有較完善的配置管理體系的情況。

　　不管采用哪種方式，都要注意控制測試件的更新，但要避免兩個或更多的人同時試圖修改同一配置項。關于測試件的存放，需要注意的是，必須規定好各測試件在配置庫中的物理位置。

　　測試件的復用與遷移

　　測試件管理工作的另一個更為重要的價值就在于測試件可以被復用，測試件蘊含的經驗和知識可以被后來者獲取并遷移到當前項目中。測試團隊的整體水平的提高很大程度上在于團隊內部知識傳遞的充分有效。由于測試件管理庫記載了各個項目采用的測試技術以及獲得的經驗教訓，這對于團隊中的新手而言，是很寶貴的資源，即便是對于從業多年的老手來說，也應該多多參考這個知識庫，因為測試件的復用能有效規避重復勞動。另外，建議測試團隊負責人通過多種方式，讓團隊成員多多了解、學習和利用測試件庫，鼓勵團隊成員對測試件提出改進意見。