Comparing the Effectiveness of Testing Techniques
簡介
論文標題
- Comparing the Effectiveness of Testing Techniques
- 比較測試技術的有效性
- 2011.8
核心內容
- 討論一個測試數據選擇標準是否另一個更有效
本篇論文主要是討論了幾種形式化定義的測試數據集的好壞標準,以及形式化定義的缺點,並且討論了這些標準在實踐中的應用
摘要
測試軟件系統需要從業者決定如何選擇測試數據。本章討論一個測試數據選擇標準比另一個更有效意味着什麼。討論了幾種建議的比較關係,強調了每種關係的優點和缺點。此外,還討論了這些關係是如何演變的,並認爲需要進行大規模的實證研究。
形式化分析
- 比較關係 Comparison relations
- 概率衡量 Probabilistic measures
比較關係
- 包容關係(subsumption relation)
- 強大關係(power relation)
- 更好關係(BETTER relation)
包容關係
定義
如果對於每個程序P,滿足C1的每個測試套件也滿足C2則測試選擇標準C1包含(subsumes)測試選擇標準C2,
c1 subsumes c2 : ∀TS satisfies(TS,C1) ⇒ satisfies(TS,C2)
缺陷
-
測試標準的不可比較性
低效”關係暴露錯誤而“有效”關係不暴露錯誤
-
可能會產生誤導
強大關係
定義
故障檢測
如果滿足測試選擇標準的每個測試集都包含導致程序P失敗的輸入,並且至少有一個測試集滿足P的標準,則稱該測試選擇標準檢測到故障
powerful
如果對於每個程序P,如果C2檢測到P中的故障,C1也會檢測到,則準則C1至少與準則C2一樣強大
C1 is at least as powerful as C2 : detects(C2,failure) ⇒ detects(C1,failure)
缺陷
-
仍然存在不可比較性問題
有可能爲權利關係認爲較不有效的標準選擇的測試集將比爲由權利關係認爲更有效的標準選擇的測試集暴露更多的故障。
C1和C2都沒有檢測到這種形式意義上的任何故障
-
C1 is at least as powerful as C2
∃C2: exposes some failures more often than C1
∃C1,C2: none of both find certain failures
更好關係
定義
required
如果該程序的每個滿足測試標準C的測試集都必須包括該測試用例,那麼這個用例被要求標準C和測試程序P要求
test case required by criterion C to test P: tc ∈ ts ∧ ∀ts.satisfies(ts,C) ⇒ requires(C,ts)
BETTER
如果對於每個程序P,C2所要求的任何導致故障的輸入C1都需要,則所述準則C1比準則C2更好
C1 is BETTER than C2: ∀tc.requires(C2,tc) ⇒ requires(C1,tc)
此外:
(C1subsumes C2) ⇒ (C1B ETTER C2) ⇒ (C1at least as powerf ul as C2)
缺陷
-
仍然存在不可比較性問題
-
很少有標準需要特定的測試用例
比較關係中的問題舉例
程序P和輸入域D,將D分成5個子域,從每個子域選擇出一個測試用例
C1 covers C2 : 如上圖所示,滿足C1條件的用例,也一定滿足C2(從 {3,4}中選擇一定滿足從{0,3,4}中選擇)
雖然C1 covers C2 ,但是C2發現錯誤的概率要比C1要高
概率衡量
覆蓋關係
定義
covers relation
設C1和C2爲標準,表示從其中選擇測試用例以滿足程序P和規格說明S的準則C的非空的多個子域集合
若 存在 屬於 且 ,則 C1 覆蓋 C2
特殊的,有universally covers: 覆蓋
M = P(”test set exposes at least one fault”)
程序P和輸入域,輸入子域爲,規範,和測試選擇標準.設是子域的大小,是其導致失敗的輸入數量,則標準M爲:
假設使用均勻分佈從每個子域中獨立選擇一個測試用例,則M是測試套件暴露至少一個故障的概率
對於 (P, S),即使 C1覆蓋C2,也有可能 可見之前的問題舉例
,爲了解決上述問題,因此有如下定義
Properly covers relation
properly covers
的每個子域由子域的並集覆蓋
子域中沒有一個比更常出現在覆蓋中
特殊的,有properly universally covers: properly covers
預期檢測到的故障數量
properly covers
M 和 E 可以用來對測試標準排序
注意: properly covers = will find more faults ⇒ just more likely
properly covers 並不保證發現更多錯誤,只是可能性更高
因此這些方法只能在理論上保證上的好壞,並不一定真實反映實際情況
覆蓋標準之間的關係摘要
從C1到C2的實線箭頭表示C1普遍適當地覆蓋C2,從C1到C2的虛線箭頭表示C1包含C2,但不是普遍適當地覆蓋C2;任何沒有在圖中明確顯示且不是從傳遞性出發的關係,以及普遍適當覆蓋意味着包含這一事實,都不成立
形式化分析的侷限性
- 關係比較測試策略的理想版本,而不是實踐版本
- 缺失風險分析:高後果故障、小故障
- 沒有提供人類變異性:經驗、專業知識、後天直覺
- 測試成本:使用某些標準是否有益?
關係比較測試策略的理想版本,而不是實踐版本
舉例,分支測試
按照該篇論文思想,分支測試的正式定義假設首先將域劃分爲子域,每個子域正好包含導致執行程序中給定分支的輸入域的那些成員。然後,假設使用均勻分佈隨機選擇每個子域的一個元素。
很難想象這一過程在實踐中會得到遵循。實際上,分支測試往往更多地被用作評估測試徹底性的一種方式,而不是作爲選擇測試用例的基礎。測試人員通常根據他們是否已經完成了全面的工作來選擇測試用例。然後,他們可以使用分支覆蓋工具,該工具確定到目前爲止他們組裝的測試套件已經執行的程序分支的百分比。如果百分比很高,那麼測試人員可能會看到哪些分支沒有被覆蓋,並嘗試確定將導致執行每個未覆蓋分支的輸入。如果百分比很低,那麼測試人員很可能會繼續使用特別的方法來選擇測試用例,然後重新評估實現的分支覆蓋率,反覆進行,直到覆蓋的分支百分比超過規定的水平,或者測試人員認爲他們已經做得足夠了
如果分支測試以這種方式使用,那麼我們根本不知道它的有效性與其他測試策略相比如何,因爲我們沒有評估分支測試的那個版本,我們評估了一種完全不同的測試方法,我們稱之爲分支測試。所有比較的測試策略都是如此–它們不是測試人員用來選擇測試用例的真正策略,它們是理想化的版本。所以我們剩下的問題是:知道理想化的測試用例選擇方法A優於理想化的測試用例選擇方法B,能告訴我們關於“真實”方法A和B的相對有效性嗎?既然真正的方法A和B沒有正式定義,那麼實際上是否只有一個“真正的”方法A或B,或者不同的實踐者各自有自己的使用方法呢?
缺失風險分析:高後果故障、小故障
另一種不同類型的問題與依賴措施M和E作爲確信一種測試策略比另一種更有效地工作的基礎是否合適有關。這兩個衡量標準都沒有區分嚴重的錯誤和微不足道的錯誤。因此,如果標準C1(正確覆蓋標準C2的標準)暴露了微小的故障,而C2暴露了災難性的故障,那麼使用C1測試程序的事實並不能真正表明它比使用C2測試時更可靠。這是正確的,儘管使用C1發現了更多的故障,並且暴露故障的可能性更高,因爲暴露的故障幾乎沒有什麼後果。
沒有提供人類變異性:經驗、專業知識、後天直覺
使用完全相同的方法來測試給定軟件系統的兩個不同的測試人員通常將選擇不同的測試用例集合
測試成本:使用某些標準是否有益?
假設C1確實做了比C2更有效的測試工作,並且暴露了比C2更嚴重或更嚴重的故障。但是,如果C1的使用成本比C2高出幾個數量級呢?增加的收益值得增加的成本嗎?
爲暴露的故障幾乎沒有什麼後果。
沒有提供人類變異性:經驗、專業知識、後天直覺
使用完全相同的方法來測試給定軟件系統的兩個不同的測試人員通常將選擇不同的測試用例集合
測試成本:使用某些標準是否有益?
假設C1確實做了比C2更有效的測試工作,並且暴露了比C2更嚴重或更嚴重的故障。但是,如果C1的使用成本比C2高出幾個數量級呢?增加的收益值得增加的成本嗎?