rbt
測試方法的核心思想是一切從需求出發構建測試過程。圍繞這個思想，
rbt提出了三大最佳實踐，作為實施
rbt測試的原則方法：盡早測試，頻繁地測試；不要單憑經驗測試；測試過程中要保持度量。
該如何落實這三大最佳實踐呢？談下我的理解。 一、
盡早測試，頻繁地測試
所謂「盡早」的意思，就是應該在需求出現的地方開始測試，而不是在設計出現或者軟體、產品出現時才開始。要做好「盡早」測試，測試人員必須弄清楚什麼是關鍵需求？軟體的價值一定是圍繞關鍵需求展開的，但是通常，使用者傾向於提出所有想要的需求，不會對需求的重要性做清晰的劃分；好的設計人員會從使用者的需求中萃取出關鍵需求，但由於要頻繁考慮技術實現問題，經常會將角度部分轉向關鍵需求實現方面，最糟糕的情況是從關鍵需求實現完全轉向關鍵技術實現，與使用者關鍵需求產生較大偏離。這時，測試人員可以首先分析使用者的關鍵需求，然後和設計人員的關鍵需求實現進行對比，從印證中發現其中的差別，測試這種差異性對使用者的影響。這時的測試需要測試人員對需求的洞察力和溝通能力，這種能力越強，測試可以開始的越早。如果一時達不到這種能力，可以適當推遲測試的開始時間，不要貿然開始。但無論早晚，上述應該做的事情是一致的：抓住關鍵需求。
頻繁測試潛在的風險是測試的成本問題，如果頻繁測試，但很少發現問題，測試的經濟性就會下降。降低這個風險的辦法是保持前後測試行為之間的相關性。後乙個測試應該是對前乙個測試在廣度上的有限擴充套件或者在深度上的有限延伸。如果上次測試後設計部門對有測試問題的部分進行了改進，同時又提供了新的部分的全新功能，這時測試時應優先考慮對改進部分做回歸測試，再增加新部分的測試內容。另一種保持相關性的方法是躍遷，比如效能測試中，在方案中設計條件用例，如果測試中軟體達到第一測試效能，就提高乙個數量級測試軟體是否達到第二測試效能，並以第二測試效能作為測試結果。這樣做的好處是可以盡早的發現軟體的價值或者缺陷，將下一次測試的內容前置，再次執行了「盡早測試」的原則。 二、
不要單憑經驗測試
依照需求規劃測試，有時會落入乙個陷阱：軟體需求，尤其是初期的需求，一般會比較關注需要軟體做到什麼，而只用少量筆墨描述不要軟體做什麼。造成軟體經常會做一些不應該做的事情。
rbt的這個原則是規避這種陷阱的好辦法。
在實踐中會發現，採用系統、嚴格的測試用例設計方法可以大幅提高設計用例覆蓋的有效性。我的經驗是，一方面通過需求獲得用例，另一方面通過系統化的標準獲得用例，然後將這兩種用例中進行匹配。注意在深思熟慮之前，不要輕易決定刪除任何乙個顯現矛盾的細節，因為這樣的細節往往有助於發現需求的不完善性。
匹配過程中最痛苦的是對用例整體結構和用例合併與分解的取捨，但這樣的痛苦是有價值的，因為這促使測試人員充分衡量用例對提高軟體價值的貢獻程度。好的測試人員經過這個過程，有可能獲得比使用者和設計人員更加完整的視野，第乙個對最終產品形成清晰的認識圖景。實際上，需求與實現上的很多細小問題都是在這個過程中被發現的。 三、
測試過程中要保持度量
在測試過程中保持需求的可度量性，與其說是檢驗測試人員的能力，不如說是在考驗測試人員的態度和毅力。
實踐中，解決需求的可測性問題會時刻受到將需求削減為可測的**，這樣的**不僅來自於測試人員的本身能力，也來自其他部門人員和環境的壓力。
將需求變得可測需要測試人員具有較強的創新能力，能夠以獨特的視角找到測試需求的方向，某種程度上和尋寶一樣，要在所有的錢沒有花光之前找到寶貝有時是很艱難的，其間會一次又一次的懷疑是都真的有寶藏存在。
另一方面，擺在測試人員面前的很多需求是具有迷惑性的，這點在
rbt理論中舉的例子中可以鮮明的看到。要撥開層層的迷霧，需要測試人員充分的挖掘真實的資訊，而這樣的資訊並不是所有人隨時都願意提供的。
對需求的懷疑和對發現的懷疑交織在一起，退縮就是乙個看似明智的選擇。然而，如果在乙個地方退縮，就會在另乙個地方重複，最終將削弱測試給軟體帶來的價值。
我們只有堅信一點：能夠實現的需求就一定是可測的。
rbt測試方法是一件極為精準的**，能不能獲得收穫，取決於我們內心的堅守和在恰當時機的致命擊發。
RBT三大最佳實踐（基於需求的測試）
rbt三大最佳實踐 1 test early and often.盡早測試，頻繁地測試 盡早的測試可以最快確認需求的業務價值。我們都知道，乙個業務的需求並不是在專案啟動前一次搞定的，特別是那些複雜的業務 創新的業務。實際上，需求是貫穿在專案整個生命週期中的。需求制定一方提出 我們需要什麼？而軟體開發...
ABAP單元測試最佳實踐
本文包含了我在開發專案中經歷過的實用的abap單元測試指導方針。我把它們安排成為問答的風格，歡迎任何人新增更多的q a s，以完成這個列表。method test 2 lief 2 pal.test assignment of deliveries to handling units set cod...
軟體單元測試（Unit Test ）最佳實踐
我們回顧幾種單元測試的最佳實踐。首先，tdd 是非常有價值的實踐。在所有現有的開發方法中，tdd 可能是多年來根本上改進開發且投資成本最小的一種。每個 qa 工程師都會告訴您，開發人員在沒有相應的測試前不會寫出成功的軟體。有了 tdd，實踐是在實現前編寫測試，並且理想情況是，編寫的測試可以成為無需人...