測試開(kāi)發(fā)過(guò)程經(jīng)驗總結 軟件測試
做這個(gè)工作也有一段時(shí)間，總結幾點(diǎn)經(jīng)驗，大家分享一下：
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)十分的費勁，甚至比理解缺陷本身還要難懂，因此，如果發(fā)現缺陷后，在登記的時(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ì)量。
以上是個(gè)人意見(jiàn)，供大家分享
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
