[轉貼] 軟件測試職業發展的 A 面和 B 面

1.所謂的軟件測試技術到底包含什么？?????????????????????????????????????????????????????????????????????????????????????????????

梅子：我先來從傳統意義上來談一下測試技術，主要就是測試分析，測試設計，測試管理，測試執行，自動化測試技術，專項測試技術，缺陷分析技術等。

Monkey：對于測試技術，這的確是個很好的話題。首先在這樣一個快速變化的時代，我們應該勇于擁抱變化。我覺得之所以現在測試行業很多測試人員會困惑于測試技術很大一部分原因就在于很多人冥頑不靈，不愿意接受新鮮的事物和變化。

在我看來，拋開以前書本上的死知識，軟件測試技術現在包含兩部分：
我們自己認為的軟件測試技術
別人認為測試應該學會的技術
那我們一個一個來講吧，先說我們自己認為的軟件測試技術。軟件測試用例設計方法，軟件測試思維，軟件測試策略等等，這些其實我不想在這里浪費篇章去說明這些，為什么？因為這些并無法真正量化，也很難去考評，在現實的行業中也無法給你帶來直接的升職加薪，所以我認為就算我寫了大家也沒有興趣看。

那么別人認為測試理論上會的又是什么呢？

就如同很多時候我們覺得自己做的怎么樣并不重要，重要的是大家普遍到底覺得你是怎么樣的。加強對于“我們自己認為的軟件測試技術”的學習這是我們測試人員的情懷，但加強對于“別人認為測試應該學會的技術”的學習這是我們測試人員為了找到一份不錯的工作，為了生存而需要面對的，其實就那么簡單。

梅子：剛才monkey講到了不那么重要的測試思維，讓我又重新去思考到底什么是測試思維，以及測試思維是如何影響我的。

我對測試思維的認識主要有2個階段：

第一階段：我認為測試思維就是測試如何去分析被測對象的視角，可以概括為測試類型（性能測試、可靠性測試、兼容性測試這種）和功能交互分析（就是把很多功能放在一起考慮）。這個測試思維能夠幫我系統的分析被測對象，讓我可以很容易的就比別人發現更多產品的問題，而且問題還蠻有價值的。

第二階段：慢慢的我發現我真的沒有必要對所有被測對象都進行那么全面的分析，有的功能特性好像不怎么測試也可以，有些功能測試卻真的需要非常深入細致的測試，并且哪些需要詳細測試，哪些不需要詳細測試是動態變化的，我認為測試的核心，就是要在項目中把握這種動態性，有策略的進行測試。我開始注意項目的成本，思考如何用最小的成本來獲得最好的測試效果。我覺得測試思維也許并不應該只是狹義的理解為測試中才需要考慮的思維，測試思維是一種探索式的思路，它不僅適合于測試，也適合于產品的其他角色。

2．為什么說測試需要開發技能，測試策略和開發 技能到底哪個重要？

梅子：對測試來說，開發技能是基礎。我特別不喜歡”代碼能力不行就去做測試”這樣的論調，別的不說，如果測試一點代碼能力都沒有，你該要怎么和開發溝通？完全不在一個頻道上又何談協做。
但我也不認為，開發技能是測試的核心，我認為測試策略才是測試的核心。

無論產品開發的方式如何演進，用戶對產品質量的期望都是客觀存在的。質量＝符合要求，而探索和評估質量最有效的方式就是測試，20年前如此，20年后還是如此。對被測對象的準確把握，是探索產品迷宮的羅盤，關鍵因素包括代碼復雜度，開發的技能和經驗準備度，需求的質量等。有了這些，就可以判斷風險的所在，在把握失效規律和失效影響的前提下，有的放矢的來開展各種測試活動。而實際的情況卻是，我們太缺少對被測對象的分析和思考，這讓我們做了很多看起來必要實際卻很低效的事情。

舉一個回歸測試的例子。如果開發修改問題改得非常好，我們的bug 99%都可以回歸通過，那么我認為測試沒有必要再做回歸測試，因為投入產出比非常小。我們可以這樣算一筆賬，假設一個周期為兩個月的產品有200個bug，測試人員一天可以驗證10個bug，這就是20人天的工作量，這還不算回歸測試中的測試設計或者是發散測試的工作量。我們完全可以把這個時間放在測試其他的更值得測試的地方，或者干脆把發布周期提前一周又為何不可呢。

