從高的角度看自動化測試

前言

高度，這個詞我很早就被說起。
高度不夠，把這個問題/東西拔高一些再看看，應該站在更高的位置看問題...這些是別人對個人評價，是面試過程當中被問到的，是別人對個人指導/建議...
有的人會問一個普通打工的須要什麼高度呢？不就是點點點的，不就是寫if-else的...
對問題的思考其實就是優秀和普通的差異吧，尤爲是來這裏更爲明顯感受到

我所瞭解的測試

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

測試並非點點點，看看有沒有bug，通常測試所在的團隊都叫質量保障or質量管控部門，對整個項目質量的把控，而不是代碼的把控。

由於以前一直在搞接口自動化，對接口自動化的流程有所瞭解，都是 數據準備--> 請求發起 --> 獲取返回 --> 進行斷言 --> 發送報告，而後結合jenkins搞下持續集成，結合代碼覆蓋率工具搞下覆蓋率，

完成整個流程：研發提交代碼 - > 靜態代碼檢測 -->自動化用例執行 --> 結果報告 --> 代碼覆蓋率報告

通常自動化就這麼樣子的流程，然而偏偏就是這樣造成了侷限性，先說說每點均可以深刻作不少東西，那麼應該思考這麼幾個問題：

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

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

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

4. 測試數據如何維護？是新建數據，仍是使用固定數據？

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

數據和環境

1. 自動化的環境要和如今的功能測試環境脫離，須要從新搭建一套自動化環境；

2. 測試數據也要跟功能測試環境隔離，互不干擾，但又須要能夠隨時同步；

3. 數據是否可清洗，可備份，可回滾，可移植；

 

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

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

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

4. 能夠從線上數據監控來分析分析業務需求是否達到指望，是否能夠促進項目的質量；

 

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

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

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

 

結尾

測試能夠從項目質量把控去要求研發作一些事情，如日誌打印的規範，線上監控... 

這邊瞭解到不少團隊是讓研發去寫測試用例，而後測試去review用例，用例執行可能由產品或開發來執行，而後測試有足夠的時間去作工程化的東西，

當有小需求過來，研發自測經過後，但擔憂會影響到其餘業務，若是測試有足夠好的自動化測試工具提供，這樣就能夠解放部分時間；

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