軟件測試的魅力何在?您為什麼選擇測試一行而不做開發? | 知乎問答精選

 

A-A+

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

2018年12月28日 知乎問答精選 暫無評論 閱讀 5 ℃ 次

【陳甫鵃的回答(42票)】:

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

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

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

假定你打算寫一個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再說的做事風格是在耽誤所有同事的工作。作為團隊的一分子,測試在產品上多花一分時間,有時候能省下開發幾天的工作量,因為測試是最熟悉這個bug的人,而開發則需要從頭開始分析。

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

有人可能還要問:我的時間也很寶貴,為什麼要替開發省時間?嗯,好問題。但我想誰都知道該怎麼回答這種「問題」。

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

【陳良喬的回答(17票)】:

你讓一場本該在用戶面前發生的災難,提前在自己面前發生了

會讓你有一種救世主的感覺

拯救了這個用戶,也拯救了這個軟件,避免了他被卸載的命運

再進一步,你還改變了你的程序員兄弟被罵娘的命運

你改變了你的老闆破產的命運

你改變了你的兄弟們失業的命運

這大約就是測試的魅力所在

為什麼選擇?

有的人喜歡創造世界,他們做了程序員

有的人喜歡拯救世界,他們做了測試員

【朱杉的回答(4票)】:

謝謝邀請。抱歉現在才來回答。

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

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

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

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

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

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

【曾凡雄(六太)的回答(3票)】:

軟件開發往往會陷入無窮無盡的技術體系當中. 一旦入迷, 永不可自拔. 所以很多軟件開發人員也開始早早的脫離開發本身而進入了管理,?而軟件測試要求關注面廣(相對於開發的深), 之後可進入的領域相對較寬.

更重要的是, 相對於軟件開發的非常直觀的量化, 軟件測試過程更像是一個藝術過程, 它要求軟件測試人員使用最小代價發現更多的缺陷, 而這個過程要求的平衡性非常難以量化, 這, 更像人生.

【馮東的回答(3票)】:

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

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

【佘文強的回答(1票)】:

謝謝邀請。

我第一次工作,服從領導的安排,於是進入了軟件測試這個行業。

這個行業,呆的越久,就會發現,開發或者上級總認為測試不重要,然後,出現問題後,總會最先找到測試人員,而他們卻有不給予測試人員相應的權利,以及對該項目的熟悉度,總是讓測試人員慌手慌腳的開展工作。

作為一名測試人員,比開發更加考驗自身的耐心。

【梁濤的回答(1票)】:

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

0. 責任感:

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

1. 成就感:

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

2. 實踐經驗密集型崗位:

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

3. 煎熬的協作關係:

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

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

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

【明明的回答(0票)】:

哪的黃土不埋人呢?

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

【張恩坤Zebra的回答(0票)】:

興趣,我從小就是喜歡挑別問毛病的人。另外一方面,我也曾經學了一個月的開發,結果找工作的時候,大家覺得我比起開發,還是測試更自然些。

【徐毅的回答(0票)】:

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

-?kaner.com/pdfs

如下是我的發展歷程:ituring.com.cn/book(點「文章」那個鏈接)

一些博客:blog.sina.com.cn/s/articl

【顏路的回答(0票)】:

沒什麼魅力~~但還是能從某些bug中獲得點成就感。

【田禾的回答(0票)】:

魅力就是我喜歡而且做得來

我覺得無論你做什麼其實都只是一份工作,用來養家餬口維持生計而已,測試是,開發也是

【武偉的回答(0票)】:

魅力:找茬還自己懶的改

如果稍微勤快點的有遠大抱負的人,我想一定會親自上去寫東西,而不是擦別人屁股的。

標籤:-陳甫鵃 -軟件測試 -勞動合同法


相關資源:





給我留言