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

12-02

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

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

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

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

你的場景支持筆記本和耳機么？你支持什麼耳機？藍牙還是3.5mm插口耳機？
你的場景支持使用筆記本麥克風么？還是只支持配麥克風的耳機？
你的場景支持使用手機設備么？Android還是iOS？

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

藍牙耳機普遍都有硬體支持的回聲消除模塊（Acrostic Echo Cancellation)，而普通3.5mm耳機則通常由於結構簡單而沒有。對於沒有回聲消除的普通耳機，我們必須自己提供軟體的回聲消除避免影響接聽效果。
我們不能使用完全相同的邏輯處理耳機和筆記本麥克風的語音輸入。因為耳機麥克風的定向性比筆記本麥克風強很多，它只能取到聲源湊得很近時發出的聲音，而筆記本麥克風的設計則是用來在屏幕前相當大的範圍內取聲的。如果對筆記本麥克風使用耳機麥克風的聲音檢測演算法則會由於靈敏度過高而將大量周邊雜音收入，影響通話效果。而且有些場景是筆記本麥克風特有的，比如用戶的打字音和風扇噪音。
Android和iOS都有內建的通話模塊。iOS甚至提供了非常高效的回聲消除和增益控制模塊，但是沒有靜音檢測模塊。所以如果桌面程序移植到手機上時可以很好地利用這些功能簡化自己的代碼。而Android的回聲消除模塊則表現非常不穩定，需要很多調整才能得到較好的效果。

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

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

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

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

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

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

開一個bug；
查找一些額外的資料如設計文檔和歷史，確定這是一個問題，然後給出詳細的bug重現步驟；
對重現步驟做一些精鍊，確定能夠重現bug的最少步驟；可能的話，將重現步驟做自動化；
嘗試通過研究代碼確認問題所在；
嘗試給出一個fix；
對錯誤的原因進行分析，提出一些標準化的方法來檢測出類似的問題，比如stress，fuzzing等等；
能夠對標準化的測試流程定義對應的數據分析方法，可以保證開發和項目主管都能從中得到需要的信息來掌控質量狀況。

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

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

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

也許還會有人問：這不是跟開發搶活兒幹麼？是的，沒錯。但為什麼不能搶呢？我們的目的是什麼？是開bug還是做更好的產品？如果你的全部目的只是多開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的時候，那種感動，一輩子都不會忘記的。

謝邀。話說不知道為何會被邀請回答，因為我之前是開發，之後是運維，並沒有很多測試實踐經驗。前面各位前輩總結得非常好，提一些粗陋看法以作補充。

0. 責任感：
這恐怕是開發和測試之間最大的區別。就Bug在整個開發活動中造成的損失來看，在分析、設計處是最小的，而在測試時是最大的，依賴於具體使用的開發工程模型。每個環節引入的Bug都會在下一環節被放大，導致修正成本迅速擴大，到了測試這裡再發現和修正Bug，返工成本相當高，攔截和修正的責任重大。

1. 成就感：
責任感越大，成就感也越大，相伴相生。在測試階段能測出大Bug並修正，任何人都會感到自豪吧。

2. 實踐經驗密集型崗位：
相較於開發，測試需要更多更齊備的實踐經驗。從正向的系統知識、架構設計，到反向的破壞性思維，無所不包。開發人員通常在理想條件下編程，適時處理一些預想中的異常或錯誤;而測試則必須確保當這些異常或錯誤出現時處理代碼能正確工作。這種檢驗工作遠比開發工作困難得多。同樣的業務代碼，開發只需要面對少數「正常執行流」即可，而測試則需要面對大量的「異常執行流」。只有實踐經驗豐富者才能保持高測試效率。

3. 煎熬的協作關係：
開發向來難以認同測試的重要作用。還記得剛開始做開發時，SQA老是過來挑我的錯，搞得我很惱火。但是Boss卻說如果項目順利收尾，我還必須請SQA吃頓飯，要不是他們的努力，說不定還得延期，嚴重的話甚至會導致用戶體驗指數下降，損失遠遠大過面子。幸而SQA組的同事都比較客觀（天天看數據想不客觀都難），他們是真正看結果不問過程的角色，一切就事論事。這一點，單向思維的開發人員很難企及。

