1.1背景
最近，看到某技術群裡面在討論精準測試，沒有弄明白到底什麼是精準測試，聽起來有點新鮮，作為測試難免有點好奇心，查了於些資料，看到一篇文章寫得不錯，也留下自己的心得體會
當我們測試時候，我們在想什麼?
相同的系統，不同的測試人員針對相同的乙個功能，a測試人員會寫10個測試用例去測，b測試人員會寫20個測試用例去測。
我們如何去評估乙個系統的測試質量更好?
事後生產遺留缺陷越少，測試的質量越好?
測試案例寫得越多、測試的時間越長，測試質量的越好?
自動化ui測試、介面測試、安全測試、效能測試，測試的種類越豐富，測試的質量越好?
當系統的測試用例不斷堆積，成百上千甚至過萬，每乙個版本變更來臨，我們該如何選擇測試用例?
隨著我們測試的越多，測試用例越來越多，工具技術越豐富，我們越來越困惑，我們怎樣算是測完乙個系統了?如何知道系統功能點測試沒有遺漏?如何清晰知道乙個系統內部呼叫流程、業務邏輯?測試效果和測試質量如何更好的體現?
1.2 精準測試理論介紹
根據對**可見程度的不同，我們可以講目前的測試活動區分為黑盒測試和白盒測試兩類。
黑盒測試主要是一種面向功能的測試，針對軟體的需求來編寫用例，通過已執行起來的系統軟體完成測試活動。在測試中，程式**對於測試人員來說是乙個不能開啟的黑盒子，只能根據程式是否能夠根據輸入資訊而產生正確的輸出資訊來測試。
白盒測試則與黑盒測試相反，測試人員需要深入到**層面，根據**邏輯結構和路徑來編寫用例，程式對於測試來說是可視的，測試需要檢查程式的內部結構，從程式邏輯入手，得到測試資料，並進行測試案例設計。
在平安內部，目前主要依然是以黑盒測試為主導。對於黑盒測試，測試人員在完成針對需求故事的用例測試後，系統覆蓋率一般能達到70%左右。但是若需要達到最終100%的目標，還需要花費大量的時間和人力補充案例，同時由於黑盒測試中，系統**對測試人員是不可見的，通常會產生大量重複冗餘的測試用例，冗餘導致測試用例難以選擇和浪費緊張的測試時間，並最終導致用例庫難以維護。
針對這種情況，白盒測試在提公升測試覆蓋率上的效果就相當明顯，由於對**層的掌握，測試人員每增加乙個測試用例，測試覆蓋率都會有乙個跳躍式的增長。然而，由於白盒測試需要測試人員對**的邏輯結構、呼叫關係、資料流等等內容都有了解，對人員的技能提出了很高的要求。對於普通測試人員來說，白盒測試並不容易掌握。
因此，針對這樣的情況，產生了穿線測試的理論。即通過技術手段，將黑盒測試與白盒測試穿插結合起來，通過黑盒測試蒐集資料，並指導使用者通過白盒測試補充案例。
基於穿線測試的理論，我們擴充套件出精準測試工具。它基於源**變更與覆蓋率來指導使用者的整個測試過程。它先通過傳統的黑盒測試把基本的功能都測試一輪，覆蓋率達到70%，同時這個過程受到精準測試工具的監控，並獲取該階段的測試結果資料。之後再通過上一階段得到的白盒結果，快速定位剩下的30%的**進行針對性的測試。
精準測試平台便是基於這樣的理論開發而成，同時增加了對增量**的分析，並引入了影響案例推進的功能。
當我們已有老系統進行測試時候，往往全量**測試用例覆蓋率結果會偏低，由於有大量無效功能和冗餘**的存在，且系統歷史悠久，每提高1%的**覆蓋可能需要200%的測試投入。對此，對於老系統，我們一般建議更著重觀察變更**覆蓋率情況，從現在做起，面向未來。
1、 基於每一次**的變更，由精準測試平台會給出此次增刪改的**行數和具體情況
2、 當執行測試案例後，精準測試平台給出測試案例執行後，此次變更的**被測試用例覆蓋的情況。
1.3 方法鏈路&覆蓋率監控原理簡介
方法鏈路監控和覆蓋率監控需要對系統**的運**況進行實時的監控和記錄，因此採用了相同的原理對系統進行監控。
方法鏈路與覆蓋率監控便是通過這種方法對執行環境的jvm進行監控，記錄各項資料，並統一同步到神兵精準測試平台。
1.4 案例推薦原理簡介
由於持續驗證平台將測試案例與系統**進行了關聯對映，因此平台還提供了針對變更**造成的影響案例推薦功能。
通過將請求與方法執行鏈路以及**覆蓋率的匹配，形成案例與**的對映表，並通過獲取版本間的**變更差異，進行反推。實現案例推薦的功能。
1.5 應用場景簡介
1、覆蓋率監控
平台提供測試過程中環境累積的覆蓋率情況，可以幫助測試人員掌握測試活動完成後整體的測試情況，並輔助測試人員就覆蓋率較低的部分補充案例，增加關注。
2、 **差異對比
檢視系統整體**行數，**各版本間的差異情況，包含增刪改**行數，詳細到**行的結果報告可以避免夾帶移交並幫助測試人員快速定位關鍵測試點。
3、 變更覆蓋率分析
通過變更**的覆蓋率以及檢視未覆蓋的變更**，幫助測試人員快速找到風險點，確認漏測的變更**，降低故障風險。
4、 受影響案例推薦
通過方法鏈路和覆蓋率提供的影響案例推薦功能，可以幫助測試人員有效定位回歸測試範圍，並幫助開發理解和查詢變更**涉及的影響點，減少bug的產生。
在以往的使用中，測試人員通過平台也發現了一些系統隱藏bug。乙個典型的案例如下：
測試人員執行案例後，發現相關方法中的分支和**行沒有被覆蓋。（標示綠色的為分支覆蓋充分，標黃色的為部分分支覆蓋，標紅色的為未執行該分支）
發現該問題後，測試人員同開發一同確定是案例設計問題還是**問題。開發反饋覆蓋分支的條件後，測試再次進行執行，發現分支依然沒有被覆蓋到。至此，測試人員可以斷定此處存在**問題，後確定是list的取值本身就存在問題。
經過開發修復後，分支實現了覆蓋。
總結：
在專案中有段時間使用過**覆蓋率，但沒有想到**覆蓋率是精準測試的一部分，之前做**覆蓋率比較粗糙，主要缺少分析，做的不夠徹底，當然這個要做好，肯定的花精力，也需兼顧測試時間是否有風險。
參考：
什麼是大資料精準營銷
精準營銷的 5w 模型已有不少答案分說，實質就是將目標客戶分類 或者是分級 有針對性地制定營銷策略。基於大資料的精準營銷就是利用大資料技術來支援精確分類，營銷效果，並根據執行結果 時效性持續改進策略。我們對精準營銷的期待，不外乎降低獲客成本 提公升營銷效率，然而 精準 首先是深刻地理解市場和使用者，...
什麼是冒煙測試？什麼是回歸測試？
一 什麼是冒煙測試？冒煙測試 smoke testing 是指 針對每個版本或每次需求變更之後，在正式測試之前，對產品或系統的一次簡單的驗證性測試，驗證產品或系統的 基本功能 流程是否正常。我們可以將冒煙測試理解為是在執行正式測試之前的 試 二 冒煙測試的目的是什麼？目的是確認軟體的基本功能正常，可...
什麼是測試
測試工作從時間上說，可以分為以下幾個階段 開發者寫程式時，要進行單元測試，比如某個函式中引數的變化是否正確，有沒有那個引數不按照期望的方式去改變 當一大塊程式寫好了，要進行 覆蓋率測試，嘗試以各種不同的組合執行各段 單元測試已通過的 最好全部 各種組合覆蓋到90 然後要進行構建，開發者進行構建測試，...