軟體測試工程師的崗位職責

之前在我創建的技術交流群裡，我分享過一個話題：如何做一個合格的測試？

昨晚聽同行分享後，我又進行了一次思考總結，軟體測試工程師的崗位職責到底是什麼？

最初，我的想法是執行用例，找缺陷，僅此而已，簡單粗暴。

後來，看了《Google的軟體測試之道》這本書，稍微有點更改，變成了積極主動地發現、暴露缺陷，並團隊合作，解決問題。

去年下半年，公司空降了一位總監，他提出了一個觀點：提高交付質量和交付速率！頓時茅塞頓開，對呀，我們工作的目的不就是提高交付的軟體系統質量，以及提高效率！

昨晚聽同行分享後，思考總結了一下，針對如何提高交付的軟體應用質量和速率這個問題，發現自己還有一些細節的地方沒考慮到，果然還是經驗不足，學習成長的道路，任重而道遠！！！

下面的內容，重新整理了大佬分享的幾個觀點，結合自己的一些想法，算是做一個參考吧。

1、需求評審

為什麼要需求評審？原因有下面幾點：

① 熟悉業務，由產品或者業務講解需求，好做到心中有數，不至於到開發測試階段暴露出由於業務不熟悉導致的問題；

② 多方協定，在正式進入開發階段之前，測試、開發、產品就某些需求的不確定點進行確認，達成一致，避免後續的問題；

③ 評估工作量，實現難度，以及大概的資源投入；

④ 明確開發測試邊界、目標和範圍，做什麼不做什麼；

2、需求文檔

① 儘可能的詳細，需要從需求中提取相應的功能點和測試點；

② 功能點和測試點選取適當的粒度，這樣可以較容易的觀察到測試結果和需求的偏離度；

③ 一般來說，系統越大，業務越複雜，需求的偏離度判定比小系統更容易些；

 

除了需求，了解熟悉整個系統的技術架構，也是必須的一點。比如整個系統的架構組成，各自的特點，採用了什麼通信服務框架，資料庫類型，前後端框架等等，這樣可以更方便定位缺陷，

以及根據系統架構選擇合適的自動化測試框架、性能測試策略等。

特徵：一般來說，系統的穩定性越好，那麼它的可適應性就越差，其帶來的影響是每次架構變更的成本上升以及開發團隊重新建設抑或測試團隊整體方向上的變化。

這幾年開始流行和大規模應用的分布式架構、微服務等，都是從系統的可用性和伸縮擴展性來考慮，以降低各方面的變更帶來的成本。

 

測試過程結果的記錄應該在一定程度上取決於流程的記錄完整程度。

如果涉及到流程更改，也應對不同的觀察對象（測試/開發）所產生的效果和結果進行記錄，以判斷其對質量的影響以及評估標準。

測試流程如下：

① 啟動階段

開發經理在開發計劃中確定測試提交時間，測試主管得到當前最新的相關文檔資料後進行規模預估並成立測試小組，完成《測試計劃》；

② 設計階段

包含測試計劃、測試方案、測試用例等輸出文檔；

在需求分析文檔確立基線以後，測試組需要針對測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標準。在用例的編寫過程中，具體的任務和責任人如下：

③ 實施階段

執行測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計劃工作的基礎之上；

④ 報告階段

在當天（或每個小的階段）的測試完成之後，測試工程師需要總結當天測試的結果，報告測試進度；

⑤ 總結階段

在測試結束之後，測試主管編寫測試報告，對測試進行總結，並且提交，為產品的後續工作提供重要的信息支持；

 

⑥ 驗收階段

在以上工作全部結束後，對測試的過程，結果進行驗收，宣布測試階段性結束；

 

⑦ 歸檔階段

測試歸檔是在測試驗收結束宣布測試有效，結束測試後，對測試過程中涉及到各種標準文檔進行歸檔；

 

 

文檔對工作的幫助，是很有必要的。雖然現在很多企業提倡敏捷，但敏捷並非沒有文檔，而是輕文檔。文檔的重要性有如下幾個方面：

1、對歷史以及當前測試過程中的知識傳遞有很大幫助；

2、可以通過對比歷史和當前文檔的變更，較容易的觀察到整個需求變更過程中測試的質量；

3、涉及到人員變更或者缺陷的爭論時，有更快的知識傳遞速率和參考依據；

 

項目的每個階段都存在風險，常見的缺陷有下面幾點：

1、需求不明確；

2、系統設計或測試設計不完善；

3、不安全規範的代碼編寫方式；

4、測試用例不充足，覆蓋率較低；

5、測試資源不足，回歸工作量預估不當；

7、項目進度安排不妥，其他項目對本項目的影響；

因此，風險管理和防範是必要且重要的一項工作，且測試工程師的職責，不就是提供交付軟體的質量麼！！！

 

有一定測試經驗的工程師基本都經歷過資源投入不足，時間不足的問題，測試時間被壓縮，導致的加班甚至生產事故！因此做好時間管理，就顯得如此重要。

會管理時間的人往往離成功更近一步，如何合理的利用時間解決緊急的項目問題、衝突問題、資源安排問題、優先級、測試用例的執行順序等，做好時間管理是保證質量的因素之一。 

比如涉及到新增需求or需求變更都必須要有相應的文檔（可以為需求說明書或郵件說明）作為測試的依據；

這裡推薦兩本書：《番茄工作法》、《高效能人士的七個習慣》

 

以上的幾部分內容，描述了測試工程師的崗位職責，以及需要注意的幾個部分和一些細節，當然，具體的一些流程管理之類的內容，不同企業有各自的特點，這裡只作為參考。

Has anything you've done made your life better?