寫的代碼越多，越認同測試的重要。曾經聽過一個很貼切的比喻：寫程序的人就像在造沒有護欄的橋，自己去走那肯定安全無虞，那怕摸黑也不至於掉河裡去;測試則像給橋修護欄的，讓橋的普通使用者也能像開發那樣來去自如。從這一點上說，測試遠比開發重要。

我也想過是不是轉任測試，但耐性不夠，忍受不了測試那種枯燥，是以非常佩服能在測試上堅持五年十年的人。至於測試的魅力么，能說是「與人斗其樂無窮」嗎？嘿嘿。

目前我的原因就是一個，我要靠我個人的努力，推動整個行業的前進。

有必要說明一下，我是因為編碼能力差才選的軟體測試，沒辦法計算機專業嘛，就這樣；

軟體測試沒有什麼魅力，就是一份工作，掙錢生活。

2015年股市很火爆，互聯網金融揭竿而起，軟體測試與開發也受到眾多想跨行業工作者的喜愛，眾所周知，軟體行業工資高於平均薪資水平。最近有朋友和網友向我諮詢軟體測試的事情，大意是：小白如何入門軟體測試行業，且聽我說。

我從事軟體測試行業整整5年，先說點我的測試經歷，讓大家對軟體測試有些認識，其次說說小白如何跨行從事軟體測試，最後推薦些軟體測試方面的書。

NO.1我的軟體測試經驗

作為一枚女漢子，大學學計算機科學與技術專業也是十分痛苦的，剛入學就學習C++，老師口中各種鳥語，聽不懂啊畢業找工作腫么辦，就這麼糊裡糊塗的學了3年的計算機語言c++、java、c#、oracle資料庫、linux操作系統，時刻擔心畢業=失業。

害怕大四找不到工作，我在大三暑假就開始準備實習，留意教務處發布的各公司實習崗位；剛好A公司來校宣傳找實習生，A公司主要做銀行系統，招測試與開發，聽說測試門檻低，邏輯思維有條理、能看懂代碼就可以。第二天直接去參觀公司並且報名考試（2011年各種城鎮銀行成立，公司大量缺人手，招聘了大量物美價廉的學生），下午公司打電話說我通過了，明天開始實習培訓。

由於態度積極主動（面試人員之後說的），實習了幾天就進入了項目組實習--銀行系統；從實習到轉正一路走來累啊，學校學習的只是很基礎的知識，工作中遠遠不夠。

城鎮銀行--麻雀雖小五臟俱全，學習了業務：存款、貸款、卡、大小額支付、票據、中間業務、網銀、信用卡等；工作中需要搞配置庫svn、缺陷管理工具qc、部署版本、操作資料庫、linux系統命令、重現生產bug等。

當時這個公司開發人員很忙，測試人員測試出bug，首先得自己對照需求，看日誌定位，然後找開發解決。非常感謝當時的師傅領我入門。

別人的大四在宿舍睡覺、看電視劇、打遊戲，而我每天7點起床倒2趟公交車去實習，現在想想當時真的很拼，每天累的焦頭爛額，一臉痘，但是很值。

由於在這個公司學到很多技能，2013年通過了北京一家大行的面試（大行--人員外包），區別與項目外包，一會給大家解釋）。大行工作內容如下：

評審文檔：大行文檔超級多很細，比如：需求說明文檔、設計說明書、組建設計說明書、動不動就上千頁。剛開始評審各種文檔，其實就是找某些功能描述模糊不清或多種描述的，然後整理成excel和需求人員確認。

web界面測試：類似與銀行的網銀系統，點擊系統，如有報錯直接丟給開發，測試人員只需要描述錯誤即可。看不到資料庫、看不到後台、看不到報錯日誌，每天匯總案例執行個數和bug測試情況，天天整理一堆excel文檔，時間久了會感覺自己像機器人，沒有激情。

