qileilove

          blog已經(jīng)轉移至github,大家請訪問 http://qaseven.github.io/

          從一個真實項目入手分析測試有效性

            去年底做了一個Android應用的項目,代碼總計2萬多行,測試周期4個月,項目雖小,但涉及到手機終端適配、網(wǎng)絡環(huán)境兼容等多個方面。項目階段一結束后,我們簡單總結了一下測試方法有效性的問題。發(fā)出來與大家共享。

            這個Android應用的主要功能很簡單,附加功能較多,基本都屬于錦上添花類。測試的實際情況如下:

            1、資源投入:持續(xù)時長4個月,人力6人+,測試機型30款+

            2、測試執(zhí)行:23輪功能測試,7輪系統(tǒng)測試,8輪健全測試,3輪機型兼容測試,3輪性能測試,1輪MTBF測試,1輪PD/UI驗證測試。

            但是這其中有很多不足之處,較明顯的如下:

            1、前期功能測試和健全測試一天一輪,頻度太快且測試費時,效果不好。

            2、初期的測試用例設計全面,但未精確定義編寫粒度,描述過程過細,后期因需求變更導致維護成本較高。

            3、因項目流程和過程控制影響,無法明確劃分測試階段,且初期沒有找到最佳敏捷測試方法,測試流程冗余僵化,導致大量重復性的工作,靈活性偏低。

            在測試進程中我們已發(fā)現(xiàn)測試策略的問題,并及時調整,在階段二開始使用新策略——使用兩階段測試模型:

            1、階段一<自由測試>:按照探索性測試(Exploratory Testing)模式,布置有針對性有重點的自由測試,以“把軟件使用壞掉”為目的,盡可能多發(fā)現(xiàn)bug。

            2、階段二<覆蓋測試>:執(zhí)行各項測試用例,以“全面測試”為目的

            具體的時間安排如下:

            1、先期產品開發(fā)階段,即Alpha release之前,做功能測試、健全測試、缺陷驗證+自由測試。

            2、項目中期,Alpha ~ Beta之間,執(zhí)行全面的系統(tǒng)測試、兼容性測試、性能測試,并開展自動化腳本開發(fā)、環(huán)境搭建等工作。

            3、Beta release之后,在產品發(fā)布前的2~3周,就開始確定穩(wěn)定版本Release Candidate,在此版本基礎上做最后一輪全面測試、重點子模塊的健全測試、缺陷主導的ET等,完成最終報告并交由項目組領導、QA審核發(fā)布。

            本次測試有效性總結我們引入了兩個質量來衡量:軟件質量指標和測試過程質量指標。

            軟件質量指標包括:

            (一)需求功能點覆蓋率:

            計算測試用例總數(shù)之和除以與之一一對應的功能點數(shù)之和,主要查看是否有功能點遺漏測試的情況。用例覆蓋需求矩陣,一個需求對應多個功能點。

            需求覆蓋率=∑測試用例數(shù)(個)/∑功能點(個)=1055/147=7.18

           

            (二)用例執(zhí)行覆蓋率:

            計算測試用例執(zhí)行總數(shù)除以與之一一對應的測試數(shù)之和,主要查看是否有測試用例執(zhí)行遺漏或有效的情況。

            用例執(zhí)行覆蓋率=∑執(zhí)行的測試用例個數(shù)(個)/∑測試用例個數(shù)(個)*100%

            功能測試276條,系統(tǒng)測試779條,用例執(zhí)行覆蓋率達到99%。


            測試過程質量指標包括:

            (一)缺陷探測率:

            計算內部發(fā)現(xiàn)的缺陷數(shù)除以內部發(fā)現(xiàn)的缺陷數(shù)與用戶發(fā)現(xiàn)的缺陷數(shù)之和,主要查看內部發(fā)現(xiàn)缺陷的能力。說明:缺陷探測率越高,即內部發(fā)現(xiàn)的bug數(shù)越多,發(fā)布后客戶發(fā)現(xiàn)的bug數(shù)就越少,質量成本就越低。

            缺陷探測率=內部發(fā)現(xiàn)的缺陷數(shù)(個)/(內部發(fā)現(xiàn)的缺陷數(shù)(個)+用戶發(fā)現(xiàn)的缺陷數(shù)(個))*100%

            缺陷數(shù)=636(有效),用戶發(fā)現(xiàn)缺陷數(shù)=1(當前)

            缺陷探測率=636/637=99.84%

            (二)有效缺陷率:

            計算被開發(fā)人員確認的BUG數(shù)總和除于本人上報BUG的總和,可用于查看測試人員的個人測試質量,也可用于查看整個測試組的測試質量。

            無效BUG狀態(tài)包括:問題重復、不是問題、不可復現(xiàn)狀態(tài)。這項指標用于考察測試人員發(fā)現(xiàn)的、被確認為缺陷的缺陷數(shù)高低或者百分比,數(shù)和比率越高測試質量越高。

            注意:由于系統(tǒng)框架根本性的、初始化參數(shù)設置錯誤引發(fā)的、錯誤數(shù)據(jù)、錯誤環(huán)境等而開發(fā)人員因無法修正、可以通過改變環(huán)境而無需修改程序、重新導入數(shù)據(jù)、再次發(fā)布而解決的BUG為有效BUG

            有效缺陷率=測試人員發(fā)現(xiàn)的有效缺陷數(shù)(個)/測試人員發(fā)現(xiàn)的總缺陷數(shù)(個)*100%=636/689=92.31%

            (三)用例執(zhí)行效率:

            計算測試人員執(zhí)行的用例數(shù)除以執(zhí)行測試的時間,主要查看測試人員執(zhí)行測試的效率

            說明:此指標的統(tǒng)計需要有一定的前提條件:用例的執(zhí)行步驟相對來說分布較均勻,執(zhí)行時間在一個較長的時間段內

            用例執(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ù)

           

          版權聲明:本文出自 cmriqa 的51Testing軟件測試博客:http://www.51testing.com/?489136

          原創(chuàng)作品,轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明,否則將追究法律責任。

          posted on 2012-10-26 13:48 順其自然EVO 閱讀(339) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2012年10月>
          30123456
          78910111213
          14151617181920
          21222324252627
          28293031123
          45678910

          導航

          統(tǒng)計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 九龙城区| 黔西县| 云龙县| 兴山县| 新兴县| 平阴县| 营口市| 巧家县| 河曲县| 崇仁县| 成都市| 玛沁县| 女性| 上虞市| 民县| 澄江县| 黎平县| 云安县| 柳州市| 大冶市| 郴州市| 尉氏县| 长岛县| 清苑县| 德格县| 永定县| 云龙县| 萍乡市| 凤翔县| 濉溪县| 斗六市| 谷城县| 棋牌| 七台河市| 孟村| 湖州市| 赤壁市| 凭祥市| 涿州市| 长春市| 遂昌县|