軟件測試基本方法

 

 

動態黑盒測試

 

    不深入代碼細節的軟件測試方法。常被稱爲行爲測試,因爲測試的是軟件在使用過程中的實際行爲。

 

    首先,從產品說明書獲知測試對象的軟件的輸入和應該得到的輸出。

    接下來,開始定義測試案例。 測試案例:指進行實驗用的輸入,以及測試軟件用的程序。

    選擇測試案例是軟件測試員最重要的任務。不正確的選擇可能導致測試量過大或者過小,甚至測試目標不對。準確評估風險,把不可窮近的可能性減少到可以控制的範圍是成功的訣竅。

 

測試基本方法:通過測試 vs 失敗測試

 

    通過測試:確認軟件至少能做什麼,而不考驗其能力。

    失敗測試:純粹爲了破壞軟件而設計和執行的測試案例,也稱爲迫使出錯測試。蓄意攻擊軟件的薄弱環節。

    在設計和執行測試案例時,總是首先進行通過測試。在破壞性試驗之前看看軟件基本功能是否實現是很重要的,否則在正常使用軟件時就會奇怪爲什麼有那麼多的軟件缺陷。

    常見的測試案例就是設法迫使軟件出現錯誤提示信息。產品說明書可能會給出這樣的功能要求,針對這個問題的測試可能是通過測試也可能是失敗測試。可能兩者都是。不用去刻意區分,重要的是找到軟件缺陷!

 

選擇測試案例:等價分配

 

    等價分配:是指分步驟地把過多(無限)的測試案例減小到同樣有效的小範圍的過程。也稱等價劃分。

    等價分配技術提供了一個選擇哪些數值、捨棄哪些數值的系統方法。

    等價類別或者等價區間是指測試相同目標或者暴露相同軟件缺陷的一組測試案例。在尋找等價區間時,想辦法把軟件的相似輸入、輸出、操作分成組。這些組就是等價區間。

    等價分配的目的是把可能的測試案例組合縮減到仍然足以測試軟件的控制範圍。因爲選擇了不完全測試,就要冒一定的風險。如果爲了減少測試案例的數量過度進行等價分配,測試的風險就會增加。另外,等價區間的劃分沒有一定的標準,只要足以覆蓋測試對象就行了。

 

數據測試

 

    軟件由數據(包括鍵盤輸入、鼠標單擊、磁盤文件、打印輸出等等)和程序(可執行的流程、轉換、邏輯和運算)兩個最基本的要素組成。

    對數據進行軟件測試,就是在檢查用戶輸入的信息、返回結果以及中間計算結果是否正確。主要根據下列原則來進行等價分配,以合理減少測試案例:邊界條件、次邊界條件和無效數據。

 

    1. 邊界條件測試

 

    程序在處理大量中間數值時都是對的,但是可能在邊界處出現錯誤。比如數組的[0]元素的處理。想要在Basic中定義一個10個元素的數組,如果使用 Dim data(10) As Integer ,則定義的是一個11個元素的數組,在賦初值時再使用 For i =1 to 10 ...來賦值,就會產生權限,因爲程序忘記了處理i=0的0號元素。

    邊界條件是指軟件計劃的操作界限所在的邊緣條件。

 

    數據類型:數值、字符、位置、數量、速度、地址、尺寸等,都會包含確定的邊界。

    應考慮的特徵:第一個/最後一個、開始/完成、空/滿、最慢/最快、相鄰/最遠、最小值/最大值、超過/在內、最短/最長、最早/最遲、最高/最低。這些都是可能出現的邊界條件。

根據邊界來選擇等價分配中包含的數據。然而,僅僅測試邊界線上的數據點往往不夠充分。提出邊界條件時,一定要測試臨近邊界的合法數據,即測試最後一個可能合法的數據,以及剛超過邊界的非法數據。以下例子說明一下如何考慮所有可能的邊界:

 

--------------------------------------------------------------------------------

   

如果文本輸入域允許輸入1-255個字符。

    嘗試:輸入1個字符和255個字符(合法區間),也可以加入254個字符作爲合法測試。

輸入0個字符和256個字符作爲非法區間。

 

--------------------------------------------------------------------------------

 

    如果程序讀寫軟盤

    嘗試:保存一個尺寸極小,甚至只有一項的文件。

    然後保存一個很大的——剛好在軟盤容量限制之內的文件。

    保存空文件。

    保存尺寸大於軟盤容量的文件。

 

--------------------------------------------------------------------------------

 

如果程序允許在一張紙上打印多個頁面

嘗試:只打印一頁

    打印允許的最多頁面

    打印0頁

    多於所允許的頁面(如果可能的話)

 

--------------------------------------------------------------------------------

 

--------------------------------------------------------------------------------

 

2. 次邊界條件測試

 

