在總結線上問題的時候，我們發現大部分的線上問題是由於功能漏測所導致的。原本應該測試的流程沒有測到，或者是根本沒有考慮到一些情況，這些都會產生漏測。
在大部分的產品中，漏測是難以避免的，只要不出大問題，漏測的危害會被人為的粉飾和縮小，但是在某些跟貨幣或貨幣等價物打交道的行業，漏測往往意味著經濟損失，一次漏測可能會影響一群人的職業生涯，萬萬馬虎不得。
下面描述的方法可能對降低漏測有所幫助。
站在業務和使用者的角度去理解需求。盡量發現需求中不合理的地方或者是對使用者來說講不通的地方，給需求**，讓需求更加清晰簡明。需求越明確，驗證點也就越明確，用例設計起來難度也會降低。
如果是新接受乙個產品或專案，盡可能的了解現有系統的邏輯和業務也可以降低漏測風險。
現有系統中總是或多或少有一些坑，由於某些複雜或者不可描述的原因，這些坑不會有人告訴你。舉乙個我朋友的例子，他在做開發的時候因為偷懶，某些異常就直接捕獲而不做相應的邏輯處理，在一些特殊條件下，這會造成資料丟失或者不一致的問題，但他認為這些問題發生的概率非常低，所以他誰也沒告訴，天知地知你不知我知。像這種坑，一般來說要麼測試同學自己試出來，要麼跟開發關係好，讓他善意的提醒某些異常場景。當然，前者可能更加靠譜一點點。
因為環境問題而翻車也是大概率事件。某些問題明明測試環境測出來是沒問題的，但是在生產環境就各種問題，有經驗的測試同學應該都遇到過。一般的解決思路是準備乙個準生產環境，盡量跟線上環境保持一致，比如軟硬體一致，資料量一致等，在準生產環境做最後一輪的回歸。
一些用例看起來測了很多東西，但是場景實際上覆蓋是不完全的。怎麼判斷場景覆蓋是否全面的，常規做法是用例評審，邀請相關責任人做評審，發現用例中考慮不全面的地方，然後改進。因為用例評審會占用專案時間，所以在專案緊急的時候往往會被砍掉，又或者評審一般流於形式，這樣到後來各方參與者的熱情不高，直接變成了流程性的東西，沒辦法提出一些有建設性的建議，所以評審在某些時候的效果是一般的。
去年曾經聽到過用**覆蓋率去衡量用例質量的案例，今年在測試沙龍上也聽到了類似的分享。既然場景都是由**實現的，那麼如果用例覆蓋的場景夠全的話，覆蓋率相應就會更高。具體可以這樣操作，對於增量**，先把用例用手工和自動化的方式去執行用例，然後跑出**覆蓋率，如果增量**中有**沒有覆蓋到，那麼就可能證明測試用例考慮的場景不全，需要改進。
**覆蓋率並不能證明**質量的高低，但是可以讓我們知道哪些**沒有被測試到。沒有被測試到，就改進用例，試著去覆蓋。
但是有些**中的異常很難從黑盒端構造，對於這些情況，白盒用例可能更加適合。
測試人員如何盡可能避免漏測
漏測是測試行業老生常談的話題，測試人員如果因為漏測出現很嚴重的生產事故，是要負全責的。一般公司都會根據生產事故的嚴重性採取一定的處罰措施。那麼問題來了實際生活中如何避免漏測？首先測試時間足夠的情況下，可以先根據需求拆分測試點，然後再根據測試點採用邊界值 等價類劃分 錯誤推測 經驗來設計測試用例。然而...
如何讓docker映象盡可能小
很容器想到from scratch,就是沒任何基礎映象 from scratch copy p entrypoint p 有幾點要注意 動態編譯的bin程式 root dev 86 205 ci sftp ldd p linux vdso.so.1 0x00007ffd6ef7b000 libpth...
準則5 盡可能避免執行緒的延遲撤銷處理
準則5 盡可能避免執行緒中做延遲撤銷的處理 說明 在前面我們已經講過，執行緒的撤消分為 非同步 延遲 這兩種型別 並且 非同步撤消 也是非常容易引起各種複雜問題的元凶。那麼，現在要在程式中除掉 延遲撤消 延遲撤消雖然不會像非同步撤消那樣會引起各種各樣的問題 但是 注意事項還是有很多的。只有把下面的這...