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

　　把握軟件的質量 《轉載》

　　蔡：如何把握軟件產品的質量？

　　鄭：不管軟件產品規模是大還是小，結構是簡單還是復雜，對它們質量的評估都不是一件容易的事情。盡管很難，但是產品質量的評估仍然是必需的，因為它也涉及軟件版本是否能夠發布。

　　軟件發布之前做評估

　　根據我和公司內的實踐經驗，可以從下面兩個方面進行評估。

　　第一，軟件產品發布之前的質量評估，具體的度量指標包括：

　　缺陷，包括發現的總的缺陷分布趨勢、缺陷在不同功能模塊中的分布等。例如，總的缺陷分布趨勢圖。

　　測試通過率，主要包括計劃的測試用例執行進度、通過的測試用例數目、失敗的測試用例數目、被阻塞的測試用例數目等。我們項目中定義的測試通過率是95%。

　　測試覆蓋率，包括測試對系統需求的覆蓋率、對測試類型的覆蓋率。例如，我們項目中定義的需求覆蓋率必須達到100%，測試類型覆蓋率也必須達到100%。

　　信心，負責這個模塊的測試人員對質量的主觀感受。可能有的人覺得很奇怪，怎么主觀感受也可以作為產品質量的評估？因為負責功能模塊測試的工程師是最了解他們的測試對象的。

　　旁觀者說：可以設計一個信心指數，例如1～10，然后通過各種數據來支持這個指數。

　　軟件發布之后做評估

　　第二，軟件產品發布之后的質量評估。我們目前采用的度量指標是缺陷檢測百分比DDP（Defect Detected Percentage），其計算公式如下：

　　客戶現場發現的缺陷數 /（發布前測試團隊發現的缺陷數 + 客戶現場發現的缺陷數）* 100%

　　我們一般統計產品發布之后6個月內在客戶現場發現的缺陷數。不同的公司與項目，采用的統計時間范圍會有所不同。

　　旁觀者說：統計客戶發現的bug是有意義的，一是可以據此對客戶做一些分析，例如，經常使用的功能、滿意度等；二是可以用于反思之前的測試活動，以求改進。

　　測試團隊為軟件發布提供質量信息

　　還有一個問題是測試團隊非常關心的：誰來決定軟件產品的發布？從我的角度而言，我認為由測試團隊決定軟件產品是否發布是不合適的。

　　軟件產品是否可以發布，需要有不同角色的成員參與進來，根據公司定義的判定準則進行評估，同時平衡產品質量、市場機會、產品戰略以及成本等多個因素。測試團隊在這個過程中主要的作用是盡量多地提供軟件產品的質量信息、風險信息等，以幫助管理層做出是否發布的決定。任何一個單方面做決定都可能是不全面的。例如，測試人員覺得質量還不夠好，發布有風險；但是市場機會要求我們發布，如果再等一段時間就會減弱市場機會，甚至喪失機會，這個時候就需要考慮哪個因素有更高的優先級。

　　旁觀者說：贊同。軟件發布與否應當綜合各種因素來考慮，而不僅僅是某個角色說了算。

　　新人如何學習軟件測試

　　蔡：對于軟件測試的新手，包括剛進入這個行業的，也包括正在學習、準備進入的，你有什么建議和經驗分享？

　　鄭：對于軟件測試的新手，假如希望在測試行業有所發展，根據我的經驗可以從下面幾個方面入手。

　　1、了解你的測試對象。你首先要知道軟件產品是干什么的，其實現的主要功能是什么，其工作的基本原理和流程等。比如，我一直從事通信產品，除了產品本身的需求資料外，還花了大量的時間學習和鉆研各種通信產品相關的國際標準和行業標準，例如路由協議、IPv6等。

　　2、多向有經驗的人學習。在剛剛入門測試行業的時候，我們應該抱著向各位前輩學習的態度，通過各種形式向有經驗的人員學習，例如，參加培訓、個人交流等。根據測試的特點，學習主要從兩個方面入手。

　　（1）我們應該積極參加項目團隊中的領域知識培訓和交流，也可以直接向系統人員和開發人員詢問產品是如何工作的，具體如何實現等問題，以更快地熟悉和掌握產品知識

去管人還是堅持做技術

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

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

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

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

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

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

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

