每次接觸到完全新的需求，在開始測試之前，似乎都會想到一個問題:是先嚴格按照需求文檔來一項項驗證功能，然后從用戶角度去添加一些非正向使用場景，還是一開始就考慮采用一些探索測試方法論，對功能進行類型劃分以求代碼覆蓋率。根據以往經驗來看，這似乎不是一個簡單的選擇題...
一般來說，以需求為導向的測試本身并沒有什么問題，但是往往需求本身定義的場景比較局限，也不會在需求定義的一開始就已經想到所有可能的使用場景。同時，作為產品設計的下游節點-開發，一向是考慮為實現需求所規定的功能為目標，自然容易忽略掉一些逆向情景，并在此暴露出很多使用入口給用戶。這些屬于需求描述場景之外的使用入口的不同組合，就是經常所見的很多bug的主要來源。
設計上無法面面俱到，開發實現上又沒有效的規范去進行約束，開發出來的產品的質量自然難以僅參照需求就能有效保證了。
但是，我們能單純從測試的一些方法論為導向去進行測試嗎？我們知道，單純從更好的保障測試覆蓋率和質量，不考慮實際情況:項目周期，技術團隊規模和產出效率，其他風險這些等等，測試理論會要求你永無止境的，使用無窮的組合方法進行無限的測試。顯然，這是現實所不允許的，事實上我們既不能滿足100%的覆蓋率，也不可能總是能確保沒有任何質量問題。所以完全以測試理論為導向沒有可能，也沒必要。
綜合兩種方式，很顯然，我們既要求覆蓋率和更好的質量，也要求測試投入可預期可控，最好的方式就是:在全局方面驗證用戶所需要的所有功能的場景，在場景局部上使用測試方法進行探索和演變。
也許是信口開河，也許是以偏概全，只有去思考，然后嘗試了，才能知道結果對錯，誰又能說不是呢？:-D
