James Bach的Rapid Test軟件測試培訓總結

　　首先感謝阿里巴巴邀請James大神在北京辦公室組織了Rapid Test的培訓。本來報名的目的只是想和兄弟部門的同事找機會一起交流交流，對測試本身并沒有抱太大的期望。結果課程開始之后，只能說不服不行。另外，哥活生生的被大神當作了教學道具…

　　雖然James大神脫離項目一線專注培訓很多年了，而且也沒有互聯網項目經驗，但是一上來就抓住了問題的本質，項目需求不清楚，進度緊張，資源有限，這都是當年項目情況活生生的寫照啊!所謂的Rapid Test就是針對這些問題的。為什么這里不說敏捷Agile?因為這里只談測試，而且談的是普遍真理，不管你用Agile還是瀑布流，測試都必須解決的一些共性問題。

　　培訓過程就不具體描述了，這里就談幾點總結：

　　如何挖掘需求。在阿里測試人員經常聽到開發人員說：這個功能做好了，你測一下，明天就發了。呃…好像這個到底是個什么樣的功能都沒搞清楚。所以對于測試人員要先了解這個系統，它的功能和設計目標。在教學中舉了一個真實的例子，系統看著很簡單，輸入->判斷->輸出。一開始覺得這個系統簡單，但是在得知是針對航天工程設計的系統時，實時性和穩定性就成為了重要的測試需求。在了解了輸入系統的復雜程度之后，測試的重點也立刻明確了。所以對于測試人員，一邊要自己摸索，同時也要和團隊的其它成員密切溝通，獲取需要的各種信息幫助決策。

　　關于測試用例。James基本上否定了測試用例的價值，這點和我們團隊內部正在摸索的實踐類似。從項目實踐的角度來說，光憑借測試用例，我們無法 1)評估測試的有效性;2)保持測試用例和實際情況同步(誰不服自己上Kelude看);3)從測試用例無法了解整個系統(測試評審基本是在過流水)。大神的觀點是基于場景做測試，你可以不寫測試用例，但是不代表你不需要做你的家庭作業。取代測試用例的是如下的報告：1)測試場景;2)每個場景需要覆蓋的功能點;3)對于每個功能點如何測試;4)場景設計的理由;5)重點測試模塊的選擇等?？們貉灾?，你必須讓項目組成員相信你的測試是完整的，有足夠覆蓋的，能保證產品質量的。

　　探索性測試不是無目的的。探索意味著自由，自由意味著責任。因為你能負責，所以才給你一定的自由。你必須通過試探，分析，驗證這個流程去深入了解產品，之后再去系統的分析，有針對性的設計測試，這樣才是真正的探索性測試。探索不是漫無目的的隨機布朗運動，而是要通過探索建立對整個產品的了解。

　　為什么課程叫Rapid而不是Agile敏捷?因為Rapid Test講的是普遍真理，不管你用什么開發模式，敏捷或者傳統的瀑布流都能解決問題。其實說到底，就是在人手有限，時間有限的情況下找到一個最好的平衡點，既能按時交付，又能保證質量。

　　測試人員的定位是守門員，是守住產品質量底線的人。這個觀點不是很贊同，畢竟當代足球守門員還擔負有后場防守組織的責任。個人認為當代軟件測試還承擔有帶領團隊保證軟件質量以及不斷改進質量的責任。

　　測試的第一要素是人，工具只是輔助。當人們在談自動化測試的時候，有人要求過開發自動化編程嗎?但是事實上，自動化編程某種程度上確實在發生，比如編譯器的工作。對于自動化，我們的衡量標準是生產效率的提高和投入產出比。這個是值得我們在日常工作中借鑒的，有時候比起高大上的全自動化測試腳本，手工測試輔助工具更能提高效率，而且維護成本更低，投入產出比更高。

　　課程只有短短兩天，要是指望培訓后能力有個突飛猛進那是沒可能的。這個課程讓你回到測試的原點，解答了為什么要做軟件測試，如何做軟件測試，如何像一個測試工程師一樣思考問題，如何去發現問題。把這些原則與你工作實踐想結合，才能真正的提高軟件產品質量。

原文轉自：http://blog.monstersay.cn/blog/2014/07/31/james-bach-rapid-test/