　　研究測試技術和方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

（2）測試人員向測試團隊中的前輩學習，包括他們在產品知識、測試過程、測試技術與方法等方面的經驗。他們是測試新人學習的最直接的對象，看看他們是如何掌握產品知識的，如何快速有效地找到bug的。

　　3、多實踐，不要怕失敗。不管是測試領域的知識，還是測試技能，或者是測試思想和方法，測試新人都需要勇敢地去實踐，許多經驗、思想和收獲來自于失敗的經驗教訓。

　　旁觀者說：如果真是要丟臉的話，越早越好，越晚越被動。

　　4、勤奮。在我的經驗中，勤奮總是占有非常重要的地位。只要你設定的方向是正確的，想要達到目標，勤奮將是不可或缺的基礎。特別是覺得自己在某方面基礎不好，勤奮可以彌補這方面的不足，我當時入門軟件測試就是這么走過來的。你看到有的人很牛，測試經驗豐富，各方面都懂，那是表象，其實他（她）在背后花了很多時間，你在玩游戲、看電視的時候，他（她）在看書、總結、寫文章。如果我們能夠堅持，每天堅持，這樣一段時間后你就會發現自己與以前大不相同了。

　　旁觀者說：我很相信一句話：天道酬勤。

　　如何面對職業發展的迷茫

　　蔡：你對在軟件測試行業工作了三五年的朋友有什么建議嗎？有的朋友對我說，他覺得有些迷茫。

　　問自己三個問題

　　鄭：在軟件測試行業工作幾年之后，免不了會產生各種不同的迷茫：軟件測試有前途嗎？軟件測試有技術含量嗎？將來是做技術還是做管理？我自己在2005年準備換工作的時候，就對是做技術呢，還是去找測試管理的職位有過迷茫。盡管現在已經選擇技術方向很多年了，有時候還是會迷茫：測試技術真的能順利走下去嗎？

　　在面對這些迷茫的時候，我就會問自己：

　　（1）你喜歡做技術還是做管理？我喜歡做技術。

　　（2）你的目標是什么？我希望將來成為測試專家。

　　（3）目前的工作和活動能幫助你達成這個目標嗎？是的。

　　旁觀者說：簡單直接的三個問題，就像程咬金的三板斧，蠻有威力的，你可以試試。

　　基于這些問題的內心回答，我會不斷給自己加油，并鼓勵自己繼續往前走。我幾乎每天都會反省自己當天的工作，有了哪些收獲，有了什么總結，多少時間又被浪費了等。通過這樣的形式，不斷提升自己的信心，提高學習的效率和有效性。

　　旁觀者說：能夠做到每天反省和總結，不簡單，值得學習。孔子說，吾三省吾身。或許可以這樣說，無論做什么事情，比如鍛煉、減肥、寫日記、練字、學習等，如果能夠堅持每天做，都了不起。

　　分享周圍幾個朋友在職業發展方面的例子

　　我與大家分享一下我對下面幾個迷茫問題的建議。

　　1、到底是做技術還是做管理工作？希望讀者可以從我前面的工作經歷中得到一些啟發：做自己喜歡做的事情，勤奮加堅持，你會發現你可以逐步走向成功，不管是做技術還是做管理。

　　2、軟件測試有前途嗎？這個問題應該是每個測試從業人員所關心的話題。假如大家因為這個問題而覺得迷茫，我和大家分享我周圍幾個朋友的例子，測試同樣可以成就你的未來。

　　（1）以前公司的某個測試部門經理，現在是某公司重慶研究所的所長。測試的職業發展也可以是有高度的，而不是說測試經理就是測試人員的終極目標。

　　（2）以前公司的某位測試工程師，在2005年換工作的時候，找到的職位是產品經理。測試人員的優勢是對軟件產品的工作原理、工作環境與客戶最關注什么等有充分的了解，因此產品經理是你可以努力的一個方向。

　　（3）以前公司的某位測試工程師，首先從事測試工作，在換工作的時候應聘了軟件開發的工作，在第二次跳槽的時候選擇了項目經理的職位。由于有明確的職業規劃，在對測試與開發有了深入了解之后，再加上項目管理的知識、技能與經驗，測試人員成為項目經理是可以的。

