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

　　第三章 人是軟件測試的中心  《轉載》

　　簡單的職業經歷

　　蔡：請介紹一下你的職業經歷。你是一直在華為工作？

　　邰：對，我的職業經歷很簡單。碩士研究生畢業后，在華為從事軟件測試工作11年。

　　旁觀者說：從職業發展的角度來說，長期在一家公司工作和服務于不同的公司各有好處。換多家公司，可以接觸到不同的項目和不同團隊，見多識廣。長期在一家公司服務，有利于經驗和人脈方面的積累，增加獲得更高職位的可能性。

　　我本科和研究生的專業是機械電子，都是在天津大學上的。2001年3月，我研究生畢業，當年4月9日，我進入華為工作，到今年（2012年）的4月9日離開華為，整整11年。

　　蔡：真是不容易，在一家公司服務了11年。這11年是一段豐富的經歷，給我們介紹一下吧。

　　邰：回過頭來看，這11年可以分為兩個階段。2001年到2008年做具體產品的測試。在這個階段里，從測試執行，到測試設計，再到團隊管理，也是一個逐步提升的過程。

　　旁觀者說：有一個問題，也簡單，也殘酷，就是回顧自己的職業經歷，問自己：它是不是一個逐步提升的過程？如果沒有了提升，可能就是處于停滯狀態了。

　　從2008年開始，我的工作內容發生了轉變：從"負責某個具體產品的測試"轉變到"負責幫助其他測試人員更好地做好他們的測試工作"上來。

　　當時正好我所在的測試部（華為上海研究所）和來自華為瑞典研究所的高端測試專家有一個TPI（Test Process Improvement）合作項目，而我也希望自己能夠從管理路線轉到技術路線上來，希望自己在做了七、八年的軟件測試之后，能夠系統地、深入地思考一下怎樣把測試工作做得更好。我很幸運地參與了這個合作項目，并自此開始了測試理論方面的研究。

　　TPI的工作就是對現有的測試工作做評估，并給出評估報告，然后各利益相關人再根據評估報告以及項目上下文開展具體的測試改進實施。說實話，在參與這個合作項目之前，沒有想過要做測試理論方面的工作和研究，身邊也沒有這個氛圍。和來自瑞典研究所的專家接觸后，才意識到了測試理論與測試實踐相結合的重要性。

　　TPI合作項目持續了一年多，我從中受益匪淺。TPI項目結束后，我選擇了一個當時問題比較多的領域"測試設計領域"，繼續開展更深入的調查和研究，提出了一套測試分析和測試設計的框架：MFQ&PPDCS ，該論文在葡萄牙的ICSEA2009會議上得到發表。基于這篇論文，我開發了相關的培訓課程，在公司內部講過十幾次，讓更多的同事了解了自己的主張。

　　旁觀者說：職業發展的路都是一步一步走的，我相信，在公司內部的培訓經歷對于邰曉梅后來成為獨立測試咨詢顧問是有幫助的。

　　2008年，我代表部門參加了ISTQB -FL的培訓，覺得它不錯，把測試方面的知識做了系統化的梳理。參考ISTQB大綱，結合華為的工作經驗，我開發出了"軟件測試基礎"這門課程。參加這門課程的人來自于各個產品線，而不僅僅局限于我所在的無線產品線。我從事測試工程領域的研究后，經常會收到來自不同部門不同地域的求助郵件或者咨詢電話，有的時候可能都分不清楚對方來自哪里。但是，沒有關系，我愿意給大家提供測試方面的咨詢和服務。能夠被人所信任、所依賴，是價值的體現。

　　旁觀者說：有的人可能怕做多了，心想這又不是我的職責范圍；有的人則愿意為別人提供服務，被別人需要。

　　2010年和2011年，我到美國參加了三次StarWest/StarEast會議，收獲非常大。回來后我做了詳細的總結，覺得光是把從大會上學到的技術分享給大家，并不充分，我希望更多的同事也能感受到參會的氛圍，感受到測試工作的激情，于是就開始組織策劃公司內部的軟件測試會議，這樣的會議共舉辦了兩屆，每年參加的人數大概有250人。

11年華為工作經歷中印象深刻的事情

　　蔡：在一家公司能持續工作11年，挺不容易的。在這11年里，有哪些給你留下深刻印象的項目或者事情呢？

　　測試并不只是發現bug

　　邰：這方面的事情自然很多，我舉個例子吧。大概在2005年的時候，我帶一個測試組做一個小型產品的測試。這款產品的主要功能是配置和維護，功能并不算復雜，但是是新開發的產品，從零做起。我們測試組有十幾個人，大家的干勁都比較高。這是我第一次獨立帶團隊做測試，也是既興奮又緊張。我很看重這個項目，從計劃、人員配置到團隊氛圍等，我都處處留意。

