軟件測試過程中的五要素(Five-fold Testing System) 軟件測試
本文的主要目標是提出一種測試手段的分類系統,我們把它叫做“五要素測試系統(Five-fold Testing System) ” 。人們可以做的所有測試都可以在五個方面進行描述：
·測試員。進行測試的人。例如,用尸測試是由目標市場的成員、通常使用 該產品的人應行的專項測試。
·覆蓋率。測試了哪些內容。例如，在功能測試中，要測試每個功能。
·潛在問題。測試的原因(要測試什么風險) 。例如，測試極值錯誤。
·活動。如何測試。例如探索式測試。
·評估。怎樣判定測試通過還是不通過。例如，與巳知正確結果的比較。
本章還要詳細描述幾個手段，并就另外幾個手段的使用提出自己的觀點,不過我們的主要目標還是解釋分類系統。
所有測試都包括所有這五個要素。測試手段將測試員的關注點集中的一個或幾個要素上，把其他要素留給測試員自己判斷�？梢园殃P注一個要素的手段與關注另一個要素的手段結合起來，以得到想要的結果�？梢园堰@種結合的結果叫做新手段(有人確實這樣叫)，不過我們認為思考過程要比增加另一個名字更重要。在測試領域中，正在使用的定義不一致的手段清單正在不斷膨脹。我們的分類模式有助于讀者有意識地理智深刻地理解這種結合。
測試任務常常按一個要素分配,但是完成任務時要涉及所有五個要素。例如:
·有人可能要求測試員做功能測試(徹底測試每個功能) 。它說明的是要測試什么,測試員還必須決定誰來測試，以及要尋找什么問題,如何測試每個函數,如何確定程序是否通過。
·有人可能要求測試員做極值測試(測試在向變量輸入極值條件下的錯誤處理)。它說明的是要找出什么問題。測試員還必須決定誰來測試,要測試哪些變量、如何測試這些變量,如何評估結果。
·有人可能要求測試員做?測試(讓市場的外部代表做測試) 。它說明的是誰來測試,測試員還必須決定告訴外部代表什么(告訴他們多少)、試用產品中的哪一部分、他們應該查找什么問題(應該忽略什么問題) 。在有些?測試中，測試員還要具體地告訴他們如何識別特定類型的問題，可能要求他們以特定的方式執行特定的測試。在另外一些?測試中，可能會由他們決定要完成的活動和評估。
手段不一定只涉及一種要素，也不應該是這樣。所有測試都涉及所有五個要素,因此我們應該期望跨多個要素的更綜合的測試手段。以下是多要素手段的一個例子：如果有人要求做“基于需求的測試”，則可能是表示以下三種想法的任意組合：
·覆蓋率(測試在這個需求文檔中列出的所有內容)。
·潛在問題(測試不滿足這個需求的各種方式) 。
·評估(設計測試的方式，要使得測試員能夠使用需求規格說明確定程序是否通過) 。
在說到“基于需求的測試”時，不同的測試員會有這三種想法的不同組合,對這個詞并不存在惟一的正確解釋①。
盡管存在模糊性(并且在一定程度上正是因為有這種模糊性)，但是我們認為這種分類系統是一種很有用的思想生成器。
測試時要時刻想著所有五個要素，就可能做出更好的組合選擇。在?測試中，可能決定不描述這些要素中的一個或多個，可以決定不確定如何評估測試結果或測試員該怎樣做。但是我們的建議是，要有意識地做出類似上面提到的決定，而不是采用只關注一種要素的手段，而不注意到還要做出其他決定。
①基于需求測試的多種含義,提供了軟件工程中一個重要普遍問題的例子。定義在測試領域是不固定的。定義的使用在不同子領域和個人之間有很大不同,即使存在期望能被看作是參考標準的文檔。我們稍后討論使很多人無視標準文檔的一些因素。請注意,我們在這里不是要聲稱提供權威定義,或測試領域手段的描述。有些人會使用同樣的詞匯表示不同的含義。其他人可能會同意我們的描述,但是卻以不同的方式表達。不管哪種情況都是合理的、有說服力的。
2、關注測試員的基于人員的測試手段
以下是一些通過執行測試的人來區分的常見手段舉例。
用戶測試(user testing) 。由將使用該產品的典型人員進行輸入的測試。用戶測試可以在開發期間任何時候進行，可以在開發場地，也可以在用戶場地，可以在精心指導下進行，也可以根據用戶的意愿進行。有些類型的用戶測試，例如任務分析，更像是聯合探索(涉及至少一名用戶和至少一名公司測試小組成員),而不是由一個人完成的測試。
α測試。由測試小組(可能還包括其他感興趣的、友善的內部人員)執行的內部測試。
β測試。利用不屬于開發機構并且是產品的目標市場成員的測試員實施的用戶測試。待測產品一般非常接近完成。很多公司都將讓客戶試用代碼看作是β測試,他們把所有β測試都歸結為叫做“β”的里程碑。這是個錯誤。實際上有很多不同類型的β測試。設計β,用于要求用戶(特別是有關領域的專家)評價設計，應該盡可能早地實施,以便有根據評價意見進行修改的時間。市場開發友β，用于再次確認在該產品推出并投放自己的大型銷售網上時會有大量客戶購買,實施時間相當晚，要等到產品相當穩定之后。兼容性測試β，客戶在開發機構自己不容易測試的硬件和軟件平臺上運行該產品。這種測試不能太晚，否則難以確定和解決兼容性問題。對于所管理的任何類型β測試,在確定進度和實施方法之前，都要確定測試目標。
強力測試(bug bash)。利用秘書、程序員、市場開發人員和可以找到的任何人所實施的內部測試。強力測試一般持續半天，在軟件接近投放市場時進行。(請注意,我們列出這種手段是為了舉例,并不表示贊同。有些公司由于種種原因認為它很有用，有些公刮則認為沒用。)
有關領域的專家測試(subject-matter expert testing)。向軟件目標領域內的專家提供產品，并尋求反饋唐見(錯誤、批評和贊揚)。專家可以是，也可以不是預期使用產品的客戶,公司看重的是專家的知識,而不是其市場代表性。
成對測試(paired testing) 。兩個測試員在一起發現程序錯誤。一般情況下,他們共用一臺計算機,在測試時輪流操作。
自用測試(eat your own dogfood)。全公司使用并依靠自己軟件的試用版，通常要等到軟件足夠可靠能夠實際使用時.才向市場銷售。
3、關注測試內容的基于覆蓋率的測試手段
可以根據在使用這些手段時已經掌握的知識的不同,把這些手段按所關注的問題進行多種不同的分類。例如,如果把功能集成測試用于檢查每個功能與所有其他功能組合在一起時是否能夠正常延行.則這種測試就是面向覆蓋率的測試。如果有針對功能相互交互的錯誤理論，并想進行跟蹤，則這種測試就是面向問題的測試。(例如,如果意圖是想發現功能在相互傳遞數據時出錯，就是面向問題的測試。)
我們將在本章末尾補充解釋這些定義中的一些領域測試，因為與領域有關的手段在軟件測試中使用得非常普遍、非常重要。讀者應該對其有所了解。
功能測試(function testing) 。逐個測試每個功能。徹底測試功能，直到可以確信該功能沒有問題。白盒功能測試通常叫做單元測試,集中測試可以看到代碼的功能。黑盒功能測試關注命令和特性,以及用戶可以做或選樣的事情。在做涉及多個功能的更復雜的測試之前,最好先做功能測試。在復合測試中，第一個出現問題的功能可能會使測試停下來，阻止通過這個測試發現多個其他功能也出現問題。如果依靠復合測試而下是單個測試功能，可能要到很晚才會知道有一個功能出現問題，可能要花費大量工作在復合測試中定位,最后卻發現問題出現在一個簡單功能上。
特性或功能集成測試(feature or function integration testing) 。一起測試多個功能,以檢查功能在一起執行的情況。
菜單瀏覽(menu tour) 。遍歷GUI產品中的所有菜單和對話框,使用每個可用的選項。
域測試(domain testing) 。域是一個(數學)集合,包含所有可能的函數變量取值.在域測試中,要識別函數和變量。變量可以是輸入或輸出變量。(輸入域和值域之間的數學區別在這里無關,因為這兩種域的測試分析都是一樣的。)對于每個變量,都要把其可能取值集合劃分為等價類,并從每個類中選擇少量代表(一般是邊界值) 。這種方法假設如果用類中的少量好的代表值進行測試,就可以發現用類中所有成員測試所能夠找出的大多數或全部問題.請注意,與功能測試形成對比的是,感興趣的要素是變量而不是功能。很多變量被多個功能使用。進行域測試時必須分析變量,然后再根據分析,以這個變量作為輸入或輸出,測試涉及這個變量的每個功能。
等價類分析(equivalence class analysis) 。等價類是測試員認為是等價的一組變量取值。如果相信一組測試用例:(a)測試的都是相同的東西;(b)如果其中一個捕獲到一個程序錯誤,其他測試用例也可能捕獲到;(c)如果其中一個不能捕獲到某個程序錯誤,其他測試用例可能也不能捕獲到,則這些測試用例是等價的。一旦找出一個等價類,可只測試其一兩個成員。
邊界測試(boundary testing) 。等價類是一組取值。如果可以成員映射到一列數字上,則邊界值就是類的最小和最大值。在邊界測試中,要測試這些值,還要測試相鄰類的邊界值,這些值比要測試的類的最小值略小,比要測試的類的最大值略大。例如,請考慮一個接受10-50整數值的輸入字段。感興趣的邊界值是10(最小整數) 、9(小于10的最大整數) 、50(最大整數) 、51(大于50的最小整數) 。
最佳代表測試(best representative testing) 。等價類的最佳代表是在暴露軟件中的錯誤的可能性方面至少與類中其他值一樣的值。在邊界測試中,邊界值幾乎總是最佳代表。但是有時不能將等價類映射到一組數字上。例如,兼容惠普PcL-5的打印機是(或應該是)一個等價類，因為這些打印機的工作方式相同。假設對于一個具體任務,其中一種打印機與其他打印機相比,略微更可能出現問題。那么這種打印機可以作為這個類的最佳代表。如果對它測試沒有發現問題，那么可以比較可靠地認為其他打印機也沒有問題。
輸入字段測試大綱或矩陣(input field test catalogs or matrices) 。對于每種輸入字段,可以開發一組相當標準的測試用例,在這個產品和后續產品中的類似字段中重用。本章稍后還要給出這種方法的例子。(請參閱“如何創建針對輸入字段的測試矩陣”。)
用各種方式映射和測試編輯宇段(map and test all the ways to edit a filed) 。常�？梢砸远喾N方式改變某個字段中的值。例如可以把數據輸入到該字段，直接在字段中輸入數據，通過程序將計算好的結果復制到字段中，通過程序將再次計算好的結果復制到字段中，等等。字段是有限制的(限制字段可以取哪些值) 。有些限制是不變的,有些限制要依賴于其他字段的取值。例如,如果J和K是無符號整數，其限制就是0一直到MaxInt。這些都是不變限制.依賴于程序設計語言對無符號整數的定義。但是，如果N也是無符號整數,N=J+K,N=5。在這種情況下，J=5-K，J不能大于5，(N的值) 。這是可變限制，其所允許的取值范圍取決于N的值。為了檢查J是否在所允許的取疽范圍內(5—K)，可以使用各種能夠把數據輸入到J中的方法改變J的取值。
邏輯測試(logic testing) 。變量在程序中有關系。例如,程序可能有這樣一個決策規則：如果PERSON-AGE大于50，并且如果SMOKER是YES，則OFFER-INSURANCE必須是NO。這種決策規則表達了一個邏輯關系。邏輯測試試圖檢查程序中的所有邏輯關系。因果圖(cause-effect graphing)是一種用于設計大量基于邏輯測試的手段。
基于狀態的測試(state-based testing) 。程序的狀態要發生轉換。在給定狀態中，有些輸入是有效的,其他輸入被忽略或拒絕。對于有效輸入，被測程序要完成它可以做的事，并且不嘗試做它不能做的事。在基于狀態的測試中，每次都要通過經過大量狀態遷栘(狀態改變)并仔細檢查結果來檢驗程序。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