　　（4）另外，在我們周圍有不少獨立的測試專家、咨詢師等，他們不斷出書、寫文章，參加各種大會做報告，受邀為公司開展企業咨詢工作等，這同樣是你可以選擇的一條路。

　　旁觀者說：他山之石，可以攻玉。上面幾個例子雖然簡單，但是仍有可借鑒的地方。

要懂得如何思考和分析

　　3、軟件測試有技術含量嗎？很多人都認為軟件開發有技術含量，而軟件測試就是點點鼠標，按照需求檢查工作產品，所以沒有什么技術含量。實際情況是這樣嗎？這讓我想起了一個故事：某公司的發電機出現了故障，請了一位經驗豐富的工程師進行維修，他在機器上東敲敲、西敲敲，在某個地方畫了一個圈，將其中的一個線圈換掉后發電機就正常工作了。收取了1000美元的費用。公司老總覺得費用太貴，不就是換了一個線圈嗎？維修工程師回答說：“換個線圈只要1美元，找到哪里的線圈更換需要999美元。”很多人只是看到了表象，測試人員坐在那里點點鼠標，提交了一個缺陷。但是技術含量不是測試人員點點鼠標，而是測試人員為什么點鼠標，鼠標點在哪里，要點幾次，即測試人員是如何思考的、如何分析的。這才是人與人之間的最大不同，也是測試人員真正的價值所在。優秀的測試人員與平庸的測試人員之間的最大區別在于前者更懂得如何思考和分析。

　　旁觀者說：努力成為專家型的人才，符合個人利益，也符合公司利益，雙贏。

　　如何做好測試用例的設計

　　蔡：如何做好測試用例的設計呢？

　　鄭：測試用例設計是每個測試從業人員最主要的測試活動之一。為了做好測試用例的設計，我們必須考慮下面幾個因素。

　　明確參考輸入

　　第一，做好測試用例設計，需要首先明確它有哪些參考輸入。以我為例，我是做系統測試的，因此測試對象的需求規格說明是最主要的測試設計參考。但是實際面臨的問題是需求常常不完善，因此純粹依賴于需求規格說明肯定是不全面的。根據我的經驗，下面的這些輸入也應該經常考慮：用戶需求、開發文檔、標準與規范、測試經驗知識庫等。

　　測試經驗知識庫是測試人員以前做類似項目的測試經驗、收集與分析的缺陷類型分類等，都是開展測試用例設計的基礎。例如，我們的測試用例模板中的測試類型定義，除了參考ISO 9126質量模型 ，其中的重要輸入就是以前項目的測試經驗和缺陷分類分析。

　　旁觀者說：有多少公司收集和存儲了項目的歷史數據？又是否做了分析和利用？

　　關注功能之間的交互

　　第二，做好測試用例設計，除了考慮被測對象功能之外，也需要關注被測功能與其他功能模塊之間的交互。由于每個測試人員負責各自的功能模塊，往往會導致整個測試對象不同功能模塊之間的接口、相互作用和耦合等分析不夠充分，而這些是影響測試對象質量的重要因素。例如，在我們當前的項目中，通用的交互測試點有主備倒換、內存使用、內存泄漏、CPU使用、數據備份/恢復、版本升級、系統重啟等。

　　旁觀者說：相對于開發人員來說，功能交互是測試人員的優勢，我們要在這方面好好發揮。

　　采用合適的設計技術與方法

　　第三，有了測試用例設計的輸入與交互分析之后，采用合適的測試用例設計技術與方法，有助于做好測試用例的分析。根據《軟件測試設計》中提出的“問題驅動的軟件測試設計”觀點，可以從下面四個方面考慮進行測試設計，以解決測試設計中面臨的問題。

　　1、挑戰1：被測對象的邏輯組合和輸入數據的組合是非常龐大的，而窮盡測試是不可能的。經典測試設計中的一些技術與方法，在保證測試覆蓋率與質量的情況下，對減少測試用例的數目是非常有效的。例如，在項目測試中引入了“組合測試”技術。

　　2、挑戰2：軟件產品的不同利益相關者對產品的質量要求是不一樣的，如何滿足他們各自的質量要求？基于質量特性的測試設計有助于我們選擇合適的質量特性。測試設計中要求100%的測試類型覆蓋率，可以更好地滿足不同利益相關者對質量的不同要求。