　　在我的帶領下，我們測試組每天都能發現很多缺陷，開發改不過來了，因為新增的bug數量大于開發每天所能解決的數量，再加上開發團隊還要做新功能，這樣，就出現了測試壓倒開發的"態勢"。

　　旁觀者說：測試壓倒開發，與開發壓倒測試一樣，不是好的項目狀態。二者應當勢均力敵，互相制約，互相推動和促進，做出一個好的產品來。

　　整個項目進行期間，測試團隊不可謂不努力，但是績效卻不好，也算不上快樂。這其中的原因是什么呢？當時百思不得其解。現在回過頭來看，至少有兩個方面是可以從中吸取教訓的。

　　第一，當時的理念認為測試就是提問題單。現在很多人都知道，這是不對的，測試并不僅僅是發現bug，預防bug也非常重要。

　　第二，沒有把開發和測試視作一個完整的團隊，而是開發和測試分隔得太"開"。

　　在產品bug非常多的時候，我們沒有想到去做缺陷分析，采取一些預防措施，沒有問："這類缺陷怎么又出現了？我們能不能走到開發前期，去了解測試做哪些工作，可以幫助預防這類缺陷？甚至測試能不能幫助開發解決一些bug？因為未修復的bug已經堆積很多了"等這樣的問題，不認為這些也是自己的工作職責。由于缺乏"預防測試（Preventive Testing）、完整團隊（Whole Team）"的思想，測試只是一味地發現缺陷，而大量的缺陷意味著產品質量并不高，測試人員難免會有挫敗感。

　　旁觀者說：在實際的項目中，有的時候其實也能發現流程或者工作方法方面的一些問題，但是往往因為疲于應對工作，下不了決心來做改進。項目結束后的總結過程是很有必要的，讓我們更加清晰地看到不足，制定出具體的改進辦法。

　　更多的啟發

　　如果深入思考，這個案例可以帶給我們更多的啟發。

　　第一，如果一個產品或項目有大量的bug暴露出來，作為項目管理者要注意了，這意味著項目本身有很大的改進空間，產品的質量不容樂觀。

　　處理bug是很費時間的：測試提交一個bug，開發打回，說這不是bug；測試再打過去，證明這就是一個bug；開發修改后，不經過單元測試，就打給測試去驗證；如果測試驗證沒有通過，還要打回給開發，開發重新修復，測試再重新驗證……可以想象，成千上萬個bug，如果每一個都要走這樣的流程，單是解決掉這些bug就要耗費多么大的精力！每一個bug就是對系統的一次change，軟件系統本身已經很復雜了，再加上成千上萬次change，系統變得更加復雜，潛藏的缺陷有可能更多！

　　旁觀者說：對于全新的功能，我在自己的團隊有一個提法：剝筍子。軟件的功能都是逐步完善的，在初期很容易發現這樣、那樣不對的地方，這個時候不要開過多的bug，而應該像剝筍一樣一層一層來。先提交最主要的幾個bug，開發修改了以后，測試人員得到新的build，再基于新的build提交另幾個主要的bug。bug分清楚主次，提交的時間分先后，能夠提高bug的有效性，也方便開發人員解決問題，提高研發效率。

　　第二，測試流程只起到輔助性的作用。

　　當時公司已經有了非常不錯的測試流程，有很多測試工程方法可以使用，有很多測試文檔模板可以選用，我認為只要認真遵守流程規范，就一定能做好測試。在某一個時間點，應該采用什么樣的模板、出具什么樣的測試文檔、使用哪些測試工程方法、開展哪些測試活動、做哪些測試總結和缺陷分析等，我都一一照做，花了不少的時間。但是，遺憾的是，我雖然努力了，卻沒有抓住事情的本質，忘記了我們的第一目標是要得到一個可發布的高質量軟件，而不是找到盡可能多的bug。

　　旁觀者說：測試團隊天生有想發現更多bug的傾向，有的時候績效考核會起到推波助瀾的作用。但是的確，按時發布質量達到標準的軟件產品是任何"參戰部隊"的最重要的目標。

　　實際上，我現在認為，測試流程是一種啟發式（Heuristics），遵守了流程，測試不一定就做得好；不遵守流程，測試也不一定就做不好。測試流程起到的更多的是一個輔助性的作用，而不是決定性的作用。所有的啟發式都可以幫助我們思考。我們要學會應用（Apply）測試流程，而不是遵守（Follow）測試流程。

　旁觀者說：讓測試流程為我所用，而不是機械地遵循。

　　第三，做任何測試工作，首先要做的是Know Your Mission（知道你的任務所在）。

