從高的角度看自動化測試

前言

高度，這個詞我很早就被提及。

高度不夠，把這個問題/東西拔高一些再看看，應該站在更高的位置看問題...這些是别人對我的評價，是面試過程中被問到的，是别人對我的指導/建議...

有的人會問一個普通打工的需要什麼高度呢？不就是點點點的，不就是寫if-else的...

對問題的思考其實就是優秀和普通的差别吧，尤其是來這裡更為明顯感覺到

我所了解的測試

前幾天，看到蟲師的一篇文章，是關于測試左移和測試右移的。左移就是測試提前介入，右移就是上線的跟進，這些都是接觸過的，

測試并不是點點點，看看有沒有bug，一般測試所在的團隊都叫品質保障or品質管控部門，對整個項目品質的把控，而不是代碼的把控。

因為之前一直在搞接口自動化，對接口自動化的流程有所了解，都是 資料準備--> 請求發起 --> 擷取傳回 --> 進行斷言 --> 發送報告，然後結合jenkins搞下持續內建，結合代碼覆寫率工具搞下覆寫率，

完成整個流程：研發送出代碼 - > 靜态代碼檢測 -->自動化用例執行 --> 結果報告 --> 代碼覆寫率報告

一般自動化就這麼樣子的流程，然而恰恰就是這樣形成了局限性，先說說每點都可以深入做很多東西，那麼應該思考這麼幾個問題：

1. 易用性，是不是扔給其他人寫用例，人家很容易上手；

2. 用例/資料的維護難度，這個是自動化用于項目比較頭痛的問題；

3. 自動化架構是否可優化，支援多線程嗎？ 執行1000條用例花費多少時間；

4. 測試資料如何維護？是建立資料，還是使用固定資料？

然而這裡缺失了最重要的環節，

資料和環境

1. 自動化的環境要和現在的功能測試環境脫離，需要重新搭建一套自動化環境；

2. 測試資料也要跟功能測試環境隔離，互不幹擾，但又需要可以随時同步；

3. 資料是否可清洗，可備份，可復原，可移植；

監控

1. 有沒有合理的監控機制；

2. 更早的發現問題來止損；

3. 現有的架構是否對異常能靈活的降級；

4. 可以從線上資料監控來分析分析業務需求是否達到期望，是否可以促進項目的品質；

是以接口自動化的流程應該變成了：

環境搭建 --> 資料準備/清洗  --> 用例執行 -->  發送報告 -->  線上監控 -->  項目疊代

這樣子就是從高了一層的角度去看品質，這樣形成了閉環

結尾

測試可以從項目品質把控去要求研發做一些事情，如日志列印的規範，線上監控... 

這邊了解到很多團隊是讓研發去寫測試用例，然後測試去review用例，用例執行可能由産品或開發來執行，然後測試有足夠的時間去做工程化的東西，

當有小需求過來，研發自測通過後，但擔心會影響到其他業務，如果測試有足夠好的自動化測試工具提供，這樣就可以解放部分時間；

有重構項目，遷移項目的時候，自動化也可以節省很大部分的時間；

雖千萬人，吾往矣！