軟件測試設(shè)計屬于“近憂”；軟件測試件管理屬于“遠慮”。測試團隊?wèi)?yīng)同時做好這兩方面工作，以使測試工作更加高效。

　　針對某個特定的軟件項目而言，測試團隊?wèi)?yīng)該如何合理地統(tǒng)籌安排軟件測試工作？測試團隊在完成一定數(shù)量的軟件項目測試工作后又該如何快速提升下一軟件項目測試工作的水平？這兩個問題對于成立不久的軟件測試團隊而言是很棘手也是很現(xiàn)實的。

　　做好軟件測試設(shè)計，排除“近憂”

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

　　測試策略設(shè)計

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

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

　　測試方案設(shè)計

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

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

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

　　測試用例設(shè)計

　　測試用例設(shè)計是對測試方案實現(xiàn)技術(shù)部分更為細致描述，相關(guān)設(shè)計技術(shù)已經(jīng)相對成熟（見表1）。本文選取了幾個有代表性的方法進行介紹。

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

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

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

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

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

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

　　測試用例管理系統(tǒng)

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

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

　　配置管理

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

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

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

　　測試件的復(fù)用與遷移

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

　　針對某個特定的軟件項目而言，測試團隊?wèi)?yīng)該如何合理地統(tǒng)籌安排軟件測試工作？測試團隊在完成一定數(shù)量的軟件項目測試工作后又該如何快速提升下一軟件項目測試工作的水平？這兩個問題對于成立不久的軟件測試團隊而言是很棘手也是很現(xiàn)實的。

　　做好軟件測試設(shè)計，排除“近憂”

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

　　測試策略設(shè)計

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

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

　　測試方案設(shè)計

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

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

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

　　測試用例設(shè)計

　　測試用例設(shè)計是對測試方案實現(xiàn)技術(shù)部分更為細致描述，相關(guān)設(shè)計技術(shù)已經(jīng)相對成熟（見表1）。本文選取了幾個有代表性的方法進行介紹。

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

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

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

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

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

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

　　測試用例管理系統(tǒng)

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

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

　　配置管理

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

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

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

　　測試件的復(fù)用與遷移

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