軟體測試的魅力何在？

問題：軟體測試的魅力何在？您為什麼選擇測試一行而不做開發？

　　精彩回答：

　　陳甫鵃：

　　雖然我現在換到開發去了，不過畢竟也在這一行做了六年，貌似還是有機會在這裡發言的吧。最初我接觸測試純粹是出於偶然，微軟到我們學校的面試只有做測試的肯要我啊。不過後來做了一陣子之後慢慢就喜歡上這個位置了。說說我過去的一些經驗吧。

　　正如我之前在很多回複中說的，測試和開發是兩個關注點不一樣的工作。開發的目標是實現功能，測試的目標是確定功能是否能夠正常運作。那麼它的樂趣在哪裡？簡單地說是兩個關鍵詞：“發現”和“分析”。

　　一兩句話很難說清楚，舉一個例子吧。

　　假定你打算寫一個VOIP程式，請問怎麼測試它的效果？沒有經驗的測試可能會告訴你我連上兩台機器確定電話可以打通就可以了，而有經驗的測試可能會給你列出一大堆的組合：

　　1、你的情境支援筆記本和耳機嗎？你支援什麼耳機？藍芽還是3.5mm插口耳機？

　　2、你的情境支援使用筆記本麥克風嗎？還是只支援配麥克風的耳機？

　　3、你的情境支援使用手機裝置嗎？Android還是iOS？

　　為什麼要列出這麼多東西？有人可能會對此嗤之以鼻：只是為了保證什麼都能測到而已。但是其實這裡每一個情境都是有意義的：

　　1、藍芽耳機普遍都有硬體支援的回聲消除模組（Acrostic Echo Cancellation），而普通3.5mm耳機則通常由於結構簡單而沒有。對於沒有回聲消除的普通耳機，我們必須自己提供軟體的回聲消除避免影響接聽效果。

　　2、我們不能使用完全相同的邏輯處理耳機和筆記本麥克風的語音輸入。因為耳機麥克風的定向性比筆記本麥克風強很多，它只能取到聲源湊得很近時發出的聲音，而筆記本麥克風的設計則是用來在螢幕前相當大的範圍內取聲的。如果對筆記本麥克風使用耳機麥克風的聲音檢測演算法則會由於靈敏度過高而將大量周邊雜音收入，影響通話效果。而且有些情境是筆記本麥克風特有的，比如使用者的打字音和風扇噪音。

　　3、Android和iOS都有內建的通話模組。iOS甚至提供了非常高效的回聲消除和增益控制模組，但是沒有靜音檢測模組。所以如果傳統型程式移植到手機上時可以很好地利用這些功能簡化自己的代碼。而Android的回聲消除模組則表現非常不穩定，需要很多調整才能得到較好的效果。

　　這就是所謂的“發現”，發現開發沒注意的地方，發現專案經理沒定義的情境，並提出相應的測試情境。這需要寬廣的知識面才能做到。沒有經驗的測試更傾向於對所有測試的平台做全排列，但求不忽略任何一個情境。這在資源無限的情況下當然沒問題，但真實項目中，測試的資源經常是最有限的，所以我們得學會怎麼做最有效測試，而不是閉著眼睛搞全面鋪開。

　　那麼什麼是“分析”？舉例來說：如果一個內測客戶投訴你的VOIP程式實際使用中聲音斷斷續續，你怎麼分辨問題的原因？聲音斷斷續續的情況有很多種，有由於網路延遲導致的，有由於作業系統處理過於繁忙導致程式執行時間被高優先順序程式搶走而導致的處理中斷產生的。我們怎麼去分析哪些原因呢？沒經驗的測試可能會直接要求跑客戶現場看看，但如果使用者的環境不是每次都重現該怎麼樣？有經驗的測試會提出：我們可以給客戶一個調試用的版本，這個版本要求把資料包的收取時間點和每個資料區段的開始處理時間點和CPU佔用率紀錄下來。通過前一個我們可以測量使用者的網路情況，後一個資料區段可以用來發現是否是作業系統換出導致的。反過來，對產品不熟悉的人，這些資料可能看不出什麼用途。

