JB的測試之旅-關於線上問題的看法
本文以文字為主，會講解到理論及具體工作思路，因當時沒有儲存程式碼，因此程式碼部分不貼，也懶得寫了；
前言
這篇文章修改很多次，各種推倒重寫，原因是，一開始只想寫自己做過的東西，但是寫著寫著，覺得太局面，因此想換個大點的角度，能力有限，寫的不好或不夠，歡迎討論；
去年8月份，做了線上問題跟進的事情，持續到去年年底，後來因進度問題，以及採用的底層方案有點問題，就讓研發負責了，從某種意義上，這是第一個完全自主負責的專案；
整個專案對於Jb來說是個挑戰，同時是一個明顯的成長點，後來找工作面試的時候，很多企業對這個感興趣，問的東西比較細，到現在為止，依然很感恩有這個機會；
一年後的今天，如果要問自己，同樣的問題，有沒有更好的解決方案？目前來看，沒特別的想法，總感覺今年在測試這方面，有點退步了，畢竟今年都在不務正業；
日常騷操作
廢話一大堆，來談主題吧；
相信每一位測試&研發，都會有這日常工作： 跟進線上問題 ；
無論是PC、M端、小程式，只要是面向C端的產品，釋出後，肯定會有使用者反饋問題；
XX功能無法使用； XX功能閃退； XX功能充值不到賬 複製程式碼
相信很多同學都會遇到這些問題，遇到問題別慌，這類問題一般都會有一套應急流程，因不同公司而異，這裡只說知道的；
一般來說，線上反饋分兩類： 緊急&非緊急 ；
緊急問題處理流程
一般的 緊急問題 處理流程如下：
- 客服/運營收到線上反饋，且短時間內呈現明顯上漲；
- 通知專案經理/測試/研發，測試嘗試重現難問題，研發同步排查程式碼；
- 能重現問題/研發知道原因，解決問題；如果重現不了，研發排查差不出問題，嘗試聯絡使用者及動員更多的同學一起重現，嘗試重現；
- 確定解決問題方案（回滾程式碼/緊急線上處理，APP則hotfix或重新提交各商店），內部驗收
- 問題上線後，監控/及時回訪使用者，觀察是否已經解決問題；
- 分析產生問題的原因，總結；
- 覆盤，後續如何規避；
大致上是說，就是這麼一個流程；
非緊急問題處理流程
而對於 非緊急 的問題，一般如下：
- 客服/運營收到線上反饋，先確認，標準下不同問題的重現情況；
- 定時整理，比如一週，反饋到測試&專案處；
- 測試確認，如果是能重現，報Bug給開發，根據問題嚴重程度，酌情排期；如果不能重現，也先報Bug，列為觀察問題，後面3個版本留意下是否有類似問題或是否能重現，如果一直不重現，關閉觀察處理；
- 問題解決，測試通過，安排版本上線，同時反饋到客服/運營處，安排進行使用者回訪；
- 定時關注線上資料，確保問題已解決，並且及時郵件通知最後的結果；
基本上，這兩套流程就能用了，很普通的流程，尤其非緊急流程，內部反饋問題也大概是這樣，只是內部反饋，可以及時要現場重現；
一般來說， 緊急情況，如果實在找不到解決方案，回滾是最後的方案；
而對於非緊急情況，現實往往是測試折騰半天，無法重現，然後放一邊，畢竟工作繁忙，而且反饋的問題也比較多，沒可能過多投入；
一旦形成習慣，這類情況一般都會說， 無法重現 ，完，然後沒下文了，這也是測試日常的騷操作；
其實從使用者角度想想，蠻累的，之前簡單統計過，使用者主動反饋問題的比例是萬分之一，而這萬分之一的使用者反饋問題過來，測試卻說，無法重現就完了，而且也沒個交代，猶如石沉大海一般，很打擊積極性；
到這裡，要知道一點，不能挑戰使用者，有使用者反饋，就說明使用者想這個產品越來越好，然而現實很殘酷，他明明愛著你，但是你卻不知道，舔狗不得house；
吹下理論吧
上文得知，一條使用者反饋來自不易，那如何有效利用使用者反饋，以及把沒反饋的使用者也利用起來，就是需要思考的問題了；
需要注意， 使用者不反饋問題並不代表沒問題 ，也許使用者想反饋問題直接crash了，無法反饋，或者有問題模組不影響使用者日常使用，jb也是使用者，看到軟體有bug，懶得反饋，反正可替代品那麼多，不行就換一個羅；
Line"/>
上面說到的，這裡都不介紹，主要想說說自己對質量保障的看法，可能比較片面，但是想增加對線上質量的關注；
目前整個質量環節大致是這樣：
- 研發階段，通過研發自測、概要設計評審等手段儘可能提高交付質量；
- 測試階段，通過用例評審、豐富測試手段（探索性測試等）來驗收產品；
- 灰度驗證，快速驗證產品上線是否存在嚴重問題；
- 問題修復，線上問題快速定位、修復；
當然，上面說的只是大致環節，還有很多小環節沒有暴露，比如上車檢查（程式碼檢查）、monkey、核心資料、集體試用等環節；
看到這裡，不得不問，如何在敏捷專案中做好質量管理？
質量管理是一個大環節，並不單單是測試找bug，而是貫穿專案立項到結項整個過程，比如產品文件規範等都是一環，比如，產品文件模稜兩可，研發測試也沒有核實，結果成品跟產品要的效果不一致或者有很多BUG，導致專案延期；
怎麼做好質量管理，目前想到兩個環節： 預防 & 測試分級 ；
預防
預防，在專案初期就可以有一定的計劃，讓專案避免出現已知或可能出現的風險。 提前規避，是檢驗專案經理對整體專案把控程度好壞的重要考量標準。
而定期檢查和調整是保證產品質量的關鍵，定期召開評審會/晨會，及時同步資訊，在此顯得尤為重要；
那研發側怎麼預防？目前大眾的方案就是靜態程式碼檢查、lint、程式碼覆蓋率（jacoco較多），從以往經驗來說，靜態程式碼、lint的檢查，能發現不少編碼、效能問題；
測試分級
一般說的測試，大部分指功能測試，但是靠功能測試，不足以保障質量，因此需要對測試進行分級，拆分出更細的測試維度；
- 單元測試，不說，白盒測試的一種，即使大公司也不一定會做，小公司簡直別想；
- 介面測試，保障業務邏輯和後臺質量，常用是postman，輸入輸出，看輸出是否跟介面文件要求一致，更進一步，去資料庫修改資料，來校驗後臺處理邏輯是否正常；
- UI測試，保障到C的體驗跟互動；
- 效能測試，保障整體業務效能和穩定性，滿足大環境需求；**常見的效能監控有穩定性、啟動速度、卡頓率、流暢度、記憶體、耗電、流量，伺服器的話，就是CPU、記憶體、IO、併發使用者數、響應時間、事件成功率、超時錯誤率，**可能有遺漏，歡迎提出補充；
- 安全測試，保障系統安全性；比如涉及到下載，需要考慮到劫持場景，充值功能，需要考慮網路傳輸是否加密以及是否有破解方式；
- 自動化測試，主要是使用者迴歸測試和常規驗證，比如某些配置項、主路徑功能等；
自動化驗證和持續交付
網際網路的節奏非常快，想在高強度的氛圍保障質量，是一件很有挑戰性的事情，換個角度，是否有不需要測試就可以直接上線的情況？
如果想達到這種情況，要做什麼？
這個話題就更大了，jb也還在學習ing，但上面有提及到，靜態程式碼檢查、看研發程式碼等，除此，程式碼覆蓋率、自動化都是提高質量的一環；
但有一點是肯定的，要做這塊，必須要懂程式碼，記得前前前老大跟jb說過一句， 好的測試，編碼能力應該要比最差的研發要強；
上面說的都是臺前，那我們也要關注幕後，因為質量並不是一環；
那幕後有什麼？打包效率、提測質量、上線部署、線上質量監控，這裡不像詳細說明，直接貼一個圖；
從價效比看，釋出部署是價效比最高的，直接弄個jenkins，寫點具體釋出指令碼即可，收益是最高的；
別少看 打包效率 這類問題，一人打包10分鐘，2人打包20分鐘，如果提高到5分鐘，那1人就節省5分鐘，100人就節省500分鐘了，親身經歷，這類問題不能輕視；
其他的提測質量、線上監控，都是很大的點，這裡不說；
質量管理優化
不管什麼公司，多多少少都會有不同的問題，只是，在大公司裡面，往往通過協助平臺、流程規範等方式把問題解決或遮蔽，但是在小公司，問題就會暴露出來；
做質量管理不容易，需要強大的內心，而且，公司資源向你傾斜，只有這樣才能真正推行，否則如石沉大海；
遇到問題，不要慌，這裡介紹三步走：
體系狀況，分析梳理
古人云：工欲善其事，必先利其器，想優化，必須得先知道病在哪裡，那不妨從以下幾個維度去了解問題；
- 瞭解公司總體業務現狀
- 瞭解各業務產品應用架構、技術架構、團隊組織架構及分工配合情況
- 瞭解業務和產品需求以及未來發布規劃
- 收集核心業務質量現狀資料，明確需要優化的方向，優先順序，排期處理；
-
- 研發流程現狀資料
-
- 產品質量問題資料
-
- 測試質量問題資料
-
- 質量流程問題資料
-
- 團隊協助問題收集
- 診斷分析並找出問題根源（流程、方法、標準、工具、協助、規範等）
- 根據以上的問題以及具體原因，初步給出一個改善建議的且可行的優先順序；
質量流程，優化設計
上面給出了初步改善建議，那接下來就要規定流程，針對具體問題制定規範，明確每個職能部門的分工；
- 確認目標，即做質量前後有什麼變化，要解決什麼問題；
- 根據上一輪診斷資訊和優先順序順序，進行優化方案設計
-
- 團隊角色及分工定義
-
- 基本流程定義
-
- 流程相關工具平臺選擇，比如UI用A工具設計，測試報bug用B平臺等，確保統一
-
- 初步質量目標和模板定義
-
- 選擇試用產品/專案和推廣順序
-
- 實施計劃和風險分析
- 方案討論，修改，然後跟具體大佬溝通，得到認可後推行
- 組織團隊培訓，敏捷思想和方法
質量規範，部署實施
定下規範，就去試試吧；
- 關鍵環節控制流程部署和實施
-
- 需求跟蹤
-
- 測試設計
-
- 研發編碼、提測
-
- 釋出驗收
- 全面流程管控和標準化
- 建立自動化測試平臺體系
-
- 介面測試
-
- UI測試
-
- 效能測試
-
- 安全測試
- 構建持續整合和持續測試
- 質量保障持續優化機制建立
業界也有個詞，叫 測試左移 ，簡單說，就是讓測試提前介入所有流程：
- 需求評審，測試必須對業務熟悉；
- 技術方案評審，測試能讀懂和理解技術方案，憑豐富的經驗或者嗅覺，挖掘技術方案不足的地方，比如業務場景的可擴充套件性，業務量大幅增加後的效能問題、可測性；
- 測試用例和業務編碼並行，包括介面測試用例、功能測試用例，准入標準，功能都無問題，迴歸指令碼全部通過；
- 單元測試質量，除了保障程式碼覆蓋率之外，還要檢查UT程式碼的有效性；
- 靜態程式碼分析，有能力則協同開發一起保障程式碼質量，或者引入第三方工具，准入標準，沒有嚴重級別的問題
- 程式碼審查，同需要程式碼能力；
- 測試用例評審，提測前組織產品、研發、測試一起完成，提測後直接使用；
- 冒煙測試，提高提測質量，要通過冒煙才能提測，准入標準，比如沒有主路徑問題；
更詳細的，自行上網查詢；
大家怎麼玩
上面啪啪啪的一大堆廢話，本文的重點在於線上質量，那就聊正經事情吧；
問題一般分兩類， 效能問題、功能問題 ，體驗問題不算在這裡；
效能問題能通過一定的規則來抓取，比如獲取當前APP的記憶體，是比較固定的內容：
- 定時查詢統計
- 有問題直接落地生成log
- 日誌回傳到伺服器
- 伺服器解析日誌，做聚合統計入庫
- 前端查詢展示資料
那，在跟進線上反饋的時候，到底遇到什麼問題？
- 聯絡上使用者，但因各種問題 ，問題沒法跟進了或者需要的log拿不回來，怎麼辦？
- 壓根聯絡不上使用者，怎麼辦？
記得是在去年2月份，上testerhome發帖子問，幸運得到部分大佬答覆，看到的方式有2種：
- 部分企業有大量log（使用者行為日誌），通過log分析出使用者行為，然後內部排查問題，發現是問題處理，不能發現的，線上增加埋點log；
- 內部重現，如不能重現，則聯絡使用者，給各種除錯包等，聯絡不上的，放棄；
很不好，當時就是處於第二種，只是覺得，即使是聯絡不上的使用者，也不能浪費；
懷著這份激情，跟老大反饋多次，逐漸的，老大們也開始關注到這塊，因此就立了個專項，讓jb去負責處理這個事情，因此，這個事情的開端就是： 如何跟進線上問題；
這裡更多指的是，無法聯絡，或者聯絡了重現不了之類的使用者；
既然大家都是 依賴log 來玩，那我們也這麼玩吧；
題外話：雖然很不喜歡處理線上反饋，但遇到暖心的使用者真的很感動，幸運的是，jb遇到不少，遠端各種協助跟進問題，好人還是不少的；
獨樂樂不如眾樂樂
既然問題核心是沒有log，導致無法跟進問題，那換個角度，有怎樣的log才能跟進問題？
因此，有了以下的內容：
- 當時產品裡面有很多收集效能日誌功能，比如卡頓、記憶體、啟動速度，只是都不會在release版本開啟，因為收集日誌本身存在效能問題；
- 那使用者行為日誌是不是也可以跟效能日誌一樣收集？
- 但是，不在release版本開啟，做了也沒意義，那，有沒有辦法做到在release版本開啟這些日誌功能？
- 如果支援release版本開啟，那怎樣的日誌內容能滿足不同業務進行跟進問題？畢竟不同業務需要的日誌內容不一樣；
- 日誌什麼時候儲存？儲存在哪裡？什麼時候回傳？回傳到哪裡？回傳到怎麼處理？
這就是第一期的目標- 發現問題 ；
上面的問題如何解決？
Q：如何在release版本開啟收集日誌功能？並且支援動態關閉？
A： push ，產品本身支援push，有獨立push通道，即使使用者退出APP也能收到push訊息， 因此，針對不同模組（使用者行為日誌、卡頓、啟動速度、記憶體等）做獨立的標記，定好協議，客戶端收到push訊息後做協議解析，然後修改對應模組的標記，APP重啟後做判斷，這樣就可以達到動態開啟\關閉的效果；
Q：怎樣的日誌內容能滿足不同業務進行跟進問題？
A：這是個問題，一開始想著做全家桶，但是後來發現不適合，原因是業務方只會關注自己業務的出錯日誌，如果弄全家桶，業務方過濾日誌需要大量成本；
因此覺得，封裝一層提供介面，提供一個寫日誌的介面，業務方根據協議來傳對應的內容即可；
這樣，一份日誌可能會有多個業務方的內容，沒關係，因為格式是固定的，日誌回傳到伺服器後，伺服器指令碼做解析，最終會把一個日誌根據格式內容拆分出N個日誌，這樣拆分出來的日誌就是對應一個業務方的日誌；
******************************************** #此處公共模組資訊 版本號：XXXX 子版本號：XXXXX 流水號：XXXX 時間：XXX 模組：小說 ******************************************** #具體業務日誌內容 ******************************************** ******************************************** #此處公共模組資訊 版本號：XXXX 子版本號：XXXXX 流水號：XXXX 時間：XXX 模組：搜尋 ******************************************** #具體業務日誌內容 ******************************************** 複製程式碼
Q：日誌什麼時候儲存？儲存在哪裡？什麼時候回傳？回傳到哪裡？回傳到怎麼處理？
A：這裡面，只有日誌什麼時候儲存是關鍵；但是這裡不細說過程，最終選擇的是 ofollow,noindex">xlog ;
微信開源的一個收集日誌庫，好處就是，不需要自己處理各種邏輯（比如日誌檔案限制多少M後拆分等），直接初始化，然後XLog.d就可以用了；
xlog是後面換的，一開始是自己折騰的，浪費不少時間，所以，造輪子之前，想看看有沒有好輪子，避免浪費時間；
因為有個業務是聯網業務，因此選擇軟體啟動後就非同步初始化，只要業務方一呼叫XLog.d，就會有檔案生成；
Q：什麼時候回傳日誌？
A：這裡要解釋下，一般情況下，日誌不會回傳，上面都說了，要解決兩個場景，
- 1）使用者不反饋；
- 2）使用者反饋但是沒日誌；
如果是使用者主動反饋，則在點選反饋的時候，先把日誌上傳，得到一個地址，然後再把地址傳給客服系統的介面，
這樣就能在具體反饋裡面看到具體日誌，當然這個是原始日誌，需要解密處理，因此會再傳一個解密後的地址，跟解密伺服器約定好的格式；
如果使用者沒反饋問題，那就在業務出錯時把日誌上傳，業務出錯的時機交給業務方自行判斷；
部分業務是沒辦法識別到出錯的，比如聯網業務，因此這類業務採用日誌先落地不上傳的策略，需要時通過push拉取日誌；
至此，第一階段，發現問題，到此結束；
看看幹了啥
既然有日誌了，那對於測試同學來說，比較方便了，如果沒記錄，問題解決率在30%左右，看上去覺得很低，但實際是因為，很多功能研發還沒埋點，算是一個不錯的效果；
點對點的問題解決了，那點對面了？從專案的角度，想知道線上什麼情況，怎麼搞？
因此專項第二階段就是 監控問題 ；
其實，監控問題，沒有太多的內容可以說，無非就是把日誌如何解析，聚合，資料處理再顯示而已，最終的效果就是，點選某一個版本，選擇某一個模組，就可以知道這個模組收集到的日誌排名，研發根據這個排名依序解決問題就好了；
換種方式踩坑
做完上面2個階段，時間到了10月初，期間從立項，方案，調研，編碼，灰度，推行都花了不少時間，尤其在推行這一環節，要有具體資料來吸引業務方來使用，不然做出來沒人用是很尷尬的事情；
這時候，既然產品有這樣的功能，想讓使用者有意識使用，說白就是想增加曝光，有如下的想法：
- 新手引導使用者
- 產品首頁增加懸浮框告訴使用者
- 簡化使用者反饋的路徑（原有路徑有3級，比較麻煩，業界大部分產品也類似）
但是1、2被產品經理打回，原因是，使用者反饋這個功能不是每個使用者都必須的，為了那點人而浪費一個新手引導位，不合適；
當時聽到很不舒服，但是事後回去站在場景的時候思考，有點道理，打臉了吧~
那就想辦法簡化使用者進行反饋的路徑吧，經過思維的碰撞，內部覺得，在產品上三指長按一定時間彈出反饋介面，是一個不錯的場景；
跟產品溝通後，產品覺得可以，那需求就為： 使用者三指同時長按螢幕2S，彈出意見反饋頁面；
從此，跌入深淵，自己給自己挖了一個大坑；
跌入深淵
需求很簡單： 使用者在app內使用三指長按螢幕2s，APP執行某操作；
挖坑
需求關鍵字： 三指，長按，2s，執行 （這不是需求原話麼）
當時的處理邏輯是這樣的：
- 判斷使用者手指個數
- 如果是3個，設定一個runnable 2S後執行
- 執行時再判斷使用者手指個數
- 如果還是3個，執行操作A，over
（懂的大神已經笑了～）
當時信心滿滿的上線後， 發現使用的uv\pv都非常高 ，非常不合理，因為app上沒有功能引導，使用者也沒有三指的行為習慣，所以 肯定是出bug 了；
跟進這問題2個步驟，
- 看使用者反饋，結果上千條反饋，都沒有一條相關反饋，那是否可能是打點問題？
- 檢視統計程式碼，也沒發現異常；
問題到底在哪裡？ 新增了使用者的場景統計，發現部分使用者 在色情網站會連續出現打點 ，本地嘗試沒發現問題，就讓其他同學幫忙用用，結果發現問題了！！（一個人的力量是有限的，理解也是有限的～）
原來使用者是 有多指（3指及以上）進行縮放的習慣 ，如果使用者是使用 三指進行縮放 ，而且還是 一直在螢幕不停縮放 （即沒有手指離開螢幕），就會出現問題了；
因為程式碼只判斷觸發前後的手指個數，中招了！（事後跟產品溝通，這種使用者可能是平時有用iPad的習慣。。而色情網站是使用者在看圖片或者漫畫，為了看得更清晰，所以需要縮放，就出現問題了，但是還是沒想懂如此明顯問題，居然沒使用者反饋？）
噗，多明顯的設計問題啊～！
二遇坑
重現後問題就好辦了，邏輯重寫，處理event事件，觸發邏輯不變：
1）當用戶手指個數為3個且每隻手指按下時間差不大於50ms（防止使用者是一隻手指點選後再放第二隻手指，這種場景是 無效的，因此設定個兩個手指的時間差），就會設定一個runnable 2S後執行； 2）其他情況，長按後，產生up事件（有手指抬起）、move事件大於一定距離（認為使用者在滑動）、大於3只 手指，這些場景都會把執行removeRunnable操作，則把runnable取消，避免觸發操作a邏輯； 複製程式碼
這樣算是把門檻調高了，上線後，誤觸發的佔比大幅下降，但是，仍然有百分之一的使用者誤觸發，雖然人均pv大部分為1！！
對比原來動不動誤觸發，的確是有優化效果的，但是，百分之一的uv也是很困擾～
經過好幾輪灰度，最終發現一個問題，問題使用者的event常規統計數對不上，那說明有其他沒有統計到事件在一直執行，最終 發現是cancel事件！！！
再次懵逼，cancel事件理論上是不會觸發，至少自己本地用幾臺機器都沒出現。
android文件的說明很簡短，想看明白很難。國外一網頁說的還比較詳細，寫在這裡分享給大家：
原文是這樣的：
You receive this when a parent takes possession of the motion, for example when the user has dragged enough across a list view or scroll view that it will start scrolling instead of letting you press the buttons inside of it. 複製程式碼
意思是這樣的：
當你的手指（或者其它）移動螢幕的時候會觸發這個事件，比如當你的手指在螢幕上拖動一個listView或者 一個ScrollView而不是去按上面的按鈕時會觸發這個事件。” 複製程式碼
當時懵逼，我們的場景沒有這種行為，為什麼還會有cancel事件，肯定有其他原因，最終終於找到了：
“當控制元件收到前驅事件（什麼叫前驅事件？一個從DOWN一直到UP的所有事件組合稱為完整的手勢，中間的任意一次事件 對於下一個事件而言就是它的前驅事件）之後，後面的事件如果被父控制元件攔截，那麼當前控制元件就會收到一個CANCEL事件， 並且把這個事件會傳遞給它的子事件”； 複製程式碼
劃重點：被父控制元件攔截！！
最後經過多次驗證，的確是被攔截了，但是，是 被rom攔截 了！
通過統計資料，發現oppo r9及以上機器很容易出現該問題，人均pv高達幾十次，後來找來機器驗證，發現問題了：
原來這些 手機系統上自帶了一個三指上/下滑動進行手機截圖 的功能，而 原理就是監聽event事件 ，如果發現手指個數等於3，作業系統層直接返回cancel事件；
而客戶端沒有針對cancel事件做處理，因此導致邏輯繼續跑，意味著使用者執行系統三指截圖功能時，順帶把app的這個三指功能也觸發了～
這個問題已經跟oppo的研發溝通，的確如此，而且一加、小米、魅族等新機器都有此功能，如果手動在系統設定把系統的三指功能關閉，則app的三指功能恢復正常，再次驗證這個假設；
雖然發現了問題，但是開心不起來，因為後來 發現不同廠商雖然都有這功能，但是實現的方案不一樣 ，這裡不細聊，後面權衡後，決定對oppo的手機做相容處理；
（系統邏輯是三指長按後滑動，我們的邏輯是三指長按2s，其實還有區別，但是被系統強姦了。。）
處理方案討論了好久，也好了好多大神溝通，紛紛表示沒辦法，畢竟是作業系統返回的，你能怎麼辦？話雖這麼說，但是後來還是針 對cancel事件做了特殊的處理 ；
通過除錯發現，一旦觸發這種cancel事件，oppo系統會一直返回cancel事件（原理是觸發move，系統把所有事件觸發都返回cancel，對於系統而言，move是很高頻的且很短，而如果真的觸發了系統的截圖， 每次截圖耗時基本在200ms以上 ，針對這一特性做手腳）
1）在收到cancel事件時，判斷之前觸發的runnable是否已經存在；如果存在，則手動把runnable取消； 2）如果每次cancel事件大於200ms，則認為觸發了系統的截圖，則把這個事件相加儲存起來，原因是排除move事件 的影響；並且執行次數+1； 3）當執行次數少於15次且時長大於2s，則認為滿足條件，此時判斷是否為3隻手指且沒明顯滑動操作，如果是， 則立即觸發執行操作a；（設定次數是為了提高門檻，不然隨著次數的增加，肯定會有達到2s的情況，這樣就沒意義了） 複製程式碼
程式碼上線了，雖然不是百分百杜絕誤觸發，但是佔比再次下降，基本達到萬分之一，這事後來就不折騰了～
如果有更好的解決辦法，歡迎一起討論，這個方案並非合理方案，只是簡單處理，而整個功能雖然一句話，但是從編碼到最後發現，用了一個月多點，而不停灰度收集統計是時間的大頭～
小小結：
- 研發的概要設計文件流程還是需要的，別以為只是一句話需求就不做了；容易陷入想當然；
- event容易出現相容性問題，廠商有可能做了定製處理，這塊要切記；
愛理不理
既然使用者反饋這麼重要，是不是每條都需要跟進？
答案也是否定的，給自動化一樣，自動化很重要，那是不是所有專案都要做自動化？同理而已；
有一類產品，不需要做過多的線上閉環這麼一個流程，是跟錢相關的，比如P2P，理財類；
為什麼？因為使用者的錢在你那裡，再大的bug的，使用者的也得忍受，而工具類產品不一樣，比如新聞資訊類，有問題，換一個，很現實；
這也不代表用理財這類產品不需要管線上反饋，只是不需要做到那麼細的地步，遇到線上問題，還是要處理的哦；
撒花
寫了將近1天的時候，本來三指那塊是重點，但是想著既然都要寫了，就從一個大的角度去說說吧，對自己來說，算是鞏固了這塊的知識了，算一個知識回顧吧；
看到這裡，感謝您的堅持，純文字的文件，居然能堅持看到這裡，兄弟，不容易吧；
小結
常規流程，來個小結；
- 線上質量要重視，很容易造成使用者流失；
- 想做好質量管理，有兩個環節：預防&測試分級；
- 預防是依賴流程、工具進行約束；
- 測試分級大致為：單元、介面、UI、效能、安全、自動化測試；
- 瞭解持續交付，包括部署流程，線上監控等；
而質量管理優化，有以下三步：
- 體系狀況，分析梳理
- 質量流程，優化設計
- 質量規範，部署實施
剩下的，就是收集log的工作，大概思路如下：
- 客戶端具備生成日誌且儲存日誌功能；
- 客戶端具備上傳日誌功能；
- 客戶端具備關閉上傳日誌功能；
- 後臺系統具備將上傳日誌進行問題排序且提供日誌下載功能
接著就是安卓三指遇到的坑，總結下：
- 研發的概要設計文件流程還是需要的，別以為只是一句話需求就不做了；容易陷入想當然；
- event容易出現相容性問題，廠商有可能做了定製處理，這塊要切記；
題外話
以前見識到手淘的黑科技，具體連結忘記的，大致流程如下：
- 使用者遇到問題
- 程式上傳日誌
- 解析日誌，轉化成使用者行為資訊
- 通過視訊回放的方式觀察到使用者的操作場景
這樣，就可以把使用者的操作一覽無遺，高階玩家高階玩家；
最後，謝謝大家~
