關(guān)于質(zhì)量保障，好像已經(jīng)說過太多，但這里還是抽象的嘮叨幾句。

多年的軟件測(cè)試和質(zhì)量保障工作讓我越來(lái)越清晰的認(rèn)識(shí)到：質(zhì)量絕對(duì)不是一個(gè)環(huán)節(jié)，一個(gè)工種可以搞定的。比如：

• 從對(duì)語(yǔ)言的誤用，到對(duì)第三方組件的誤用；

• 從需求根源就有問題，到需求傳遞過程中出現(xiàn)的誤差；

• 從設(shè)計(jì)代碼基本邏輯設(shè)計(jì)不合理，到代碼架構(gòu)設(shè)計(jì)不合理；

• 從一些參數(shù)配置錯(cuò)誤到上線版本的弄混；

• 從架構(gòu)師不良的設(shè)計(jì)，到運(yùn)維人員不規(guī)范的操作；

質(zhì)量問題可以產(chǎn)生于任何一個(gè)環(huán)節(jié)。

隨著系統(tǒng)越來(lái)越復(fù)雜，單點(diǎn)的問題會(huì)累計(jì)成片的問題，面的問題，最后產(chǎn)生災(zāi)難性事故。這些例子見得太多太多了。因此，**搞定質(zhì)量是系統(tǒng)性工程，是絕對(duì)的。TeamWork。人、流程、技術(shù)、標(biāo)準(zhǔn)都是不可或缺的。**如果只嘗試從單一角度解決質(zhì)量問題，即使采用再牛逼的技術(shù)，下再多的力氣，定再多的流程，也可能只會(huì)事倍功半。

但是我發(fā)現(xiàn)，很多團(tuán)隊(duì)解決問題總是極度偏向一個(gè)維度的。

• 有的組織定義一大堆流程，并嚴(yán)格執(zhí)行，最后演變成了摳文字的游戲和郵件大戰(zhàn)，而對(duì)采用落后的技術(shù)給生產(chǎn)力、質(zhì)量帶來(lái)的極大拖累視而不見；

• 有的團(tuán)隊(duì)極度追求技術(shù)，什么新用什么，最新的架構(gòu)、框架全都用上，卻發(fā)現(xiàn)開發(fā)人員一行單測(cè)也不寫，連類型轉(zhuǎn)換，不捕獲異常，少寫個(gè)等號(hào)這樣的基礎(chǔ)代碼級(jí)別的 bug 都要等系統(tǒng)測(cè)試階段再發(fā)現(xiàn)；

• 有的團(tuán)隊(duì)開發(fā)人員極為強(qiáng)悍，從代碼工程角度來(lái)看架構(gòu)、設(shè)計(jì)、代碼、單元測(cè)試、評(píng)審都無(wú)懈可擊，但是需求竟然是郵件來(lái)回溝通，到最后還是為其所累；

• 還有的團(tuán)隊(duì)似乎每一個(gè)點(diǎn)都照顧到了，還過了 CMMI5，貌似一切都很好，但是發(fā)現(xiàn)，改一個(gè)按鈕的需求要搞一個(gè)半月才能上線，要知道，開發(fā)效率也是質(zhì)量的一環(huán)啊。

以上這些都是我見過的真實(shí)的例子。

所以，**如何搞定質(zhì)量呢？**答案是”綜合治理“這幾個(gè)字。

至于如何做，其實(shí)不同的團(tuán)隊(duì)實(shí)現(xiàn)起來(lái)會(huì)大不一樣。因?yàn)閳F(tuán)隊(duì)結(jié)構(gòu)不一樣，產(chǎn)品類型不一樣，公司文化不一樣，怎么會(huì)有萬(wàn)靈藥呢？

在大多數(shù)情況下，質(zhì)量的長(zhǎng)足改進(jìn)都是對(duì)基礎(chǔ)的重視和通過無(wú)數(shù)次磨練團(tuán)隊(duì)成員打造出來(lái)的，對(duì)于老的團(tuán)隊(duì)，更需要拿出傷筋動(dòng)骨的勇氣和從每一行代碼搞起的決心。