　　測試是一種服務，為我們的客戶（包括其他各種角色和最終的客戶）提供質量相關的信息。當我們接收到一個測試任務時，首先要做的就是了解客戶是誰，客戶期望得到什么價值，希望測試為其提供什么樣的服務。有的朋友可能有這樣的工作習慣，不管軟件大小或者功能大小，一上來就動手測試，迫不及待地想提交bug。可是，如果不知道客戶的期望是什么，則容易出現偏差。要了解客戶在哪里，期望的價值在哪里。

　　旁觀者說：我很贊同測試是服務的提法。記得幾年前在一家企業做演講，當我提出測試是一種服務的時候，就有朋友表示不理解，認為服務人員的地位太低了，這么說是看低了軟件測試。

　　在社會生活中，從事服務的人員沒有得到足夠的尊重。其實每一個人都是平等的，只是從事的職業不一樣而已。說測試是一種服務，并不意味著測試低人一等。在大的研發體系中，軟件測試這支力量扮演的是服務的角色，為提高研發效率和提高產品質量而奮斗。

　　對測試認識的三個階段

　　蔡：謝謝你的分享。雖然你的工作經歷比較單純，但我相信你在華為工作的11年當中，對軟件測試的認識應該是變化和逐步提高的。

　　以bug、流程、人為中心

　　邰：是，我對軟件測試的認識是有變化的。

　　在2008年之前，雖然我也一直在做測試工作，但是我的確思考不多。現在回過頭來看，如果在成長的道路上有人時不時地指點一下，那真是一件值得慶幸的事，會進步很快。從2008年開始，我會經常瀏覽測試類的博客、網站，參加各種會議，多做交流，對測試的認識有明顯上升。

　　旁觀者說：找到自己的導師，虛心請教。有的時候經驗豐富的人一句話，就能讓自己少折騰幾個月。

　　到現在為止，我對測試的認識可以大體劃分為三個階段。

　　第一階段，以bug為中心。認為測試就是找bug，bug越多越好。這可稱為原始階段。在這個階段里，一般都是拿到軟件就開測，流程不一定規范，也沒有想到要規范，只是找bug。

　　第二階段，以流程為中心。在測試工作中，認為應該先定義各種測試流程和規范，認為只要follow這些流程和規范，就可以更有效、更高效地找bug，就可以做好測試。

　　第三階段，以人為中心。認為測試是以人為中心。我現在也還在這個階段。不再以流程為中心，把流程、模板放到邊上，而把人放在中心的位置上。把測試工程師的能力和潛能發揮出來，這是比流程更重要的事情。

　　旁觀者說：團隊的核心就是人，團隊管理者的主要工作始終是調動和保持員工的工作積極性。

　　注意：這三個階段對于我個人而言是個順序認知的過程，但不意味著每個組織都要串行依次經歷這三個階段，也就是說，不一定要先建立測試流程，才談測試以人為中心的事情。

　　軟件測試在沒有規范的時候也能做，也能找到一些問題，有了規范之后你的測試看起來就會正式一些，但如果想把測試做好，就應該以人為中心。最近國內開始流行的探索性測試，就是以人為中心，充分發揮人的各項技能。

　　研究軟件測試思維

　　認識到測試以人為中心后，我開始研究"軟件測試思維"相關課題，這是一個很大的課題，不僅涉及測試領域的知識，還可以從心理學、社會學、人類學等很多領域獲得啟發，這個課題的研究我也是剛剛起步，目前開發了"認識你的測試思維"這門課程，旨在幫助學員認識自己的測試思維，以實現改進和提高。

　　我通過和不同的測試人員開展結對測試發現，在外部條件都相近的情況下，例如，在相同的時間內，相同的測試對象和測試環境，甚至相同的測試用例，不同的人卻得到不同的測試結果。在測試工作當中，測試思維扮演著重要的角色。但是，對于大多數人來說，測試思維--你測試時是如何思考的--是在潛意識下發生，很難用語言表達的，所以為了提高測試思維，首先得認識當前的測試思維。

　測試深度圖

　　為了把看不見的東西可視化地表現出來，我提出了"測試深度圖（Test Depth Graph）"的概念。通過這張圖，可以展現出學員測試思維的特點，例如，是擅長深入思考（Focused Thinking）還是擅長廣度思考（Defocused Thinking）等。在觀察的過程中，我會告訴學員，哪些地方他（她）做得很好，這樣他（她）就會得到激勵，對測試工作更有信心。對于不足，我也會提起，這樣他（她）在下次遇到類似場景時就會有意識地提醒自己，去做改進。這樣的事情反復幾次，一個人在測試思維方面就會得到提高。

　　旁觀者說：表揚就是一種正面的引導。

　　蔡：對這三個階段的認識的跨越你都是在一家公司，你的職業生涯比較順利。

　　邰：是，我比較幸運，相對還是比較順利的。剛進華為時，我告訴自己，兩年后我就離開。過了兩年，我發現有很多東西要去學習。就這樣，年復一年，不斷地覺得有新的值得去學習的東西，我也在一路不斷成長。當你一直在學習一直有收獲的時候，就會感覺很充實。我喜歡這種充實的感覺。

