測試開(kāi)發(fā)過(guò)程總結

　最近公司的產(chǎn)品一直忙于測試，看著(zhù)每天的Bug不斷的增加和修正，真是痛并快樂(lè )著(zhù)，痛苦是因為Bug不斷的出現，快樂(lè )是看著(zhù)Bug一個(gè)一個(gè)的被消滅，把這些天的測試開(kāi)發(fā)過(guò)程總結一下。

1、測試要盡早

　　公司的產(chǎn)品已經(jīng)修訂一段時(shí)間了，但是由于任務(wù)繁忙和人手不足，因此測試一直拖后，因此當進(jìn)行集中測試的時(shí)候Bug集中爆發(fā)，因此感覺(jué)更加的繁忙，另外由于很多功能和修訂，都已經(jīng)修改了很長(cháng)的時(shí)間，因此程序員再次進(jìn)入修改的時(shí)候，往往需要重新分析和理解，造成Bug的修復周期延長(cháng)了很多。

　　建議當完成功能修訂后，要盡快進(jìn)入測試狀態(tài)，以縮短Bug的存在時(shí)間，降低程序員修訂成本。

2、使用好的缺陷管理工具

　　之前公司只是使用一個(gè)BBS作為缺陷的跟蹤和管理工具，但是，效果很不理想，雖然缺陷管理的工具很多，但是都有自己的長(cháng)處和短處，后來(lái)使用了TD，效果的確好的多。

3、缺陷描述要準確

　　很多測試人員反饋的缺陷，程序員讀起來(lái)十分的費勁，甚至比理解缺陷本身還要難懂，因此，如果缺陷后，在登記的時(shí)候，一定要盡量描述準確和清晰，以免造成錯誤的理解，反而更加干擾缺陷的修訂。如果缺陷的確很難描述，可以將缺陷的發(fā)生過(guò)程錄制下來(lái)，或者干脆手工給程序員演示一遍，效果就更好了。

4、缺陷描述不完整

　　很多缺陷都是有前世和今生的，因此把缺陷產(chǎn)生的出發(fā)條件描述的完整，對解決缺陷起著(zhù)很重要的作用。

5、缺陷要分等級

　　缺陷都是要優(yōu)先級別的，嚴重的當然要盡快解決，低級別的放一放。

6、開(kāi)發(fā)和測試最好不同步

　　公司是早上8：30上班，一般是9：00左右才能給測試部一個(gè)新的測試版本，而如果Build出現意外，則新的版本發(fā)布就會(huì )推遲，因此開(kāi)發(fā)和測試一定要有個(gè)時(shí)間差，開(kāi)發(fā)部最好在早上第1時(shí)間給測試部一個(gè)最新的測試版本。一種是開(kāi)發(fā)部早點(diǎn)來(lái)，一種是晚點(diǎn)走，最后我們的約定是下午4:30分開(kāi)發(fā)部Build版本給測試部明天使用。

7、優(yōu)先驗證Fixed狀態(tài)的缺陷

　　測試部每天最優(yōu)先的任務(wù)就是驗證新版本中Fixed狀態(tài)的缺陷是否正確，這個(gè)很主要，因為開(kāi)發(fā)部剛剛修正，如果沒(méi)有驗證通過(guò)，程序員可以立刻進(jìn)行修訂，如果過(guò)了很長(cháng)時(shí)間才通知沒(méi)有通過(guò)，那么可能程序員還得重新理解和分析代碼。

8、一個(gè)缺陷報告包含多個(gè)缺陷

　　有些時(shí)候測試人員在一個(gè)測試報告中，包含N（N>=1）個(gè)缺陷，結果程序員修訂了其中一個(gè)，另一個(gè)需要拒絕掉，結果缺陷的狀態(tài)就失去效果了，因此一個(gè)缺陷記錄只能包含一個(gè)缺陷，如果存在多個(gè)就是測試人員的責任了。

9、交叉測試的重要性

　　我們最初安排測試的時(shí)候，是某個(gè)測試人員只測試其中一部分，另外的測試人員測試另外一部分，過(guò)了幾天后發(fā)現，每個(gè)測試人員的Bug檢測數量都下降了，原來(lái)，測試人員對自己部分已經(jīng)發(fā)現不出來(lái)缺陷了，后來(lái)采用了交叉測試的方式，就是測試人員交換測試工作，結果不同的人從不同的角度進(jìn)行測試，結果一些缺陷又發(fā)現了，因此交叉測試很重要。

10、測試經(jīng)驗的總結

　　測試的過(guò)程很枯燥，而測試過(guò)程中發(fā)現的測試經(jīng)驗是十分重要的，不斷的調整測試的策略、流程，多總結和借鑒別人的測試經(jīng)驗，會(huì )更好的提高測試質(zhì)量。

原文轉自：http://kjueaiud.com