軟件測(cè)試工程師這個(gè)崗位職責(zé)是什么？軟件測(cè)試工程師都需要具體干什么?

做軟件測(cè)試工程師的人大多數(shù)都不是很清楚軟件測(cè)試工程師這個(gè)崗位到底是做什么的？其實(shí)我的想法是執(zhí)行用例，找缺陷，僅此而已，簡(jiǎn)單粗暴。后來(lái)，看了《Google的軟件測(cè)試之道》這本書(shū)，稍微有點(diǎn)更改，變成了積極主動(dòng)地發(fā)現(xiàn)、暴露缺陷，并團(tuán)隊(duì)合作，解決問(wèn)題。下面的內(nèi)容，重新整理了大佬分享的幾個(gè)觀點(diǎn)，結(jié)合自己的一些想法，算是做一個(gè)參考吧。

01 需求

1、需求評(píng)審

為什么要需求評(píng)審？原因有下面幾點(diǎn)：

① 熟悉業(yè)務(wù)，由產(chǎn)品或者業(yè)務(wù)講解需求，好做到心中有數(shù)，不至于到開(kāi)發(fā)測(cè)試階段暴露出由于業(yè)務(wù)不熟悉導(dǎo)致的問(wèn)題；

② 多方協(xié)定，在正式進(jìn)入開(kāi)發(fā)階段之前，測(cè)試、開(kāi)發(fā)、產(chǎn)品就某些需求的不確定點(diǎn)進(jìn)行確認(rèn)，達(dá)成一致，避免后續(xù)的問(wèn)題；

③ 評(píng)估工作量，實(shí)現(xiàn)難度，以及大概的資源投入；

④ 明確開(kāi)發(fā)測(cè)試邊界、目標(biāo)和范圍，做什么不做什么；

2、需求文檔

① 盡可能的詳細(xì)，需要從需求中提取相應(yīng)的功能點(diǎn)和測(cè)試點(diǎn)；

② 功能點(diǎn)和測(cè)試點(diǎn)選取適當(dāng)?shù)牧６?，這樣可以較容易的觀察到測(cè)試結(jié)果和需求的偏離度；

③ 一般來(lái)說(shuō)，系統(tǒng)越大，業(yè)務(wù)越復(fù)雜，需求的偏離度判定比小系統(tǒng)更容易些；

02 系統(tǒng)架構(gòu)

除了需求，了解熟悉整個(gè)系統(tǒng)的技術(shù)架構(gòu)，也是必須的一點(diǎn)。比如整個(gè)系統(tǒng)的架構(gòu)組成，各自的特點(diǎn)，采用了什么通信服務(wù)框架，數(shù)據(jù)庫(kù)類(lèi)型，前后端框架等等，這樣可以更方便定位缺陷，

以及根據(jù)系統(tǒng)架構(gòu)選擇合適的自動(dòng)化測(cè)試框架、性能測(cè)試策略等。

特征：一般來(lái)說(shuō)，系統(tǒng)的穩(wěn)定性越好，那么它的可適應(yīng)性就越差，其帶來(lái)的影響是每次架構(gòu)變更的成本上升以及開(kāi)發(fā)團(tuán)隊(duì)重新建設(shè)抑或測(cè)試團(tuán)隊(duì)整體方向上的變化。

這幾年開(kāi)始流行和大規(guī)模應(yīng)用的分布式架構(gòu)、微服務(wù)等，都是從系統(tǒng)的可用性和伸縮擴(kuò)展性來(lái)考慮，以降低各方面的變更帶來(lái)的成本。

03 流程管理

測(cè)試過(guò)程結(jié)果的記錄應(yīng)該在一定程度上取決于流程的記錄完整程度。

如果涉及到流程更改，也應(yīng)對(duì)不同的觀察對(duì)象（測(cè)試/開(kāi)發(fā)）所產(chǎn)生的效果和結(jié)果進(jìn)行記錄，以判斷其對(duì)質(zhì)量的影響以及評(píng)估標(biāo)準(zhǔn)。

測(cè)試流程如下：

① 啟動(dòng)階段

開(kāi)發(fā)經(jīng)理在開(kāi)發(fā)計(jì)劃中確定測(cè)試提交時(shí)間，測(cè)試主管得到當(dāng)前最新的相關(guān)文檔資料后進(jìn)行規(guī)模預(yù)估并成立測(cè)試小組，完成《測(cè)試計(jì)劃》；

② 設(shè)計(jì)階段

包含測(cè)試計(jì)劃、測(cè)試方案、測(cè)試用例等輸出文檔；

