功能測試詳解 ZT

黑盒測試（black-box testing，又稱為功能測試或資料驅動測試）是把測試對象看作一個黑盒子。利用黑盒測試法進行動态測試時，需要測試軟體産品的功能，不需測試軟體産品的内部結構和處理過程。

      黑盒測試注重于測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測試并不是白盒測試的替代品，而是用于輔助白盒測試發現其他類型的錯誤。

      黑盒測試試圖發現以下類型的錯誤：

      1）功能錯誤或遺漏；

      2）界面錯誤；

      3）資料結構或外部資料庫通路錯誤；

      4）性能錯誤；

      5）初始化和終止錯誤。

      采用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合政策。

黑盒測試的測試用例設計方法

·等價類劃分方法

·邊界值分析方法

·錯誤推測方法

·因果圖方法

·判定表驅動分析方法

·正交實驗設計方法

·功能圖分析方法

等價類劃分

      是把所有可能的輸入資料,即程式的輸入域劃分成若幹部分（子集）,然後從每一個子集中選取少數具有代表性的資料作為測試用例.該方法是一種重要的,常用的黑盒測試用例設計方法.

1) 劃分等價類:

      等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對于揭露程式中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.是以,可以把全部輸入資料合理劃分為若幹等價類,在每一個等價類中取一個資料作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

      有效等價類:是指對于程式的規格說明來說是合理的,有意義的輸入資料構成的集合.利用有效等價類可檢驗程式是否實作了規格說明中所規定的功能和性能.

      無效等價類:與有效等價類的定義恰巧相反.

      設計測試用例時,要同時考慮這兩種等價類.因為,軟體不僅要能接收合理的資料,也要能經受意外的考驗.這樣的測試才能確定軟體具有更高的可靠性.

2）劃分等價類的方法:下面給出六條确定等價類的原則.

      ①在輸入條件規定了取值範圍或值的個數的情況下,則可以确立一個有效等價類和兩個無效等價類.

      ②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下,可确立一個有效等價類和一個無效等價類.

      ③在輸入條件是一個布爾量的情況下,可确定一個有效等價類和一個無效等價類.

      ④在規定了輸入資料的一組值（假定n個）,并且程式要對每一個輸入值分别處理的情況下,可确立n個有效等價類和一個無效等價類.

      ⑤在規定了輸入資料必須遵守的規則的情況下,可确立一個有效等價類（符合規則）和若幹個無效等價類（從不同角度違反規則）.

      ⑥在确知已劃分的等價類中各元素在程式進行中的方式不同的情況下,則應再将該等價類進一步的劃分為更小的等價類.

3）設計測試用例:在确立了等價類後,可建立等價類表,列出所有劃分出的等價類:

      輸入條件 有效等價類 無效等價類

      ... ... ...

      然後從劃分出的等價類中按以下三個原則設計測試用例:

      ①為每一個等價類規定一個唯一的編号.

      ②設計一個新的測試用例,使其盡可能多地覆寫尚未被覆寫地有效等價類,重複這一步.直到所有的有效等價類都被覆寫為止.

      ③設計一個新的測試用例,使其僅覆寫一個尚未被覆寫的無效等價類,重複這一步.直到所有的無效等價類都被覆寫為止.

邊界值分析法

      邊界值分析方法是對等價類劃分方法的補充.

1）邊界值分析方法的考慮:

      長期的測試工作經驗告訴我們,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的内部.是以針對各種邊界情況設計測試用例,可以查出更多的錯誤.

      使用邊界值分析方法設計測試用例,首先應确定邊界情況.通常輸入和輸出等價類的邊界,就是應着重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料.

2）基于邊界值分析方法選擇測試用例的原則:

      ① 如果輸入條件規定了值的範圍,則應取剛達到這個範圍的邊界的值,以及剛剛超越這個範圍邊界的值作為測試輸入資料.

      ② 如果輸入條件規定了值的個數,則用最大個數,最小個數,比最小個數少一,比最大個數多一的數作為測試資料.

      ③ 根據規格說明的每個輸出條件,使用前面的原則1）.

      ④ 根據規格說明的每個輸出條件,應用前面的原則2）.

      ⑤ 如果程式的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最後一個元素作為測試用例.

      ⑥ 如果程式中使用了一個内部資料結構,則應當選擇這個内部資料結構的邊界上的值作為測試用例.

      7）分析規格說明,找出其它可能的邊界條件.

錯誤推測法

      錯誤推測法: 基于經驗和直覺推測程式中所有可能存在的各種錯誤, 進而有針對性的設計測試用例的方法.

      錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在子產品中常見的錯誤. 以前産品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入表格為空格或輸入表格隻有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

