前言

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

我所瞭解的測試

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

測試並不是點點點，看看有沒有bug，一般測試所在的團隊都叫質量保障or質量管控部門，對整個專案質量的把控，而不是程式碼的把控。

因為之前一直在搞介面自動化，對介面自動化的流程有所瞭解，都是 資料準備--> 請求發起 --> 獲取返回 --> 進行斷言 --> 傳送報告，然後結合jenkins搞下持續整合，結合程式碼覆蓋率工具搞下覆蓋率，

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

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

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

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

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

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

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

資料和環境

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

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

3. 資料是否可清洗，可備份，可回滾，可移植；

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

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

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

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

因此介面自動化的流程應該變成了：

環境搭建 --> 資料準備/清洗  --> 用例執行 -->  傳送報告 -->  線上監控 -->  專案迭代

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

結尾

測試可以從專案質量把控去要求研發做一些事情，如日誌列印的規範，線上監控... 

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