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