軟件測試工程師的職責(zé)是什么

第第頁軟件測試工程師的職責(zé)是什么？軟件測試工程師的職責(zé)是什么？

發(fā)表于：2023-03-04來源：豆瓣：@行知-追尋技術(shù)之美點(diǎn)擊數(shù)：標(biāo)簽：軟件測試

軟件測試工程師的職責(zé)是什么？在阿里也差不多待了一個多月，接觸的項(xiàng)目也很具有代表性，簡單描敘一下場景吧。需求方是我們的運(yùn)營同學(xué)，該項(xiàng)目涉及到有ETL部分和UED部分，前期，我沒有進(jìn)入到該項(xiàng)目組，詳細(xì)設(shè)計階段缺少我們測試人員，導(dǎo)致當(dāng)進(jìn)行項(xiàng)目之后，發(fā)現(xiàn)項(xiàng)目文檔寫

在阿里也差不多待了一個多月，接觸的項(xiàng)目也很具有代表性，簡單描敘一下場景吧。（需求）方是我們的運(yùn)營同學(xué)，該項(xiàng)目涉及到有ETL部分和UED部分，前期，我沒有進(jìn)入到該項(xiàng)目組，詳細(xì)設(shè)計階段缺少我們（測試）人員，導(dǎo)致當(dāng)進(jìn)行項(xiàng)目之后，發(fā)現(xiàn)項(xiàng)目文檔寫得不具備可（測試）性。后期，文檔修改完成之后，測試階段碰到的最多的就是變化，（需求）在變，設(shè)計也在變，（測試人員）拖在后面，壓力很大的!

場景，大致就是這樣子的。具體的問題細(xì)節(jié)，應(yīng)該是很有代表性的。

1.進(jìn)入項(xiàng)目比較晚，導(dǎo)致的問題就是詳細(xì)設(shè)計文檔，沒有測試人員參與，當(dāng)測試人員進(jìn)入之后，發(fā)現(xiàn)根據(jù)文檔，測試人員無法進(jìn)行測試分析，編寫測試案例的工作。而此時（開發(fā)）人員已經(jīng)（開發(fā)）了一定的時間，所以，這個時候，開發(fā)人員配合修改文檔的工作不是很積極。當(dāng)直接和開發(fā)人員討論，會看到每個開發(fā)人員并不清楚其他人的工作，也就是說開發(fā)人員也都沒法完全理解詳細(xì)設(shè)計文檔。他們的工作模式可能是邊coding邊重新設(shè)計。這個是很可怕的事情。

如果這種事情發(fā)生了，怎么辦?一個好的測試人員，需要在整個項(xiàng)目流程中，引導(dǎo)開發(fā)，PM，去遵守一定的流程，好的流程可以事半功倍的。當(dāng)我碰到這個情況后，我是按下面的步驟進(jìn)行:

第一步，與開發(fā)，PM溝通，花一個下午的時候，把詳細(xì)設(shè)計文檔中的問題指出來，并給出一個期望的（模板）。

第二步，制定測試計劃，期間規(guī)定詳細(xì)設(shè)計文檔交付的時間，（單元測試）交付的時間，測試案例評審的時間，測試腳本和測試執(zhí)行的時間。這個測試計劃也需要和DEV，PM達(dá)成共識。

第三步，為開發(fā)人員引進(jìn)一個合適的單元測試框架，給出單元測試的案例標(biāo)準(zhǔn)。

第四步，在流程的每個關(guān)鍵點(diǎn)進(jìn)行把控開發(fā)的活動，不能只制定流程，而不去關(guān)心流程在運(yùn)轉(zhuǎn)的狀況。

2.需求變更太多.雖然說，標(biāo)準(zhǔn)的流程已經(jīng)制定了，但是由于之前沒有一個好的設(shè)計，后面需求的實(shí)現(xiàn)出入也會比較大。一般情況下，開發(fā)，測試，PM溝通之后，設(shè)計還是會修改的。那么，這個時候的測試人員一定得搞清楚，變更所帶來的影響，以及測試會增加的工作量。

比如說：在項(xiàng)目測試的最后階段，發(fā)現(xiàn)一個（缺陷），但是開發(fā)人員的修改方案卻是推翻之前的一個模塊設(shè)計(該模塊的測試已經(jīng)結(jié)束)，也就說該模塊的代碼需要重構(gòu)。在進(jìn)行多次討論之后，開發(fā)人員還是需要對這部分進(jìn)行變更(雖然我是反對在項(xiàng)目發(fā)布前做這么大的改動)。這種情況下，我能做的事情主要就集中在下面幾個方面:

1.分析,這些改變會影響到那些模塊，及時發(fā)出郵件通知影響涉及到的人員。

2.同開發(fā)人員講清楚，單元測試一定要更新，并保證通過。

3.即使更新測試腳本和測試數(shù)據(jù)，進(jìn)行（回歸）測試。

4.對之前所以的測試模塊進(jìn)行一次測試執(zhí)行。

自己也不知道要說明什么，只是感慨一下進(jìn)入阿里之后的一個項(xiàng)目經(jīng)歷，和之