　　重點測試技術

　　蔡：請你給大家介紹一下你認為重要的測試方面的技術，或者新技術。

　　邰： 所謂的新技術，是有context（上下文）的。例如ReqBT（Requirements Based Testing，基于需求的測試），我邀請了Richard Bender在ChinaTest 2012上做了介紹，有的朋友可能會認為這是測試新技術，其實作者提出來已經30多年了。新與不新，是個相對的概念，有的人感覺比較新，有的人則早就接觸過了。

　　不同的公司也有不同的情況。對于有些公司來說，在時間、資源等很有限的情況下，ReqBT這樣偏"重"型的方法可能就不適合，他們可能更需要類似于RST（Rapid Software Testing，快速軟件測試）這樣偏"輕"型的方法，RST是James Bach和Michael Bolton講述的一門課程，側重于如何在測試進度緊張、測試資源有限等條件下快速而有效地開展測試工作。所以，技術的應用或者重要與否取決于項目上下文。

　　人也是有上下文的。不同資歷的人，看法會不一樣。當然，如果只是年資的增長但是見識沒有增長，這是自己要認真思考的問題。對于培養測試新手而言，我的觀點是，并不一定一開始就要學習系統的軟件測試知識，或者去學習測試新技術，而應當是多實踐并且多思考。給他們一個測試任務，讓他們去做。這對于新手來說肯定是個挑戰，但是在這種情況下他們也會發揮自己的各項能力去做。當然，指導者也不是撒手不管，可以和他們一起結對測試，發現他們的不足，指導他們去做測試。通過實踐，新人對軟件測試的認識和興趣都會得到提高，然后再去教他們測試理論知識，例如等價類邊界值等，效果會更好。

　　旁觀者說：邰曉梅這里提出來一個新的觀點：對于軟件測試，可以走先實踐、后理論的學習路子。這里有新意，值得參考。對于公司內部轉崗的情況，可以嘗試一下這種做法，先直接做測試，然后慢慢回過頭來學習理論。對于剛畢業的大學生朋友，因為需要找一份測試工作，先學習測試理論會有利于通過面試。

　　如何學習軟件測試

　　蔡：你對于正在學習軟件測試的朋友有哪些建議？

　　多實踐，多思考

　　邰：我強調的是，不管你是在學校里，還是在公司里，要多交流，多實踐。如果條件允許，最好找一個導師，項目里的最好，可以面對面交流，這對成長有很大的幫助。從我個人的體會來說，人與人之間傳遞信息最有效的方式就是面對面的交流，比看文檔、讀書、參加培訓效果更好。

　　旁觀者說：尋找導師，向周圍的人學習。如果真能找到一位師傅，建立一種或密切或松散的師徒關系，收獲往往很大。除了技術方面，思維方式和做事風格都是對人有很大影響的幾個方面。

　　找導師往往很難，因為這是要雙方愿意的事情。每個人對自己的師傅有一定的期望，有的時候你看準了一位師傅對方也不一定愿意來指點你。虛心請教，有利于學習和找到導師。

　　多實踐，多思考。如果工作了七、八年，在軟件測試方面的進步卻并不明顯，這是值得反思的：是不是自己思考不多？

　　三步法

　　如果你想學習軟件測試，甚至成為測試的牛人，我們可以應用前面提到的Know Your Mission的方法思考這個問題。

　　第一步，請你描述自己的目標，你想成為什么樣的人？是想寫軟件測試方面的著作，還是要得到公司的認可？目標要定下來。

　　第二步，如果想要實現這些目標，需要具備哪些技能和知識？也許你需要了解測試設計技術，也許你需要在某個方面很強，比如測試自動化、安全性測試、性能測試等。

　　第三步，如何掌握這些知識和技能？也許你要去學習一些相關的測試課程，瀏覽相關的網站，閱讀一些測試書籍，思考總結自己的測試經驗等。

　　歸納起來，這是一個What'What'What（目標是什么-需要什么技能和知識-做些什么以獲取這些知識和技能）的過程。這3個What是一個迭代的過程，剛開始的時候對每一個What的認知少一點沒有關系，循環執行這個過程，就會一步步貼近你的目標。

　　旁觀者說：定一個目標何其容易，愿意一步一步、一天一天去實現它又何其難啊！

　　測試就是學習

　　我主張的一個觀點是，Testing is learning（測試即學習）。誰的學習能力強，誰就可以快速地了解被測對象，快速地了解哪些區域bug比較多、風險比較高，從而把測試做得很好。一個人要想成為測試高手，需要具備很強的學習能力。如果只是資歷高，但學習能力差，會很麻煩的。

　　（未完待續）

天貓 軟件自動化測試開發