可惜國(guó)內(nèi)大部分團(tuán)隊(duì)的質(zhì)量體系只停留在一個(gè)初級(jí)階段（我做過上百人的訪談，還是有一點(diǎn)發(fā)言權(quán)的）。我們國(guó)內(nèi)大部分 IT 團(tuán)隊(duì)離成熟、高效仍然有很遠(yuǎn)的距離，需要我輩一起努力。

那么問題來(lái)了，在這種前提下，測(cè)試人員如何開展工作？

我的觀點(diǎn)如下：

1.?測(cè)試工程師的傳統(tǒng)工作邊界會(huì)越來(lái)越模糊甚至?xí)淮蚱?。不再固守”系統(tǒng)測(cè)試“這片疆土，而把測(cè)試工作左右移是一個(gè)必然趨勢(shì)。

測(cè)試左移需要開發(fā)技能和開發(fā)人員的半成品對(duì)接，這是個(gè)殘酷的現(xiàn)實(shí)；測(cè)試右移也是趨勢(shì)，利用生產(chǎn)數(shù)據(jù)、行為做測(cè)試也將是測(cè)試人員需要掌握的技能，這里就需要測(cè)試人員掌握一些運(yùn)維知識(shí)和數(shù)據(jù)分析知識(shí)，這些也和開發(fā)技能難以分開；

而隨著系統(tǒng)越來(lái)越復(fù)雜，各種非功能性測(cè)試也會(huì)越來(lái)越重要，而大部分非功能測(cè)試同樣需要開發(fā)技能（如性能測(cè)試，安全測(cè)試）。沒有這部分技能是無(wú)法做好測(cè)試的。測(cè)試對(duì)開發(fā)技能既要求廣，又要求深，其實(shí)挺過分的。

2.?人的認(rèn)知和學(xué)習(xí)能力有極限，作為一個(gè)群體，又會(huì)是正態(tài)分布的樣子。因此不可能所有人都是大神級(jí)人物（企業(yè)也招不來(lái)養(yǎng)不起或不愿意養(yǎng)），測(cè)試會(huì)是以 TeamWork 的形式 Cover 各個(gè)質(zhì)量環(huán)節(jié)的一部分，并形成一張質(zhì)量網(wǎng)。

在縱切面上會(huì)有一些人鉆得很深，如安全測(cè)試工程師，性能測(cè)試工程師，做框架的測(cè)試開發(fā)工程師，系統(tǒng)測(cè)試分析師，這樣才有可能把精力集中在一點(diǎn)，搞定技術(shù)的難點(diǎn)，把事情做下去；又例如有些業(yè)務(wù)極為復(fù)雜的企業(yè)，需要很多 BA 來(lái)搞定業(yè)務(wù)復(fù)雜性，有一些 BA 是偏向測(cè)試的；

如果組織很大，你就會(huì)發(fā)現(xiàn)無(wú)數(shù)流程上的低效率，反模式，這時(shí)候其實(shí)需要有一些人專注過程，一些測(cè)試人員會(huì)承擔(dān)起這些責(zé)任。這些都會(huì)造成測(cè)試人員內(nèi)部的分工，也會(huì)造成測(cè)試人員之間的薪酬差異逐步拉開。我覺得做測(cè)試的同學(xué)應(yīng)該找準(zhǔn)自己的努力方向，要學(xué)的太多，精力總是有限的，得有自己的個(gè)人發(fā)展路線圖。

3.?不要把自己局限于”我是測(cè)試工程師“，這樣你的職業(yè)路線才會(huì)逐漸開拓，你對(duì)組織的貢獻(xiàn)才會(huì)逐漸加大。這個(gè)不展開說了，工作久了并有一定靈性的同學(xué)都會(huì)懂。

4.?做好測(cè)試工程師其實(shí)挺難的，甚至可以說投入產(chǎn)出比要低于其他 IT 崗位。測(cè)試的上限很高，挑戰(zhàn)很大，如果你真的喜歡測(cè)試，需要持續(xù)突破自我，努力堅(jiān)持下去。

搜索微信公眾號(hào)：TestingStudio 霍格沃茲的干貨都很硬核