　　3、挑戰3：測試時間與資源總是非常有限的，如何平衡測試時間、成本與質量之間的關系是每個測試人員都需要考慮的。基于風險的測試設計可以幫助我們有效地解決這個問題。例如，先給模塊確定測試優先級，然后分析每個模塊存在的主要風險，并按照不同風險級別開展測試設計活動，以盡快盡早發現嚴重程度高的缺陷。

　　4、挑戰4：測試人員面對的需求經常是不完善的、經常變更的。除了前面提到的完善測試用例設計的參考輸入之外，基于經驗的測試設計也可以幫助測試人員在這種情況下做得更好。例如，根據以前發現的缺陷和用戶現場反饋的缺陷，進行缺陷分類分析和評估。另一個策略是更多地采用探索性測試，更好地發揮測試人員的主觀能動性與分析能力

做好評審

　　第四，在測試用例設計過程中，發揮團隊的力量分析和評審測試點，其得到的效率和有效性會更好。例如，通過在測試分析與設計過程中應用思維導圖 工具，幫助我們拓寬測試思路，增加測試條目。測試團隊的放射性思維可以很好地幫助我們提升測試用例設計的效率和有效性。

　　測試用例的顆粒度沒有嚴格的標準，我的觀點是只要它們滿足測試目的，符合產品特點、開發特點和測試過程等要求，有助于我們更好地發現缺陷和開展測試活動，測試用例的顆粒度就是合適的。

　　如何做好測試用例的評審

　　蔡：測試用例的評審一直是個問題。如何做好評審呢？

　　鄭：測試用例是測試人員最重要的輸出之一，也是后續開展測試執行與評估的基礎。評審應該是開發過程中比較有爭議的關鍵域，現實中存在矛盾：不做評審，這又是一個強制活動；開展評審吧，效果很一般，甚至得不到有用的評審建議，浪費時間。

　　結合我自己在評審方面的經驗教訓，做好測試用例的評審，下面是我的幾個建議。

　　合適的評審團人選

　　第一，選擇合適的人參與測試用例評審。例如，我們在做測試用例評審的時候，強制參與的評審人員有該功能的系統人員（他定義具體的需求）、開發人員以及測試架構師等。每個人參與測試用例評審的關注點是不一樣的，例如，測試架構師關注測試類型的覆蓋率方面，而開發人員和系統人員關注測試用例是否覆蓋業務場景與不同功能模塊之間的交互等。另外，語法、拼寫、排版等方面的問題應該關注，但不應該是評審的重點。

　　管理層的支持

　　第二，管理層的支持。有效的評審是需要時間與資源的。例如，在我們公司的火車開發模型下，針對測試用例的評審是強制的，而且定義了評審的入口準則與出口準則；而且在做項目計劃的時候，測試用例評審作為一個重要的活動，也相應地進行了工作量的估算和時間進度安排，這些都需要管理層的支持。

　　做好準備

　　第三，評審人員的準備，這是有效評審的關鍵所在。例如，我們針對測試用例的評審，定義了評審檢查表，包括：測試類型覆蓋、系統需求覆蓋、測試用例模板符合程度檢查等，這有助于有效開展測試用例的評審，也可以集中評審的重點。

　　旁觀者說：即使我們要求不了別人，至少可以要求自己，評審前做些準備。

　　宣傳評審的價值

　　第四，讓更多的人明白測試盡早介入（評審）的意義。很多時候，大家不愿意積極參與評審，除了時間和資源方面的原因，主要是大家對評審的優點沒有直觀的感覺和定量的數據。例如，提高質量、降低成本、加快進度與過程改進等。只有認可了這些優點，大家參與評審才能更加自覺、有效。

　　我舉一個寫作的例子。我與馬均飛在寫作《軟件測試管理》與《軟件測試設計》過程中，對書稿進行交叉評審。評審過程中的討論與交流，不僅使得我們對寫作內容有更多的理解并達成一致，而且可以使內容更加全面、完善。評審取得成功的主要因素包括：選擇合適的評審人員、每個人準備充分、時間與資源有保證，特別是認識到評審對作品（產品）的重要意義！

天貓 軟件自動化測試開發