<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    qileilove

    blog已經轉移至github,大家請訪問 http://qaseven.github.io/

    用技術提高回歸測試精確度

      在大家的常識中,回歸測試在范圍的選擇上,有如下四種方法:

      1、測試全部用例——選擇基線測試用例庫中的全部測試用例,這是一種比較安全的方法,再測試全部用例具有最低的遺漏回歸錯誤的風險,但測試成本最高;

      2、基于風險選擇測試——可以基于一定的風險標準來從基線測試用例庫中選擇回歸測試;

      3、基于操作剖面選擇測試——如果基線測試用例庫的測試用例是基于軟件操作剖面開發的,回歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例,釋放和緩解最高級別的風險,有助于盡早發現那些對可靠性有最大影響的故障;

      4、再測試修改的部分——當測試者對修改的局部化有足夠的信心時,可以通過相依性分析識別軟件的修改情況并分析修改的影響,將回歸測試局限于被改變的模塊和它的接口上。

      我前一段時間在微博里發了一個號稱“回歸測試用例自動生成器”的設計圖(如下),核心思路就是通過配置管理工具對版本差異的掃描來獲取改動的文件,通過用代碼掃描工具對改動文件的掃描得到改動的內容,再通過這些改動的內容掃描出關鍵字:

      SP:cursor、function、procedure……

      JAVA:method、interface、class、DAO、DTO……

      最后通過這些關鍵字和系統功能點、回歸測試用例庫中的測試用例,這三者的映射關系來精確的找到每次移交之后所要進行的關聯測試。其實后來經過大家的討論,發現這種構思叫“回歸測試范圍界定選擇器”更加合適,用“生成”二字有點歧義。我自己也沒有想清楚到底如何實現,需要關注哪些問題,但是我做這種設想的理由很簡單:

      1、我厭倦了每次版本最后一次移交之后都需要的全面回歸測試,這是一種無恥的浪費;

      2、我厭倦了這種“瞎蒙”式的回歸測試,不精確,而且所謂的全面回歸也無法避免測試遺漏;

      3、我不相信在沒有足夠的時間的情況下,所謂的回歸測試剪裁,所謂基于風險的評估是無法保證規避一些重要的測試遺漏的;

      4、我不相信coder兄弟們告訴我的,他們基于本次版本所有需求所修改的內容,因為他們其中個別人往往會稍帶著做一些自認為“無傷大雅的優化”;

      5、我憎恨任何一個把前期測試沒有盡力卻在出了測試遺漏的時候把責任推給回歸測試的人,開發人員也好、測試人員也罷;

      當然,這些只是我個人主觀上的認知傾向,貌似我應該用更有說服力的數據來說明我這么思考和想做這件事情的理由,那么不妨讓我算一筆賬給大家看看:

      1、前提:自動化開發和維護的成本撇開不算,因為有沒有這個構思,自動化測試開發和維護都必須要做;

      2、按照目前Selenium/WebDriver的自動化回歸測試腳本的粒度算,假設一個系統平均Web頁面回歸測試用例1000個,其中80%是自動化的,20%是手動的;

      3、這1000個Web頁面測試Case的執行,總計約消耗12.67小時,其中人力是7人時:

      ● 受限與應用邏輯和環境效率,自動化平均每個可能要30s(現階段全部門實際是100+,后續必須組織系統的優化),1000*80%*30=6.67小時;

      ● 手動的平均每個可能要執行1分鐘到2分鐘,按平均1分半計算:1000*20%*90=5小時;

      ● 自動化測試執行的6.67小時是機器時間,而我們需要關注和分析結果,同時硬件資源消耗在測試范圍沒有優化的情況下需要投入更多,這里將硬件資源的多余耗費也計入人力成本,則人力的總耗費大約為1.5+0.5=2小時;

      4、參照歷史數據,實際上每個版本涉及的改動功能點和分支,只是整個系統功能點的10%不到,大家可以自己回顧思考一下有沒有超過這個比例的;

      5、用10%的改動點,假設我們將回歸測試用例挑選這件事情分三個步驟來做:

      ● 第一階段:映射關系很粗糙,甚至只掃描到JAVA的獨立文件和SP的獨立文件,那么10%的改動點應該平均對應最多不過30%的回歸測試用例的執行需求;

      ● 第二階段:映射關系細化一層,JAVA改動點細化到.do/.screen,SP改動點細化到procedure,那么10%的改動點可能只涉及20%的回歸測試用例的執行需求;

      ● 第三階段:精確映射,加上關聯影響的延伸,10%的改動點可能只會涉及15%左右的回歸測試用例的執行需求;

      6、參照歷史數據:在QC里,除去DBEAIETLTJSMIS等暫時無需自動化回歸測試的系統,最近107天發布版本約760個,這樣算下來每年大約2600個版本,按照每人時180元計算,測試人力每人月成本3萬,看一下每年這2600個版本的回歸測試能夠節省多少:

      ● 第一階段:3萬元/人月*(1-30%)*7*2600/22/7.58=約230萬元

      ● 第二階段:3萬元/人月*(1-20%)*7*2600/22/7.58=約260萬元

      ● 第三階段:3萬元/人月*(1-15%)*7*2600/22/7.58=約276萬元

      對于某些保險公司或者銀行來說,一年區區的兩三百萬算不得什么,不過,一屋不掃何以掃天下?精細經營才是王道,況且員工們在每次版本發布之前都能正常下班不也是Boss們的無上成就么?目前這個構思還在細化分析中,期待后續能夠拿出實際的成果再來和大家分享。


    posted on 2012-10-18 09:33 順其自然EVO 閱讀(541) 評論(0)  編輯  收藏 所屬分類: selenium and watir webdrivers 自動化測試學習

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

    導航

    統計

    常用鏈接

    留言簿(55)

    隨筆分類

    隨筆檔案

    文章分類

    文章檔案

    搜索

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲自偷自偷偷色无码中文| 无码国产亚洲日韩国精品视频一区二区三区 | 亚洲精品无码久久千人斩| 美女免费精品高清毛片在线视| 免费a级毛片高清视频不卡| 亚洲精品无码久久毛片波多野吉衣| 久久免费观看国产精品88av| 亚洲国产成人精品无码区在线观看| 久青草视频97国内免费影视| 亚洲综合伊人久久大杳蕉| 好湿好大好紧好爽免费视频| 色久悠悠婷婷综合在线亚洲| 最新久久免费视频| 亚洲国产另类久久久精品黑人| 三年片免费高清版| 久久精品国产96精品亚洲 | 青草草在线视频永久免费| 亚洲精品国产首次亮相| 国产成人aaa在线视频免费观看| 美女黄频视频大全免费的| 亚洲国产成人精品91久久久| 国产一级高青免费| 久久亚洲AV无码精品色午夜| 99爱在线精品免费观看| 亚洲成熟丰满熟妇高潮XXXXX| 亚洲成av人在片观看| 91成人免费观看在线观看| 亚洲视频网站在线观看| 成年女人午夜毛片免费看| 成人福利在线观看免费视频| 亚洲AV无码国产精品色午友在线| 91频在线观看免费大全| 欧美亚洲国产SUV| 亚洲国产精品一区第二页 | 成熟女人特级毛片www免费| 免费在线观看亚洲| 国产AV无码专区亚洲AWWW| 67194国产精品免费观看| 青青青亚洲精品国产| 亚洲Av永久无码精品三区在线| 毛片大全免费观看|