然而，針對于某個特定的軟件項目而言，測試團隊應該如何合理地統籌安排軟件測試工作？測試團隊在完成一定數目軟件項目的測試工作后又該如何快速提升下一軟件項目測試工作的水平？這兩個問題對于剛成立或成立不久的軟件測試團隊而言是很棘手也是很現實的。前者關乎軟件測試設計，屬于“近憂”；后者關于軟件測試管理，屬于“遠慮”。本文的寫作目的，正是試圖為這些測試團隊的負責人“排憂解難”，提供決策參考性意見。
1、 做好軟件測試設計，排除“近憂”
正如上文所言，測試團隊建立伊始，就會碰到這么一個問題：“應該如何合理地統籌安排軟件測試工作”？軟件測試技術林林總總，過度測試會造成項目的測試成本上升，而測試不夠又會造成項目中遺留某些重要的缺陷。一些企業的測試主管曾私下向我咨詢過此類問題，我覺得這可能帶有一定的普遍性。的確，針對于某個特定的軟件項目量身定做相應的軟件測試方案是需要足夠的技術能力和實戰經驗的。一些資歷尚淺的測試團隊需要在這方面獲得幫助，以解燃眉之急。
要回答這個問題，我們必須先從“軟件測試活動的生命周期”開始談起。一個典型的軟件測試活動的生命周期大致可以分為“測試計劃 à 測試設計 à 測試執行 à 測試總結與改進”四個環節[注：也有些技術文章在測試設計環節后增加了一個環節：測試環境搭建，筆者認為這也是一種可取的劃分方法]。其中，測試計劃環節要對具體的測試活動給出宏觀的指導與預算，具體內容包括：1.定義開發團隊和用戶對于測試工作的需求項；2.定義測試可能會經歷的階段、測試類型、測試大致會采用的技術及工具、測試通過的標準等等；3.確定測試協作需求。如需要臨時聘用的專家、測試進度與開發進度協調、測試活動與用戶存在接口關系的計劃安排等等；4.粗略估計測試需要的工作量�？筛鶕愴椖康臄祿M行模擬逼近，也可以根據某個算法，從項目規模導出；5.確定測試活動需要配備的資源（如人、場地、軟硬件等等）。測試設計環節則是在“測試計劃”環節的基礎上進一步細化和分析，從而制定出針對于該項目及每個測試活動的測試策略、測試方案及測試用例的過程。通常，這一部分工作對測試人員提出的素質要求是相當高的，也是最不易把握的部分，下文將有詳細的論述。測試執行是按照測試設計產生的輸出，執行相應的測試活動，查找并報告相應錯誤和缺陷的過程，當然，也包括某些不使用測試用例的開放式測試，如GUI測試等等。測試總結與改進則是完成以上三個環節的基礎上收集各環節產生的相關測試件（如測試文檔、測試腳本、測試工具及測試工作經驗教訓等等），納入測試團隊知識庫，以便于測試團隊更好地進行測試件管理，從而推動測試工作的不斷優化與改進。
上面對測試活動的生命周期做一個簡要的介紹。需要提醒注意的是某些概念在特定的領域可能含義稍有差異。如在某些大型項目的測試活動中，測試計劃環節產生的文件是《測試大綱》以及高層《軟件測試計劃》，而在測試設計環節產生的文件是針對于某個系統、某個模塊的底層《測試計劃》、測試方案等等。這些差異并不影響本文對測試設計及測試件管理的討論。
有了前面的鋪墊，我們就可以開始討論軟件測試設計這個大難題了。測試設計實際上是對高層測試計劃（含測試大綱）進行進一步細化、具體化從而形成針對于特定項目的測試策略、測試方案及測試用例的過程。
1.1 測試策略設計
測試策略要解決的問題是根據測試需求、資源配備及工程環境，因地制宜剪裁測試技術，形成測試工作的技術路線。我們知道，對于一個小項目做大測試是得不償失的，同樣，對一個大項目做小測試也是不負責任的�；蛘吒鼘I一點，對于工作量小于5個人月的普通商用軟件，重點應該抓系統測試（包括功能測試、性能測試及GUI測試等）及驗收測試，而不宜鋪排開來，面面俱到（如設計驗證與確認、代碼評審及單元測試可以視情況壓縮）。而對于一個工作量接近30個人月的中型商用軟件而言，一般應該認真完成需求驗證、設計驗證、單元測試、集成測試、系統測試及驗收測試，而不宜只關注系統測試，忽略其它部分。以上討論是以人月數為參照系的，這并不絕對。譬如，用戶需求就常常是更重要的考慮因素，如用戶希望軟件有好的人機交互界面，這時，就應該考慮采用快速原型生成工具來進行用戶界面設計的確認測試，又如用戶希望軟件有較好的健壯性，這時，就應該考慮進行相應的負載測試和可恢復性測試。除此之外，資源配備也是很重要的考慮因素。一個團隊成員寥寥無幾的測試團隊，要承擔一個中型項目的軟件測試工作，這幾乎是不可能的。然而，個別企業的高層出于成本考慮或技術上的不敏感可能會分派出此類不可實現的任務。這時，消極應付是下策，要充分利用測試外包、測試協作（如從其他部門借調人員）等多種形式，把優先級相對較低的部分甩出去，留下最核心的、優先級最高的部分，組織測試人員進行專業的測試。
測試策略設計本質上是一門藝術，因為它是測試經驗積累與特定項目工程實際交互作用下的“厚積薄發”，是多個因子（測試需求、測試資源配置、項目規模、類似項目測試策略參考等）綜合作用的結果。要做好測試策略的設計工作，是非常不容易的事情。一個好的測試策略設計應能清楚地回答下列問題：（1）是否在測試成本與測試預期效果之間達到了最佳平衡？（2）是否在測試需求與測試活動安排之間達到了最佳平衡?（3）策略設計形成的技術路線是否在工程實際與企業質量承諾之間達到了最佳平衡？（4）策略設計形成的技術路線是否具有可行性？有無設計依據？等等。對于資歷較淺的測試團隊而言，可能在團隊建設早期尚難以達不到這種境界。不過也無需過于擔心和憂慮，隨著不同項目測試經驗的積累，以及測試團隊測試件管理工作的深入，很多障礙會逐步消除，從而最終達到“胸中有丘壑”的境界。
1.2 測試方案設計
經過測試策略設計，形成了針對特定項目的測試工作技術路線，下一步測試團隊就進到了測試方案的設計階段。測試方案是對技術路線的進一步細化。如某一技術路線規定了某小型軟件項目測試工作要重點圍繞 “功能測試與驗收測試”展開。那么測試方案設計階段就必須具體定義哪些功能需要被測試到以及如何去測試，哪些部分（軟件？用戶手冊？操作指南）需要做驗收以及采用什么形式去做驗收測試（評審會？Beta測試?還是現場測試?等等）。
測試方案的設計要除了要明確定義各個測試活動的對象、執行人員、測試進度、放行標準等一系列屬性外，還要充分考慮到成本與技術可行性。一個好的測試方案總是遵循著以下設計原則：(1) 測試成本與測試工作產生的效益處于最佳比值；（2）各具體測試活動描述清晰，目標明確，內容完備；（3）測試手段是可行的；（4）測試產生的結果是可以用于指導產品質量改進的。筆者注意到一些企業對于第（3）點存在認識上的誤區，盲目購置的一批自動化測試工具，卻無人懂操作，或者根本就不適合自己的開發環境。這些問題在測試方案設計過程中應該努力避免的。
在進行測試方案的具體設計時，常常也暴露出來一些難題和障礙。最常見的就是角色安排多，測試人員少。解決這一問題的根本途徑是招募測試人才，建設高效測試團隊。然而，遠水解不了近渴。如果你的測試團隊遭遇到此類尷尬，那么，你就需要考慮一下變通之策：前面提到的外包和外協都是不錯的處理辦法。另外，建議你適當考慮自動測試工具，某些工具的確能減少你的工作壓力（如自動集成工具能實現每日建構、壓力測試工具能緩解你編寫模擬并發程序的壓力）。除了人手的問題，了解你所在的測試團隊各成員的專業技能也是很重要的。有些項目測試方案設計得很好，但由于缺乏相應素質的測試團隊成員擔當測試方案中的相應角色，測試方案只能無限期擱淺，結果不了了之。除此之外，測試方案設計人員還應多多參考軟件開發管理類文檔，在測試的時間進度安排上與開發保持同步，如果開發進度有變動，應及時調整相應的測試進度安排。
1.3 測試用例設計
測試用例設計是對測試方案實現技術部分更為細致描述，相關設計技術已經相對成熟[注：目前測試用例設計的某些分支仍是研究熱點]。市面上，關于測試用例的理論著作也是琳瑯滿目。下表列出了各類測試用例設計技術，在本文中筆者不打算一一介紹，而是根據測試實踐和個人取向，選出了幾個有代表性的方法，供讀者參考。有興趣的讀者，可以進一步查閱論述更細致一些的書籍。
|
MILY: 宋體">項目與類別 |
黑盒測試（功能性） |
白盒測試（結構性） |
其他 |
|
共同點 |
參考單元接口和功能描述規格文檔，不需了解被測單元的內部結構； |
參考詳細設計規格文檔，對照代碼，測試被測單元內部如何工作的； |
強調個人經驗，采用猜測或選測選擇特殊值的方法。 |
|
具體類別 |
軟件設計導出的測試 等價類劃分 邊界值分析 判定表驅動測試 因果圖 基于狀態的測試 …… |
路徑測試 控制結構測試 邏輯覆蓋 程序插裝 …… |
錯誤猜測 特殊值測試 |
其中，黑盒測試中常用的等價類劃分方法用例設計思想如下：
先把程序的輸入域劃分成若干區間，然后從每個區間中選取少數代表性數據當作測試用例。由于數量太大，窮舉測試一般情況下不可能實現，因此我們往往僅從大量可能的數據中選取一部分有代表性作為測試用例。在使用等價類劃分方法時，通常會涉及到兩種等價類：有效等價類和無效等價類。顧名思義，有效等價類就是對程序的規格說明是有意義的合理的輸入數據集；無效等價類就是對程序規格說明書不合理或無效的輸入數據集。我們在設計測試用例時，要兼顧這兩種情況。同時要注意一個測試用例只能覆蓋一個無效等價類。這樣便于錯誤定位，防止一個錯誤表征掩蓋了另一個錯誤。例如，程序的規格說明中規定了“……每類科技圖書10至50冊，……”，若一個測試用例為“小說5冊”，在測試中很可能只檢測出書的類型錯誤（小說不是科技類圖書），而忽略了書的冊數錯誤（5不在10至50之間）。
黑盒測試中另一個常用的測試用例設計方法是邊界值分析。它的思想如下：
邊界值分析是一種補充等價類劃分的測試用例設計技術，它選擇一組測試用例檢查邊界值是否符合相應規格說明。因為輸入域的邊界比中間更加容易發生錯誤，所以我們引進了邊界值分析方法往往能發現更多的軟件缺陷和錯誤。
使用邊界值分析的步驟為：選擇等價類的邊界值－>從輸入域導出測試用例。
【例子】a是實數，在10到100之間，請使用邊界值分析的方法設計測試數據。
測試數據為：9.9、10.1、20、99.9、100.1。
不管黑盒測試多么全面，它都可能忽略類似于邏輯性錯誤、潛在破壞性執行流程、冗余程序代碼乃至于簡單打字錯誤等，而白盒測試則可以進一步發現它們，查找出代碼層次的錯誤和缺陷。白盒測試用例設計包括的門類相當繁多，這里筆者僅介紹路徑測試方法。
在設計路徑相關測試用例前，應首先分析程序的內在邏輯結構：查找程序的執行入口，然后跟蹤程序體中經歷的各個分支語句及判斷語句，直到程序的出口。然后針對于每個分支及判斷語句，均設置一個不同情況的測試用例，并向下依序遍歷遞歸，生成更細的子用例，直至程序結束或抵達出口。細心的讀者可能會發現，這種方法實際上是程序體中分支與判斷語句各種可能情況的排列與組合。對于小的程序模塊而言，這是可行的，然而，對于較為復雜的程序模塊（尤其是對面向對象語言中頻繁使用的異常與消息捕獲時機而言）這種方法收效甚微。因此從該方法衍生出了很多變種，如功能點覆蓋、語句覆蓋等方法。這些方法對于設計白盒測試用例，均有較好的參考價值。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