很多時候在大行恨不得一份工作5個人來干，每天很閑，姐姐還很年輕好不好，需要工作帶來的成就感，想看代碼、想了解單元測試、性能測試、linux、資料庫，身邊的同事各種跳槽（人員外包沒出息啊，隨時換工作地點、不讓玩手機、不讓干這不讓干那、跳槽加薪啊）憋屈，姐下決心辭職不幹了---ByeBye『A』公司。

2014年5月換到了B公司，項目外包--理財系統，公司有自己的產品（理財、基金、支付、P2P）項目經理很nice、主管也很nice；理財之前沒有一點基礎，從頭學起（和比我早到1月的實施美女共同學習，成長蠻快的），也和業務人員經常打交道，學到很多。

第一次用loadrunner做性能測試加班到凌晨2點，這是平身第一次啊，實體環境中調通了腳本並且跑起來了，明白了性能測試場景設計、TPS、通過事務數、最大並發用戶數等，了解了性能瓶頸如：查詢耗時、實時寫日誌、缺少索引、硬碟等；最近在配合各個渠道做測試，理財處於中間系統，接一堆外圍渠道，寶寶心裡苦。

我的測試經歷講完了，想必大家已經了解了從事軟體測試需要的一些基本技能。

NO.2軟體測試人員的工作地點

以我現在的公司為例，公司分為產品部、實施部、測試部等；

產品部人員一般在自己家公司工作，有時候會出差到現場去解決問題，自己家公司環境好、自由，公司有微波爐、下午茶、水果等。

實施部人員一般在客戶現場做實施（公司把理財產品賣給客戶，需要實施維護），現場工作的宗旨是：客戶虐我千百遍，我待客戶如初戀。客戶會不定期有個性需求，實施人員維護。環境一般般，在現場就會有銀行的人管著。

測試部：有的在公司做產品測試、有的在客戶現場做測試，比如我在客戶現場，科技部人都還不錯，相處蠻愉快的。

軟體測試工作性質分3種:

1、找個非外包公司，公司自己給自己做項目，比如鏈家app等，人員很和諧，在自己家公司做項目很幸福。

2、進入大點的公司，做項目外包，項目外包對測試人員較嚴格，功能測試、性能測試都得會，人員比例：10個開發1個測試。

3、剛培訓完人員外包，有些公司專賣人員，某些銀行給價2.5萬每人月，公司橫豎都是賺。缺點：人員管理鬆散，找不到組織。

NO.3軟體測試入門

如果你身處北上深，想跨行做軟體測試，前途還是很光明的，這些城市需求多，提升很快，尤其是越來越多的創業公司，找工作不難。

如果你身處某些二線城市，尤其是平均工資較低的情況，不建議轉行做軟體測試，大家轉行是為了掙錢，除非你學習後想去北上深發展或是特別愛好。

1、如果你的親人在做軟體測試，這是個特別好的資源，買本軟體測試的書籍，讓他教你；他個人電腦里會有他公司的資料需求、設計文檔、測試案例、被測系統、資料庫等，利用周末時間在家教，先看需求了解業務--找出測試點-寫案例，然後自己跑系統。之後教資料庫的增刪改查語句以及一些簡單的linux操作命令。

我同事利用周末時間已經把他弟弟、他女朋友都培訓成了軟體測試人員，現在工資相當不菲。

2、培訓班

眾所周知，培訓班費用很高，如果你學過c語言，了解軟體開發與測試流程，就自己買本書多看，網上關於軟體測試的資源很多，多看，多投簡歷，必定會找到份工作。

如果你是其他專業畢業，對計算機軟體一點都不了解，那就可以考慮報培訓班學習，至於報哪個班，大家上網自行搜索，最好去知乎找答案，滿滿的都是乾貨。

3、工作態度：

跨行業進入軟體測試，隔行如隔山，想必大家都會珍惜這份來之不易的工作，首先端正態度入職新人都會有老員工帶著，一般公司都有配置庫，裡面有各種文檔，測試案例、測試bug文檔等；

