去年底做了一個Android應(yīng)用的項目，代碼總計2萬多行，測試周期4個月，項目雖小，但涉及到手機終端適配、網(wǎng)絡(luò)環(huán)境兼容等多個方面。項目階段一結(jié)束后，我們簡單總結(jié)了一下測試方法有效性的問題。發(fā)出來與大家共享。
這個Android應(yīng)用的主要功能很簡單，附加功能較多，基本都屬于錦上添花類。測試的實際情況如下：
1、資源投入：持續(xù)時長4個月，人力6人+，測試機型30款+
2、測試執(zhí)行：23輪功能測試，7輪系統(tǒng)測試，8輪健全測試，3輪機型兼容測試，3輪性能測試，1輪MTBF測試，1輪PD/UI驗證測試。
但是這其中有很多不足之處，較明顯的如下：
1、前期功能測試和健全測試一天一輪，頻度太快且測試費時，效果不好。
2、初期的測試用例設(shè)計全面，但未精確定義編寫粒度，描述過程過細，后期因需求變更導(dǎo)致維護成本較高。
3、因項目流程和過程控制影響，無法明確劃分測試階段，且初期沒有找到最佳敏捷測試方法，測試流程冗余僵化，導(dǎo)致大量重復(fù)性的工作，靈活性偏低。
在測試進程中我們已發(fā)現(xiàn)測試策略的問題，并及時調(diào)整，在階段二開始使用新策略——使用兩階段測試模型：
1、階段一<自由測試>：按照探索性測試（Exploratory Testing）模式，布置有針對性有重點的自由測試，以“把軟件使用壞掉”為目的，盡可能多發(fā)現(xiàn)bug。
2、階段二<覆蓋測試>：執(zhí)行各項測試用例，以“全面測試”為目的
具體的時間安排如下：
1、先期產(chǎn)品開發(fā)階段，即Alpha release之前，做功能測試、健全測試、缺陷驗證+自由測試。
2、項目中期，Alpha ~ Beta之間，執(zhí)行全面的系統(tǒng)測試、兼容性測試、性能測試，并開展自動化腳本開發(fā)、環(huán)境搭建等工作。
3、Beta release之后，在產(chǎn)品發(fā)布前的2~3周，就開始確定穩(wěn)定版本Release Candidate，在此版本基礎(chǔ)上做最后一輪全面測試、重點子模塊的健全測試、缺陷主導(dǎo)的ET等，完成最終報告并交由項目組領(lǐng)導(dǎo)、QA審核發(fā)布。
本次測試有效性總結(jié)我們引入了兩個質(zhì)量來衡量：軟件質(zhì)量指標和測試過程質(zhì)量指標。
軟件質(zhì)量指標包括：
（一）需求功能點覆蓋率：
計算測試用例總數(shù)之和除以與之一一對應(yīng)的功能點數(shù)之和，主要查看是否有功能點遺漏測試的情況。用例覆蓋需求矩陣，一個需求對應(yīng)多個功能點。
需求覆蓋率=∑測試用例數(shù)（個）/∑功能點（個）=1055/147=7.18
（二）用例執(zhí)行覆蓋率：
計算測試用例執(zhí)行總數(shù)除以與之一一對應(yīng)的測試數(shù)之和，主要查看是否有測試用例執(zhí)行遺漏或有效的情況。
用例執(zhí)行覆蓋率=∑執(zhí)行的測試用例個數(shù)（個）/∑測試用例個數(shù)（個）*100%
功能測試276條，系統(tǒng)測試779條，用例執(zhí)行覆蓋率達到99%。
測試過程質(zhì)量指標包括：
（一）缺陷探測率：
計算內(nèi)部發(fā)現(xiàn)的缺陷數(shù)除以內(nèi)部發(fā)現(xiàn)的缺陷數(shù)與用戶發(fā)現(xiàn)的缺陷數(shù)之和，主要查看內(nèi)部發(fā)現(xiàn)缺陷的能力。說明：缺陷探測率越高，即內(nèi)部發(fā)現(xiàn)的bug數(shù)越多，發(fā)布后客戶發(fā)現(xiàn)的bug數(shù)就越少，質(zhì)量成本就越低。
缺陷探測率=內(nèi)部發(fā)現(xiàn)的缺陷數(shù)（個）/（內(nèi)部發(fā)現(xiàn)的缺陷數(shù)（個）+用戶發(fā)現(xiàn)的缺陷數(shù)（個））*100%
缺陷數(shù)=636（有效），用戶發(fā)現(xiàn)缺陷數(shù)=1（當前）
缺陷探測率=636/637=99.84%
（二）有效缺陷率：
計算被開發(fā)人員確認的BUG數(shù)總和除于本人上報BUG的總和，可用于查看測試人員的個人測試質(zhì)量，也可用于查看整個測試組的測試質(zhì)量。
無效BUG狀態(tài)包括：問題重復(fù)、不是問題、不可復(fù)現(xiàn)狀態(tài)。這項指標用于考察測試人員發(fā)現(xiàn)的、被確認為缺陷的缺陷數(shù)高低或者百分比，數(shù)和比率越高測試質(zhì)量越高。
注意：由于系統(tǒng)框架根本性的、初始化參數(shù)設(shè)置錯誤引發(fā)的、錯誤數(shù)據(jù)、錯誤環(huán)境等而開發(fā)人員因無法修正、可以通過改變環(huán)境而無需修改程序、重新導(dǎo)入數(shù)據(jù)、再次發(fā)布而解決的BUG為有效BUG
有效缺陷率=測試人員發(fā)現(xiàn)的有效缺陷數(shù)（個）/測試人員發(fā)現(xiàn)的總?cè)毕輸?shù)（個）*100%=636/689=92.31%
（三）用例執(zhí)行效率：
計算測試人員執(zhí)行的用例數(shù)除以執(zhí)行測試的時間，主要查看測試人員執(zhí)行測試的效率
說明：此指標的統(tǒng)計需要有一定的前提條件：用例的執(zhí)行步驟相對來說分布較均勻，執(zhí)行時間在一個較長的時間段內(nèi)
用例執(zhí)行效率=∑測試人員執(zhí)行的用例數(shù)（個）/∑執(zhí)行用例的時間（小時）
（四）缺陷發(fā)現(xiàn)率：
計算測試人員各自發(fā)現(xiàn)的缺陷數(shù)總和除于各自所花費的測試時間總和。
缺陷發(fā)現(xiàn)率=∑提交缺陷數(shù)（個）/∑執(zhí)行測試的有效時間（小時）
以第18輪功能測試為例：
用例執(zhí)行效率=10.17
缺陷發(fā)現(xiàn)率=36.67%
（五）缺陷覆蓋率：
計算缺陷與測試用例的比率，用來衡量測試用例覆蓋缺陷的能力。
缺陷覆蓋率=∑缺陷個數(shù)/∑測試用例條數(shù)
版權(quán)聲明：本文出自 cmriqa 的51Testing軟件測試博客：http://www.51testing.com/?489136
原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。