中國軟件測試專家訪談錄（1）
把握軟件的質量
蔡：如何把握軟件產品的質量？
鄭：不管軟件產品規模是大還是小，結構是簡單還是復雜，對它們質量的評估都不是一件容易的事情。盡管很難，但是產品質量的評估仍然是必需的，因為它也涉及軟件版本是否能夠發布。
軟件發布之前做評估
根據我和公司內的實踐經驗，可以從下面兩個方面進行評估。
第一，軟件產品發布之前的質量評估，具體的度量指標包括：
缺陷，包括發現的總的缺陷分布趨勢、缺陷在不同功能模塊中的分布等。例如，總的缺陷分布趨勢圖。
測試通過率，主要包括計劃的測試用例執行進度、通過的測試用例數目、失敗的測試用例數目、被阻塞的測試用例數目等。我們項目中定義的測試通過率是95%。
測試覆蓋率，包括測試對系統需求的覆蓋率、對測試類型的覆蓋率。例如，我們項目中定義的需求覆蓋率必須達到100%，測試類型覆蓋率也必須達到100%。
信心，負責這個模塊的測試人員對質量的主觀感受。可能有的人覺得很奇怪，怎么主觀感受也可以作為產品質量的評估？因為負責功能模塊測試的工程師是最了解他們的測試對象的。
旁觀者說：可以設計一個信心指數，例如1～10，然后通過各種數據來支持這個指數。
軟件發布之后做評估
第二，軟件產品發布之后的質量評估。我們目前采用的度量指標是缺陷檢測百分比DDP（Defect Detected Percentage），其計算公式如下：
客戶現場發現的缺陷數 /（發布前測試團隊發現的缺陷數 + 客戶現場發現的缺陷數）* 100%
我們一般統計產品發布之后6個月內在客戶現場發現的缺陷數。不同的公司與項目，采用的統計時間范圍會有所不同。
旁觀者說：統計客戶發現的bug是有意義的，一是可以據此對客戶做一些分析，例如，經常使用的功能、滿意度等；二是可以用于反思之前的測試活動，以求改進。
測試團隊為軟件發布提供質量信息
還有一個問題是測試團隊非常關心的：誰來決定軟件產品的發布？從我的角度而言，我認為由測試團隊決定軟件產品是否發布是不合適的。
軟件產品是否可以發布，需要有不同角色的成員參與進來，根據公司定義的判定準則進行評估，同時平衡產品質量、市場機會、產品戰略以及成本等多個因素。測試團隊在這個過程中主要的作用是盡量多地提供軟件產品的質量信息、風險信息等，以幫助管理層做出是否發布的決定。任何一個單方面做決定都可能是不全面的。例如，測試人員覺得質量還不夠好，發布有風險；但是市場機會要求我們發布，如果再等一段時間就會減弱市場機會，甚至喪失機會，這個時候就需要考慮哪個因素有更高的優先級。
旁觀者說：贊同。軟件發布與否應當綜合各種因素來考慮，而不僅僅是某個角色說了算。
新人如何學習軟件測試
蔡：對于軟件測試的新手，包括剛進入這個行業的，也包括正在學習、準備進入的，你有什么建議和經驗分享？
鄭：對于軟件測試的新手，假如希望在測試行業有所發展，根據我的經驗可以從下面幾個方面入手。
1、了解你的測試對象。你首先要知道軟件產品是干什么的，其實現的主要功能是什么，其工作的基本原理和流程等。比如，我一直從事通信產品，除了產品本身的需求資料外，還花了大量的時間學習和鉆研各種通信產品相關的國際標準和行業標準，例如路由協議、IPv6等。
2、多向有經驗的人學習。在剛剛入門測試行業的時候，我們應該抱著向各位前輩學習的態度，通過各種形式向有經驗的人員學習，例如，參加培訓、個人交流等。根據測試的特點，學習主要從兩個方面入手。
?。?）我們應該積極參加項目團隊中的領域知識培訓和交流，也可以直接向系統人員和開發人員詢問產品是如何工作的，具體如何實現等問題，以更快地熟悉和掌握產品知識。
（2）測試人員向測試團隊中的前輩學習，包括他們在產品知識、測試過程、測試技術與方法等方面的經驗。他們是測試新人學習的最直接的對象，看看他們是如何掌握產品知識的，如何快速有效地找到bug的。
3、多實踐，不要怕失敗。不管是測試領域的知識，還是測試技能，或者是測試思想和方法，測試新人都需要勇敢地去實踐，許多經驗、思想和收獲來自于失敗的經驗教訓。
旁觀者說：如果真是要丟臉的話，越早越好，越晚越被動。
4、勤奮。在我的經驗中，勤奮總是占有非常重要的地位。只要你設定的方向是正確的，想要達到目標，勤奮將是不可或缺的基礎。特別是覺得自己在某方面基礎不好，勤奮可以彌補這方面的不足，我當時入門軟件測試就是這么走過來的。你看到有的人很牛，測試經驗豐富，各方面都懂，那是表象，其實他（她）在背后花了很多時間，你在玩游戲、看電視的時候，他（她）在看書、總結、寫文章。如果我們能夠堅持，每天堅持，這樣一段時間后你就會發現自己與以前大不相同了。
旁觀者說：我很相信一句話：天道酬勤。
如何面對職業發展的迷茫
蔡：你對在軟件測試行業工作了三五年的朋友有什么建議嗎？有的朋友對我說，他覺得有些迷茫。
問自己三個問題
鄭：在軟件測試行業工作幾年之后，免不了會產生各種不同的迷茫：軟件測試有前途嗎？軟件測試有技術含量嗎？將來是做技術還是做管理？我自己在2005年準備換工作的時候，就對是做技術呢，還是去找測試管理的職位有過迷茫。盡管現在已經選擇技術方向很多年了，有時候還是會迷茫：測試技術真的能順利走下去嗎？
在面對這些迷茫的時候，我就會問自己：
?。?）你喜歡做技術還是做管理？我喜歡做技術。
?。?）你的目標是什么？我希望將來成為測試專家。
（3）目前的工作和活動能幫助你達成這個目標嗎？是的。
旁觀者說：簡單直接的三個問題，就像程咬金的三板斧，蠻有威力的，你可以試試。
基于這些問題的內心回答，我會不斷給自己加油，并鼓勵自己繼續往前走。我幾乎每天都會反省自己當天的工作，有了哪些收獲，有了什么總結，多少時間又被浪費了等。通過這樣的形式，不斷提升自己的信心，提高學習的效率和有效性。
旁觀者說：能夠做到每天反省和總結，不簡單，值得學習。孔子說，吾三省吾身。或許可以這樣說，無論做什么事情，比如鍛煉、減肥、寫日記、練字、學習等，如果能夠堅持每天做，都了不起。
分享周圍幾個朋友在職業發展方面的例子
我與大家分享一下我對下面幾個迷茫問題的建議。
1、到底是做技術還是做管理工作？希望讀者可以從我前面的工作經歷中得到一些啟發：做自己喜歡做的事情，勤奮加堅持，你會發現你可以逐步走向成功，不管是做技術還是做管理。
2、軟件測試有前途嗎？這個問題應該是每個測試從業人員所關心的話題。假如大家因為這個問題而覺得迷茫，我和大家分享我周圍幾個朋友的例子，測試同樣可以成就你的未來。
（1）以前公司的某個測試部門經理，現在是某公司重慶研究所的所長。測試的職業發展也可以是有高度的，而不是說測試經理就是測試人員的終極目標。
?。?）以前公司的某位測試工程師，在2005年換工作的時候，找到的職位是產品經理。測試人員的優勢是對軟件產品的工作原理、工作環境與客戶最關注什么等有充分的了解，因此產品經理是你可以努力的一個方向。
?。?）以前公司的某位測試工程師，首先從事測試工作，在換工作的時候應聘了軟件開發的工作，在第二次跳槽的時候選擇了項目經理的職位。由于有明確的職業規劃，在對測試與開發有了深入了解之后，再加上項目管理的知識、技能與經驗，測試人員成為項目經理是可以的。
?。?）另外，在我們周圍有不少獨立的測試專家、咨詢師等，他們不斷出書、寫文章，參加各種大會做報告，受邀為公司開展企業咨詢工作等，這同樣是你可以選擇的一條路。
旁觀者說：他山之石，可以攻玉。上面幾個例子雖然簡單，但是仍有可借鑒的地方。
要懂得如何思考和分析
3、軟件測試有技術含量嗎？很多人都認為軟件開發有技術含量，而軟件測試就是點點鼠標，按照需求檢查工作產品，所以沒有什么技術含量。實際情況是這樣嗎？這讓我想起了一個故事：某公司的發電機出現了故障，請了一位經驗豐富的工程師進行維修，他在機器上東敲敲、西敲敲，在某個地方畫了一個圈，將其中的一個線圈換掉后發電機就正常工作了。收取了1000美元的費用。公司老總覺得費用太貴，不就是換了一個線圈嗎？維修工程師回答說：“換個線圈只要1美元，找到哪里的線圈更換需要999美元。”很多人只是看到了表象，測試人員坐在那里點點鼠標，提交了一個缺陷。但是技術含量不是測試人員點點鼠標，而是測試人員為什么點鼠標，鼠標點在哪里，要點幾次，即測試人員是如何思考的、如何分析的。這才是人與人之間的最大不同，也是測試人員真正的價值所在。優秀的測試人員與平庸的測試人員之間的最大區別在于前者更懂得如何思考和分析。
旁觀者說：努力成為專家型的人才，符合個人利益，也符合公司利益，雙贏。
如何做好測試用例的設計
蔡：如何做好測試用例的設計呢？
鄭：測試用例設計是每個測試從業人員最主要的測試活動之一。為了做好測試用例的設計，我們必須考慮下面幾個因素。
明確參考輸入
第一，做好測試用例設計，需要首先明確它有哪些參考輸入。以我為例，我是做系統測試的，因此測試對象的需求規格說明是最主要的測試設計參考。但是實際面臨的問題是需求常常不完善，因此純粹依賴于需求規格說明肯定是不全面的。根據我的經驗，下面的這些輸入也應該經?？紤]：用戶需求、開發文檔、標準與規范、測試經驗知識庫等。
測試經驗知識庫是測試人員以前做類似項目的測試經驗、收集與分析的缺陷類型分類等，都是開展測試用例設計的基礎。例如，我們的測試用例模板中的測試類型定義，除了參考ISO 9126質量模型 ，其中的重要輸入就是以前項目的測試經驗和缺陷分類分析。
旁觀者說：有多少公司收集和存儲了項目的歷史數據？又是否做了分析和利用？
關注功能之間的交互
第二，做好測試用例設計，除了考慮被測對象功能之外，也需要關注被測功能與其他功能模塊之間的交互。由于每個測試人員負責各自的功能模塊，往往會導致整個測試對象不同功能模塊之間的接口、相互作用和耦合等分析不夠充分，而這些是影響測試對象質量的重要因素。例如，在我們當前的項目中，通用的交互測試點有主備倒換、內存使用、內存泄漏、CPU使用、數據備份/恢復、版本升級、系統重啟等。
旁觀者說：相對于開發人員來說，功能交互是測試人員的優勢，我們要在這方面好好發揮。
采用合適的設計技術與方法
第三，有了測試用例設計的輸入與交互分析之后，采用合適的測試用例設計技術與方法，有助于做好測試用例的分析。根據《軟件測試設計》中提出的“問題驅動的軟件測試設計”觀點，可以從下面四個方面考慮進行測試設計，以解決測試設計中面臨的問題。
1、挑戰1：被測對象的邏輯組合和輸入數據的組合是非常龐大的，而窮盡測試是不可能的。經典測試設計中的一些技術與方法，在保證測試覆蓋率與質量的情況下，對減少測試用例的數目是非常有效的。例如，在項目測試中引入了“組合測試”技術。
2、挑戰2：軟件產品的不同利益相關者對產品的質量要求是不一樣的，如何滿足他們各自的質量要求？基于質量特性的測試設計有助于我們選擇合適的質量特性。測試設計中要求100%的測試類型覆蓋率，可以更好地滿足不同利益相關者對質量的不同要求。
3、挑戰3：測試時間與資源總是非常有限的，如何平衡測試時間、成本與質量之間的關系是每個測試人員都需要考慮的。基于風險的測試設計可以幫助我們有效地解決這個問題。例如，先給模塊確定測試優先級，然后分析每個模塊存在的主要風險，并按照不同風險級別開展測試設計活動，以盡快盡早發現嚴重程度高的缺陷。
4、挑戰4：測試人員面對的需求經常是不完善的、經常變更的。除了前面提到的完善測試用例設計的參考輸入之外，基于經驗的測試設計也可以幫助測試人員在這種情況下做得更好。例如，根據以前發現的缺陷和用戶現場反饋的缺陷，進行缺陷分類分析和評估。另一個策略是更多地采用探索性測試，更好地發揮測試人員的主觀能動性與分析能力。
做好評審
第四，在測試用例設計過程中，發揮團隊的力量分析和評審測試點，其得到的效率和有效性會更好。例如，通過在測試分析與設計過程中應用思維導圖 工具，幫助我們拓寬測試思路，增加測試條目。測試團隊的放射性思維可以很好地幫助我們提升測試用例設計的效率和有效性。
測試用例的顆粒度沒有嚴格的標準，我的觀點是只要它們滿足測試目的，符合產品特點、開發特點和測試過程等要求，有助于我們更好地發現缺陷和開展測試活動，測試用例的顆粒度就是合適的。
如何做好測試用例的評審
蔡：測試用例的評審一直是個問題。如何做好評審呢？
鄭：測試用例是測試人員最重要的輸出之一，也是后續開展測試執行與評估的基礎。評審應該是開發過程中比較有爭議的關鍵域，現實中存在矛盾：不做評審，這又是一個強制活動；開展評審吧，效果很一般，甚至得不到有用的評審建議，浪費時間。
結合我自己在評審方面的經驗教訓，做好測試用例的評審，下面是我的幾個建議。
合適的評審團人選
第一，選擇合適的人參與測試用例評審。例如，我們在做測試用例評審的時候，強制參與的評審人員有該功能的系統人員（他定義具體的需求）、開發人員以及測試架構師等。每個人參與測試用例評審的關注點是不一樣的，例如，測試架構師關注測試類型的覆蓋率方面，而開發人員和系統人員關注測試用例是否覆蓋業務場景與不同功能模塊之間的交互等。另外，語法、拼寫、排版等方面的問題應該關注，但不應該是評審的重點。
管理層的支持
第二，管理層的支持。有效的評審是需要時間與資源的。例如，在我們公司的火車開發模型下，針對測試用例的評審是強制的，而且定義了評審的入口準則與出口準則；而且在做項目計劃的時候，測試用例評審作為一個重要的活動，也相應地進行了工作量的估算和時間進度安排，這些都需要管理層的支持。
做好準備
第三，評審人員的準備，這是有效評審的關鍵所在。例如，我們針對測試用例的評審，定義了評審檢查表，包括：測試類型覆蓋、系統需求覆蓋、測試用例模板符合程度檢查等，這有助于有效開展測試用例的評審，也可以集中評審的重點。
旁觀者說：即使我們要求不了別人，至少可以要求自己，評審前做些準備。
宣傳評審的價值
第四，讓更多的人明白測試盡早介入（評審）的意義。很多時候，大家不愿意積極參與評審，除了時間和資源方面的原因，主要是大家對評審的優點沒有直觀的感覺和定量的數據。例如，提高質量、降低成本、加快進度與過程改進等。只有認可了這些優點，大家參與評審才能更加自覺、有效。
我舉一個寫作的例子。我與馬均飛在寫作《軟件測試管理》與《軟件測試設計》過程中，對書稿進行交叉評審。評審過程中的討論與交流，不僅使得我們對寫作內容有更多的理解并達成一致，而且可以使內容更加全面、完善。評審取得成功的主要因素包括：選擇合適的評審人員、每個人準備充分、時間與資源有保證，特別是認識到評審對作品（產品）的重要意義！
?。ㄎ赐甏m）