多看測試文檔、你的師傅加班時你就在旁邊看著幫助他干點零碎活，很快熟絡之後工作中遇到問題也會積極幫助你，不懂就要問，多問多思考，最好和他要套測試環境，自己跑案例，遇到問題多記錄。微軟的OneNote很好用，記錄問題可以分各個頁簽。

NO.4測試流程

1、需求分析

需求分析是軟體工程中的一個關鍵過程，只有吃透需求，後續工作才能得以開展。每次有新需求要求參與討論，否則後期測試各種疑問（測試人員和開發人員思考問題角度不同），討論時記錄關鍵點，整理在OneNote里，以便日後查看。

2、寫測試案例

如：地鐵里的自動販賣機，提煉測試點，然後寫測試案例；

有效的等價類有：

金額正好，順利出貨

金額超出，找零出貨

金額不足，提示，並吐出貨幣

金額足夠，取消交易

假幣，吐出

無效等價類：

放入金額，不出貨，不找零

放入金額，不出貨，退錢

金額超出，出貨，不找零

金額超出，不出貨，找零

金額不足，出貨，找零

金額不足，出貨，不找零

金額不足，不出貨，不退錢

金額正好，不出貨，退錢

金額正好，出貨，找零

金額正好，不出貨，找零

不投金額，直接出貨

測試案例設計有很多種方法，大家可以看書學習。

3、執行測試案例

把2的測試點，完全形成文檔，在測試環境執行每條案例。

4、測試bug追蹤

測試過程中難免會出現bug，如果有bug先自己對照著需求自查，看日誌，確認無誤，找開發人員看代碼，記錄測出的bug，實時更新bug狀態；

5、寫測試報告

主要寫測試背景、測試目標、測試案例覆蓋率、測試周期、測試bug修復率等。

NO.5測試書籍

《軟體測試原書第二版》老外寫的，佩螣譯，機械工業出版社，實習時培訓老師介紹的，眾多測試書中最好的一本入門書，此書淺顯易懂，很全面的講解，適合軟體測試入門的同學學習，我也會經常翻閱。

《軟體性能測試過程詳解與案例剖析(第2版)》段念，清華大學出版社，想學性能測試，然後百度搜索的答案，買了這本書，真的很不錯；銀行業務數據量大所以需要壓力，第一次做看的這本書，加班到凌晨2點，終於成功了，內容豐富，有大量的案例供大家參考，每次做性能測試，都會看，每次都有不同的收穫。

《Google軟體測試之道》老外寫的，人民郵電出版社，未來是軟體測試開發工程師（SET）的天下，抓緊時間學點開發知識。

《探索式軟體測試》老外寫的，清華大學出版社，如果你抱著未來手工測試人員會消失，不妨看看這本探索式測試。

題外：雖然軟體測試人員有時會被開發人員鄙視，但是沒有測試過的程序他敢上生產？bug一堆一堆的，做測試很好，未來測試會越來越被重視的！！！歡迎大家圍觀
—————————————

謝謝邀請。
我第一次工作，服從領導的安排，於是進入了軟體測試這個行業。
這個行業，呆的越久，就會發現，開發或者上級總認為測試不重要，然後，出現問題後，總會最先找到測試人員，而他們卻有不給予測試人員相應的權利，以及對該項目的熟悉度，總是讓測試人員慌手慌腳的開展工作。
作為一名測試人員，比開發更加考驗自身的耐心。

以筆者自己的經歷回答下該問題，應該具有一定的普遍性。
先回答第二個問題吧。

