首次作為項目負(fù)責(zé)人總結(jié)
JT項目總結(jié)
一、概述
二、測試計劃
1、測試計劃的安排是基于整個項目的進(jìn)度,雖然當(dāng)時有大線表,但是開發(fā)基本上都沒有按照或者接近時間點(diǎn)完成,導(dǎo)致測試工作無法提前安排,出現(xiàn)了要么沒事做,要么加班通宵的情況。
2、當(dāng)有測試任務(wù)的時候,沒有正確估算出測試時間,或者急于出結(jié)果,導(dǎo)致測試不詳細(xì)、不全面,連續(xù)通宵的加班和提測時無止境的等待,人員情緒低落,不能提交高質(zhì)量的測試版本。
3、測試前期有相關(guān)文檔,后期由于時間問題,沒有充分了解需求,對于提測的功能也是在摸索中測試,不能準(zhǔn)備充分測試。
4、當(dāng)測試人員較多的時候,測試任務(wù)的分配不是很清楚,出現(xiàn)了“三不管”地方。
三、測試執(zhí)行及進(jìn)度
1、前期寫好的測試用例沒有高效的執(zhí)行,前期的測試準(zhǔn)備不能指導(dǎo)后期的測試。原因很多,包括需求的變動等。
2、需求的變動,使得測試出現(xiàn)無效工作,之前已經(jīng)花費(fèi)時間做過了,后期由于需求變動,又要重新測試。
3、在測試執(zhí)行過程中,人員之間缺乏溝通,測試的結(jié)果或者測試方向錯誤。
四、測試質(zhì)量
1、測試功能全面性:在測試過程中,發(fā)現(xiàn)測試會出現(xiàn)漏測的現(xiàn)象。由于前期的測試計劃工作沒有做好,比如沒有測試用例,沒有進(jìn)行測試需求的挖掘,在模塊提測后進(jìn)行隨機(jī)的測試,沒有條理,容易導(dǎo)致漏測的現(xiàn)象。
2、測試深度:在測試過程中,只關(guān)注前臺界面顯示或者功能實(shí)現(xiàn)是遠(yuǎn)遠(yuǎn)不夠的,很多隱藏的bug都是通過數(shù)據(jù)庫體現(xiàn)出來的。比如數(shù)據(jù)庫的主鍵設(shè)置不合理,或者是數(shù)據(jù)庫信息不全面,那么在前臺顯示的信息也是不全面的,特別是商品詳情頁的相關(guān)測試。
3、測試廣度:測試的時候容易只關(guān)注自己模塊的東西,不能把整個流程都串聯(lián)起來,如果是對整個流程的測試,也會發(fā)現(xiàn)不少問題。
五、測試規(guī)劃
目前在后期的項目中會規(guī)范項目流程,測試作為項目整體中很重要的一部分,也要規(guī)范測試流程。
1、文檔完整。
在現(xiàn)有需求文檔和開發(fā)設(shè)計文檔的情況下,編寫測試用例并評審。測試用例作為測試執(zhí)行的指導(dǎo),是很有必要的,可以幫助測試人員更好更深入的理解需求及我們程序到底是要做什么,而不是在開發(fā)提交測試后測試人員邊測邊摸索。
2、測試執(zhí)行及進(jìn)度。
1)在執(zhí)行測試的過程中,必須按照測試用例執(zhí)行,在保證測試用例100%執(zhí)行的情況下,可以自由測試。執(zhí)行測試用例是保證測試質(zhì)量的有效方法之一,所以必須保證用例的100%執(zhí)行。在測試過程中,不管bug大小及優(yōu)先級,只要是發(fā)現(xiàn)的bug,全部提交到bugfree中,開發(fā)可以根據(jù)優(yōu)先級和嚴(yán)重程度來修改bug,而不是說測試的時候只提嚴(yán)重bug。
2)測試的過程中,測試人員之間要及時溝通,避免出現(xiàn)無人測試的地方。每個測試人員都要非常清楚的知道所有的流程,有助于測試過程理解及加強(qiáng)測試廣度及深度。
3)在測試過程中,必須對數(shù)據(jù)表和和數(shù)據(jù)流轉(zhuǎn)很清楚。數(shù)據(jù)的交互,一定要及時關(guān)注數(shù)據(jù)表,保證自己當(dāng)前測試的模塊數(shù)據(jù)存儲都是正確的,關(guān)注與其他模塊交互的數(shù)據(jù)字段或數(shù)據(jù)表,保證和其他模塊的數(shù)據(jù)交互也是絕對ok的。
4)根據(jù)線表來計劃測試時間,保證測試有充分的時間來執(zhí)行用例和自由測試。
5)執(zhí)行測試的過程中,及時提交bug到bugfree上,既然有bugfree就要執(zhí)行。任何以文檔記錄的bug在最后是非常難統(tǒng)計的,作為以后的參考或者是項目bug統(tǒng)計,所有的bug都必須直接提交在bugfree上。開發(fā)人員已更改狀態(tài)的bug,在修改bug的版本上測試要及時驗(yàn)證。
6)對于與開發(fā)有爭議的bug,有些要確認(rèn)需求是否是這樣,保證提交的bug是有效的。對于開發(fā)不改的情況,可以舉例示范,拿出相關(guān)文檔來說服。如若還是有爭議,那么可以找需求或者項目負(fù)責(zé)人來商定是否需要修改。對于某些問題的修改,可能會考慮到修改效率和成本,只要能達(dá)成一致即可。盡可能確保在發(fā)布版本前,所有的bug都被關(guān)注到并且處理。
3、非功能測試及建議。
除了功能測試外,還應(yīng)該要關(guān)注web測試的其他方面,比如性能測試,數(shù)據(jù)庫測試,安全測試等。鑒于目前大家掌握的技能有別,可以抽出時間分享自己掌握的測試技能,共同提高和進(jìn)步,提升整個團(tuán)隊的素質(zhì)。
PS:首次作為項目負(fù)責(zé)人難免會有很多失誤,在以后的項目過程中一定會更加努力,避免再犯類似的錯誤,正確把好質(zhì)量關(guān)。
posted on 2014-02-11 10:28 順其自然EVO 閱讀(335) 評論(0) 編輯 收藏 所屬分類: 測試學(xué)習(xí)專欄