@import url(http://www.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); 勤奮是一條通往成功的路  《轉載》

　　我的職業發展路徑

　　蔡：謝謝文強接受我的采訪。請相對詳細地介紹一下你的個人經歷。就我個人而言，我比較喜歡看人物傳記。雖然我們不是什么大人物，但是每個人都是獨特的，人生的經歷都是寶貴的，其中或許有可以供其他朋友借鑒的地方。

　　按工號隨機分配而進入軟件測試行業

　　鄭：我不是計算機相關專業畢業的，卻陰差陽錯地從事了與之相關的軟件測試工作。1994年到1998年我在華東師范大學物理系上學，1998年到2001年接著在本校上了精密激光物理專業的研究生。因為大學與研究生專業都是理科，在整個7年學習期間基本沒有上過計算機相關的專業課，因此IT基礎很差，導致工作以后入門相對比較難。

　　2001年碩士畢業以后我應聘進入中興通訊上海第一研究所。中興通訊在上海有兩個研究所：第一研究所和第二研究所，其中第一研究所的主要產品線是有線通訊。我在中興通訊上海第一研究所的工作是軟件測試，產品是園區寬帶接入系統IPDSLAM，主要提供ADSL/VDSL的用戶端接入。從時間上來說，在國內我算是做軟件測試比較早的一批了。當時國內測試行業剛剛起步，測試工作并不受重視。說起來比較有意思，新入職一批新人，按工號排列，奇數的去做開發，偶數的去做測試（或者反過來，記得不是很清楚了），就是這么隨機分配的。

　　努力學習軟件測試

　　由于專業的原因，我的IT基礎很差，甚至TCP/IP協議和IP地址/掩碼等方面的知識都沒有。不懂怎么辦？我能做的只能是比其他同事更加勤奮努力。在工作之余，我拼命看書，同時多向其他同事學習。當時測試組加我只有三個人，兩個做功能測試，一個做性能測試，我就是被分配做性能測試的那位。剛出校門，我對通信設備的功能都不了解，就要做性能測試，壓力非常大。但是，沒有別的路可以走，只能靠自己努力。當時所做的性能測試，主要是偏硬件的，要搭建大的測試環境，是個體力活，基本都是沒有人愿意接手的工作。更苦的是，除了性能測試，還需要負責通信設備的EMC（電磁兼容性）測試，每次都是背著沉重的設備，乘公交車去其他公司的EMC實驗室做測試，經常在外面奔波。

　　旁觀者說：剛畢業后的第一份工作，不要挑工作內容。不管做什么，都是一種歷練，像鄭文強一樣踏踏實實做下來。剛畢業的時候有沖勁，總想學習，沒有家累，這些都是優勢，能夠彌補工作經驗的不足。如果這也不愿做，那也不愿做，要享受老員工的"待遇"，等于在破壞自己的優勢。一個人在公司總要有點優勢。

　　就像前面說的，當時所謂的性能測試和EMC測試，都是最沒有地位的工作，即使是在測試部門內部。為了使自己更多地了解產品功能和協議方面的知識，我在完成性能測試與EMC測試工作之后，就會拿一個本子，坐到做功能測試的同事邊上，邊看邊記，不懂的就問。等他們中午吃飯和休息的時候，我就自己動手嘗試操作，這個過程對自己掌握產品功能的測試幫助很大。

　　旁觀者說：在這里，我看到了鄭文強刻苦學習的精神。天道酬勤。

　　除了產品測試的任務之外，為了在公司內部引入一些自動化測試的內容，我開始嘗試學習編程語言。沒有一點編程的基礎，怎么辦？時間對每個人都是平等的，在不影響每天測試工作的前提下，我主動加班以獲取更多的學習時間。那時候，每個月的加班時間都在40個小時以上。因此，很快熟悉了如何通過C++和TCL（Tool Command Language，一種通用的腳本語言，可以在各種平臺上解釋運行）進行測試腳本的編寫。大概過了半年的時間，我不但在性能測試和EMC測試上是了解最多的，同時在產品功能測試方面也不遜色。因此，部門經理開始讓我在技術上負責公司內IPDSLAM的總體測試任務和公司外OEM交換機的驗收測試。

　　旁觀者說：時間都是擠出來的。一個月加班40個小時，相當于給自己增加了一周。

　　旁觀者說：機會來自能力，而能力來自于日常的學習和積累。

　　在2001年的時候，公司對測試并不大重視。當然這并不是單個公司的問題，整個國內的大環境就是這樣，整個軟件測試行業還是剛起步，流程上也不規范。項目計劃主要是根據客戶的要求來確定的，在項目進度與質量之間發生沖突的時候，往往先滿足發布的時間要求，而犧牲產品質量。因此，對于測試人員，除了在公司內部有緊張的測試任務之外，還需要不斷地去解決客戶現場的問題，就是一個不斷救火的過程。

　　在中興通訊上海第一研究所的2年測試工作為我在產品知識領域打下了非常堅實的基礎。這是合格的測試人員首先需要具備的一個技能--深入了解你的測試對象，它的架構、功能，以及客戶是如何使用他們的業務知識的。

　　旁觀者說：對軟件產品了解到什么程度，測試才能做到什么程度。

　　學習好軟件研發流程

　　2003年中，我第一次換工作，到上海貝爾-阿爾卡特繼續從事測試工作。現在回過頭來看，即使是在2003年，上海貝爾-阿爾卡特的項目管理、開發流程和測試流程都是做得相當好的。在上海貝爾-阿爾卡特公司內部，一個蘿卜一個坑，不僅僅強調個人的能力，更注重團隊的整體能力。上海貝爾-阿爾卡特的文檔管理系統非常好，以前項目的所有文檔你都能找得到，而且是正確的版本，同時針對各種測試工作產品，都會有相應的文檔模板，以方便測試人員迅速了解每個文檔中應該包括哪些內容。當時采用的開發模型是火車模型 ，即迭代增量的開發模型，針對產品有5年的長遠計劃，基本上是每隔半年會發布一個版本。

　　旁觀者說：團隊越大，項目越大，配置管理就越重要。

　　在上海貝爾-阿爾卡特，除了繼續在產品知識和業務領域進行學習與實踐之外，我將很大的精力花在了流程的學習上，包括PMP知識體系、開發模型、測試流程的主要活動、測試輸入與輸出文檔等。在上海貝爾-阿爾卡特的幾年工作經驗，使得自己對整個研發流程都有了全局了解，也讓自己可以更輕松地和不同的測試從業人員進行交流與分享。不同公司盡管其采用的開發模型和測試流程會有所不同，但是基本的測試知識體系都大同小異。

　　旁觀者說：在一家公司工作，除了學到軟件產品對應的技術外，不要忘了學習“軟技能”，例如研發流程。
　去管人還是堅持做技術

　　在上海貝爾-阿爾卡特，我當時的目標是去做經理，簡單地講，就是去管人。周圍的氛圍大抵如此，大家基本都認為管人的經理有地位、有能力，當然也有面子。其間我曾經去UT-斯達康面試過，目標職位是項目經理。所有的面試流程都通過了，但是這個職位因為各種原因最終被取消了，我沒有去成。這件事情讓我深思，我問自己：自己真的喜歡做項目管理工作嗎？自己真的適合做項目經理嗎？是自己喜歡還是活在其他人的期望之中？深思和反省了一段時間之后，發覺自己并不是真的喜歡項目經理這樣的職位，更多的是由于人家覺得這樣是好的。經過這次反思，我給自己重新做了一個定位：發揮自己在測試領域的專長與經驗，繼續自己的軟件測試技術之路。

　　旁觀者說：做自己，而不是生活在別人的期望中。

　　上海貝爾-阿爾卡特是一家不錯的公司，我在其中的幾年最大的收獲是：深入了解了軟件開發流程、測試流程與項目管理方面的知識。這也是合格測試人員需要具備的技能。除了了解你的測試對象之外，你需要深入了解軟件產品是如何開發出來的，開發與測試之間的關系是什么，主要的測試活動與測試任務，等等。

　　由于辦公場所在浦東，離家太遠，每天往返上下班需要2到3個小時。雖然公司有班車，但是每天在路上花費的時間太多。在2006年的時候，我猶豫、徘徊了很久，最終決定到離家更近的朗訊科技光網絡有限公司，繼續做我喜歡的軟件測試工作。這樣，我也可以更好地平衡工作與生活。

　　旁觀者說：一個人最珍貴的資源是什么？時間。

　　在朗訊我做了2年多的測試管理職位，帶領一個測試團隊。在朗訊工作2年多后，也就是2008年年底，我主動向公司申請，轉做測試技術崗位。我感覺自己的個人興趣還是在技術上，我想專注在軟件測試過程和測試能力改進等領域上，這樣從管理崗位轉到技術崗位有利于自己的發展，有更多的時間和精力去做自己想做的事情。

　　旁觀者說：能夠看清自己的興趣在哪里，看清自己擅長的在什么地方，真是幸事。

　　研究測試技術和方法

　　在朗訊公司內部，完成測試任務之后，我將其他時間與精力放在了測試技術與方法的研究上面，提出了一些解決方案來不斷提高團隊內部的測試能力。例如，在測試用例設計與執行中引入了測試類型的概念；根據敏捷開發的特點，在測試團隊中提出并引入了Pair Testing（結對測試 ）的概念；在測試用例設計中提出了"精簡化的測試用例"的概念；在測試用例設計中提出了放射性思維，使得測試用例編寫的工作量與測試人員創造性思維方面得到了很好的平衡。

　　旁觀者說：提出新概念是一種創新，當然這不容易做到。

　　同時，我開始在公司內部更廣泛地參與測試相關的活動。2011年和2012年分別參加了公司中國區第一屆和第二屆技術大會，并做了主題演講。積極參與公司內部的軟件測試社區建設，并在公司內部推廣測試知識、測試技術與方法、測試管理等方面的培訓與分享。現在非常明顯地感覺到公司對軟件測試的重視程度在不斷提高。

　　到現在為止，我在朗訊的工作時間已經有7年了，在軟件測試方面給我最大的體會是：不管多好的測試理念、測試技術與方法，我們都需要和實際測試工作結合起來，不斷提高測試效率和有效性，不斷提升測試質量。這是合格的測試人員需要具備的技能。

　　旁觀者說：讓理論經過實踐的檢驗，落地，形成適合自己公司和團隊的做法和經驗。

　　我在測試行業工作已經超過11年了，我感覺是在更深入地了解測試的內涵，更愿意將當前的狀態看做是超越自己的一個起點。堅持去做自己喜歡的工作，不斷積累、總結和分享，相信每個人都可以成為領域內的專家。

　　旁觀者說：11年的積累，仍然看做是一個新的起點，值得學習。

　　跳槽時要考慮自己的興趣愛好

　　蔡：一個人跳槽的時候要有哪些方面的考慮呢？

　　鄭：首先，從大的方向而言，我不鼓勵經常跳槽，特別是在沒有職業規劃的情況下，僅僅因為待遇、人際關系等原因而匆匆下決定的跳槽。從個人的發展機會而言，在一個公司待的時間久了，可以獲得更多的機會，俗話說"偉大是熬出來的"。當然行業也很重要，要注意自己知識和技能的持續積累。假如真的決定要跳槽，那么下面幾個方面需要仔細考慮。

　　旁觀者說：跳槽會有新的機會，同時也會付出代價。在做決定的時候，要看到兩面。

　　第一，跳槽要考慮自己的興趣愛好。做自己喜歡做的事情，盡管錢也很重要，但是為了漲一些錢就跳槽，甚至為此去做自己并不真正喜歡的工作，并不見得是一個明智的選擇，同時很難一直堅持下去。我自己就是一個例子，在2005年準備換工作的時候，我心儀的職位是項目經理，感覺特有面子和地位。但在求職失敗之后，我重新審視了自己：去做自己喜歡的，還是去做人家喜歡的？最終我選擇了前者。從目前的結果看，感覺到自己在公司內部可以做的事情更多了，參與的活動也在增加。不管對公司還是對個人，體現的價值都是在不斷增加的。

　　旁觀者說：在公司里工作，我們難免會被安排，而不一定都遂人愿，但是在發展的大方向上，還是要自己定。

　　第二，如果興趣愛好能和自己的優點結合起來，那么跳槽就會更加理性。認識自己的優缺點實際上是挺困難的一件事情，"當局者迷，旁觀者清"。還是以我自己為例，我的優點是勤奮、專注于技術能力。因此我更適合有條理地工作，自己計劃和控制時間完成每一件事情，而不太適合每天參與各種會議、討論與協調工作。所以，從這個層面而言，我更適合去做測試技術方面的工作，而不是測試管理工作。假如你認定自己的性格并不適合做管理工作，那就不要強求，否則不僅自己痛苦，整個團隊也痛苦。

　　旁觀者說：去認識自己的優缺點。一個人要想認清自己其實并不容易。

　　第三，跳槽需要和自己的職業規劃相一致，不要亂了方向。假如有了明確的職業規劃，清楚實現職業發展需要具備哪些方面的技能，那么在跳槽的時候就會考慮如何更快地掌握這些技能。記得我在中興通訊上海第一研究所的一位同事，原來是做測試工作的，但是其職業規劃是做項目經理。項目經理不僅需要了解測試工作，而且需要了解整個軟件開發流程和管理工作。因此，除了平時積極學習項目管理方面的知識外，他在第一次跳槽的時候，找到了一個軟件開發的職位，目的就是為了獲取軟件開發的實際經驗，待遇方面考慮得比較少。在軟件開發方向工作3年以后，他再次跳槽，如愿以償地得到了某個公司項目經理的職位。由于他不僅了解開發工作，而且了解測試，同時這一結果又符合自己的職業規劃，因此目前他的工作狀態是非常有激情，這對公司、對個人都是一個不錯的結果。

　　旁觀者說：目的非常明確的職業發展路線，值得學習。

　　第四，在考慮跳槽的時候，也需要考慮公司的企業文化、團隊氛圍、個人在公司內的發展空間等，例如，公司離家是否方便，公司是否經常加班，公司是否等級森嚴，公司是否鼓勵員工個性化發展等。

 

印象深刻的從巴西到上海的項目轉移

　　蔡：請談一下讓你印象深刻的項目。

　　鄭：從事軟件測試工作超過11年了，經歷的大大小小的項目超過了幾十個，有成功的，也有失敗的。不管是成功的軟件項目還是失敗的，我從中都學到了很多經驗和教訓，其中印象最深的項目是2006年從巴西成功地將IPAFM/AFM項目轉移到上海。該項目的主要功能是為電信運營商提供寬帶接入系統，分別提供IP的上行鏈路和ATM的上行鏈路，客戶端的主要接入手段有ADSL、ADSL2+、PSTN、100M電口/光口等。

　　公司從成本方面考慮，2006年的時候希望將該項目從巴西轉移到上海，包括相關的資源、知識、工具等都轉移過來。作為該項目的測試負責人，我面臨多項挑戰，例如，產品相關文檔、知識、技能和資源如何有效地轉移到上海研發中心，新團隊對該產品功能缺乏經驗，在有限的時間與資源下如何開展有效的回歸測試，如何測試新的功能，等等。

　　面對面的溝通是重要的

　　為了提高產品轉移的速度和效率，公司派了幾個人到巴西出差，為期一個半月。面對面的溝通對于項目轉移非常重要。我們積極參加巴西研發團隊針對我們的各種培訓和討論，深入學習產品相關的功能與業務知識。我們盡量多地收集需求文檔、開發文檔和測試文檔，包括原來測試團隊在前面項目中測試的經驗教訓等，熟悉軟件環境的搭建和配置，包括測試儀表的使用、測試環境的基本配置等。由于巴西測試團隊的鼎力相助，整個測試知識和技能的轉移非常順利。

　　旁觀者說：即使電話、QQ、微博等各種溝通方法很方便，也取代不了面對面的溝通。見到“真人”的感覺是不一樣的。

　　毫無保留地做分享

　　回國以后，我們的任務是將學到的知識與技能在整個測試團隊內共享。在共享過程中，我印象最深的是大家毫無保留地將自己學到的知識和技能分享給團隊中的每個人。

　　只要是我懂的，我會主動在團隊內進行分享。我會主動給每個成員講解功能的工作原理，如何搭建測試環境，如何執行測試步驟，如何判斷測試結果等。只有掌握了測試對象的業務和測試知識，他們才能順利完成任務。而對于我來說，整個項目測試的管理與監控也會比較容易。同時，由于測試成員都能學到新的知識，也可以增加他們在團隊內的凝聚力。

　　作為測試的負責人，不要期望自己在所有的方面都比其他人強，你的定位應該是為整個測試團隊服務。如果你能在團隊內帶頭分享自己的知識與經驗，也一定能帶動其他人分享，更好地做好測試團隊的知識與技能的儲備，有利于測試經理更好地分配測試工作，并做好備份工作。

　　旁觀者說：管理者要成為團隊的核心、精神領袖，并不是什么都要比別人強，更不能去壓制別人的“強”。

　　有的人不愿意分享，是擔心別人超過了自己。從實際來看，你今天分享了經驗，同事仍然要花一段時間去消化，并不是說，你一說大家就都到了你的這個程度，還是需要實際操作和慢慢體會的。在這段時間里，你可能又學會了新的東西，所以不必過于擔心。你經常做分享，大家也會因此而尊重你，這對于你在團隊里立足是很有幫助的。

　　旁觀者說：管理者要鼓勵大家分享，甚至可以把分享算入績效。

　　回歸測試不能流于形式

　　測試的工作量主要集中在回歸測試上面，因此，如何選擇合適的測試用例是我在實施整個測試工作中的重點。我們考慮到的重點是：什么功能是客戶最經常使用的；哪些功能對客戶而言是最重要的；哪些功能在以前版本中發現的缺陷是最多的；針對新增加的功能或者升級，對原來的哪些功能和模塊的影響是最大的。

　　回歸測試不應該是流于形式的，應該制定嚴格的回歸測試過程，包括軟件變更分析、軟件變更影響分析、定義回歸測試策略、定義回歸測試套件、執行回歸測試套件，以及報告回歸測試結果等。

　　旁觀者說：常見的做回歸測試的幾條依據：按照功能的重要性來做；按照bug來做；按照新功能（即變化量）來做。這幾條標準往往是同時運用的。

　　推動開發和測試的規范化

　　我們需要對每個增加的功能、升級修改的功能進行詳盡的需求文檔化，作為后續開發測試活動的參考和基線。這樣，可以在后續的開發設計、測試設計等方面擁有共同的輸入和參考點。這對于系統的研發非常重要，這個環節沒有做好，項目的開發將一直處于混亂狀態，例如，系統需求不明確、開發條目不清晰、測試輸出預期沒有標準等，無法保證項目產品的質量。所以，我們和開發一道，推動整個后續開發、測試的規范化，有助于整個測試的順利完成。

　　簡單而言，項目成功轉移的關鍵點是：溝通、分享、合適的測試過程、開發與測試的緊密合作。

　　旁觀者說：表面上開發和測試為了bug會有爭執，其實兩股力量的目標是一致的，都是想做出好產品，所以緊密合作是有可能的，也是應該的

 

成為優秀的測試工程師：勤奮、努力、堅持不懈

　　蔡：如何成為優秀的測試工程師呢？

　　鄭：優秀的測試工程師，不僅需要時間的積累，也需要測試知識、技能和測試經驗等的持續積累。要想成為優秀的測試工程師，至少需要從下面幾個方面不斷地充實自己。

　　第一，深入了解測試對象，即測試人員需要深入了解被測產品的架構、功能與業務知識。對于我自己，我一直從事的是寬帶接入系統與交換功能，因此掌握ADSL、VDSL、以太網交換功能、L2協議標準、三層交換功能、OAM功能等是開展各種測試任務的基礎。

　　第二，熟悉研發流程，即知道在什么時候應該做什么事情。測試人員需要了解每個開發階段的輸出是什么，測試的主要活動與任務有哪些，只有對測試過程中的各種活動與任務了然于心，測試人員才能主動去完成任務，而不是每次被動地等著測試經理給你分配任務。另外，了解每個階段可能存在的問題，可以提前制訂應對計劃。

　　第三，除了知道測試過程中我們需要做什么之外，測試人員需要掌握如何有效地去做，因此需要測試人員深入了解各種軟件測試技術與方法，例如：測試用例設計技術與方法、測試估算方法、測試風險識別與評估方法等。

　　第四，培養各種軟技能，例如溝通與合作。現在更強調整體團隊運作過程，測試人員不僅需要和開發人員溝通與合作，也需要和客戶緊密合作。另外，測試人員還需要培養專業的懷疑態度、嚴密的分析能力、處理沖突的能力、嚴謹的工作態度與創新能力等方面的技能。

　　想成為優秀的測試工程師，勤奮、努力和堅持不懈是非常重要的。

　　猜數字游戲和探索性測試

　　蔡：什么是探索性測試？

　　鄭：探索性測試（Exploratory Testing，ET）是Cem Kaner在1983年提出的，是軟件測試的一種方式。與腳本化測試（Scripted Testing，ST）相比，探索性測試將更高的認知水平放在了測試執行上面，同時更加強調測試人員學習、設計、執行與結果分析等測試活動的并行、相互反饋與相互支持。

　　很多人都玩過猜數字游戲：我預先在心里想好一個1到100之間的數字，你來猜。你可以問任何問題，而我只有兩種回答"是"或"不是"。然后通過你的不斷提問與我的不斷回答，最終猜到我心中想的數字。在猜對的情況下，問的問題越少得分越高。這就是一個典型的探索性測試的例子。測試人員需要根據前面問題的答案分析和設計下一個問題。第一個問題可能不靠譜，但是根據前面問題的不斷反饋和結果分析，你設計的問題將會越來越靠近問題的答案。假如參與者了解二分法，那么最多7次就可以猜中數字。假如不了解二分法，你也可以猜到數字，但是嘗試的次數可能遠多于7次。你的策略、技術與方法，直接決定了你完成任務的速度與質量。

　　探索性測試的過程與猜數字游戲的過程是類似的。游戲中你要猜的數字，就是你要尋找的缺陷或者其他質量信息；你要問的問題，是你分析和設計的測試用例；每個問題的答案，則是測試過程中測試對象的輸出。測試人員面對一個被測試的功能，首先對它有個模糊的概念與范圍，然后不斷地分析、設計和執行測試用例，觀察測試對象的輸出和反應，并以此為基礎判斷下一步的測試用例，獲取缺陷或者其他質量信息。

　　由于探索性測試的不斷探索、不斷分析、不斷反饋的特點，它可以較好地解決腳本化測試中的一些問題，例如，腳本化測試強調盡早的測試設計，但是測試設計越早，測試人員對測試對象的了解越少，對風險的了解越少。測試人員對測試對象的了解是一個逐步的過程，腳本化測試需要更多的工作量以應對這個過程（需求的細化和變更等）。

　　與腳本化測試相比，探索性測試更強調測試人員的思維自由度與主觀能動性。然而，探索性的自由，并不代表它是不做準備的，它也不是隨機的。好的探索性測試依賴于測試人員綜合應用測試策略、測試技術與方法的能力，例如，獲取測試數據，掌握測試設計技術，建立失效模式，創建測試模型等。口號式的探索性測試并不能幫助測試人員成功。探索性測試如下象棋，規則不多。但是我們在欣賞象棋比賽的時候，關注的是在這些規則下選手選擇下一步如何走的技巧與技能，它的技術含量也不在其規則，而在選手的技巧與技能。規則簡單，技巧復雜。

　　旁觀者說：探索性測試的基礎是對測試對象的熟悉。

　　盡管探索性測試可以解決腳本化測試中的一些問題，但我并不認為探索性測試優于腳本化測試，或者將來會誰取代誰的問題。它們之間各有所長，作為測試人員，我們應該做的是根據測試對象特點、組織特點、資源特點等具體情況，如何更好地發揮兩者的各自優點，彌補兩者的不足。

天貓 軟件自動化測試開發