? 最近看到的這個詞，可能有點落伍，但覺得很有道理，當(dāng)一個測試和一個開發(fā)團(tuán)隊合作時間很長，就像同一款農(nóng)藥對農(nóng)作物上面的害蟲的效果，最開始的時候鋒芒畢露，有奇效，慢慢的效果會越來越差，也就是害蟲知道了殺蟲劑的弱點在哪，盲區(qū)在哪，因而產(chǎn)生了耐受性，免疫殺蟲劑。測試就像殺蟲劑，想去去除開發(fā)出來的軟件上面的蟲子（bug），而長時間的一直合作，測試同學(xué)的手法、思維方式會在一定區(qū)間內(nèi)禁錮，使得這個區(qū)間之外的bug不容易被看到，事實上這個問題也不是不能解，借鑒農(nóng)藥的例子，也許可以想一下：
換別的牌子的農(nóng)藥，也就是測試崗輪換，每個人的思維方式不同，每個人的盲區(qū)也不同，這個時候輪換可以將重疊的部分加固，盲區(qū)部分被一點點發(fā)現(xiàn)，相輔相成互相溝通，可成活水。
農(nóng)藥升級，修改配方，也就是測試同學(xué)通過各種途徑，拓展自己的視野和思路，試著消滅自己的盲區(qū)，這個拓展和提高不僅局限于技術(shù)，還包括思考方式以及對業(yè)務(wù)核心的理解等。
多用集中不同農(nóng)藥，也就是交叉測試，跟換品牌農(nóng)藥差不多一個意思，多種不同的覆蓋面，會讓盲區(qū)變得小，但也可能會導(dǎo)致副作用，比如耗時會比較長，ROI低。
提升農(nóng)藥濃度，也就是加大測試密度和強(qiáng)度，這樣也可以解決一部分盲區(qū)，一些耐受力不強(qiáng)的蟲子會被去掉，但也有弊端，比如ROI低，高密度和強(qiáng)度會使頑固的bug更加頑固，還會使降低工作積極性和成就感。
?我們一直在做自動化覆蓋的核心思路是：“我來看看系統(tǒng)是不是有bug，是不是和之前不一樣了”，就像有一條路，有一個機(jī)器人按照既定路線往前走，看看原來平坦的地方是否有坑了。
?按照這個思路再拓展一下，另一個核心思路也許是“系統(tǒng)里現(xiàn)在可以確認(rèn)有1個bug，能不能找到”，就像有一條路，現(xiàn)在明確了有1個坑，這個機(jī)器人按照它既定的路線走，能否找到這個坑。
?再按照這個思路往下想想，發(fā)現(xiàn)也許也可以這么想
系統(tǒng)里現(xiàn)在有1-10個bug，能不能都找到
系統(tǒng)里現(xiàn)在有至少10個bug，能找到多少
系統(tǒng)里面有1個關(guān)于數(shù)字格式化的bug，能不能找到
系統(tǒng)里面有1個關(guān)于數(shù)字格式化的bug，有1個空指針bug，能不能找到
系統(tǒng)里有3個類型的bug各2個，能不能都找到
...
?想了想，今年云棲大會上有人的分享了一個思路，修改被測代碼、用AOP等手段注入故障或者修改運(yùn)行時數(shù)據(jù)，以此來檢查測試用例有效性，也就是說，不再是從未知的一片漆黑中找坑，而是制造明確的1個或者多個坑，看看我們的用例是否能找得到。
?這個思路可以做的事情其實還挺多的，也是對于測試同學(xué)對業(yè)務(wù)代碼的理解要求更高了一層，需要能夠通曉業(yè)務(wù)代碼，并且有模擬故障模擬bug的能力，然后以此去測試自己的自動化的覆蓋能力，也許這就是有同學(xué)曾經(jīng)問過，但至今不知道怎么回答的那個問題：
“你用自動化去測試業(yè)務(wù)系統(tǒng)，那用什么來測試你的自動化呢？”
現(xiàn)在這個問題也許可以這么回答：“用自動化的斷言測業(yè)務(wù)系統(tǒng)，用業(yè)務(wù)系統(tǒng)的bug測自動化，測開閉環(huán)，相輔相成”
3.用開發(fā)業(yè)務(wù)系統(tǒng)的思路寫自動化測試用例?我們測試業(yè)務(wù)系統(tǒng)的時候，從單元考慮到接口考慮ui然后考慮大qps考慮多并發(fā)，考慮容錯考慮異常處理，考慮監(jiān)控考慮.....
?設(shè)計自動化測試的用例的時候，也許也應(yīng)該試試能不能這么做，比如：
單元能力封裝，可能是接口，可能是數(shù)據(jù)準(zhǔn)備，每個單元可以單獨(dú)運(yùn)行，可以復(fù)用
單元能力編排成流程，可能是接口-接口-數(shù)據(jù)可能是數(shù)據(jù)-數(shù)據(jù)-接口，每個編排可以單獨(dú)運(yùn)行，可以復(fù)用，比如編排成提交流程、發(fā)起審批流程、審批通過流程
流程編排成業(yè)務(wù)，可能是提交-審批-通過可能是提交-審批-拒絕
考慮并發(fā)問題，單個用例多觸發(fā)，同時觸發(fā)運(yùn)行
單元用例，也是需要測試的輸入--運(yùn)行--輸出--斷言，就像業(yè)務(wù)代碼中的1個方法一樣。
把自己業(yè)務(wù)線的自動化用例封裝成一套以單元用例、單元流程、單元業(yè)務(wù)組成的一套有層次有驗證側(cè)重點的框架，比如單元用例主要校驗單個接口或者數(shù)據(jù)準(zhǔn)備的健壯性、可靠性、正確性等等，單元流程用例主要通過每個單元用例吐出的數(shù)據(jù)進(jìn)行業(yè)務(wù)流程串聯(lián)，以驗證單個流程【或者某頁面，1個頁面的渲染需要很多接口同時生效】正確性，業(yè)務(wù)用例主要通過各流程的能力串聯(lián)完成完整的業(yè)務(wù)，驗證業(yè)務(wù)正確性。
以接口為單位封裝單元用例，以頁面為單位封裝流程用例，以頁面操作步驟為單位封裝業(yè)務(wù)用例，大致思路如是。
數(shù)據(jù)構(gòu)造類自動化，核心目的是構(gòu)造測試數(shù)據(jù)，如果能構(gòu)造出來預(yù)期數(shù)據(jù)，代表其中的各個環(huán)節(jié)、接口是ok的，順帶驗證了功能，作用是人工測試可以替代的。
業(yè)務(wù)驗證類自動化，核心目的是驗證業(yè)務(wù)功能，大約需要3個基本板塊，作用是人工測試可以替代的。這一類自動化，被數(shù)據(jù)、環(huán)境問題嚴(yán)重干擾其穩(wěn)定性和結(jié)果可信性。
數(shù)據(jù)構(gòu)造，用于給后續(xù)的流程生成將要驗證的數(shù)據(jù)
執(zhí)行驗證，通過既定數(shù)據(jù)，進(jìn)行相關(guān)業(yè)務(wù)邏輯操作，驗證正確性
數(shù)據(jù)銷毀，將構(gòu)造的數(shù)據(jù)、執(zhí)行后產(chǎn)生的臨時數(shù)據(jù)、垃圾數(shù)據(jù)進(jìn)行銷毀，保證自動化的清潔。
必要自動化，核心目的是完成一些必要的枚舉和排列組合的相關(guān)驗證，其作用是人工測試無法替代的。
? 業(yè)務(wù)驗證類自動化，多數(shù)是以驗證業(yè)務(wù)完整性為準(zhǔn)繩，這類自動化核心邏輯是“它本來應(yīng)該是這樣的，等下次我再跑的時候，看看它還是不是這樣”，對于bug發(fā)現(xiàn)能力其實相對較弱，必要自動化能很大程度上發(fā)現(xiàn)排列組合各種極限場景的bug，但需要這種自動化的場景也較少，數(shù)據(jù)類自動化，其發(fā)現(xiàn)問題的能力、發(fā)現(xiàn)bug的能力都是最弱的，但對于手工測試的提效是最為明顯的。
UI自動化
前端是最貼近用戶使用習(xí)慣，用戶對系統(tǒng)能力的直觀感認(rèn)知，直接決定用戶對系統(tǒng)的評價
UI自動化的穩(wěn)定性、可靠性、ROI一直是阻礙這個其實最應(yīng)該沖在業(yè)務(wù)最前沿猛士的核心原因。
接口自動化
服務(wù)端業(yè)務(wù)邏輯的正確和健壯，是業(yè)務(wù)能夠平穩(wěn)運(yùn)營的根本，也是讓業(yè)務(wù)贏的根基。直接決定對業(yè)務(wù)的支撐能力和擴(kuò)展能力。
接口自動化相對于UI，更穩(wěn)定，能驗證的點更多，更深入，更容易發(fā)現(xiàn)服務(wù)端業(yè)務(wù)邏輯的問題，保證業(yè)務(wù)核心邏輯的正確完整
單元測試
單元邏輯的正確和健壯，直接決定了由單元拼裝起來的接口、業(yè)務(wù)的能力，是整個工程健壯、穩(wěn)定、擴(kuò)展性的基石。
單元測試相對于接口自動化，極穩(wěn)定，一般都與業(yè)務(wù)在同一工程，驗證顆粒度更細(xì)，驗證更全面、深入，更能發(fā)現(xiàn)每個邏輯單元的問題，保證每個邏輯單元基礎(chǔ)的正確、完整、健壯，但，目前單元測試難于推進(jìn)，實施難度相當(dāng)大，增加開發(fā)時長、增加項目時長，也增加工作量，因此目下多數(shù)應(yīng)用都沒有鋪設(shè)單元測試。
安全測試
試圖通過技術(shù)手段，站在***的角度，嘗試攻破系統(tǒng)，類似于安全演練，挖掘更深層次的框架、或者部署架構(gòu)、或者網(wǎng)絡(luò)、或者中間件等相關(guān)的bug。
對專業(yè)技能要求極高，不僅對網(wǎng)絡(luò)、操作系統(tǒng)、中間件、開源框架有整體了解，更需要對當(dāng)前業(yè)務(wù)系統(tǒng)的業(yè)務(wù)有深層理解和分析，甚至要比開發(fā)同學(xué)更了解業(yè)務(wù)系統(tǒng)代碼，綜合從各方面對系統(tǒng)進(jìn)行全方位的專業(yè)性技術(shù)測試，保障的是系統(tǒng)的安全性
性能測試
通過對系統(tǒng)進(jìn)行各方面的大量摧殘，去看系統(tǒng)的支撐能力、反應(yīng)速度等，比如同時又10000個人在用會不會出問題，10000個人能同時用多久不出錯，最多能同時支撐多少個人用等。其實是為了保證系統(tǒng)的可用性，一個系統(tǒng)在業(yè)務(wù)能力滿分，UI設(shè)計交互等滿分的時候，如果總是不能用或者用起來很慢，那么業(yè)務(wù)能力滿分，UI設(shè)計交互等滿分這樣的好東西就會蕩然無存。
對專業(yè)技能要求較高，不僅需要對系統(tǒng)的整體部署接口很了解，也需要對系統(tǒng)所采用的的框架、實現(xiàn)方案、數(shù)據(jù)庫、網(wǎng)絡(luò)結(jié)構(gòu)等進(jìn)行評估，還需要對業(yè)務(wù)特點進(jìn)行分析，從而通過對系統(tǒng)進(jìn)行各種場景的模擬，對系統(tǒng)的支撐能力進(jìn)行全面評估，大致有，穩(wěn)定性測試（大并發(fā)撐很久不出問題），容量測試（系統(tǒng)大能抗住多少并發(fā)），并發(fā)測試（某個業(yè)務(wù)被同時操作時的業(yè)務(wù)邏輯處理，增減庫存問題）。
其實無論哪種測試，當(dāng)積累抽象到了一個層面時，就可以進(jìn)行自動化，性能測試自動化、安全測試自動化，UI、接口等等各種自動化，甚至借助于AI可以自動生成自動化case，自動修正等等，但問題在于，當(dāng)把這些東西都做成自動化了，那么就需要有一個手段來驗證自動化，否則自動化變成一個開環(huán)的東西，往往會變成“為了完成目標(biāo)”，最終自動化也沒起效果，手工回歸覆蓋也不做了，從而廢棄。
5.測試【自動化測試】? 斗膽說接下來的話：
? 業(yè)務(wù)系統(tǒng)的能力有自動化測試作為衡量手段，但自動化測試的能力卻幾無衡量手段。
代碼覆蓋率，分支覆蓋率，核心業(yè)務(wù)覆蓋率，這些可以證明，測試覆蓋過，或者覆蓋了，但無法體現(xiàn)自動化的能力，譬如我加了case，但沒做斷言，覆蓋率會上去，但事實上是無效case
在衡量自動化提效比例或者時長時，鮮有將維護(hù)自動化投入時間的比例、時長算進(jìn)去，如果每提效5分鐘就需要維護(hù)1小時，那么就需要考量是自動化沒有必要，還是自動化有問題亟待解決
單一、不閉環(huán)衡量標(biāo)準(zhǔn)很多時候會造成“為了衡量標(biāo)準(zhǔn)”！自動化測試對業(yè)務(wù)系統(tǒng)有制衡，但自動化測試卻無物制衡。
試試想一想集中自動化和業(yè)務(wù)系統(tǒng)的閉環(huán)衡量方式衡量業(yè)務(wù)系統(tǒng)：用自動化去卻
衡量業(yè)務(wù)系統(tǒng)：用自動化去確認(rèn)業(yè)務(wù)系統(tǒng)某個功能或接口或前端是否符合預(yù)期。
衡量自動化：用接口返回的某個功能或接口或前端不符合預(yù)期去確認(rèn)自動化是否會發(fā)現(xiàn)。
也許需要做的幾件事
從體系化的業(yè)務(wù)場景定義出發(fā)：看自動化核心驗證的是什么，保障的是什么，如果是保障業(yè)務(wù)，那么就挑核心業(yè)務(wù)、故障場景定義了的業(yè)務(wù)，在其中隨機(jī)挑選一個點進(jìn)行bug注入。
從用戶使用直觀感出發(fā)：可以進(jìn)行隨機(jī)挑選，把自己看成一個用戶，或者找到旁邊的同學(xué)，讓他看看自己在這個系統(tǒng)上會關(guān)心什么樣的功能和地方，然后在這些場景里面進(jìn)行隨機(jī)注入。
從競技角度出發(fā)：如果我是你系統(tǒng)的用戶，你是我系統(tǒng)的用戶，那么我們調(diào)過來，你把自己用我系統(tǒng)最多的地方進(jìn)行注入，我也對你的系統(tǒng)做同樣的事，我們都來看一看互相的自動化是否能夠?qū)Ψ疥P(guān)注的業(yè)務(wù)點有問題有感知能力。
從紅藍(lán)角度出發(fā)：開發(fā)同學(xué)在發(fā)布的時候，隨機(jī)對自己認(rèn)為最重要的地方專門寫一個bug，檢查自動化測試是否能在發(fā)布后可以發(fā)現(xiàn)，或者將注入能力提供給開發(fā)同學(xué)、PD、業(yè)務(wù)方，這樣的行為可以大大提高開發(fā)同學(xué)、PD、業(yè)務(wù)方對測試專業(yè)性、對自動化的認(rèn)可，以及對自動化結(jié)果可信性的認(rèn)可。
很大一個問題是，這個bug、故障給注入到哪
依然需要通過數(shù)據(jù)mock、環(huán)境探活、數(shù)據(jù)準(zhǔn)備等手段，確保自動化運(yùn)行時，需要驗證的業(yè)務(wù)邏輯所必須的條件都具備，而后需要通過技術(shù)手段或者直接改代碼（不推薦）對系統(tǒng)進(jìn)行bug注入，然后執(zhí)行自動化，盡可能嘗試在一切必要條件都完備的時候，模擬系統(tǒng)出現(xiàn)了bug的情況，用這個確切已知的bug驗證自動化的能力。
服務(wù)端的bug多數(shù)時候很難被用戶感知，但前端的很容易被用戶感知，因此，前端的bug注入驗證自動化能力，變得價值更高，數(shù)據(jù)返回對，但前端沒加載、數(shù)據(jù)返回不對但前端展示了、后端報錯前端沒有彈窗、前端圖標(biāo)位置不正確等等。盡可能嘗試將前端這個用戶感知最明顯的地方，將自動化驗證的能力放大到像真正的用戶在進(jìn)行操作。
逆向方式“我系統(tǒng)今天告訴你我有bug，我倒要看看你自動化有沒有這個本事找到”?
通過數(shù)據(jù)mock、環(huán)境探活、數(shù)據(jù)準(zhǔn)備等手段，確保自動化運(yùn)行時，需要驗證的業(yè)務(wù)邏輯所必須的條件都具備，嘗試盡可能將驗證業(yè)務(wù)邏輯這件事做的純粹。用自動化驗證系統(tǒng)的業(yè)務(wù)能力。
通過數(shù)據(jù)清理、數(shù)據(jù)恢復(fù)，將自動化運(yùn)行后產(chǎn)生的中間數(shù)據(jù)、臨時數(shù)據(jù)等進(jìn)行清理，嘗試盡可能將自動化做的，我來過，看過，但不帶走一片云彩，不留下一篇垃圾。
正向方式“我自動化今天要看看你這系統(tǒng)有沒有bug”?
重慶分公司
重慶分公司
