[測試平臺] 全流程客戶端測試質量保障

yyy丶發表於2020-07-25

客戶端

前言：

該平臺為了解決在日常測試中遇到的問題！
整片文章從迭代的時間線中描述，遇到什麼問題並如何解決。

提測前：

問題場景：

【excel表格、純html-table】在【評審用例、維護、執行】下拉框的方式，一個頁面內的所有case中，不方便【查詢、維護、直觀的看到重點】
- 思維導圖：管理整個用例的大局只展示【頁面、測試點】，需要哪個頁面，如何跳轉，下面有哪些功能點一目瞭然
- html-table：展示每個測試點的細節case
【excel表格、純html-table】遇到自動化case時，不能很好的結合
- 頁面節點關聯 className
- 測試點的每個細節關聯 methodName
- 如何執行排程我後面再自動化測試時在講。。。
當開發重構某一個模組時，無法很直接判斷出需要執行的case
- 【測試特性】: 一種屬性，可以是一個很大的模組，也可以是一個很小的點。一個【測試點、case、頁面】往往對應著多個特性（經常漏測的case，大部分都跟這個有關）
- 漏測例子：QQ登入頁面（模組），我們經常寫case時【賬號框、密碼框、登入按鈕、修改密碼】(容易跟著需求走)。大部分人都沒有發現他們共同的特性【登入狀態】，例如：同賬號登入，登入後修改密碼，登入斷網等等。。
- 影響範圍例子：開發重構播放器，這時候我們知道把跟【播放器】(特性)相關的case全部執行一遍。這時候需要在海量的case中找...浪費大量的時間
- 在【case、頁面、功能點】打上【特性標籤】, 不論是開發重構的影響範圍，還是在寫case時模組之前的互相影響(同時跟產品確認那些是沒考慮到的)，都能很好的應對。

提測後：

段子小場景(自備小板凳、瓜子、花生)：

冒煙測試
- 測試小哥：@開發小哥，修復一下bug？
- (經過幾個小時修復)
- 開發小哥：已經改完啦
- 測試小哥：好的。。 -（經過測試小哥一番驗證，10個bug，修復了5個簡單bug，還有3個一般bug只修了一半，2個複雜bug未修復）
第一輪測試
- 測試小哥：@開發小哥，還有7個bug，啥時候修復完？
- 開發小哥：正在修改中，快了。
- (經過幾個小時修復)
- 測試小哥：（快下班了）@開發小哥，bug修復了嗎？
- 開發小哥：【你這場景我怎麼復現不了啊、feed推薦一直不給我推薦相應場景】
- 測試小哥：。。。你設定的abtest了嗎？
- 開發小哥：。。。沒有，【這裡還有abtest啊、你給我造一下資料吧、你這個復現步驟寫的不詳細】
- (在測試小哥的幫助下，經過幾番的努力終於解決了bug)
第二輪測試
- 測試小哥：@開發小哥，還有幾個小bug，趕緊修復一下。
- 開發小哥：不急，幾個小問題很快就解決了。
- （測試小哥看幾個小bug，又不好意思一直催）
- 開發小哥：（快下班了）@測試小哥，修復了
- 測試小哥：自測了嗎？
- 開發小哥：測過了（編譯通過，等於自測通過）
- （經過測試小哥一番驗證，仍然只解決了一部分，甚至改出了新的bug）
- (最後一來二去，到了深夜)
經過N輪測試後
上線（產品的催促下）
- (線上出現嚴重bug)
- 產品：@開發小哥這裡有bug，趕緊修復，影響很大！
- 開發小哥：【這個bug測試怎麼沒有測出來啊、復現不了、改動很大、暫時無法解決】
- 測試小哥：【我看看、這個bug復現不了、我這裡是正常的、我之前測試都好的、我們沒有XX機型】
- 產品：。。。
- （經過一段時間，最後復現了bug，並修復重新發版）
迭代總結
- 產品：線上有bug，導致使用者留存又下降了
- 開發小哥：【測試沒有測出來，需求沒有明確描述】
- 測試小哥：【測試人力不足，測試時間不夠，復現概率低，我們沒有XX的機型，需求沒有明確描述】
- (最後通過各方協商，定製了一大堆流程。。。) 以上段子純屬虛構，如果有雷同，純屬巧合！

遇到的問題

開發修復bug【不好復現，不自測，資料問題、描述溝通問題】
- 解決方式：記錄使用者操作資訊（跟錄製指令碼相識）
- 傳統錄製指令碼：最大的問題就是複用性問題，【程式碼複用性、case複用性(後臺資料)、錄製速度慢】
- 記錄操作資訊：1、根據使用者點選滑動座標，找到相應控制元件（也就是說在你手動點點點的時候，就記錄了）2、記錄所有的request
- 上報給後臺，根據json中的event方法呼叫，測試樁中的提供的服務，同時向mockServer 注入request資訊。將app請求地址指向mockServer，就解決了bug復現的問題。減少溝通(測試，開發都可以用)
測試過程中【人力不足，時間不夠】
- 解決方式：自動化指令碼
- 傳統指令碼：公認缺點【元素變化，編寫效率低，校驗引數有限，執行不靈活】
- 元素變化：當開發改了UI，改了Id。測試人員不知道，執行之後才知道那些錯誤。
- 解決：拉開發程式碼，看git提交記錄，那些新增id，修改了哪些id名稱，一目瞭然。上面那個問題，同時也解決元素定位問題，根據點選地方，直接找到View獲取id，不在需要每一個頁面都要打uiautomatorviewer手動定位。
- 編寫效率低：【獲取元素浪費太多時間，編寫太繁瑣】
- 編寫太繁瑣：例如：A->B->C ，我需要進入C頁面操作斷言，首先A點選進入B在點選進入C，這就多了2行click，如果還有另一條A->B->D，我需要進入D頁面操作斷言，就會將A點選進入B 封裝一下，有沒有想過如果一個很複雜的場景，需要在多個頁面間切換，那就要出現N個click跳轉。但是我實際上case只需要最後一個C或者D頁面操作斷言，之前的都是依賴步驟。就是這些依賴步驟的程式碼量，比實際最後C或者D頁面操作斷言的程式碼還要多的多。
- 解決：請回到最上面看需求圖，可以很明顯的看出來頁面的跳轉關係，實際上就是個json資料，根據json資料遍歷後找到路徑，根據路徑自動跳轉到，需要執行case的頁面。就避免了N個click的情況。每個頁面只用管好自己頁面元素操作即可。。
- 解決：在冒煙測試，就可以記錄使用者操作，開發去改bug期間，將使用者操作，生成程式碼，合併到正式程式碼中去。
- 步驟依賴例子
- 校驗引數有限：其實就uiautomator許可權有限
- 解決：uiautomator + espresso 提供api
- 執行不靈活：測試指令碼就是測試套件，之前平臺就是命令列執行某個指令碼。
- 解決：看需求第二個問題，每個case關聯這一個方法，每個頁面下多個case，隨意呼叫
上線【監控，反應慢】
- 傳統監控：友盟第三方監控crash，bug大部分靠使用者反饋，可能流失使用者，不好復現
- 解決：參考問題1，做線上監控。