現在互聯網的發展帶動了很多行業的進步，特別是軟件測試行業。軟件測試行業的水到底深不深呢？業內人士常說的一句話是“別拿測試不當研發”，軟件測試本身就是一種研發，對企業來講是不可忽視的大工程。要做出一款軟件需要大量的人才，最早那些軟件運作的人可以說是一當十，產品，研發，測試，運維等等都得搞，現在隨著行業的不斷發展，人才隊伍逐漸擴充，工作崗位也分工細致了。從產品調研需求，到開發功能實現，再到測試的質量把控再到運維環境都做的非常精細。

而隨著軟件的復雜度越來越高，一個人是擼不出真正的大型商業軟件的，所以才開始各司其職，產品去調研需求，開發負責實現功能，測試負責把控質量，運維負責照看環境等等。測試崗本身就是從研發分出來的，絕大多數公司也都會把測試歸類于研發中心，所以如果你以為測試只是偏業務的點點點小兵，那就大錯特錯了。

但是測試確實是又不如研發，因為測試本身是個成本崗位，說白了就是不負責產出的，理論上研發的能力強和自測做的好，測試甚至可以打醬油，這也是為什么有些公司或者領導不怎么看中測試的原因。所以測試前景好不好，現在是看你自己怎么定位測試這個職業，你是偏向產品和業務的功能測試?還是偏向于研發的自動化、性能或者測開?

所以測試人員的難點其實就是如果你只想安安靜靜的當一個純粹的測試人員，那確實沒啥前景和出路，實際上測試走到最后都是要點技能樹轉職的：

1、點業務技能點的，以后可以成為半個產品，甚至業務專家，這在金融領域等重業務的公司是很吃香的。

2、點研發技能點的，以后可以成為測開、自動化、性能、安全等等，有研發能力的測試在大多數互聯網公司都是很受歡迎的，一是開發愿意跟你溝通，二是互聯網的測試內容需要一點的技術底子。

3、點管理技能點的，因為測試本身處在整個需求生命周期的中后端，也就是前期沒啥事，后期能不能上線全看測試的表現，所以也有測試兼職做項目管理的，做著做著最后就成了實際的管理者了，所以如果你見到一個項目的負責人是測試不要覺得奇怪，這系統能不能上是他來點頭的。

這既是測試的優點、也是難點，優點在于測試轉崗的能力是僅次于開發的，缺點就在于純測試的上限也確實是最低的，相比于業務、研發這兩大直接產出職能來說，不信你瞧瞧各公司的高層、創始人，幾乎沒誰是一路測試干上來的。

所以測試到了中后期是一定要轉型的，而后期能不能轉型成功全看你頭幾年的個人積累。我的建議是，你擅長干什么，或者喜歡干什么，就往那個方向轉。

如果你業務賊牛，功能很熟練，整個公司比你更熟悉這個系統功能的人沒幾個，那你就嘗試著轉型項目負責人或者產品，不要只是被動的等需求。

如果你仍然把自己當作研發，那就去寫代碼，看代碼，不要只會有問題就提BUG，要了解系統是如何運作的，要知道問題出在哪，最好是代碼要改哪一行都給研發指出來，然后自己平時搞點自動化，前端后臺都搞搞，弄個小的自動化平臺出來，了解一點底層的知識，學到最后你就已經跟開發無異了。

我來給你說說一個測試工程師提BUG是分幾個等級的：

初級：只知道提BUG，原因是啥不知道，讓開發自己去研究。

中級：大概知道是哪里出了問題，能提供數據和日志，細致的還得開發自己去排查代碼。

高級：有代碼閱讀能力，已經能把問題定位到具體的模塊甚至具體的代碼塊了。

專家：拿個小版凳坐在開發旁邊，用手指著開發的屏幕，吶，就這里出問題了，我來告訴你怎么改，你如果不會的話我甚至可以親自幫你改。其實我一直都認為測試應該就跟開發排排坐，兩個人盯著代碼慢慢的debug，而不是測試只管提BUG，一問怎么出問題的啥都不知道，那樣只會降低測試的權威性。

什么是測試的權威性?為什么有些公司的測試沒人權，而有些公司的測試地位高。主要就是看測試對這個系統的熟悉程度，某些老測試堪稱百科全書，這個系統從業務到代碼都懂，這種人他指出的問題即便是研發大佬都不太敢反駁，但實際上更多的人只是用例執行人，BUG收集器，一問三不知，反正就有問題，代碼看不懂，原理不了解，一看就感覺這人不太靠譜，所以這也是為何有些研發會認為測試門檻低是個人就能做的原因。

說了這么多，簡單提煉一下：

1、純粹只干測試上限來的快，要趁著年輕多積累，爭取轉型的機會。

2、盡量提高個人的權威性，不論是技術、還是業務，這都需要更深入的學習和積累。

以上我們分享了軟件測試行業的相關內容，大家都知道了現在軟件測試行業的發展也逐漸正規系統化，如果您想了解更多相關信息，請您繼續關注中培偉業。