1. 前言
作為一名自信的 QA释树，對于測試通過的項目，如果有人反饋有問題，腦海中的第一反應一定就是：不可能奢啥！一定是操作有問題署浩。入職以來經(jīng)手大大小小的項目也有 40 多個，一直沒出過問題扫尺，也讓我在年度的總結(jié)上自信地寫到：所有項目按時按質(zhì)發(fā)版筋栋，未出現(xiàn)線上問題。
但是正驻，這種自信讓我掉以輕心弊攘，使得微信小程序 SDK 的第一個線上問題也隨之而來了。
對于線上問題姑曙，可能很多人都以為把問題解決了就完事了襟交，并不重視對問題的復盤。事實上伤靠，復盤的作用可能遠大于解決問題本身捣域。
在神策的企業(yè)文化中重要的一項就是復盤，每一個問題對于我們來說都是一筆寶貴的財富宴合。通過對于問題的復盤焕梅，總結(jié)經(jīng)驗教訓，能夠更好地促進我們成長卦洽。
下面我們來看下對于這個問題是如何進行復盤的贞言。
2. 回顧目標
神策微信小程序 SDK 的目標是實現(xiàn)對于主流小程序開發(fā)框架的全埋點功能。但是阀蒂，在測試過程中發(fā)現(xiàn)由于 Taro3.0 框架重新定義了標簽點擊行為的邏輯该窗，使得一次點擊行為會觸發(fā) SDK 的兩次點擊事件 $MPClick，造成了埋點數(shù)據(jù)重復蚤霞。
因此酗失，這次發(fā)布的 v1.14.3 版本旨在解決 Taro3.0 框架下點擊事件重復觸發(fā)的問題，實現(xiàn)神策微信小程序 SDK 真正意義上的無框架障礙全埋點采集昧绣。
3. 評估結(jié)果
3.1. 符合目標
- 解決了 Taro3.0 框架下點擊事件重復觸發(fā)的問題规肴；
- 實現(xiàn)了神策微信小程序 SDK 真正意義上的無框架障礙全埋點采集。
3.2. 低于目標
- 本次發(fā)布的版本存在嚴重的線上問題滞乙。
4. 分析原因
4.1. 回顧過程
- **2020 年 12 月 17 日 19 : 05 **微信小程序 SDK 發(fā)布了 v1.14.3 版本奏纪，新增了 $MPClick 事件可自定義屬性鉴嗤，修復了 Taro3.0 框架下點擊事件重復觸發(fā)的問題斩启；
- **2020 年 12 月 18 日 16 : 27 **技術(shù)顧問收到客戶反饋：微信小程序 SDK 更新到 v1.14.3 版本后，測試過程中發(fā)現(xiàn) SDK 篡改了他們方法的返回值醉锅，屬于破壞型 proxy兔簇；
- **2020 年 12 月 18 日 16 : 30 **技術(shù)顧問查看代碼發(fā)現(xiàn)這個問題以前在支付寶小程序出現(xiàn)過，并和 QA 一起復現(xiàn)了問題；
- **2020 年 12 月 18 日 16 : 35 **問題同步給研發(fā)和 QA 組長垄琐，并分配下一步具體工作：QA 去 GitHub 上刪除對應版本代碼边酒，研發(fā)組長協(xié)助刪除 npm 上的版本，研發(fā)開始修復問題狸窘；
- **2020 年 12 月 18 日 16 : 37 **研發(fā)組長和 QA 完成版本刪除墩朦；
- **2020 年 12 月 18 日 16 : 45 **研發(fā)修復完成，交由 QA 測試翻擒；
- **2020 年 12 月 18 日 18 : 05 **QA 測試完成氓涣，并發(fā)布了最新的修復版本 v1.14.4，完成了線上驗證陋气；
- 2020 年 12 月 19 日 11 : 31 技術(shù)顧問組長找出了所有使用問題版本 v1.14.3 的客戶并同步給技術(shù)顧問劳吠；
- **2020 年 12 月 19 日 15 : 00 **技術(shù)顧問通知了所有使用 v1.14.3 的客戶，告知他們存在的問題并提醒他們更新版本巩趁。
整個問題的生命周期從 2020 年 12 月 17 日 19 : 05 發(fā)版痒玩，到 2020 年 ****12 月 19 日 15 : 00 所有客戶通知完成，總共歷時 44 個小時议慰〈拦牛可以分為如圖 4-1 中的 6 個階段：
圖 4-1 線上問題生命周期
這次問題是我經(jīng)歷的第一個線上問題，這次經(jīng)歷不僅讓我完整了解到線上問題的處理流程别凹，更讓我充分地感受到各個環(huán)節(jié)上團隊人員的密切配合便瑟。從問題開始到問題解決，小程序團隊全員時刻處于待命狀態(tài)番川，每個環(huán)節(jié)都爭分奪秒到涂，確保了此次問題的快速修復，沒有造成較大的影響颁督。
回顧線上問題的整個過程之后践啄，我們需要分析產(chǎn)生這個問題的具體原因。
4.2. 原因分析
4.2.1. 自動采集點擊事件
在進行具體的原因分析之前沉御，我們先來看下神策微信小程序 SDK 自動采集點擊事件的原理屿讽。
1、在重寫 Page 函數(shù)時吠裆，先通過 _.getMethods 獲取除 Page 鉤子以外的自定義事件處理函數(shù)集合 methods：
2伐谈、對 methods 集合的每一個自定義事件處理函數(shù)進行重寫，獲取事件觸發(fā)時的 type 類型试疙，type 為 tap诵棵、longpress 或者 longtap 則觸發(fā) $MPClick 事件，將 wxml 文件標簽中 dataset 定義的屬性作為事件屬性：
點擊事件的自動采集不僅能采集到用戶的點擊行為祝旷，還能自動采集點擊標簽的相關(guān)屬性履澳。
只要在 wxml 文件的標簽中通過 data- 定義的屬性都可以采集到嘶窄，可以自動采集的屬性如表 4-1 所示：
建議在元素中定義 id 、data-content距贷、data-name 這三個元素之一作為元素標識柄冲，若無這三個屬性，則在神策分析平臺無法進行標識忠蝗。
接下來现横，我們來看一個自動采集點擊事件的例子。
1阁最、配置如下的 button 標簽：
2长赞、點擊 button 后觸發(fā)的事件內(nèi)容如下所示：
至此，我們可以看到自動采集了 button 的點擊事件闽撤。
4.2.2. 具體原因
了解了微信小程序 SDK 是如何實現(xiàn)自動采集點擊事件的原理得哆，此次問題的原因就比較容易分析了，下面我們看下導致此次問題的具體原因是什么哟旗。
1贩据、首先我們需要了解下小程序的頁面邏輯，每個頁面都有一個單獨的 JS 文件為頁面組件添加執(zhí)行邏輯闸餐，所有方法都寫在 Page( { } ) 中饱亮，主要包含三個部分：頁面的初始數(shù)據(jù)，小程序本身帶有的生命周期函數(shù)和自定義的函數(shù)方法舍沙。例如下面示例中定義的兩個方法 testA 和 testB：
2近上、根據(jù)上一節(jié)提到的點擊事件自動采集原理，我們對客戶小程序的所有自定義方法進行了重寫代理拂铡，判斷 type 類型為點擊時觸發(fā) $MPClick 事件壹无，但前提一定是不能影響客戶自定義方法的執(zhí)行；
3感帅、小程序 SDK v1.14.3 版本在更新現(xiàn)有邏輯時斗锭，修改了代理方法的返回值，由返回客戶方法的執(zhí)行結(jié)果改成了直接返回 false失球，如圖 4-2 所示：
- 這就使得上面代碼中 Page 自定義的方法 testB()岖是，原本客戶業(yè)務邏輯是 “return '執(zhí)行方法 B'”，但是經(jīng)過我們 SDK 的方法重寫实苞，變成了 “return false”豺撑。
-
testA() 本來應該打印出 testB() 中定義的返回值，不過由于 SDK 代理使得 testB() 返回 false黔牵，導致 testA() 的執(zhí)行結(jié)果不符合預期聪轿，如圖 4-3 所示：
圖4-3.png
正確的業(yè)務邏輯執(zhí)行結(jié)果應該如圖 4-4 所示：
圖4-4.png
4.2.3. 解決方案
知道了問題的原因之后，解決問題就比較容易了荧止。只需要在代理客戶方法時修改返回值為客戶原來方法的返回值屹电，如圖 4-5 所示：
圖4-5.png
5. 總結(jié)規(guī)律
5.1. 經(jīng)驗教訓
雖然此次線上問題的原因比較簡單，但是經(jīng)過深刻的反省之后跃巡，我總結(jié)了如下幾點經(jīng)驗教訓：
QA 對代碼的改動需要具有敏銳的感知危号，要詳盡追究每行代碼改動的目的。對于代碼的 diff素邪，一定要知其然外莲，知其所以然。QA 可能不需要編寫很復雜的代碼兔朦，但是一定要能看懂代碼偷线，否則測試覆蓋率一定不高；
此次問題的發(fā)生主要在于 QA 的測試 case 未覆蓋到方法的返回值沽甥，對于小程序基本原理理解的不夠深入声邦。因此，QA 需要對測試的業(yè)務非常熟悉摆舟，通過業(yè)務屬性探索測試 case亥曹；
QA 沒有遵守流程，在研發(fā)組長沒有給出 code review 通過的回復之前恨诱，就直接開始測試媳瞪。這樣使得測試代碼是未經(jīng)過 double check 的，很容易出現(xiàn)問題照宝；
此次問題屬于再犯蛇受，之前在其他小程序上也出現(xiàn)過同樣的問題。這種再犯的問題是最可怕的厕鹃，表明了沒有對出現(xiàn)的問題做好總結(jié)兢仰。對于 QA 而言，需要將漏測的 case 加入回歸測試的 case 中剂碴，定期對回歸測試的 case 進行總結(jié)旨别。
5.2. 問題
通過此次線上問題暴露了自己作為一名 QA 所存在的一些問題：
對于 SDK 代碼和小程序基本原理還不夠熟悉；
對于代碼的改動沒有追根究底汗茄，相關(guān)邏輯的了解不夠充分秸弛；
沒有嚴格遵守測試流程；
沒有及時總結(jié)已有的問題洪碳，導致同樣的問題再次出現(xiàn)递览。
5.3. 改進
經(jīng)過此次線上問題的復盤，有如下行動作為改進的方向：
QA 在 2021 年的 Q1 季度完成對微信小程序 SDK 代碼的熟讀瞳腌，研發(fā)負責組織 2 次以上針對 QA 的小程序基本原理培訓绞铃，從而讓 QA 和研發(fā)在代碼理解上達到水平一致；
研發(fā)在以后項目中需要詳細評估改動嫂侍，準確定位影響范圍儿捧，并在相應的提測郵件上重點備注荚坞，讓 QA 能更詳盡的設計測試 case；
此次問題之后菲盾，QA 和研發(fā)都需要嚴格遵守開發(fā)測試流程颓影，相互監(jiān)督，絕不在任何一個流程環(huán)節(jié)中出現(xiàn)越界或者違規(guī)懒鉴；
QA 在 2020 年 12 月底之前完成對此次問題的詳細總結(jié)诡挂，并把漏測的 case 加入到回歸測試 case 中，防止再次出現(xiàn)同樣的問題临谱。
6. 結(jié)語
本文通過對于一次線上問題的復盤璃俗，介紹了復盤的整體流程，希望通過本文能給大家提供一些復盤相關(guān)的參考悉默。
更多內(nèi)容城豁，歡迎關(guān)注公眾號：神策技術(shù)社區(qū)
