qileilove

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

          大型軟件回歸測試方法研究

           摘要:程序被修改后,要保證程序能正常運行并且修改不能給程序質量帶來任何負面影響,回歸測試是必要的。大型軟件系統結構復雜,構成要素多,如何做到不遺漏功能點同時降低軟件回歸測試代價,本文結合業務規則模型、修改影響分析和成本風險管理等技術提出了一種自動化回歸測試方法。

            關鍵詞:回歸測試風險管理修改影響分析

            1、引言

            在軟件測試過 程中,由于需要對軟件進行修改,修改后的程序必須重新測試,以確保程序的修改是否達到了目的和是否引入了新的錯誤,這種測試就是回歸測試。軟件的變化可能 是源于發現了錯誤并做了修改,也有可能是因為在集成或維護階段加入了新的模塊。當軟件中所包含的錯誤被發現時,如果對錯誤的跟蹤管理系統不夠完善,可能會 遺漏對這些錯誤的修改;而開發人員對錯誤理解的不夠透徹,也可能導致所做的修改只修正了錯誤的外在表現,沒有修改錯誤本身,甚至可能產生副作用,從而導致 軟件未被修改的部分又產生新的問題,使本來正常的功能產生錯誤。同樣,在有新代碼加入軟件的時候,除了新加入的代碼中有可能含有錯誤外,新代碼還有可能對 原有的代碼帶來影響。因此,每當軟件發生變化時,我們就必須重新測試現有的功能,以便確定修改是否達到了預期的目的,檢查修改是否損害了原有的正常功能。 因此需要進行回歸測試。

            回歸測試是一種代價較高,比較耗時的測試方法,然而又是必不可少的。大型軟件通常規模大,系統結構復雜,構成要 素多、層次多,在漸進和快速迭代開發中,新版本的連續發布使回歸測試的實施更加頻繁。因此,通過選擇正確的回歸測試策略來改進回歸測試的效率和效果,減小 回歸測試代價是非常有意義的。

            2、大型軟件回歸測試面臨的問題

            大型軟件回歸測試面臨兩個重大難題:一是系統變更引起的回歸測試范圍無法準確界定;二是參數組合引起的測試用例急劇膨脹,無法在較短時間內以合理成本完成最低覆蓋率要求的回歸測試。而且大型軟件回歸測試往往受到測試時間和測試環境條件的約束,而測試的工程性質又決定了它不可能達到理論上的完整。

            在有限的時間和資源條件下,為了更合理的規劃和安排測試工作,在測試計劃的制定階段需要一個決策機制能夠在資源約束,如時間、人力、成本的前提下基于風險管理和測試成本預算進行決策。

            隨著軟件生命周期的推進,軟件的開發與回歸測試反復迭代,規則的表達逐漸完善,測試用例庫越來越豐富,回歸測試的實施效率將越來越高。

            3、大型軟件回歸測試方法

            通過構建回歸測試決策支持平臺可以為大型軟件的回歸測試提供可行的解決方案。

            3.1 業務規則

             業務規則是定義和約束業務結構與業務行為的規定或規范,是業務運作和管理決策所依賴的重要資源。建立大型軟件業務規則模型正是要繼承資深測試專家所積累 的業務知識,使事實上得到使用的規則有一種顯式的表達。在此基礎上,結合測試理論和規則的整合以及用例優化算法,建立自動化用例生成系統。

            業務規則的來源一般包括:

            1)業務需求導出的規則;

            2)測試理論原則導出的規則;

            3)軟件業傳統導出的規則;

            4)業內常識導出的規則。

            業務規則模型的基礎是手工測試中積累的一系列用例設計規則、行業規范和源于業務的特殊約束。業務規則模型用于表達這些手工時代的規則,并建立一種可加載規則的引擎結構,在通過該引擎加載規則后,可以通過決策支持系統生成面向某個具體過程的用例模板的基礎用例集。

            所謂規則的加載,是將某條規則加入規則庫中,重點是適用條件的表達和優化算法的指定。

            對于一個目標系統,一次窮盡所有可能的規則是不可能的,只能漸進地逼進,所以應該允許手工追加規則,這一過程是業務規則模型的學習過程。

           3.2 修改影響分析

            對于軟件回歸測試來說,確定修改影響的范圍是至關重要的,修改的影響范圍也是回歸測試的目標范圍。如果無法確定修改的范圍,則理論上說就得把整個系統重測一遍,對于大型軟件,這種代價也是巨大的。

            3.3 成本風險評估

            如何在有限的時間和資源預算下,更合理的規劃和安排測試工作。回歸測試在實踐中往往受到測試時間、測試成本、人工投入和測試對象業務關鍵性等約束,因此需要制定一個科學的測試計劃,以保證在滿足各種條件約束的前提下能夠確保測試質量。

            Boehm 用公式RE=P(UO)*L(UO)對風險進行定義,其中RE表示風險或者風險所造成的影響,P(UO)表示令人不滿意的結果所發生的可能性,L(UO)表示糟糕的結果會產生的破壞性程度。

            因此,被測試對象f中存在的風險值 Re(f)的大小可以用出錯的概率與出錯的代價的乘積來表達:

            Re(f) = p(f)*l(f)

            確定待測試對象風險因素發生的可能性及其造成的損失的過程是風險估計階段。將風險發生的概率與風險發生造成的損失相乘,可以得到每個測試對象的風險值。

            為了方便對風險進行定量的估計,采用等級評定的方法對出錯代價和出錯概率進行表達。其中風險概率由模塊成熟度和開發人員的出錯預期共同計算。確 定開發方的出錯預期的依據是過往的缺陷率記錄,在沒有缺陷記錄時,所有的開發人員度成熟度都默認為高,此后,個人成熟度分值隨著個人缺陷率對平均缺陷率的 相對值和個人缺陷率趨勢而變化。

            根據風險值的估算,可以確定待測試對象的最低測試深度。在測試深度的要求下,首先選擇適當強度的測試用例簡約算法進行試算,可以得出完成該對象測試需要的用例數。

            由于回歸測試中大量用例可以復用,計算實施成本是需要對自動生成的測試用例和手工完成的測試用例區分對待,以不同的權重進行計算,最終得出整個 測試過程的實施成本。實施成本可以表示為測試投入的人時數。根據實施成本與項目預期成本投入和時間進行比較,判斷待測試對象的成本是否在可以接受的范圍 里,如果可以接受,就可以根據相應簡約算法生成最終需要的測試用例庫。如果實施成本無法接受,可以重新調整用例簡約算法,降低或者提高測試強度,重新計算 實施成本,直到滿足預算要求。

            4、結論

            回歸測試研究有著廣闊的空間,尤其對于系統結構復雜,構成要素多的大型系統軟件回歸測試,本文提出的自動化回歸測試方法,對于降低回歸測試代價,提高回歸測試質量和效率具有及其重要的作用。

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

          <2012年11月>
          28293031123
          45678910
          11121314151617
          18192021222324
          2526272829301
          2345678

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 醴陵市| 东山县| 罗江县| 扎囊县| 湟源县| 东兴市| 拜城县| 闽侯县| 余庆县| 平安县| 湟源县| 台湾省| 贡山| 土默特右旗| 璧山县| 凭祥市| 和平县| 烟台市| 屏南县| 吉木乃县| 阜阳市| 凉城县| 城固县| 连云港市| 深水埗区| 炉霍县| 关岭| 佛坪县| 海宁市| 资兴市| 曲靖市| 苏尼特左旗| 新竹市| 丽水市| 高要市| 渝北区| 雅江县| 靖远县| 石河子市| 黄骅市| 开原市|