讓我們從更高的角度看自動化測試

前言

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

我所了解的測試

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

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

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

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

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

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

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

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

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

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

數據和環境

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

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

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

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

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

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

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

因此接口自動化的流程應該變成了：

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

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

結尾

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

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

原文轉自：http://www.cnblogs.com/jwentest/p/8024968.html