關(guān)于項(xiàng)目測(cè)試平緩期低效率的看法
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2010/12/27 10:23:51 ] 推薦標(biāo)簽:
個(gè)人認(rèn)為項(xiàng)目測(cè)試過程中的測(cè)試效率總體趨勢(shì)是隨著項(xiàng)目進(jìn)度的深入呈現(xiàn)先上升到達(dá)頂點(diǎn),然后遞減,再項(xiàng)目發(fā)布前達(dá)到低點(diǎn)的規(guī)律。這個(gè)規(guī)律反映在活躍bug趨勢(shì)圖上尤其明顯。測(cè)試過程進(jìn)入穩(wěn)定期后效率會(huì)非常低。主要表現(xiàn)為:
1、每天進(jìn)行幾遍幾十遍主流程甚至核心流程的回歸。
2、測(cè)試執(zhí)行的用例數(shù)非常多,發(fā)現(xiàn)bug數(shù)非常少。
3、bug隱藏較深發(fā)現(xiàn)bug難度大。
4、bug的溝通交流的成本大。
5、開發(fā)修復(fù)bug進(jìn)入遲滯期,每個(gè)人修復(fù)不了幾個(gè)bug。
一般bug開閉數(shù)曲線呈現(xiàn)平緩期開始進(jìn)入效率低潮期。那么在這個(gè)階段我們?cè)撟瞿男┐胧┨岣呶覀兊臏y(cè)試效率呢?我覺得可以從宏觀和微觀兩個(gè)方面著手處理:
宏觀上:
1、多交叉測(cè)試:在執(zhí)行完所有用例的前提下,我們測(cè)試同學(xué)可以頻繁的進(jìn)行交叉測(cè)試,盡可能的掃描到未涉及到的死角。
2、測(cè)試手段的多樣性:在平緩期采取探索性、隨機(jī)測(cè)試等方法,甚至可以邀請(qǐng)部分同學(xué)來體驗(yàn),當(dāng)小白鼠,這個(gè)時(shí)期我們可以多重視用戶體驗(yàn)性問題。
3、風(fēng)險(xiǎn)檢測(cè):進(jìn)入平緩期后再次檢視下目前尚未關(guān)閉的風(fēng)險(xiǎn)問題,在功能穩(wěn)定的同時(shí)及早的采取措施關(guān)閉風(fēng)險(xiǎn),深度挖掘尚未發(fā)現(xiàn)的風(fēng)險(xiǎn)問題,防止風(fēng)險(xiǎn)觸發(fā)引起的測(cè)試反復(fù)。
4、測(cè)試計(jì)劃實(shí)時(shí)性有效性:檢查我們的測(cè)試計(jì)劃是否已經(jīng)匹配當(dāng)前的測(cè)試過程,及時(shí)做出調(diào)整。
微觀上:
1、減少回歸核心流程的次數(shù),每天回歸一遍基本夠了。
2、深挖用例與功能,盡可能早的發(fā)現(xiàn)隱藏的功能,和未測(cè)試到的功能點(diǎn)。
3、敦促開發(fā)調(diào)整修復(fù)bug策略優(yōu)先修復(fù)教容易修復(fù)的bug。
4、bug描述到位,做到每個(gè)bug均可重現(xiàn)。
5、提醒開發(fā)自測(cè):
1)這個(gè)階段開發(fā)可能會(huì)發(fā)現(xiàn)很多我們發(fā)現(xiàn)不到的bug。
2)開發(fā)修復(fù)bug完整性與正確性,防止?fàn)窟B功能bug數(shù)反彈。
在項(xiàng)目測(cè)試過程中我們應(yīng)該隨時(shí)關(guān)注我們的測(cè)試效率,多快好省的完成測(cè)試工作。
注:我個(gè)人覺得測(cè)試執(zhí)行過程中效率可以這樣俠義量化定義:當(dāng)天開閉bug數(shù)之和/當(dāng)天執(zhí)行的測(cè)試用例數(shù)。
相關(guān)推薦

最新發(fā)布
性能測(cè)試之測(cè)試環(huán)境搭建的方法
2020/7/21 15:39:32軟件測(cè)試是從什么時(shí)候開始被企業(yè)所重視的呢?
2020/7/17 9:09:11Android自動(dòng)化測(cè)試框架有哪些?有什么用途?
2020/7/17 9:03:50什么樣的項(xiàng)目適合做自動(dòng)化?自動(dòng)化測(cè)試人員應(yīng)具備怎樣的能力?
2020/7/17 8:57:06幾大市面主流性能測(cè)試工具測(cè)評(píng)
2020/7/17 8:52:11RPA機(jī)器人能夠快速響應(yīng)企業(yè)需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消滅嗎?為什么?
2020/7/17 8:43:03軟件測(cè)試基本概念是怎么來的?軟件測(cè)試生命周期的形成歷經(jīng)了什么?
2020/7/16 9:11:10