在需求分析文檔確立基線(xiàn)以后，測(cè)試組需要針對(duì)測(cè)試需求編寫(xiě)測(cè)試用例，在實(shí)際的測(cè)試中，測(cè)試用例將是唯一實(shí)施標(biāo)準(zhǔn)。在用例的編寫(xiě)過(guò)程中，具體的任務(wù)和責(zé)任人如下：

③ 實(shí)施階段

執(zhí)行測(cè)試用例將花費(fèi)測(cè)試組絕大部分時(shí)間，這些工作都是建立在前期很多計(jì)劃工作的基礎(chǔ)之上；

④ 報(bào)告階段

在當(dāng)天（或每個(gè)小的階段）的測(cè)試完成之后，測(cè)試工程師需要總結(jié)當(dāng)天測(cè)試的結(jié)果，報(bào)告測(cè)試進(jìn)度；

⑤ 總結(jié)階段

在測(cè)試結(jié)束之后，測(cè)試主管編寫(xiě)測(cè)試報(bào)告，對(duì)測(cè)試進(jìn)行總結(jié)，并且提交，為產(chǎn)品的后續(xù)工作提供重要的信息支持；

⑥ 驗(yàn)收階段

在以上工作全部結(jié)束后，對(duì)測(cè)試的過(guò)程，結(jié)果進(jìn)行驗(yàn)收，宣布測(cè)試階段性結(jié)束；

⑦ 歸檔階段

測(cè)試歸檔是在測(cè)試驗(yàn)收結(jié)束宣布測(cè)試有效，結(jié)束測(cè)試后，對(duì)測(cè)試過(guò)程中涉及到各種標(biāo)準(zhǔn)文檔進(jìn)行歸檔；

04 文檔管理

文檔對(duì)工作的幫助，是很有必要的。雖然現(xiàn)在很多企業(yè)提倡敏捷，但敏捷并非沒(méi)有文檔，而是輕文檔。文檔的重要性有如下幾個(gè)方面：

1、對(duì)歷史以及當(dāng)前測(cè)試過(guò)程中的知識(shí)傳遞有很大幫助；

2、可以通過(guò)對(duì)比歷史和當(dāng)前文檔的變更，較容易的觀察到整個(gè)需求變更過(guò)程中測(cè)試的質(zhì)量；

3、涉及到人員變更或者缺陷的爭(zhēng)論時(shí)，有更快的知識(shí)傳遞速率和參考依據(jù)；

05 風(fēng)險(xiǎn)管理

項(xiàng)目的每個(gè)階段都存在風(fēng)險(xiǎn)，常見(jiàn)的缺陷有下面幾點(diǎn)：

1、需求不明確；

2、系統(tǒng)設(shè)計(jì)或測(cè)試設(shè)計(jì)不完善；

3、不安全規(guī)范的代碼編寫(xiě)方式；

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

5、測(cè)試資源不足，回歸工作量預(yù)估不當(dāng)；

7、項(xiàng)目進(jìn)度安排不妥，其他項(xiàng)目對(duì)本項(xiàng)目的影響；

因此，風(fēng)險(xiǎn)管理和防范是必要且重要的一項(xiàng)工作，且測(cè)試工程師的職責(zé)，不就是提供交付軟件的質(zhì)量么！?。?/span>

06 時(shí)間管理

有一定測(cè)試經(jīng)驗(yàn)的工程師基本都經(jīng)歷過(guò)資源投入不足，時(shí)間不足的問(wèn)題，測(cè)試時(shí)間被壓縮，導(dǎo)致的加班甚至生產(chǎn)事故！因此做好時(shí)間管理，就顯得如此重要。

會(huì)管理時(shí)間的人往往離成功更近一步，如何合理的利用時(shí)間解決緊急的項(xiàng)目問(wèn)題、沖突問(wèn)題、資源安排問(wèn)題、優(yōu)先級(jí)、測(cè)試用例的執(zhí)行順序等，做好時(shí)間管理是保證質(zhì)量的因素之一。 

比如涉及到新增需求or需求變更都必須要有相應(yīng)的文檔（可以為需求說(shuō)明書(shū)或郵件說(shuō)明）作為測(cè)試的依據(jù)；

這里推薦兩本書(shū)：《番茄工作法》、《高效能人士的七個(gè)習(xí)慣》

以上的幾部分內(nèi)容，描述了軟件測(cè)試工程師的崗位職責(zé)，以及需要注意的幾個(gè)部分和一些細(xì)節(jié)，當(dāng)然，具體的一些流程管理之類(lèi)的內(nèi)容，不同企業(yè)有各自的特點(diǎn)，這里只作為參考。

 版權(quán)說(shuō)明：部分內(nèi)容來(lái)源網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系小編做刪除處理！