所以，我個人認為，測試策略是測試技術中最核心的部分。測試，簡單來說就是，測什么和怎么測，這都是策略的范疇。相比自動化、工具、測試設計等，測試策略往往更能更舉足輕重地影響測試的質量和效率——測什么和怎么測決定了質量，實際也決定了效率。如果能在深入分析的基礎上大幅度減少測試用例，測試效率提升一定比自動化還高。然后再對最值得自動化的部分進行自動化，而不是為了自動化而自動化，測試效率又會大幅度提高。實際上，系統越來越復雜，我們總有分析不清楚的時候，如果自動化平臺足夠強大，我們多測試一些也沒有關系，可以避免一些低級遺漏。所以，策略是重要的，但是畢竟是基于經驗的，總會有不完善的地方，工具和自動化可以很好的補充。測試還沒有達到科學或者工程定量的程度，但也不是只有少數人才會的藝術，而是一門基于經驗，可復制性的工藝學科，只是還沒有達到可以給出明確標準的批量復制程度。也正是因為如此，才更需要我們去做深入的思考和分析。

Monkey：這個的確是個好問題，但我覺得很多會問這個問題的主要問題在于自己根本就沒有怎么做過測試，跟風問題，對測試策略的理解太淺。在我看來測試策略其實已經是一個很高等級的詞匯了，能做到這個根本就是屈指可數，其根本就和所謂的開發技能不在一個水平面上，所以不能去做一定的對比。行業中很多次拿出來對比在我看來就是大家的理解太過淺層次。

其次就來討論下開發技能，這里的開發技能更多的其實指的就是看代碼能力和寫代碼能力，現在行業里基本上都是考核寫代碼能力了。我們撇開所謂的自動化（因為在我看來，很多測試做的最多只不過是半自動化，遠遠達不到自動化的程度）和測試工具來講，我們要了解一個復雜的項目的時候必須去深入了解其技術設計和實現，那么對于一個測試人員的研發能力就有著很高的要求。無論是代碼能力還是架構思維都是為了能夠更快的更準確的去理解被測對象打下扎實基礎的，從而才能夠制定出正確的測試策略。所以從我的理解上來講，測試人員越往上走就需要越強的研發技能，否則只會依賴于PRD或者與研發雞同鴨講，最終只了解產品的皮毛。

最后來談下測試策略吧，在我理解的測試策略并不是你掌握了一個很厲害的用例設計方法或者看看幾個PRD，會寫幾行代碼就能夠制定出來的，測試人員制定一個真正的測試策略應該至少滿足以下幾點：
擁有不錯的代碼能力和架構思維
經歷過大項目復雜業務，對業務有深入的理解
深入正確的理解PRD和項目架構
了解項目在企業中的定位
了解項目需要哪些團隊來合作
測試團隊目前資源分配的現狀
等等
只有一個測試人員同時了解這些的情況才可能真正的去制定所謂的測試策略，所以無論我們說的研發技能還是測試用例設計方法還是溝通交流能力等等這一切都是制定測試策略的基礎。對測試人員真正重要的就現在而言真的就是一個綜合的能力，而不是單獨的某一個技能。

3.測試前移，無專職測試，內測，灰度發布，測試開發等會是測試未來的發展趨勢么？

梅子：我認為這些活動一定會是測試未來發展的一個趨勢。
其實“質量活動提前”、以“內測、灰度發布等手段來替代傳統測試”等這些新的測試實踐，最后都會導致“無專職測試人員”，“無專職測試人員”或者說“專職測試人員”會變少，會是未來測試的一個發展趨勢，但這并不等于未來就“沒有測試活動”了，相反，測試活動會分散到產品開發活動的各個階段，產品經理，開發，運維都要進行各自層面的測試（例如驗收測試由產品經理來進行，功能測試會由開發來進行），測試思維、測試方法、自動化測試等不再是測試的“獨有”的能力。而對那些保留下來的少數的專職測試人員，可能會更關注：
制定整體的測試策略、落地。
測試工具或平臺的支撐。
承擔那些對測試技能要求非常高的測試。
測試方法的研究和改進。
測試人員也可能會同時服務于多個團隊，形式可能會是服務，或者是解決方案。

Monkey：恩，首先我也認為這是一定的發展趨勢，那么就問題先一個一個來談談吧。
測試前移是很多年前就開始討論的了，其本質更多的是希望測試人員能夠更早的介入項目，更深的層次的原因其實就是希望有一個擁有很強質量意識的人來在前期給項目更多的建議，甚至能夠將質量意識帶給大家，那么測試則是最佳人選。國內早幾年的項目中，項目經理和研發在項目早期討論階段都認為不需要測試的，而只有在產品開發完畢之后才需要測試進行產品功能的驗證和尋找缺陷，這當然是不對的。但這也是進步必須的一個過程，現在來看這樣的情況應該已經不存在了。