上面所講的是普通的邊界條件,在產品說明書中有定義,或者在軟件的過程中確定。但有些邊界在軟件內部,最終用戶幾乎看不到,但是軟件測試仍有必要檢查,這樣的邊界條件成爲次邊界條件或者內部邊界條件。尋找這樣的邊界條件,不要求軟件測試員成爲程序員或者具有閱讀源代碼的能力,但是確實要求大體瞭解軟件的工作方式。2的乘方和ASCII表是這樣的兩個例子:

 

--------------------------------------------------------------------------------

    2的乘方

    術語

範圍或值

 

    位bit

    0或1

 

    雙位doublebit

    0~15

 

    字節Byte

    0~255

 

    字word

    0~65,535或者0~4,294,967,295

 

    千K

    1,024

 

    兆M

    1,048,576

 

    億

    1,073,741,824

 

    萬億

    1,099,511,627,776

 

    計算機和軟件的基礎是二進制數。因此二的乘方是作爲邊界條件的重要數據。如:在通訊軟件中,帶寬或者傳輸信息的能力總是受限制,因此軟件工程師會盡一切努力在通訊字符串中壓縮更多數據。其中一個方法就是把信息壓縮到儘可能小的單元中,發送這些小單元中最常用的信息,在必要時再擴展爲大一些的單元。假設某種通訊協議支持256條命令。軟件將發送編碼爲一個雙位數據的最常用的15條命令;如果用到第16到256之間的命令,軟件就轉而發送編碼爲更長字節的命令。這樣,軟件就會根據雙位/字節邊界執行專門的計算和不同的操作。

    在建立等價區間的時候,要考慮是否需要包含2的乘方邊界條件。例如:軟件接受1~1000範圍內的數字,那麼合法區間除了1和1000,也許還有2和999之外,還應該有臨近2的乘方次邊界:14,15,16以及254,255和256。

 

--------------------------------------------------------------------------------

 