　　有人說，這些都可以讓開發來做，用不著測試。完全正確。可問題是：開發有時間做這些嗎？在微軟這樣層級的公司裡，所有的項目都有嚴格的開發進度，開發部門忙於實現功能的時候，我想沒幾個產品經理會同意頻頻打斷開發的進度要求停下來做bug分析。

　　另一點是我們不需要把開發與測試的界限分得那麼清楚。事實上大部分如今的跨國IT公司都很少分開發與測試這兩個職位（大約只有微軟還嚴格地分兩個職位吧，即使是這樣，搜尋那邊也開始探索改變了），但是要做的工作還是那麼多，只是頂著的頭銜換了換，所以沒必要糾結。

　　=== 我是轉換話題的分割線 ===

　　另一個問題是關於測試的工作方式的。就像開發一樣，有經驗和沒有經驗的測試在團隊起到的作用是很不一樣的。從測試中遇到問題採取的行動來看，我觀察到的測試人員能達到的層次大概有這麼幾個層級：

　　1、開一個bug；

　　2、尋找一些額外的資料如設計文檔和曆史，確定這是一個問題，然後給出詳細的bug重現步驟；

　　3、對重現步驟做一些精鍊，確定能夠重現bug的最少步驟；可能的話，將重現步驟做自動化；

        4、嘗試通過研究代碼確認問題所在；

　　5、嘗試給出一個fix；

　　6、對錯誤的原因進行分析，提出一些標準化的方法來檢測出類似的問題，比如stress，fuzzing等等；

　　7、能夠對標準化的測試流程定義對應的資料分析方法，可以保證開發和項目主管都能從中得到需要的資訊來掌控品質狀況。

　　那麼作為一個測試人員，我們的目標是什嗎？我對自己的目標是能對我控管的所有的bug從1做到4，在至少兩個例子中我甚至能做到層級6。我在微軟六年多，在很多部門都見到過可以見到可以總是做到層級7的測試，能做到這個狀態的測試，沒有人敢說他們技術不行。對於開發人員來說，如果你身邊有一位能對大部分bug做到層級4的測試，我相信開發的工作也會輕鬆很多。

　　即使是抓bug也分很多種。抓一群猴子來隨便在鍵盤上胡點兩下也算是測試，認認真真地一步步通過各種技術手段（代碼覆蓋、壓力測試、安全分析等等）來步步推進也是測試。作為技術人員，你信任哪一種？我想多數人都會選擇後者，但我要說的是在實踐中很多測試團隊都會不知不覺地變成前一種。為什嗎？因為測試對產品的設計不瞭解，所以本能地會選擇最容易做的，可問起他們：你們測了多少？信心多高？他們就都傻掉了。我不是說猴子測試沒意義：恰恰相反，它可以抓到我們思維上的許多盲點。但如果你的整個團隊完全靠猴子測試過日子，那絕對不可能給你一個可信任的結果。

　　那麼看官們必然會問，這種大牛測試和大牛團隊有多少？很不幸，就我個人的經驗來說，事實是在我遇到的測試人員中，最多隻能做到層級1的測試人員並不罕見，能做到3的測試人員就被很多人認為相當不錯了，至於團隊中存在多個大牛測試的隊伍則真的很少見（微軟總部的比例高很多）。是的，別驚訝，這就是我工作中遇到的情況。但是請注意，這不是說公司在花錢養廢物，而是說在沒有專業測試教育的情況下在入行初期必然會導致的現狀。我們所有人都是從這個狀態開始的，也都需要時間來讓自己進步。

　　也許還會有人問：這不是跟開發搶活兒幹嗎？是的，沒錯。但為什麼不能搶呢？我們的目的是什嗎？是開bug還是做更好的產品？如果你的全部目的只是多開bug，那真的很簡單。真實的例子，我曾經見過將測試自動化代碼的bug開成產品bug的。我知道要求一個同事幹這個幹那個很不禮貌，但這種什麼都不做就先開了bug再說的做事風格是在耽誤所有同事的工作。作為團隊的一分子，測試在產品上多花一分時間，有時候能省下開發幾天的工作量，因為測試是最熟悉這個bug的人，而開發則需要從頭開始分析。