無專職測試這個事情我是想在這里好好強調下的，行業說的無專職測試絕對不是大家想的那種沒有測試人員，哪怕是國內的知名公司也不是這樣的初衷。所謂無專職測試無非是以下幾種情況：
的確沒有專職的測試崗位，但有外包來做一些基本的測試工作。
的確沒有專職的測試崗位，但測試工作還是繼續的，驗證工作也平分到了其他各個人頭上。
由于團隊負責產品的特殊性，比如一些中間件或者sdk，最終判斷不需要專職的測試崗位。
有專職的測試人員，但測試已經不做普遍名義上的測試工作了，所以會宣稱沒有專職的測試人員。
某些團隊或者公司由于產品的特殊性，自動化能夠覆蓋比較多的場景，當自動化成熟了之后，測試人員就會轉到產品或者研發團隊，此時就沒有了專職的測試。
所以綜上所述，我認為有沒有專職的測試人員并不重要，重要的是選擇適合自己團隊的測試策略，同時行業大眾看一個觀點的時候一定要明白上下文，不要斷章取義，弄的人心惶惶。

灰度發布在移動互聯網中是使用的最多的，眾測和bug bash還有A B測試也常用。灰度測試分成線下灰度和線上灰度。線下灰度其實就類似于bug bash，灰度機制本身其實就是為了讓產品在真正上線之前暴露出更多的問題而存在的。而在移動互聯網中由于企業中沒有真正用戶群那么多的Android和iOS測試機，所以灰度也就變得更加重要了。

4.軟件測試到底可以做幾年？

chat主持人：兩位可以聊聊，軟件測試工作可以做多少年嗎？

梅子：好，這其實是個很難回答的問題。我做了11年的測試，做過測試管理，最多的時候也只是一個二十多人的異地的團隊，也做過現在好多人都還沒有搞明白的測試架構師。我也覺得我可能會再10年測試，但在去年我轉崗了。但對我自己來說，我也不介意又做回測試。測試究竟可以做多少年，我覺得是可以做很久的。
關鍵是，你要有你的個人價值。而且不是你自己說自己有價值，而是你的團隊，你的領導都認為你有用。

Monkey：要我說吧，這個問題根本不是大家關心的，大家關心的應該是這個問題——”軟件測試到底可以賺多少錢？是不是可以比開發賺的多？”。很多時候我們堅持不下去的原因有很多，但如果收入高于我們的期望的話大多數人還是會選擇忍的，畢竟真的轉行的話成本還是很大的。所以換句話來說，轉行很大一部分原因就還是收入的問題。關于測試收入我不是很想在這里去描述了，我這里的確應該有很多大家關心的敏感信息，如果有可能我更希望大家眾籌讓我來寫一篇專門關于測試收入的文章。

梅子：Monkey提到了收入的問題，這是個很好討論點，也是大家很關心的內容。我所遇到的優秀的測試人員，薪水和優秀的開發的薪水是不相上下的，但是能夠拿到和優秀的開發相當的薪水的優秀的測試人員，換句話說老板愿意出這個價的測試人員，真的非常少。
很多同學可能會說，看吧，測試的發展就是不如開發吧。我想，雖然我認同開發和測試的工作都是創造性的工作，但客觀的說，開發工作的創造性是“開創性的”，是從0到1的，而測試工作的創造性是“探索式的”，是來確認1是否真的是1。從老板的角度來說，測試并不能直接產生價值，而是一種投資。除非老板已經不差錢了，否則他一定會把資源往開發這個方向傾斜，這是最基本的資本法則，測試要能夠理解并接受這點，不要總要和開發比較，把精力消耗在自怨自艾上，真的沒有意義。測試應該更多的去思考如何提高自己的價值，而且這個價值還要是老板眼中的價值，這樣老板才愿意付給你相應的薪水。
其實測試可以做幾年并不重要，重要的是“繼續做測試”，或是“不做測試了”，是測試者自己主動的選擇，而不是被動無奈的選擇。

轉載于:https://www.cnblogs.com/jianfeijiang/p/10622873.html

總結

以上是生活随笔為你收集整理的[转贴] 软件测试职业发展的 A 面和 B 面的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。