問題：軟件測試的魅力何在？您為什么選擇測試一行而不做開發(fā)？
精彩回答：
陳甫鸼：
雖然我現(xiàn)在換到開發(fā)去了，不過畢竟也在這一行做了六年，貌似還是有機(jī)會在這里發(fā)言的吧。最初我接觸測試純粹是出于偶然，微軟到我們學(xué)校的面試只有做測試的肯要我啊。不過后來做了一陣子之后慢慢就喜歡上這個位置了。說說我過去的一些經(jīng)驗(yàn)吧。
正如我之前在很多回復(fù)中說的，測試和開發(fā)是兩個關(guān)注點(diǎn)不一樣的工作。開發(fā)的目標(biāo)是實(shí)現(xiàn)功能，測試的目標(biāo)是確定功能是否能夠正常運(yùn)作。那么它的樂趣在哪里？簡單地說是兩個關(guān)鍵詞：“發(fā)現(xiàn)”和“分析”。
一兩句話很難說清楚，舉一個例子吧。
假定你打算寫一個VOIP程序，請問怎么測試它的效果？沒有經(jīng)驗(yàn)的測試可能會告訴你我連上兩臺機(jī)器確定電話可以打通就可以了，而有經(jīng)驗(yàn)的測試可能會給你列出一大堆的組合：
1、你的場景支持筆記本和耳機(jī)么？你支持什么耳機(jī)？藍(lán)牙還是3.5mm插口耳機(jī)？
2、你的場景支持使用筆記本麥克風(fēng)么？還是只支持配麥克風(fēng)的耳機(jī)？
3、你的場景支持使用手機(jī)設(shè)備么？Android還是iOS？
為什么要列出這么多東西？有人可能會對此嗤之以鼻：只是為了保證什么都能測到而已。但是其實(shí)這里每一個場景都是有意義的：
1、藍(lán)牙耳機(jī)普遍都有硬件支持的回聲消除模塊（Acrostic Echo Cancellation），而普通3.5mm耳機(jī)則通常由于結(jié)構(gòu)簡單而沒有。對于沒有回聲消除的普通耳機(jī)，我們必須自己提供軟件的回聲消除避免影響接聽效果。
2、我們不能使用完全相同的邏輯處理耳機(jī)和筆記本麥克風(fēng)的語音輸入。因?yàn)槎鷻C(jī)麥克風(fēng)的定向性比筆記本麥克風(fēng)強(qiáng)很多，它只能取到聲源湊得很近時發(fā)出的聲音，而筆記本麥克風(fēng)的設(shè)計(jì)則是用來在屏幕前相當(dāng)大的范圍內(nèi)取聲的。如果對筆記本麥克風(fēng)使用耳機(jī)麥克風(fēng)的聲音檢測算法則會由于靈敏度過高而將大量周邊雜音收入，影響通話效果。而且有些場景是筆記本麥克風(fēng)特有的，比如用戶的打字音和風(fēng)扇噪音。
3、Android和iOS都有內(nèi)建的通話模塊。iOS甚至提供了非常高效的回聲消除和增益控制模塊，但是沒有靜音檢測模塊。所以如果桌面程序移植到手機(jī)上時可以很好地利用這些功能簡化自己的代碼。而Android的回聲消除模塊則表現(xiàn)非常不穩(wěn)定，需要很多調(diào)整才能得到較好的效果。
這就是所謂的“發(fā)現(xiàn)”，發(fā)現(xiàn)開發(fā)沒注意的地方，發(fā)現(xiàn)項(xiàng)目經(jīng)理沒定義的場景，并提出相應(yīng)的測試場景。這需要寬廣的知識面才能做到。沒有經(jīng)驗(yàn)的測試更傾向于對所有測試的平臺做全排列，但求不忽略任何一個場景。這在資源無限的情況下當(dāng)然沒問題，但真實(shí)項(xiàng)目中，測試的資源經(jīng)常是最有限的，所以我們得學(xué)會怎么做最有效的測試，而不是閉著眼睛搞全面鋪開。
那么什么是“分析”？舉例來說：如果一個內(nèi)測客戶投訴你的VOIP程序?qū)嶋H使用中聲音斷斷續(xù)續(xù)，你怎么分辨問題的原因？聲音斷斷續(xù)續(xù)的情況有很多種，有由于網(wǎng)絡(luò)延遲導(dǎo)致的，有由于操作系統(tǒng)處理過于繁忙導(dǎo)致程序執(zhí)行時間被高優(yōu)先級程序搶走而導(dǎo)致的處理中斷產(chǎn)生的。我們怎么去分析哪些原因呢？沒經(jīng)驗(yàn)的測試可能會直接要求跑客戶現(xiàn)場看看，但如果用戶的環(huán)境不是每次都重現(xiàn)該怎么樣？有經(jīng)驗(yàn)的測試會提出：我們可以給客戶一個調(diào)試用的版本，這個版本要求把數(shù)據(jù)包的收取時間點(diǎn)和每個數(shù)據(jù)段的開始處理時間點(diǎn)和CPU占用率紀(jì)錄下來。通過前一個我們可以測量用戶的網(wǎng)絡(luò)情況，后一個數(shù)據(jù)段可以用來發(fā)現(xiàn)是否是操作系統(tǒng)換出導(dǎo)致的。反過來，對產(chǎn)品不熟悉的人，這些數(shù)據(jù)可能看不出什么用途。
有人說，這些都可以讓開發(fā)來做，用不著測試。完全正確。可問題是：開發(fā)有時間做這些么？在微軟這樣級別的公司里，所有的項(xiàng)目都有嚴(yán)格的開發(fā)進(jìn)度，開發(fā)部門忙于實(shí)現(xiàn)功能的時候，我想沒幾個產(chǎn)品經(jīng)理會同意頻頻打斷開發(fā)的進(jìn)度要求停下來做bug分析。
另一點(diǎn)是我們不需要把開發(fā)和測試的界限分得那么清楚。事實(shí)上大部分如今的跨國IT公司都很少分開發(fā)和測試這兩個職位（大約只有微軟還嚴(yán)格地分兩個職位吧，即使是這樣，搜索那邊也開始探索改變了），但是要做的工作還是那么多，只是頂著的頭銜換了換，所以沒必要糾結(jié)。
=== 我是轉(zhuǎn)換話題的分割線 ===
另一個問題是關(guān)于測試的工作方式的。就像開發(fā)一樣，有經(jīng)驗(yàn)和沒有經(jīng)驗(yàn)的測試在團(tuán)隊(duì)起到的作用是很不一樣的。從測試中遇到問題采取的行動來看，我觀察到的測試人員能達(dá)到的層次大概有這么幾個級別：
1、開一個bug；
2、查找一些額外的資料如設(shè)計(jì)文檔和歷史，確定這是一個問題，然后給出詳細(xì)的bug重現(xiàn)步驟；
3、對重現(xiàn)步驟做一些精煉，確定能夠重現(xiàn)bug的最少步驟；可能的話，將重現(xiàn)步驟做自動化；
4、嘗試通過研究代碼確認(rèn)問題所在；
5、嘗試給出一個fix；
6、對錯誤的原因進(jìn)行分析，提出一些標(biāo)準(zhǔn)化的方法來檢測出類似的問題，比如stress，fuzzing等等；
7、能夠?qū)?biāo)準(zhǔn)化的測試流程定義對應(yīng)的數(shù)據(jù)分析方法，可以保證開發(fā)和項(xiàng)目主管都能從中得到需要的信息來掌控質(zhì)量狀況。
那么作為一個測試人員，我們的目標(biāo)是什么？我對自己的目標(biāo)是能對我控管的所有的bug從1做到4，在至少兩個例子中我甚至能做到級別6。我在微軟六年多，在很多部門都見到過可以見到可以總是做到級別7的測試，能做到這個狀態(tài)的測試，沒有人敢說他們技術(shù)不行。對于開發(fā)人員來說，如果你身邊有一位能對大部分bug做到級別4的測試，我相信開發(fā)的工作也會輕松很多。
即使是抓bug也分很多種。抓一群猴子來隨便在鍵盤上胡點(diǎn)兩下也算是測試，認(rèn)認(rèn)真真地一步步通過各種技術(shù)手段（代碼覆蓋、壓力測試、安全分析等等）來步步推進(jìn)也是測試。作為技術(shù)人員，你信任哪一種？我想多數(shù)人都會選擇后者，但我要說的是在實(shí)踐中很多測試團(tuán)隊(duì)都會不知不覺地變成前一種。為什么？因?yàn)闇y試對產(chǎn)品的設(shè)計(jì)不了解，所以本能地會選擇最容易做的，可問起他們：你們測了多少？信心多高？他們就都傻掉了。我不是說猴子測試沒意義：恰恰相反，它可以抓到我們思維上的許多盲點(diǎn)。但如果你的整個團(tuán)隊(duì)完全靠猴子測試過日子，那絕對不可能給你一個可信任的結(jié)果。
那么看官們必然會問，這種大牛測試和大牛團(tuán)隊(duì)有多少？很不幸，就我個人的經(jīng)驗(yàn)來說，事實(shí)是在我遇到的測試人員中，最多只能做到級別1的測試人員并不罕見，能做到3的測試人員就被很多人認(rèn)為相當(dāng)不錯了，至于團(tuán)隊(duì)中存在多個大牛測試的隊(duì)伍則真的很少見（微軟總部的比例高很多）。是的，別驚訝，這就是我工作中遇到的情況。但是請注意，這不是說公司在花錢養(yǎng)廢物，而是說在沒有專業(yè)測試教育的情況下在入行初期必然會導(dǎo)致的現(xiàn)狀。我們所有人都是從這個狀態(tài)開始的，也都需要時間來讓自己進(jìn)步。
也許還會有人問：這不是跟開發(fā)搶活兒干么？是的，沒錯。但為什么不能搶呢？我們的目的是什么？是開bug還是做更好的產(chǎn)品？如果你的全部目的只是多開bug，那真的很簡單。真實(shí)的例子，我曾經(jīng)見過將測試自動化代碼的bug開成產(chǎn)品bug的。我知道要求一個同事干這個干那個很不禮貌，但這種什么都不做就先開了bug再說的做事風(fēng)格是在耽誤所有同事的工作。作為團(tuán)隊(duì)的一分子，測試在產(chǎn)品上多花一分時間，有時候能省下開發(fā)幾天的工作量，因?yàn)闇y試是最熟悉這個bug的人，而開發(fā)則需要從頭開始分析。
——當(dāng)然，反過來開發(fā)也應(yīng)該盡量將測試帶入開發(fā)過程，讓大家都知道各種功能進(jìn)度的細(xì)節(jié)。這種合作同樣能大大減少測試在產(chǎn)品設(shè)計(jì)變更時重新設(shè)計(jì)用例的時間。
有人可能還要問：我的時間也很寶貴，為什么要替開發(fā)省時間？嗯，好問題。但我想誰都知道該怎么回答這種“問題”。
現(xiàn)在知道我為什么要做六年測試了么？
朱杉：
和軟件測試遭遇是個偶然，故事有點(diǎn)長，有空且看看作消遣吧。之前在一國企做金融類軟件開發(fā)，開vi寫C偶爾還客串VB，終于不堪一年200工作日以上的出差在外和出差期間徹夜加班且無雙休待遇之折磨，一怒之下轉(zhuǎn)而重回學(xué)校作個調(diào)整。大學(xué)同學(xué)所在公司招收實(shí)習(xí)生，本著賺點(diǎn)學(xué)費(fèi)生活費(fèi)的需要，抱著沒做過的事情試試無妨的心態(tài)，邂逅了軟件測試。研究生期間，學(xué)校先后開設(shè)了兩門軟件測試的課程，由于有實(shí)踐在先，發(fā)現(xiàn)學(xué)習(xí)起來頗有心得。由于老師要求嚴(yán)格，第二學(xué)期選課人頗少，于是一門大課變成了給少數(shù)幾個人開小灶，時間和資源瞬間變得充裕，讓我受益匪淺。而自身的一些觀察、分析、理解、想象能力上的優(yōu)勢逐漸在這個學(xué)習(xí)+實(shí)踐的過程中體現(xiàn)出來。同時，在實(shí)習(xí)公司那邊，我開始跟進(jìn)一個至今說起來都讓大家望而卻步的新功能開發(fā)，遇到了開始做測試以來最大的一個挑戰(zhàn)，那絕對是一段痛苦不堪的日子，但也正是這段時間讓我飛速地成長起來，并獲得了大家的認(rèn)同。畢業(yè)后，自然也就留在了這家公司，正式加入了軟件測試的大部隊(duì)，似乎也不存在選擇的問題。
軟件測試的魅力嘛，其實(shí)在你這個問題之前，我也沒有刻意地去想過，況且一百個人眼里一百個哈姆雷特，大家的癢處也未必在同一處。于是就臨時想到的說上一說，個人色彩濃，可能不太切題了：
首先，我喜歡玩解謎類的益智游戲，而且發(fā)現(xiàn)我對這類的游戲通常上手較快。雖然我說不好這個跟測試具體有什么關(guān)聯(lián)，不過有一些感覺是一樣的，觀察、推演、嘗試、歸納、發(fā)現(xiàn)，一個妙趣橫生的過程。測試本身也是對這方面能力的一個綜合考驗(yàn)，拿到一個難題的時候那種又擔(dān)心又手癢的感覺實(shí)在是和玩游戲很像。測試的過程又是一個學(xué)習(xí)和思維進(jìn)一步發(fā)散的過程，一直引領(lǐng)人往前探索，很有吸引力。
其次，新鮮感。我做功能測試和可訪問性測試，新功能的探索和發(fā)現(xiàn)，是我個人一直愛接新功能勝過做回歸的主要原因。新工具新技術(shù)的發(fā)現(xiàn)和學(xué)習(xí)是個有趣的過程。測試其實(shí)是個目的驅(qū)動的事情，基于這一點(diǎn)，沒人會要求你從頭造輪子，能拿來用的現(xiàn)成都得學(xué)會撿，不然什么都要從main寫起，黃花菜都涼了。囤新奇工具、學(xué)新鮮技術(shù)，都是有趣的事情。
再者，成就感吧。作為某應(yīng)用的QA owner和一個dev團(tuán)隊(duì)長期合作，雖然大家也會有爭論，時間緊張的時候也會互有抱怨，但合作非常順暢。只有Dev和QA把發(fā)布一個健康的產(chǎn)品當(dāng)做共同目標(biāo)而密切合作的時候，才是一個良性的開發(fā)生態(tài)環(huán)境，一個成功發(fā)布的產(chǎn)品是大家共同努力的成果，既是dev team的驕傲，也是QA的驕傲，即使走向前臺接受贊譽(yù)的更多是Dev，你也能因你所做出的貢獻(xiàn)而自信滿滿，成就滿滿。想想，在參與設(shè)計(jì)討論時指出可能存在的設(shè)計(jì)缺陷，在功能開發(fā)之前提供建議避免功能誤讀和錯誤風(fēng)險評估，一個描述清晰、根源挖掘準(zhǔn)確充分的defect送到dev處被干凈利落地?cái)夭莩?dāng)support team來征詢產(chǎn)品功能的相關(guān)問題時，當(dāng)用戶來尋求解決方案時，是不是都有一種叫成就感的東東在心里撒了歡地奔走呢。
最后，當(dāng)跟你吵架吵得最兇的開發(fā)背著你對別人夸你是最好的QA的時候，那種感動，一輩子都不會忘記的。