如何解決軟件測試的近憂和遠慮[3] 軟件測試
測試件的復用與遷移
測試件管理工作的另一個更為重要的價值就在于測試件可以被復用，測試件蘊含的經驗和知識可以被后來者獲取并遷移到當前項目中。測試團隊的整體水平的提高很大程度上在于團隊內部知識傳遞的充分有效。由于測試件管理庫記載了各個項目采用的測試技術以及獲得的經驗教訓，這對于團隊中的新手而言，是很寶貴的資源，即便是對于從業多年的老手來說，也應該多多參考這個知識庫，因為測試件的復用能有效規避重復勞動。另外，建議測試團隊負責人通過多種方式，讓團隊成員多多了解、學習和利用測試件庫，鼓勵團隊成員對測試件提出改進意見。
針對某個特定的軟件項目而言，測試團隊應該如何合理地統籌安排軟件測試工作?測試團隊在完成一定數量的軟件項目測試工作后又該如何快速提升下一軟件項目測試工作的水平?這兩個問題對于成立不久的軟件測試團隊而言是很棘手也是很現實的。
做好軟件測試設計，排除“近憂”
[NextPage]
過度測試會造成測試成本上升，而測試不夠又會造成項目中遺留某些重要缺陷。但針對于某個特定的軟件項目量身定做相應的軟件測試方案是需要足夠的技術能力和實戰經驗的。在軟件測試活動的生命周期中，測試設計實際上是對前面所做測試計劃進行進一步細化、具體化從而形成針對特定項目的測試策略、測試方案及測試用例的過程。
測試策略設計
測試策略要解決的問題是根據測試需求、資源配備及工程環境，因地制宜剪裁測試技術，形成測試工作的技術路線。對于一個小項目做大測試是得不償失的，同樣，對一個大項目做小測試也是不負責任的。通常，對于工作量小于5個人月的普通商用軟件，重點應該抓系統測試(包括功能測試、性能測試及GUI測試等)及驗收測試，而不宜鋪排開來，面面俱到。而對于一個工作量接近30個人月的中型商用軟件而言，一般應該認真完成需求驗證、設計驗證、單元測試、集成測試、系統測試及驗收測試，而不宜只關注系統測試。但這并不絕對，譬如，用戶希望軟件有好的人機交互界面，這時，就應該考慮采用快速原型生成工具來進行用戶界面設計的確認測試;又如用戶希望軟件有較好的健壯性，這時，就應該考慮進行相應的負載測試和可恢復性測試。
一個好的測試策略設計應能清楚地回答下列問題：是否在測試成本與測試預期效果之間達到了最佳平衡?是否在測試需求與測試活動安排之間達到了最佳平衡?策略設計形成的技術路線是否在工程實際與企業質量承諾之間達到了最佳平衡?策略設計形成的技術路線是否具有可行性?有無設計依據?
測試方案設計
測試方案是對測試策略設計形成的技術路線的進一步細化。如某一技術路線規定了某小型軟件項目測試工作要重點圍繞“功能測試與驗收測試”展開。那么測試方案設計階段就必須具體定義哪些功能需要被測試到，以及如何去測試，哪些部分需要做驗收，以及采用什么形式做。
測試方案的設計除了要明確定義各個測試活動的對象、執行人員、測試進度、放行標準等一系列屬性外，還要充分考慮到成本與技術可行性。一個好的測試方案總是遵循以下設計原則：測試成本與測試工作產生的效益處于最佳比值; 各具體測試活動描述清晰，目標明確，內容完備; 測試手段是可行的; 測試產生的結果是可以用于指導產品質量改進的。
在進行測試方案的具體設計時，常常也暴露出來一些難題和障礙。最常見的就是角色安排多，測試人員少。解決這一問題的根本途徑是招募測試人才，建設高效測試團隊。然而，遠水解不了近渴。那么，就需要考慮一下變通之策：外包和外協都是不錯的處理辦法。另外，建議適當考慮自動測試工具，某些工具的確能減少工作壓力。除了人手的問題，了解測試團隊各成員的專業技能也是很重要的，避免無人擔當相應角色。除此之外，設計人員還應多多參考軟件開發管理類文檔，在測試的時間進度安排上與開發保持同步，如果開發進度有變動，應及時調整相應的測試進度安排。
測試用例設計
測試用例設計是對測試方案實現技術部分更為細致描述，相關設計技術已經相對成熟(見表1)。本文選取了幾個有代表性的方法進行介紹。
其中，黑盒測試中常用的等價類劃分方法是先把程序的輸入域劃分成若干區間，然后從每個區間中選取少數代表性數據當作測試用例(由于數量太大，窮舉測試一般情況下不可能實現)。在使用等價類劃分方法時，通常會涉及到兩種等價類：有效等價類和無效等價類。顧名思義，有效等價類就是對程序的規格說明是有意義的合理的輸入數據集; 無效等價類就是對程序規格說明書不合理或無效的輸入數據集。我們在設計測試用例時，要兼顧這兩種情況。同時要注意一個測試用例只能覆蓋一個無效等價類。這樣便于錯誤定位，防止一個錯誤表征掩蓋了另一個錯誤。例如，程序的規格說明中規定了“……每類科技圖書10至50冊，……”，若一個測試用例為“小說5冊”，在測試中很可能只檢測出書的類型錯誤(小說不是科技類圖書)，而忽略了書的冊數錯誤(5不在10至50之間)。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
