2020年軟件測試工程師崗位職責

做軟件測試工程師的人大多數都不是很清楚軟件測試工程師這個崗位到底是做什麼的?其實我的想法是執行用例，找缺陷，僅此而已，簡單粗暴。後來，看了《Google的軟件測試之道》這本書，稍微有點更改，變成了積極主動地發現、暴露缺陷，並團隊合作，解決問題。下面是本站小編給大家帶來的2020年軟件測試工程師崗位職責，希望大家喜歡!

01需求

1、需求評審

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

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

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

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

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

2、需求文檔

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

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

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

02系統架構

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

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

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

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

03流程管理

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

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

測試流程如下：

①啟動階段

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

②設計階段

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

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

③實施階段

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

④報告階段

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

⑤總結階段

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

⑥驗收階段

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

⑦歸檔階段

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

04文檔管理

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

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

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

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

05風險管理

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

1、需求不明確;

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

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

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

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

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

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

06時間管理

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

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

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

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

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