前言

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

我所瞭解的測試

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

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

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

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

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

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

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

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

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


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

資料和環境

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

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

3. 資料是否可清洗,可備份,可回滾,可移植;

 

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

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

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

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

 

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

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

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

 

結尾

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

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