因果圖方法

      前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯系, 互相組合等. 考慮輸入條件之間的互相組合,可能會産生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 是以必須考慮采用一種适合于描述對于多種條件的組合,相應産生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）.

      因果圖方法最終生成的就是判定表. 它适合于檢查程式輸入條件的各種組合情況.

      利用因果圖生成測試用例的基本步驟:

      ① 分析軟體規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 并給每個原因和結果賦予一個辨別符.

      ② 分析軟體規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關系. 根據這些關系,畫出因果圖.

      ③ 由于文法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記号表明限制或限制條件.

      ④ 把因果圖轉換為判定表.

      ⑤ 把判定表的每一列拿出來作為依據,設計測試用例.

      從因果圖生成的測試用例（局部,組合關系下的）包括了所有輸入資料的取true與取false的情況,構成的測試用例數目達到最少,且測試用例數目随輸入資料數目的增加而線性地增加.

      前面因果圖方法中已經用到了判定表.判定表（decision table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程式設計發展的初期,判定表就已被當作編寫程式的輔助工具了.由于它可以把複雜的邏輯關系和多種條件組合的情況表達得既具體又明确.

      判定表通常由四個部分組成.

      條件樁（condition stub）:列出了問題得所有條件.通常認為列出得條件的次序無關緊要.

      動作樁（action stub）:列出了問題規定可能采取的操作.這些操作的排列順序沒有限制.

      條件項（condition entry）:列出針對它左列條件的取值.在所有可能情況下的真假值.

      動作項（action entry）:列出在條件項的各種取值情況下應該采取的動作.

      規則:任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.

      判定表的建立步驟:（根據軟體規格說明）

      ①确定規則的個數.假如有n個條件.每個條件有兩個取值（0,1）,故有 種規則.

      ②列出所有的條件樁和動作樁.

      ③填入條件項.

      ④填入動作項.等到初始判定表.

      ⑤簡化.合并相似規則（相同動作）.

      b. beizer 指出了适合使用判定表設計測試用例的條件:

      ①規格說明以判定表形式給出,或很容易轉換成判定表.

      ②條件的排列順序不會也不影響執行哪些操作.

      ③規則的排列順序不會也不影響執行哪些操作.

      ④每當某一規則的條件已經滿足,并确定要執行的操作後,不必檢驗别的規則.

      ⑤如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要.

黑盒測試的優點

      1. 基本上不用人管着，如果程式停止運作了一般就是被測試程式crash了

      2. 設計完測試例之後，下來的工作就是爽了，當然更苦悶的是确定crash原因

黑盒測試的缺點

      1. 結果取決于測試例的設計，測試例的設計部分來勢來源于經驗，ouspg的東西很值得借鑒

      2. 沒有狀态轉換的概念，目前一些成功的例子基本上都是針對pdu來做的，還做不到針對被測試程式的狀态轉換來作

      3. 就沒有狀态概念的測試來說，尋找和确定造成程式crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨确認一遍。而就有狀态的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

常用的功能測試方法

功能測試就是對産品的各功能進行驗證，根據功能測試用例，逐項測試，檢查産品是否達到使用者要求的功能。常用的測試方法如下：

1. 頁面連結檢查：每一個連結是否都有對應的頁面，并且頁面之間切換正确。

2. 相關性檢查：删除/增加一項會不會對其他項産生影響，如果産生影響，這些影響是否都正确。

3. 檢查按鈕的功能是否正确：如update, cancel, delete, save等功能是否正确。

4. 字元串長度檢查: 輸入超出需求所說明的字元串長度的内容, 看系統是否檢查字元串長度,會不會出錯.

5. 字元類型檢查: 在應該輸入指定類型的内容的地方輸入其他類型的内容(如在應該輸入整型的地方輸入其他字元類型),看系統是否檢查字元類型,會否報錯.

6. 标點符号檢查: 輸入内容包括各種标點符号,特别是空格,各種引号,Enter鍵.看系統處理是否正确.

7. 中文字元處理: 在可以輸入中文的系統輸入中文,看會否出現亂碼或出錯.

8. 檢查帶出資訊的完整性: 在檢視資訊和update資訊時,檢視所填寫的資訊是不是全部帶出.,帶出資訊和添加的是否一緻

9. 資訊重複: 在一些需要命名,且名字應該唯一的資訊輸入重複的名字或id,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入内容的前後輸入空格,系統是否作出正确處理.

10. 檢查删除功能:在一些可以一次删除多個資訊的地方,不選擇任何資訊,按”delete”,看系統如何處理,會否出錯;然後選擇一個和多個資訊,進行删除,看是否正确處理.

11. 檢查添加和修改是否一緻: 檢查添加和修改資訊的要求是否一緻,例如添加要求必填的項,修改也應該必填;添加規定為整型的項,修改也必須為整型.

12. 檢查修改重名:修改時把不能重名的項改為已存在的内容,看會否處理,報錯.同時,也要注意,會不會報和自己重名的錯.

13. 重複送出表單：一條已經成功送出的紀錄，back後再送出，看看系統是否做了處理。

14. 檢查多次使用back鍵的情況: 在有back的地方,back,回到原來頁面,再back,重複多次,看會否出錯.

15. search檢查: 在有search功能的地方輸入系統存在和不存在的内容,看search結果是否正确.如果可以輸入多個search條件,可以同時添加合理和不合理的條件,看系統處理是否正确.

16. 輸入資訊位置: 注意在光标停留的地方輸入資訊時,光标和所輸入的資訊會否跳到别的地方.

17. 上傳下載下傳檔案檢查：上傳下載下傳檔案的功能是否實作，上傳檔案是否能打開。對上傳檔案的格式有何規定，系統是否有解釋資訊，并檢查系統是否能夠做到。

18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示資訊，如在必填項前加*

19. 快捷鍵檢查：是否支援常用快捷鍵，如ctrl+c ctrl+v backspace等，對一些不允許輸入資訊的字段，如選人，選日期對快捷方式是否也做了限制。

20. Enter鍵檢查: 在輸入結束後直接按Enter鍵,看系統處理如何,會否報錯.