大學畢業後出來找工作（科班出身），當時一心想的是做程序猿，甚至沒有聽過軟體測試這個職位（暴漏年齡了）。面試了幾家自己比較有意向的公司，沒有成功。然後備受打擊後偶爾看到一家招測試的，也沒有多管想著先去試下，結果一下就成功了（尼瑪）。
後面看了測試相關的書，覺得白盒測試貌似很高大上的樣子，想著做這個也不錯，或者轉開發也可以，結果就這樣進來了，剩餘的大家應該都懂了，後面也會提到。
接著回答第一個問題
進入測試後，突然發現自己很享受找bug的過程。每次根據自己的分析發現bug後就很有成就感（這裡不是簡
單的執行測試案例），還可以把開發拉過來鄙視一頓（公司對質量很重視，所以不要懷疑，這樣的情況還是存在的）。後來，自己想著去嘗試自己排查和定位問題，也覺得比寫代碼更有趣。這個可能就是我認為的測試的魅力吧！
不知道有沒有回答你的問題？不過還沒有完，後面開始推行自動化，測試度量等一堆效率改進後，我就很難找到這樣的成就感了。

到今日為止，其實我已經沒有在專職地從事測試工作，雖然工作內容中也有輔導敏捷測試的部分。不過我一直很慶幸我中途走上了測試的道路，測試工作對我思維的影響一直到今天，我想也會到永遠。它讓我對一切都保持著好奇心，都想要去問個究竟，了解其中的來龍去脈和根由。正如Cem Kaner他們說的那樣，我也真的覺得測試就像是CSI那樣的刺激。
- http://www.kaner.com/pdfs/QAIExploring.pdf

如下是我的發展歷程：圖靈社區 : 會員信息（點「文章」那個鏈接）
一些博客：測試和TA_徐毅-Kaveri_新浪博客

如果軟體測試真的有什麼「魅力」的話，應該是下面幾項：

更早更頻繁的去思考價值問題，包括艱難的人生
享受少數派的樂趣
享受Telling The Hard Truth的樂趣
享受做幕後英雄的樂趣

我相信如果100個人有做選擇的自由和能力，告訴他這些「魅力」，99.5個應該不會主動選擇去做測試。還有半個有自虐傾向。而那些由於種種原因走上了軟體測試道路，並且長期堅持做出成就的人，大多數應該是因為做一行，愛一行，而不是愛一行做一行。

那些告訴你軟體測試人員需要什麼不同的技能和思維方式，等等等等，都是不靠譜的。好的軟體工程師在本質上沒有什麼不同，只是大家的偏好和選擇不同。但是正是由於軟體測試的這些「魅力」，導致大多數人更願意選擇其他角色。這就是人性。

-------------------------

做一些思考的嘗試，不一定對，與大家切磋。

---------------------------

UP最多的答案有一些乾貨，但是我認為嚴重文不對題，也有很多誤導，就不一一去駁了。

首先其實我推測題主其實想問的是軟體測試區別於其他平行工種的特質。

還是得從問題入手，什麼是「軟體測試」，怎麼定義「魅力」。

--------------魅力分割線-------------
先說「魅力」，簡單可以理解成事物吸引人的內在品質。它應該是中性的和穩定的。這些品質之所以吸引人，是在特定的環境和文化背景下造成的。比如女人的魅力，據說唐代女人以豐滿唯美，還有所謂「楚王好細腰，宮中多餓死」，魅力是審美的結果，審美是一個文化的東西，人，人類社會是不穩定的。

為什麼要說這個。現實中選擇做軟體測試有多種原因：

偶然 - 剛好有個測試的工作機會，面上了，各方面也不反感，沒有更好的選擇，或者不知道自己的傾向性
理性 - （注意理性並不代表正確），試舉幾例

測試工作比開發對代碼能力要求低，對溝通要求高。我代碼能力一般，溝通還可以
現實中測試工作女生多，我是女生，我做測試理所當然
最近測試職位比較多，競爭不是很激烈
測試的面試要求低，可以先進自己心儀的公司，然後轉開發，曲線救國

上面能不能稍微總結幾條軟體測試的固有特質呢？我們試試：

測試工作比開發對代碼能力要求低 ------ 否。行業的現實情況是測試從業人員的整體代碼能力是比開發要低，但是這個是事實而不是理想情況。再者有很多公司對測試人員和開發人員的開發能力要求是一樣高的。
測試工作中女生多 ----- 同樣是部分公司的事實，但是也有不少例外
測試職位比較多 ----- 這個顯然是感覺而已
測試面試要求低 ----- 這個也有很多例外，而且這個理解本身也是錯誤的

