在我們行業(yè)中，總有人在pk在這問題。大約半年還是一年前，我在《測試架構(gòu)師修煉之道 從測試工程師到測試架構(gòu)師》微信群里面也辯論過這個問題，當(dāng)時被認為是站在“測試技術(shù)”一端的我，有種被群起而攻之的感覺。這周面試一個平安的小伙伴，給我推薦了testhome的文章《測試方法論－質(zhì)量的基石》里面的辯論，想不到，這個問題還有這么廣泛的群眾基礎(chǔ)。這里我就也忍不住插一腳。
自省
在插之前，我問了我自己兩個問題。
一、我太偏頗“技術(shù)”了？ 別人看來也許是，但是我一直覺得我就是“墻頭草”。后面我也會說，不論技術(shù)還是思維，在我面前，能發(fā)現(xiàn)問題、解決問題就是王道。
二、互聯(lián)網(wǎng)公司聲音大，只是覺得互聯(lián)網(wǎng)公司的測試才是測試？ 這些年有幾次分享學(xué)習(xí)的機會，包括TID，QCON，海西等等，確實也見識了銀行系統(tǒng)、toB的軟件對質(zhì)量的重視，也知道原來還有TMMI這種質(zhì)量相關(guān)的體系來評估，所以我自覺眼界不算太窄，能公平地說這個事情。下面來說我的第一個觀點。
局限
做好測試，測試思維只是其中一種思維
以前看過一篇我覺得歸納得挺好的文章《做好軟件測試需要具備的思維方式 》，文章里面也提到了思維。但是測試思維只是其中一種。他歸納了三種思維，分別是用戶思維，架構(gòu)思維和測試思維。認真想想，所謂“知己知彼，百戰(zhàn)不殆”就在此，測試思維代表測試角色，用戶思維和架構(gòu)思維就分別代表著測試角色最常打交道的兩個角色，產(chǎn)品角色和開發(fā)角色。
這里更深一層的啟發(fā)是，思維。思維的重點不是怎么做，而是為什么做。所謂了用戶思維，架構(gòu)思維，測試思維，其實是讓自己在不同角色來思考，為什么做。例如測試為什么要介入到不同的階段，為什么要做性能測試，為什么要做功能測試，為什么要需求評審。
工程效率是個好維度
測試在于發(fā)現(xiàn)和預(yù)防風(fēng)險，那基于此的測試思維其實是一個單維度，單目標(biāo)的系統(tǒng)，這也是我為什么很喜歡《測試方法論－質(zhì)量的基石》里面辯論提到的“工程效率”的原因之一。因為“工程效率”很好地給“質(zhì)量”加了個“期限”，讓單目標(biāo)的系統(tǒng)變成多目標(biāo)的系統(tǒng)，也讓測試給項目帶來的價值更明確，更好度量。
舉個真實案例，QQ錢包里面有許多類似運營需求，控件行為都是一樣的，什么抽個獎、給個獎品之類，無非就是換個圖，不同的wording而已。如果從測試思維的角度，我們會想用什么策略去測試，當(dāng)然也不排除怎么逼迫開發(fā)自測。而從工程效率角度，我們可以推動他變成一個拖放控件的平臺，讓控件的邏輯可以沉淀到工具平臺，直接可以不用測試。這里的區(qū)別就是“不是在整個研發(fā)階段能做什么測試，而是測試這個角色能做什么？”
思考題：是否非要給測試需要的思維和技術(shù)帶上“測試”的頭銜呢？
知行合一
“測試行業(yè)最難的命題不是測試技術(shù)，而是測試質(zhì)量......尤其重要的是－測試方法論?！保?/b>
“現(xiàn)在有太多的人盲目地走在追求自動化的路上，忽視了自身對質(zhì)量保證意識的全局思考，其實所謂技術(shù)只是質(zhì)量保證的一種手段而已，真正的核心還是思想啊”,?
這些其實很有道理的，因為在幾百年前到現(xiàn)在，朱熹的理論就很讓人稱道，如知難行易，先知后行。如果完全沒道理，大家也不會聽。只不過這個道理叫做“公說公有理，婆說婆有理而已”。如果我換個造句說，一樣很通順，“現(xiàn)在有太多的人盲目地走在追求測試思維的路上，忽視了實踐，實踐過程中遇到的問題，忽略了用技術(shù)來解決問題，其實所謂測試思維只是想法而已，真正的核心還是實實在在的測試技術(shù)啊”
這里更有價值的其實是，王陽明提出了知行合一，知和行是一體的，不存在雞先還是蛋先的問題，有思維就必然有對應(yīng)的技術(shù)，有技術(shù)必定有對應(yīng)的思維，為什么要分裂來看這個事情呢？我們很多工作的價值在于如何更有效地“解決問題”，而不在于思維還是技術(shù)。
說點實際案例，探索性測試。探索性測試應(yīng)該是測試思維的一個很好的體現(xiàn)。有次通道面試，我作為面試官也遇到了這個一個小伙伴在說自己在“探索性測試”的成果。他是這樣描述到的，我落地了探索性測試，帶領(lǐng)團隊學(xué)習(xí)，發(fā)現(xiàn)了a問題，發(fā)現(xiàn)了b問題，bug量增加多少。聽到這里，我不會給他過的，難道是因為毫無技術(shù)含量么？
是因為沒有解決探索性測試引入的問題，要解決問題，技術(shù)手段是避不開的。這里起碼有兩個問題，
1. 大家對探索性測試理解的深淺不同，掌握的信息不同，測試的效果就不同，測試經(jīng)驗要如何傳承？?
2. 質(zhì)量和效率如何平衡，探索性測試總能發(fā)現(xiàn)一堆雞肋bug（改與不改的猶豫之間），浪費時間。
也許面試者不是沒有給第一個問題的答案，就是“學(xué)習(xí)”。只通過“學(xué)習(xí)”能解決問題？你相信么？在這時把“技術(shù)”和“思維”對立起來，就會失去一些更有效解決問題的方案。在探索性測試里面有個叫郵遞員測試（快遞測試，郵差測試）的，是依據(jù)數(shù)據(jù)的流動來進行測試。但是如果當(dāng)app是黑盒，你是知道數(shù)據(jù)怎么流動，還是猜到數(shù)據(jù)怎么流動。如果我利用技術(shù)，如內(nèi)存快照，把數(shù)據(jù)變量和activity的綁定關(guān)系分析出來，把這個信息在測試的時候展現(xiàn)出來給測試看呢？告訴你這個界面有什么數(shù)據(jù)，什么數(shù)據(jù)會因為你的操作而變換，什么數(shù)據(jù)會傳遞到下一個界面。這樣的探索性測試不是更好嗎？
還有長路徑測試法，博物館測試法，能不能使用技術(shù)呢？前者能通過monkey平日遍歷的數(shù)據(jù)，通過計算，推薦給你長路徑。后者可以通過svn記錄的分析，找出那些陳年代碼，而且最近居然還修改了的地方。這些都是技術(shù)能給予的。
思考題：怎么評價測試質(zhì)量的好壞？用了多少技術(shù)？多少漏測？發(fā)現(xiàn)了多少bug？思想有多精妙？
醫(yī)生與測試
也是在討論區(qū)中的啟發(fā)，他們用“中醫(yī)”的迂腐不進取、不會先進技術(shù)來比喻只懂測試思維的人，用“西醫(yī)”的動不動就動手術(shù)，拍片子來比喻只懂測試技術(shù)的人。
我同樣用醫(yī)生來說說。醫(yī)生無非就是做三個事情，獲取信息，判斷癥狀，開藥治療。測試也是類似，通過設(shè)計測試用例獲取信息，然后通過自己的經(jīng)驗來判斷癥狀，最后一步，同樣是根據(jù)經(jīng)驗、方法論來定制解決方案。如下圖所說，這里終究還是離不開技術(shù)。但是反過來說，懂得這么做，其實就是有對應(yīng)的思維嘛，通過技術(shù)獲取更多信息的思維，通過技術(shù)沉淀經(jīng)驗的思維，通過技術(shù)整合經(jīng)驗的思維。所以還是那句“知行合一”。
思考題：借助大數(shù)據(jù)、AI，你解決了什么軟件質(zhì)量建設(shè)的問題？有什么好實踐
文章里有三道思考題，期待你的回復(fù)。最后一題與下文密切相關(guān)。
最后，最近在籌備2018年的QCon， 在征集專題《大數(shù)據(jù)下的軟件質(zhì)量建設(shè)實踐》的分享，如果大家有什么在這方面的干貨、好的實踐，求推薦，大家一起推進測試行業(yè)的發(fā)展。下面是專題的介紹。
專題介紹：
在從源碼撰寫、持續(xù)集成、測試調(diào)試、發(fā)布運營，整個流程中大數(shù)據(jù)無所不在，svn的checkin日志，來源于人工、自動化、APM系統(tǒng)發(fā)現(xiàn)的缺陷、缺陷的堆棧和日志、缺陷的解決流水、用戶行為數(shù)據(jù)、App性能數(shù)據(jù)、甚至是代碼本身，每個數(shù)據(jù)關(guān)聯(lián)起來對軟件質(zhì)量中的發(fā)現(xiàn)、度量、定位都有著重要的價值。本次專題，我們會收集在各個公司中利用大數(shù)據(jù)來改善軟件質(zhì)量的最佳實踐。希望聽眾從中能收獲到，
借力大數(shù)據(jù)技術(shù)來解決軟件質(zhì)量中的頑固問題的思路和創(chuàng)意，例如重復(fù)bug要如何減少，如何識別自動重要緊急的問題，如何快速定位隨機crash、卡頓、甚至是功能問題。
借力大數(shù)據(jù)的軟件質(zhì)量建設(shè)中遇到的難點以及解決方案，例如質(zhì)量類數(shù)據(jù)如何處理才能更高校地結(jié)合到大數(shù)據(jù)工具spark、hive。
大數(shù)據(jù)帶給軟件質(zhì)量的具體效益，例如提升大數(shù)據(jù)幫助我們發(fā)現(xiàn)了什么隱藏缺陷，幫助我們節(jié)約了多少人力投入和定位缺陷的耗時。