ASCII表

 

    ASCII碼錶並不是結構良好的連續表。數字0~9對應48~57;斜槓字符(/)在0的前面,冒號(在9的後面;大寫字母A~Z對應65~90;小寫字母對應97~122。這些情況都代表次邊界條件。

    如果測試進行文本輸入或文本轉換的軟件,在定義數據區間包含哪些值時,參考一下ASCII表是相當明智的。例如:測試的文本框只接受用戶輸入字符A~Z和a~z,就應該在非法區間中包含ASCII表中這些字符前後的值——@,',[,{。

 

--------------------------------------------------------------------------------

 

--------------------------------------------------------------------------------

 

    3. 默認值測試(默認、空白、空值、零值和無)

 

    好的軟件會處理這種情況,常用的方法:一是將輸入內容默認爲合法邊界內的最小值,或者合法區間內某個合理值;二是返回錯誤提示信息。

    這些值在軟件中通常需要進行特殊處理。因此應當建立單獨的等價區間。在這種默認下,如果用戶輸入0或-1作爲非法值,就可以執行不同的軟件處理過程。

 

--------------------------------------------------------------------------------

 

    4.  破壞測試(非法、錯誤、不正確和垃圾數據)

 

    數據測試的這一類型是失敗測試的對象。這類測試沒有實際規則,只是設法破壞軟件。不按軟件的要求行事,發揮創造力吧!

 

--------------------------------------------------------------------------------

 

狀態測試

 

    狀態測試是通過不同的狀態驗證程序的邏輯流程。軟件測試員必須測試軟件的狀態及其轉換。軟件狀態是指軟件當前所處的情況或者模式。軟件通過代碼進入某一個流程分支,觸發一些數據位,設置某些變量,讀取某些變量,從而轉入一個新的狀態。

    同數據測試一樣,狀態測試運用等價分配技術選擇狀態和分支。因爲選擇不完全測試,所以要承擔一定的風險,但是通過合理選擇減少危險。

 

    1. 建立狀態轉移圖

 

使用:方框和箭頭;圓圈(泡泡)和箭頭。

    應包含的項目:

    - 軟件可能進入的每一種獨立狀態。

       如果不能斷定是否獨立,先認爲是;以後一旦發現不是,隨時剔除。

- 從一種狀態轉入另一種狀態所需的輸入和條件。

       狀態變化和存在的原因,就是我們要尋找的對象。

    - 進入或退出某種狀態時的設置條件及輸出結果。

       包括顯示的菜單和按鈕、設置的標誌位、產生的打印輸出、執行的運算等等。

    由於是黑盒測試,因而只需從用戶的角度建立狀態圖即可。

 

2. 減少要測試的狀態及轉換的數量

 

測試每一種路線的組合,走遍所有分支是不可能的事情。大量的可能性也需要減少到可以操作的測試案例集合。方法有以下5種:

    - 每種狀態至少訪問一次。

       無論用什麼方法,每種狀態都必須測試。

    - 測試看起來最常見最普遍的狀態轉換

    - 測試狀態之間最不常用的分支。

       這些分支是最容易被產品設計者和程序員忽視的。

    - 測試所有錯誤狀態機器返回值。

      錯誤是否得到正確的處理、錯誤提示信息是否正確、修復錯誤時是否正確恢復軟件等

    - 測試隨機狀態轉換。

 

    3. 進行具體的測試——定義測試案例

 

    測試狀態及其轉換包括檢查所有的狀態變量——與進入和退出狀態相關的靜態條件、信息、值、功能等等。如:窗口外觀、窗口尺寸定義(固定/上次使用時的尺寸)、顯示的菜單、默認設定值、文檔的名稱等。狀態無論是否可見,都必須進行狀態確定。       狀態變量也許不可見,但是很重要,一個常見的例子時文檔塗改標誌(以此判斷退出時是否詢問保存)。

 

失敗狀態測試

 

    狀態測試的失敗測試的案例,主要是競爭條件、重複、壓迫和重負。

 

    1. 競爭條件和時序錯亂

 

    設計多任務操作系統不是很難,設計充分利用多任務能力的軟件纔是艱鉅的任務。在真正的多任務環境中軟件設計絕對不能想當然,必須處理隨時被中斷的情況,能夠與其他任何軟件在系統中同時運行,並且共享內存、磁盤、通信設備以及其他硬件資源。

    這樣的結果,就是導致競爭條件問題;軟件未預料到的中斷髮生,時序就會發生錯亂。

    競爭條件測試難以設計,最好是首先仔細查看狀態轉換圖中的每一個狀態,以找出哪些外部影響會中斷該狀態。考慮要使用數據如果沒有準備好,或者在用到時發生了變化,狀態會怎樣。數條弧線或者直線同時相連的情形如何。

 

   一下是要面臨競爭條件的典型情形:

    - 兩個不同的程序同時保存或打開同一個文檔。

    - 共享同一臺打印機、通信端口或者其他外圍設備。

    - 當軟件處於讀取或者修改狀態時按鍵或者單擊鼠標。

    - 同時關閉或者啓動軟件的多個實例。

    - 同時使用不同的程序方位一個共同數據庫。

 

2. 重複、壓迫和重負

 

    這三個測試的目標是處理那些連程序員都沒有想到的惡劣條件下產生的問題的能力。

 

    - 重複測試

 

    重複測試是不斷執行同樣的操作。最簡單的是不停地啓動和關閉程序,或者反覆讀寫數據或者選擇同一個操作。這種測試的主要目的是看內存是否不足。如果內存被分配進行某項操作,但操作完成時沒有完全釋放,就會產生一個常見的軟件問題。

 

    - 壓迫測試

 

    壓迫測試是使軟件在不夠理想的條件下運行——內存小、磁盤空間少、CPU速度慢、調制解調器速率低等等。觀察軟件對外部資源的要求和依賴程度。壓迫測試就是將支持降到最低限度,目的在於儘可能的限制軟件的必要條件。

 

    - 重負測試

 

    重負測試和壓迫測試相反。壓迫測試是儘量限制軟件,而重負測試是儘量提供條件任其發揮。讓軟件處理儘可能大的數據文件。最大限度的發掘軟件的能力,讓它不堪重負。比如:軟件對打印機或通信端口進行操作,就把能連的都連上;服務器可以處理幾千個模擬連接,就按他說的做。

    不要忘了,時間也是一種重負測試。

 

    重複、壓迫和重負測試應聯合使用,同時進行。

 

    需要注意的是:

    一、項目管理員和小組程序員可能不完全接受軟件測試員這樣打破軟件的做法。但是軟件測試員的任務就是確保軟件在這樣惡劣的條件下正常工作,否則就報告軟件缺陷。如何以最佳方式報告軟件缺陷,使其得到嚴肅對待和修復,也是一門學問。

    二、無數次重複和上千次的連接對於手工操作是不可能的。因而需要藉助自動化測試工具來實現。

 

其他黑盒測試方法

 

    1. 像無經驗的用戶那樣做

 

    輸入意想不到的數據;中途變卦而退回去執行其他操作;單擊不應該單擊的東西……

 

    2. 在已經找到軟件缺陷的地方再找找

 

    原因有二:一是軟件缺陷的集中性。如果發現在不同的特性中找出了大量上邊界條件軟件缺陷,那麼就應該對所有特性着重上邊界條件。對某個存在的缺陷,應當投入一些案例來保證這個問題不是普遍存在的。二是程序員往往傾向於只修改報告出來的軟件缺陷,不多也不少。比如報告啓動-終止-再啓動255次導致衝突,程序員可能只修復了這個問題。重新測試時,一定要重新執行同樣的測試256次以上。

 

    3. 憑藉經驗、直覺和預感

 

    記錄哪些技術有效,哪些不行。嘗試不同的途徑。如果認爲有可疑之處,就要仔細探究。按照預感行事,直至證實這是錯誤爲止。

    經驗是人們對錯誤行爲的稱謂。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章