這些所謂屬性都不穩定。
再來看看有朋友提出的-------------發現」和「分析」
那麼其他的兄弟工種，比如產品，開發，運維，又有那一個不需要發現與分析呢？

那麼究竟什麼是軟體測試工作的相對穩定的內在特質？

首先，我覺得還得從專職軟體測試的產生說起。首先，軟體行業最初是沒有專職的測試人員和測試團隊的，這個分工是後來形成的。其次，現在很多互聯網創業公司，最初也沒有專職測試人員和測試團隊。科學管理的先驅者查爾斯·巴貝奇（Charles Babbage，1792—1871）發展了亞當·斯密關於勞動分工的利益的思想，分析了分工能提高勞動生產率的原因。他指出，這些原因是：

節省了學習所需要的時間。生產中包含的工序愈多，則所需要的學習時間愈長。例如一個工人無需從事全部工序而只做其中少數工序或一道工序，就只需要少量的學習時間。
節省了學習中所耗費的材料。因為在學習中都要耗費一定的材料。實行勞動分工後，需要學習的內容減少了，所耗費的材料也相應地減少。
節省了從一道工序轉變到另一道工序的耗費的時間。而且，由於分工後經常作某一項作業，肌肉得到了鍛煉，就更不易疲勞。
節省了改變工具所耗費的時間。在許多手藝中，工具常常是很精細的，需要作精密的調節。調節這些工具所佔的時間相當多，分工後就可以大大節省這些時間。
由於經常重複同一操作，技術熟練，工作速度可以加快。
分工後注意力集中於比較單純的作業，能改進工具和機器，設計出更精緻合用的工具和機器，從而提高勞動生產率。

這個顯然是針對體力勞動的，巴貝奇還指出，腦力勞動也同體力勞動一樣地可以進行分工。（來自百度百科）類比軟體行業的分工，我覺得可以大概總結出類似幾點：

節省了學習所需要的時間 - 依然成立
節省了學習中所耗費的材料 - 依然成立
節省了從一道工序轉變到另一道工序的耗費的時間 - 減少Context Switch，可以更專註，成立
由於經常重複同一操作，技術熟練，工作速度可以加快 - 成立
分工後注意力集中於比較單純的作業，能改進工具和機器 - 能改進測試工具和流程

那麼在軟體測試的專業分工形成以後，究竟什麼工作被分了出來？這個回答很簡單，就是軟體測試的活動？那麼軟體測試的活動包含哪些？這個就有可能不那麼容易形成一致了，在現實場景中每個行業和每個公司可能有差距。我認為軟體測試的最終目的和產品、開發、運維等等應該是一致的，就是保證軟體產品符合用戶的預期，給用戶和企業創造價值和利潤。在這個工程中，以傳統瀑布模型為例，試著比較一下各個工種的分工：

需求提出階段

大家都會關注需求的合理性
開發人員更關注需求的實現方式和代價等
測試人員關注需求的可測性（不展開可測性，有需要自己查）
------------------這個階段我認為對測試人員和開發人員只有技能要求不同，沒有本質區別

技術設計階段

大家都關注設計本身的正確性，完整性等
開發人員更關注設計的實現方式、工具、代價
測試人員還需要關注可測性
------------------這個階段我認為對測試人員和開發人員只有技能要求不同，沒有本質區別

開發測試階段

開發人員構建產品，修改bug
測試人員構建測試工具，測試用例等素材，執行測試，暴露bug
-------------------這個階段我認為對測試人員和開發人員只有技能要求不同，沒有本質區別

失望----還是沒什麼區別。

未完待續

陰差陽錯。事實上這個工作也就一般般。。
--------
做測試第9年：繞來繞去最後還是寫代碼。

對將要入行的人我只想說：還是先做開發好。

說兩句有人不愛聽的。測試那些事，那些所謂樂趣，開發都能體會到。一如達斯勛爵即能領導死星建設、剿滅整基地的義軍，亦能用光劍鈦戰機親自殺敵痛快。而測試不過是只會開鈦戰機而已。

