http://danielzzu.blog.163.com/blog/static/118515304201091902343768/
測試人員的首要職責是找bug，但是最重要、最根本的職責應該是在軟件產品發佈前確保公司的軟件產品滿足顧客的需求。
測試組採用RBT（Requirements-based testing），基於需求的測試方法會使測試更加有效，因爲它使測試專注於質量問題產生的根源。
研究報告指出，多年來，大部分的軟件項目不能按計劃完成，不能有效控制成本。大部分項目失敗的首要原因是軟件質量差，導致大量的返工、重新設計和編碼。
其中軟件質量差的兩大原因是：軟件需求規格說明書的錯誤、有問題的系統測試覆蓋。
需求規格說明書中的錯誤
我們經常聽到最終用戶抱怨、不用我們的軟件，而這些軟件還通過了嚴格的測試和QA。對於這點我們不會感到驚訝，原因是我們知道需求從一開始就是錯誤的。
一項調查（James Martin (“An Information Systems Manifesto,” Prentice Hall, 1984）表明56%的缺陷其實是在軟件需求階段被引入的。而這其中的50%是由於需求文檔編寫有問題、不明確、不清晰、不正確導致的。剩下的50%是由於需求的遺漏導致的。
有問題的測試覆蓋
要獲得滿意的測試覆蓋率是很難的。尤其現在的系統都比較複雜，功能場景很多，邏輯分支很多，要做到完全的覆蓋幾乎不可能。
再者，需求的變更往往缺乏控制，需求與測試用例之間往往缺乏可跟蹤性。
RBT三大最佳實踐
1、 Test early and often.儘早測試，頻繁地測試
確認需求的業務價值。
各利益相關方應該對需求進行評審。
通過用例檢查需求的完整性
應用語言分析技術確保需求文檔清晰一致，不會引起同一問題不同人有不同的解釋。
2、 Test with your head, not your gut.不要單憑經驗測試
不要依賴測試人員的經驗來設計測試用例，應該採用系統、嚴格的測試用例設計方法，而不是依賴有經驗的測試人員的技巧。通過這樣的方式來增加測試覆蓋的有效性。格式化、結構化的需求文檔有助於測試人員評估需求的測試覆蓋率。
通過測試用例評審來檢查測試用例存在的錯誤，並且找出需求的不足之處。
3、 Test with measurement and improvement in mind.測試過程中要保持度量
在使用基於需求的測試方法的過程中，保持對需求的可追蹤性非常重要。保持需求與測試用例及測試之間的可追蹤性有助於監視進度、度量覆蓋率，當然也有助於控制需求變更。
---
hink we need to break out of the mythology that testing is some kind of robotic process.
我想我們需要粉碎這種測試觀點:測試是一種機械的過程
需求開發不是在項目啓動時一次搞定的。實際上，需求是貫穿在項目生命週期中的兩方談判。一方在問：我們需要什麼？而另一方則在問：我們能構建什麼？
這兩方對話的質量幫助決定產品的最終質量。
我把需求理解成衆多想法的集合，它們共同爲特定產品定義質量。我把測試定義成開發一套評估系統的過程，用於對產品質量進行評估。
RISK AND REQUIREMENTS TESTING 風險與需求測試
至少有四種關於需求與測試的腐朽觀點：
1.除非有穩定的需求，否則測試不可能進行。
2.一個軟件產品必須滿足它的特定的需求。
3.所有測試用例必須可追蹤到一個或多個特定的需求項，反之亦然。
4.需求必須以可測的方式描述。
然而，當我們考慮到風險，我相信有更豐富的概念出現。
Testing without stated requirements 沒有特定需求下的測試
滿足需求是非常重要的，測試員的工作之一就是確認產品滿足需求，所以明顯測試人員需要清楚需求。所以上面說的不無道理，並且在大部分情況下是對的。
但是，由於不完整性和不清晰性，測試不能僅僅認爲是一個確認過程。測試同時還是探索需求和實現的過程。因此，測試不僅可以沒有特定需求，而且在需求不確定的情況下特別有用。我想我們需要粉碎這種測試觀點:測試是一種機械的過程.通過測試和開發的合作會產生巨大的價值。有經驗的測試員通過他們對未定需求的理解評價產品，並且通過觀察來挑戰或提問項目成員對質量的共同理解。
一個好的測試員會對特定需求的差距始終保持警惕，並且解決這些差距到一定的程度：滿足特定情況下的風險。
Satisfying stated requirements 滿足特定需求
如果每一個特定的需求項都是產品的真實聲明，然後我們把產品質量定義爲這一前提的延伸。那麼軟件產品必須滿足它的特定需求這一觀點是成立的。但是那有賴於我們有非常清晰和完整的需求集合。否則，你將被鎖定在一個很窄的質量範圍內。
關於滿足需求的更廣泛的思考範圍是把我們的思維轉變到考慮不滿足特定需求的風險。好的測試員會努力地回答這個問題：什麼是這個產品的重要問題？
Tracing test cases to requirements 把測試用例跟蹤到需求
需求如果要發揮作用，則測試與需求之間應該有所關聯。談到可追蹤性，通常摘要爲：
爲每個需求項ID，列舉關聯的測試用例的ID；爲每個測試ID，列舉關聯的需求ID。
測試的完整性被大概地通過“對於每個需求項，至少有一個測試關聯”來估計。這是一個很理想的觀點。
如果可追蹤性的目的是用於證明測試策略已經驗證了產品的需求，那麼我們應該進一步。我們應該隨時準備回答客戶的問題。“你怎麼知道它證明了？”我們應該能解釋我們的測試與需求之間的關係。重要的是需求和測試是如何關聯的，並且隨着產品風險越高越重要。
Stating requirements in testable terms 在可測性方面衡量需求
需求有意義是非常重要的。然而，“可測性”通常定義爲“有利於完全可靠，一致性和可觀測性的度量，從而決定是否順從需求”。這個觀點強調除非我們能夠度量是否成功，否則我們永遠不能知道我們是否完成測試。
首先我們應該重新認識一下測試員，他們不是懶漢，他們擁有普通人的洞察能力和推理能力。一個典型的測試員應該能夠探索需求的含義和潛在意義，而不一定需要這些信息，就像一個瀕臨絕種的小禿鷹被滴入眼藥水一樣。事實上，嘗試通過簡化需求說明從而達到可測試程度，進而減少測試人員的麻煩，這種做法有可能造成更大的麻煩。
看一下一個真實的例子：顯示控制器應該在300毫秒內響應用戶的輸入。
當一名測試員看到這個需求的時候，他以爲要買一臺特定的儀器來測量產品的毫秒級性能。後來他意識到：一個正常人能辨別正負50毫秒的分辨率，也許這已經足夠精確了。再後來他意識到：也許這個需求項指定到毫秒級不是爲了使需求更有意義，而是爲了使需求更具衡量性。當他問到設計者時，發現真正的需求是：響應時間“在這個版本的產品中不要慢得煩人”。
因此我們看到實際的測試不一定需要精確的需求說明，測試是通過有效的和有意義的溝通進行的。
REQUIREMENTS, TESTING,AND CHALLENGING SOFTWARE 需求，測試與挑戰軟件
1.我們認識產品的問題的能力是受限於我們對問題可能產生的地方的理解。需求規格說明書是一個問題信息的潛在來源。
2.我們招致風險取決於發佈產品中包含的重要問題的程度和範圍。測試的真正任務是把這些風險暴露出來。而不僅僅是展現特定需求的不一致性。
3.特別是在高風險的情況下，如果我們能證明測試策略與定義的質量之間的關聯，測試過程應該會更具說服力。這超出了至少一個測試對應一個需求項的範疇。
4.如果需求說明更多地關注什麼纔是關鍵的要求，關注風險、益處和每個需求項的重要程度，則測試過程會更有效。目標可度量性在某些情況下是需要的，但是它不足以產生健壯的測試。
如果把這些規則應用到高風險或複雜的軟件會發生什麼事情呢？
隨着風險和複雜度的增加，如果測試過程要想完成任務，測試參與到需求的對話中就顯得尤爲重要了。需要更多的測試技巧，作爲與開發更好的配合，與用戶更好的溝通。在這個關於我們要什麼的對話中，測試員應該尋找溝通的更多渠道：更多文檔的原材料，圖表，演示，談話和用例。在關於我們能構建什麼的對話中，測試員應該熟悉採用了什麼技術，並且與開發人員一起爲產品構建可增強可測試性的特性
在整個過程中，測試員應該注意項目的風險和複雜性是否超過了測試的能力。
----
記者：那麼基於需求的測試從理論、方法、概念到工具都包含有哪些內容？
Richard Bender：我覺得RBT方法被業界廣泛認可，一個很重要的原因就是大家都已經認識到，如果不去關注軟件需求的話，是沒有很好的辦法來提高軟件質量的。有很多的數據已經表明，缺陷發現的越早，造成的損失就越少，而現在我們很多的軟件要等到代碼完成以後才進行測試，實際上那時候已經爲時過晚。
RBT的方法關注於三個方面，首先是需求，我們曾與幾百個項目在一起合作，從來沒有發現完全不存在問題的需求。但是其他的很多測試方法，通常會認爲需求是對的，接下來的開發和測試也是基於這個需求的。在RBT過程中有很多步驟可以用來保證軟件質量的，比如說RBT工具會提供給測試工程師一個檢查單，這樣很容易就可以清除軟件需求說明書裏面的故障，可以儘早的避免缺陷，而不是像現在這樣等到代碼完成以後纔去發現缺陷。RBT的一個很重要的步驟是對需求進行二義性評審，實踐證明通過需求二義性的評審可以大大減少軟件在下一版本中存在缺陷的可能性，數據也表明通過需求二義性評審可以發現大約90%的軟件缺陷，從而提高大約20倍的工作效率。
其次，目前軟件測試領域面臨一個窮舉測試的挑戰，我們知道即使一個非常簡單的軟件，要想窮盡所有的可能性都是非常困難的，如此以來就會導致測試用例的數量急劇膨脹。所以，我們面臨的挑戰，就是在有限的時間內把巨大的窮舉測試縮小到我們能夠接受的最小的一個集合的數目。對測試用例數量進行縮減也有很多方法，有組合對法、等價類劃分，相對來說RBT方法所得到的測試用例遠遠小於其他技術方法，因爲RBT方法是由硬件的邏輯測試派生出來的方法。IBM、波音和CISCO等公司的應用實踐也證明，通過RBT的方法可以減少大約1/4的測試用例，這對於提高測試效率來講是非常重要的。
最後，在軟件測試領域還有個亟待解決的問題，就是缺陷的可觀察性，目前只有通過RBT方法可以實現。在硬件測試領域中，敏感路徑法是很成熟的方法，可以實現硬件測試的可觀察性，而RBT正是基於這一方法，根據軟件的特性對這一方法做了大約70%的擴展。通過這種方法，測試工程師最終能夠通過運行測試用例發現一個或多個缺陷，讓其可觀測，並在迭代測試中發現其他缺陷。RBT方法可以告訴工程師在代碼的什麼位置應該預留測試窗口，以觀測當前系統運行狀況是否正確。比如我們以硬件爲例，羅爾斯·羅伊斯公司的航空發動機大約有2000多個硬件檢測點；而嵌入式系統因爲外部可觀察的窗口很少而在系統裏預留了很多觀測點。反觀軟件卻是世界上唯一一個如此複雜而沒有預留檢測點的產品，歸根到底關鍵問題還是目前的測試方法比較初級所致。在已經過去的40多年裏，RBT的方法和理論已經應用到PC機、大型機、CS軟件、嵌入式軟件等各個方面，運用RBT方法設計的測試可以發現超過50%的軟件缺陷，而普遍代碼測試往往只能發現3%左右。通過RBT方法測試過的這些系統一旦成爲產品，將不會存在嚴重程度的缺陷，從而可以幫助客戶大大縮短產品上市時間、減少產品研發成本、提升競爭力。所以說RBT的核心思路就是去儘可能的避免缺陷，而不是去像現在這樣一味的發現缺陷。