　　——當然，反過來開發也應該盡量將測試帶入開發過程，讓大家都知道各種功能進度的細節。這種合作同樣能大大減少測試在產品設計變更時重新設計用例的時間。

　　有人可能還要問：我的時間也很寶貴，為什麼要替開發省時間？嗯，好問題。但我想誰都知道該怎麼回答這種“問題”。

　　現在知道我為什麼要做六年測試了嗎？

朱杉：

　　和軟體測試遭遇是個偶然，故事有點長，有空且看看作消遣吧。之前在一國企做金融類軟體開發，開vi寫C偶爾還客串VB，終於不堪一年200工作日以上的出差在外和出差期間徹夜加班且無雙休待遇之折磨，一怒之下轉而重回學校作個調整。大學同學所在公司招收實習生，本著賺點學費生活費的需要，抱著沒做過的事情試試無妨的心態，邂逅了軟體測試。研究生期間，學校先後開設了兩門軟體測試的課程，由於有實踐在先，發現學習起來頗有心得。由於老師要求嚴格，第二學期選課人頗少，於是一門大課變成了給少數幾個人開小灶，時間和資源瞬間變得充裕，讓我受益匪淺。而自身的一些觀察、分析、理解、想象能力上的優勢逐漸在這個學習+實踐的過程中體現出來。同時，在實習公司那邊，我開始跟進一個至今說起來都讓大家望而卻步的新功能開發，遇到了開始做測試以來最大的一個挑戰，那絕對是一段痛苦不堪的日子，但也正是這段時間讓我飛速地成長起來，並獲得了大家的認同。畢業後，自然也就留在了這家公司，正式加入了軟體測試的大部隊，似乎也不存在選擇的問題。

　　軟體測試的魅力嘛，其實在你這個問題之前，我也沒有刻意地去想過，況且一百個人眼裡一百個哈姆雷特，大家的癢處也未必在同一處。於是就臨時想到的說上一說，個人色彩濃，可能不太切題了：

　　首先，我喜歡玩解謎類的益智遊戲，而且發現我對這類的遊戲通常上手較快。雖然我說不好這個跟測試具體有什麼關聯，不過有一些感覺是一樣的，觀察、推演、嘗試、歸納、發現，一個妙趣橫生的過程。測試本身也是對這方面能力的一個綜合考驗，拿到一個難題的時候那種又擔心又手癢的感覺實在是和玩遊戲很像。測試的過程又是一個學習和思維進一步發散的過程，一直引領人往前探索，很有吸引力。

　　其次，新鮮感。我做功能測試和可訪問性測試，新功能的探索和發現，是我個人一直愛接新功能勝過做迴歸的主要原因。新工具新技術的發現和學習是個有趣的過程。測試其實是個目的驅動的事情，基於這一點，沒人會要求你從頭造輪子，能拿來用的現成都得學會撿，不然什麼都要從main寫起，黃花菜都涼了。囤新奇工具、學新鮮技術，都是有趣的事情。

　　再者，成就感吧。作為某應用的QA owner和一個dev團隊長期合作，雖然大家也會有爭論，時間緊張的時候也會互有抱怨，但合作非常順暢。只有Dev和QA把發布一個健康的產品當做共同目標而密切合作的時候，才是一個良性的開發生態環境，一個成功發布的產品是大家共同努力的成果，既是dev team的驕傲，也是QA的驕傲，即使走向前台接受讚譽的更多是Dev，你也能因你所做出的貢獻而自信滿滿，成就滿滿。想想，在參與設計討論時指出可能存在的設計缺陷，在功能開發之前提供建議避免功能誤讀和錯誤風險評估，一個描述清晰、根源挖掘準確充分的defect送到dev處被乾淨利落地斬草除根，當support
team來徵詢產品功能的相關問題時，當使用者來尋求解決方案時，是不是都有一種叫成就感的東東在心裡撒了歡地奔走呢。

　　最後，當跟你吵架吵得最凶的開發背著你對別人誇你是最好的QA的時候，那種感動，一輩子都不會忘記的。