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

2021-09-30 23:34:04 字數 3014 閱讀 3745

摘要:程式被修改後,要保證程式能正常執行並且修改不能給程式質量帶來任何負面影響,

回歸測試是必要的。大型軟體系統結構複雜,構成要素多,如何做到不遺漏功能點同時降低軟體回歸測試代價,本文結合業務規則模型、修改影響分析和成本風險管理等技術提出了一種自動化回歸測試方法。

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、結論

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

***********************************=分割線******************************==

大型軟體經驗

原文 人往高處走,水往低處流,我們都希望每年提高一點點進步一點點,每年都能更上乙個層次。我們有時候開玩笑,說有的人吧,你把金子放到他的口袋裡,他會嫌太沉了,把金子甩開,繼續往前走,繼續尋找食物。雖然大家都有很多專案經驗,但是不知道是否進行了專案經驗的整理 甚至是工作經驗的整理,相對來講對開發人員來說...

大型軟體開發與ORM構架

在最近的幾年裡,很多程式設計師把自己的業餘時間獻給了orm框架的開發,甚至在有些單位的招聘面試中把是否理解或是能否使用一種orm構架,作為了一種評價開發人員技能的必要條件。作為乙個一線的開發工人,我毫不否認orm框架對設計模式社群發展作出巨大的貢獻,以及對提高開發效率這一目標的成果。在下面的文章中我...

大型軟體專案中的組織環境

專案管理的三大主要任務就是 計畫 組織和控制。在這三大任務中,組織是其中的核心和鈕帶。關鍵字 pm 專案經理 csa 軟體架構師 sa 設計師 testmanager 測試經理 tester 測試員 developer 程式設計師 customer 客戶代表 consultant 諮詢顧問 軟體生命...