再如，為何飛行員軍銜比步兵高。你可以說空戰和陸戰樂趣不同。但是如此設置說明關鍵時刻他們對大局的責任不同。

做自動測試純屬巧合。

現在的想法是，測試能發揮自己的長項又不用像開發那麼累，何樂而不為？

讓我重選一次，我可能會選做開發。

軟體開發往往會陷入無窮無盡的技術體系當中. 一旦入迷, 永不可自拔. 所以很多軟體開發人員也開始早早的脫離開發本身而進入了管理, 而軟體測試要求關注面廣(相對於開發的深), 之後可進入的領域相對較寬.
更重要的是, 相對於軟體開發的非常直觀的量化, 軟體測試過程更像是一個藝術過程, 它要求軟體測試人員使用最小代價發現更多的缺陷, 而這個過程要求的平衡性非常難以量化, 這, 更像人生.

其實軟體測試也是有分多個方向的，當前主流的有QA、測試、測試開發。

其中，只有測試工程師這一類崗位才是大家普遍意義理解的軟體測試，而測試開發崗位則是跟軟體開發的工作內容類似，只是開發的對象略有不同。

在做決定是否選擇互聯網測試行業之前，不妨先了解下當前互聯網企業中測試相關崗位的工作日常，相信會對迷茫的新人有所幫助。

【科普】互聯網測試崗位的工作日常 - 知乎專欄

我喜歡找出BUG,然後看開發鬱悶的表情

工作這麼長時間，越來越覺得軟體測試的領域非常寬廣，

測試工程師是一個入門相對容易，但是如要做好測試又不容易的一職業。
軟體的質量是很重要，剛才看到樓上有說【超贊】：測試把bugs提前在用戶的面前發現並修正了，它避免了用戶卸載軟體的風險，留住了用戶，保住了公司效益，穩住了大家的飯碗......
的確，軟體質量是很重要，如果你每次發布前都能發現所有問題的能力，你真是牛人也，你的價值絕對不亞於團隊的其他任何開發，你的成就感也隨之而來。
保證軟體的質量不單單是由測試來決定的，一個軟體的總體質量由需求策劃、軟體架構、代碼設計、軟體測試等環節來保證。軟體測試是一個環節，是軟體出去的最後一道關口，所以表面看上去是非常重要的，很多外行也表面的認為有問題就是測試的問題，沒有問題是天經地義、自然而然的事情。但是你忽略了前面很多環節....
有些公司對軟體測試重視不夠，是因為領導對測試認識不深罷了，就國內而言，測試更多像靶子，有問題是測試的問題，開發可以放鬆許多. 其實測試更像一門藝術性的工作，真的很難去量化它的輸出，因為你沒有創造產品，而是在不斷優化產品【有點像樓上說的測試更像一個救世主，是來拯救世界的】.
還有，測試的技術可以很深的，你可以單元測試、可以自動化測試、可以性能測試、可以寫很多測試工具、測試系統.....然後充分發揮你的發現問題、解決問題能力，你要熟練掌握網路技術、linux技術、資料庫技術和開發語言...等等
測試不單只是點點點.....如果你定位測試只是點點點那隻能停留在一個非常低水平的黑盒測試了，很多人不會認同你的能力【其實我認為黑盒測試也很重要，可惜其他人未必認同】，你不會有成就感，加薪能跟上CPI就很不錯了...
其實測試你可以做很多，你可以把行業標準摸透，在需求分析可以出謀劃策；你可以把自己變成一個資深的架構分析員，在軟體架構的時候獻出你的點子；你可以把發現的問題，分析好、定位好、並且提出解決方案。an so on ....
如果你覺得測試不好玩，你可以嘗試一下PM 和其他管理甚至轉行做獵頭【專門為IT公司去挖人...】
路，是自己走的，只要你堅持了，所有人都會為你讓路.....

當初選錯了，現在再讓我選我肯定選開發。

哪的黃土不埋人呢？

不過軟體測試這個職業還不算很成熟，能學的東西還是很多，能有所突破的地方也不少