@import url(http://www.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

　如果將整個測試體系看成一個國家的話，那么測試分析與設計的過程就是立法的過程，而最終產出的測試方案/點/用例就是一國之法律，每一個測試公民都應該在測試過程中按照這些法律來開展工作。既然是立法，那么就應該從立法動議開始考慮

　　一、分析測試需求

　　正如在立法的時候要向各人大機構收集立法建議一樣，前期需要對于測試設計進行需求的收集和分析。測試需求的主要來自于開發設計類需求、用戶應用類需求和測試經驗類需求三方面。

　　開發設計類需求。

　　主要包括產品包需求、設計需求、設計規格、產品的軟硬件架構等等。事實上，開發設計類需求僅僅是客戶需求在開發層面上的一個映像，并非客戶需求的本像，因此在收集到這些需求的同時，不僅要關心開發設計類需求文檔本身，更應該關注其隱藏的客戶實際需求，將其分析透徹，保證測試設計是貼近客戶而不是貼近開發，體現端到端的測試設計理念。

　　比如用戶需要做一個煙囪，但開發人員把圖紙拿反了，設計成了挖口井。如果測試設計貼近開發的話，那是絕對發現不了這個巨大的錯誤；如果直接看到的是用戶的需求，就能很容易就能找到這其中的陰差陽錯。當然，這僅是一個例子，但是在現實中，開發出來的特性不能滿足用戶需求而被迫返工的事實是存在的，所以在建立測試之法的時候，我們必須要求收集到的動議是最原始需求的反映。

　　用戶應用類需求

　　這主要包括一些重要的用戶實際組網等等，這些都是直接來源于用戶的內容，所以可以直接納入到我們的測試設計中來。

　　經驗類需求

　　在測試立法的過程中需要將以往的經驗固化到文檔上形成固定的典型組網、典型應用、典型場景等等。

　　值得注意的是，經驗并不是因循守舊，而應該根據當前技術的發展推陳出新，不斷更新再不斷固化。比如，早期大家對于STP的理解還停留在STP/RSTP，當時的組網不能滿足后續MSTP測試的需求，這就需要在原有組網的基礎上設計出新的組網，形成新的經驗。

　　對這三類測試需求分析清楚了，產品“需要測試什么”基本就非常清晰了。接下來，則要根據需求分析分門別類地進行詳細設計，也就是要解決“如何測試”的問題，啟動真正的設計立法工作。

　　二、設計測試方案/測試點/測試用例

　　經過前期的測試需求收集和分析，我們會根據測試對象和范圍的不同，把測試設計工作分成三類：特性測試設計、組合測試設計、應用測試設計。特性測試設計主要是針對單個特性進行的設計；組合測試設計主要是將多個相關特性組合起來進行的設計；應用測試設計是根據用戶應用而來的專項設計。需要指出的是，實際上組合測試設計和應用測試設計很類似，后者是針對特定用戶環境的組合測試設計，也就是說應用測試設計是更加貼近用戶實際應用的組合測試設計，無需根據自己的經驗再去優化組網，最好按照某用戶環境進行1：1的設計。

　　無論測試設計工作是哪一類，最終體現到實際操作中的內容就是測試方案、測試點、測試用例，即測試的規則。

　　測試方案

　　測試方案是對測試活動的總體分析和規劃，除了要進行測試對象分析以外，每一個測試方案中都應該包括網絡拓撲、網絡配置、流量模型。

　　特性測試方案是最基礎的一類，主要用于描述某個單一特性的測試方法和過程。由于特性測試方案主要用于產品功能尚未穩定的測試活動，覆蓋產品開發早期階段，那么勢必、存在實際產品物料缺乏的問題，所以在設計特性測試方案時，一定要采用盡可能簡單的網絡拓撲，避免設計過于復雜；相應的，產品開發早期版本仍然處于功能驗證階段，所以特性測試方案的網絡配置應該以被測特性為核心進行配置，避免過多過復雜組合；而流量模型應該采用輕載連續流量比較合適。

　組合/應用測試方案一般用于產品相對穩定的階段，根據組合/應用的需要，可以按需設計網絡拓撲和網絡配置。有一點需要指出的是，在組合測試方案中一般都愿意采用重載持續流量模型，而在應用類測試方案設計時，需要驗證用戶組網，所以流量模型也需要考慮符合用戶的實際情況，因為重載持續流量模型并不是在所有的用戶組網中都能奏效的，有時候在某些特定的用戶分布式網絡中，輕載疊加突發流量模型也會出現問題。

　　測試點/用例

　　測試方案只是對于需要測試的對象進行了整體的分析和分解，接下來則 需要對分析和分解出來的內容進行歸納和整理，這樣就形成了測試點。測試點就是測試設計的綱，它是整個設計的靈魂所在。好的測試點應該是測試對象的歸納，測試點安排的順序是對測試對象剖析的過程，測試點粒度（即測試點包含內容的多少）的選擇是對能力基線的嚴格把握。

　　由于測試設計人員的思想是千差萬別的，所以為了能夠得到更加一致的測試點設計，我們采用了測試類型分析法明確了測試點文件的結構，每一個測試點文件中主要包括：配置測試、功能測試、協議一致性測試、性能規格測試、壓力測試、異常測試、互操作測試等。而測試點的粒度確實很難統一，所以我們一般按照10個/人天的測試執行效率進行估計和設計，這就需要有豐富測試執行經驗。

　　但是，一個測試點無法詳細描述出具體操作的步驟，這便需要測試用例。測試用例設計就是一個將測試點細化到可執行步驟地過程，每一個測試用例都是由執行——〉驗證的不停往復。在用例的設計中我們有一些常用的工程方法：邊界值法、等價類劃分、錯誤猜測等等。這些無非是擴展我們設計的思路，讓測試設計的肉體更加豐滿。

　　三、培養設計人員

　　在測試全流程中，真正執行者都是有血有肉的個體，而這些人所擁有的經驗就是流程的活力。所以要充分發揮測試設計流程的活力，就應該讓擁有豐富經驗、技術級別高的人來主導測試設計的工作。

　　在H3C的測試體系中，主要有助理測試工程師、測試工程師、測試專家、資深測試專家等。對于一般的測試設計工作，具有良好測試實踐的人員（測試工程師）基本可以勝任；而復雜的跨領域的組網測試設計，除了需要測試實踐以外，還需要掌握廣泛的數據通信技術知識，這就要求測試專家承擔該工作；而資深測試專家則要承擔各類更加復雜的疑難雜癥的測試設計工作（如黑客攻擊測試設計）。

　　為了適應不同層次的測試設計活動，需要相應的培養不同技術等級的測試人員梯隊，盡量物盡其用，高技術等級的從事復雜的設計活動，低技術等級的從事簡單的設計活動，不具備設計資質的人員則不能參加設計活動。

　　四、測試設計維護

　　實踐是檢驗真理的唯一標準，測試執行是檢驗測試設計正確性的最佳手段。測試人員需要將將實踐中發現的設計問題，通過跟蹤流程反饋到設計團隊中，使得前期設計的缺陷漏洞得以修復和完備，這樣就會形成一個良性的循環。H3C問題單跟蹤流程就提供了一個很好的修復機制，不僅從端到端保證設計修改的正確性，而且中間設置的審核環節保證了修改的質量。

　　五、結束語

　　測試設計是一個充滿創造力的活動，無論是前期的需求分析，還是分析的落實，或是后期對于設計的不斷完善。要建立起自己的測試之法，就必須將所有測試設計的活動貫穿到整個測試活動中去，測試執行中體現測試設計的精髓，測試設計吸收測試執行的智慧結晶

天貓 軟件自動化測試開發