如何設計OpenStack測試用例

一．軟件測試

軟件測試和軟件開發一樣，是一個典型的系統工程。它包括了持續集成（CI）、持續測試（CT）、持續交付（CD）和持續部署（CD）等諸多方面，每個方面又都包括各子內容。通過這些系統工程，團隊可以保持在短周期內生產出有價值的軟件，并且保證能夠可靠地在任何時間內發布軟件。

1.軟件測試技巧

軟件測試雖然辛苦，但是掌握了一定的技巧之后將使你事半功倍。比如，如下的一些方法。

1）邊界測試，測試用戶輸入框中數值的最大數和最小數，以及為空時的情況。 
2）非法測試，例如在輸入數字的地方輸入字母、特殊字符等。 
3）跟蹤測試，跟蹤一條數據的流程，保證數據的正確性。 
4）在開始測試時應保證數據的正確性，然后在從系統中找出各種BUG。 
5）接口測試，程序往往在接口的地方很容易發生錯誤，要在此模塊測試勿掉以輕心。 
6）代碼重用測試，在開發過程中有些模塊功能幾乎相同，程序員在重用代碼時可能忘記在原有代碼上修改或修改不全面，而造成的錯誤。也就是功能相同的模塊部分。 
7）突發事件測試，服務器上可能發生意外情況的測試，比如斷電、斷網、磁盤故障等。 
8）在程序員修復Bug的地方再找一找，往往程序員只修復報告出來的缺陷而不去考慮別的功能在修改時可能會重新造成錯誤。 
9）文字測試，如果在系統中有用詞不當的地方，這是不應該的。 
10）系統兼容測試，例如有些系統在Chrome、Firefox等瀏覽器下運行良好，但在IE、搜狗、360等瀏覽器下卻出現其他問題，你很有可能發現BUG。 
11）用戶易用性測試，往往用戶的需求是不斷變化的，而其中一部份變化的原因，是用戶操作上不方便引起的。

2.如何設計測試用例

個人理解大概從3個方面去考慮：

• 表單，也就是最基礎的功能；比如，這個功能是拿來做什么用的，“更多搜索”模塊怎么用、怎么測。
• 邏輯方面；比如，當在云基礎設施管理平臺上，創建一個vmdk卷。實際上是通過VMware vmdk driver機制將卷創建在Vcenter那邊的，掛載給VMware虛擬機，也同樣是在VC環境上。
• 業務流程；比如，當用戶使用iso來安裝自定義的鏡像，操作的一個業務流程是什么。

3.一個好的測試用例具備的特點

1. 易用性：對于一個即熟悉測試工作，又熟悉被測系統的QA測試人員，應當可以花費很少的時間就可以理解測試用例表達的測試思路，并可以很快的執行完這個測試用例。對于不熟悉測試工作，不熟悉被測應用的人來說，也完全可以參照著該測試用例執行下去。
2. 易維護性：當開發過程中的某些因素影響了測試需求，測試用例的作者或其他測試設計人員，應該可以花費很少的時間就完成定位并維護所有相關測試用例的工作。
3. 可重用性：一個好的測試用例要保證可以隨著版本的變化始終保持可用狀態，不能因為版本的變更，導致測試用例無效或者冗余。

二．測試用例設計方法

1.等價類劃分法

窮舉測試是不可能的，因此等價類劃分法因運而生。它是指在每一個等價類中取一個數據作為代表性的測試數據取得較好的測試結果。等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

在輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。如：輸入值是學生成績，范圍是0～100；

等價類劃分法 

1）有效等價類

是指對于程序來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。

2）無效等價類

與有效等價類的定義恰巧相反。無效等價類是對程序無意義、不合法的輸入，輸入無效等價類后，程序應該給出錯誤提示。對于某一個測試場景，無效等價類至少應有一個，也可能有多個。比如一個程序規定了只允許輸入數字，那么無效等價類，可以輸入為空、中文、字母、特殊字符、數字長度/大小越界等多種類。

設計測試用例時，要同時考慮這兩種等價類。因為軟件不僅要能接收合理的數據，也要能經受意外的考驗，給出相應的提示信息，這樣的測試才能確保軟件具有更高的可靠性。

2.邊界值分析法

使用邊界值分析方法設計測試用例應先確定邊界情況，然后選取正好等于、大于或小于邊界的值作為測試數據。

3.因果圖法/判定表

前面介紹的等價類劃分法和邊界值分析法都是著重考慮輸入條件，但未考慮輸入條件之間的聯系、相互組合等?？紤]輸入條件之間的相互組合，可能會產生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種適合于多種條件的組合，相應產生多個動作的形式來考慮設計測試用例。這就需要利用因果圖。它適合于檢查程序輸入條件的各種組合情況。

判定表法（判定表驅動分析方法）是分析和表達多邏輯條件下執行不同操作的情況下的工具。在程序設計發展的初期，判定表就已被當作編寫程序的輔助工具了。由于它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確。因果圖方法最終生成的就是判定表。

比如，針對登錄云平臺界面上的賬號、密碼兩個輸入框，進行各種條件組合測試。

注意：

因果圖的使用和分析比較復雜，使用因果圖可能會消耗很多的時間，因此正確的策略是先考慮其他的測試用例設計方法，最后再使用因果圖和判定表，盡量的減少工作的時間并提高效率。此方法一般很少使用。

4.場景設計法；

現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，有利于設計測試用例，同時使測試用例更容易理解和執行。

5.錯誤猜測法

錯誤猜測法就是根據經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設計測試用例的方法。

例如，在云硬盤的掛載使用中，為了驗證云硬盤的掛載-卸載-重新掛載對數據完整性的保護這一場景測試。因而，可以將一個數據卷掛載到VM上，寫入文件，然后umount、卸載，重新掛載給另一個VM來驗證軟件是否存在缺陷等。

6.正交表

由于因果圖/判定表設計測試用例的固有弊端；以及為了解決窮舉測試的弊端，因此需要使用正交表設計方法：即從大量的測試數據中挑選出適量的、有代表性的測試數據，從而合理地做出測試設計。各列中出現最大數字相同的正交表稱為相同水平正交表。如L4(23)、L8(27)、L12(211)等各列中最大數字為2，稱為兩水平正交表。此設計方法適用于各種組合場景的測試，比如“更多搜索”。

正交表的構成

• 行數(Runs)：正交表中的行的個數，即試驗的次數，也是我們通過正交實驗法設計的測試用例的個數。
• 因素數(Factors) ：正交表中列的個數，即我們要測試的功能點。
• 水平數(Levels)：任何單個因素能夠取得的值的最大個數。即測試功能點的輸入條件個數。

正交表的兩個特點：

正交表必須滿足這兩個特點，有一條不滿足，就不是正交表。

1）每列中不同數字出現的次數相等。例如，在兩水平正交表中，任何一列都有數碼“0”與“1”，且任何一列中它們出現的次數是相等的。這一特點表明每個因素的每個水平與其它因素的每個水平參與試驗的幾率是完全相同的，從而保證了在各個水平中最大限度地排除了其它因素水平的干擾，能有效地比較試驗結果并找出最優的試驗條件。

2）在任意兩列其橫向組成的數字對中，每種數字對出現的次數相等。例如，在兩水平正交表中，任何兩列（同一橫行內）有序對子共有4種：（1，1）、（1，2）、（2，1）、（2，2）。每種對數出現次數相等。在三水平情況下，任何兩列（同一橫行內）有序對共有9種，1.1、1.2、1.3、2.1、2.2、2.3、3.1、3.2、3.3，且每對出現數也均相等。這個特點保證了試驗點均勻地分散在因素與水平的完全組合之中，因此具有很強的代表性。

以上兩點充分的體現了正交表的兩大優越性，即“均勻分散性，整齊可比性”。通俗的說，每個因素的每個水平與另一個因素的水平各碰一次，這就是正交性。

如何選擇正交表 
- 考慮因素（變量）的個數； 
- 考慮因素水平（變量的取值）的個數； 
- 考慮正交表的行數； 
- 取行數最少的一個；

設計測試用例時的三種情況 
- 因素數（變量）、水平數（變量值）相符； 
- 因素數不相同； 
- 水平數不相同；

正交表的形式： 

這是云平臺中的一個“更多搜索”模塊（由于某些原因，只能貼設計表）。我們可以看到要測試的控件有6個：狀態、開始時間、結束時間、所屬主機、所屬租戶、IP，也就是說要考慮的因素有6個；而每個因素的選項（水平數）有2個：填與不填。

選擇正交表時分析一下：

1、表中的因素數>=6； 
2、表中至少有6個因素數的水平數>=2； 
3、行數取最少的一個。

從正交表公式中開始查找，結果為：

L4（26）：表示需做>=4次實驗，可測試6個因素，每個因素均為2水平。 
變量映射：

測試用例如下： 
1：填寫狀態、填寫開始時間、填寫結束時間、填寫所屬主機、填寫所屬租戶、填寫IP 
2：填寫狀態、不填開始時間、不填結束時間、不填所屬主機、不填所屬租戶、不填IP 
3：不填狀態、填寫開始時間、不填結束時間、填寫所屬主機、不填所屬租戶、填寫IP 
4：不填狀態、不填開始時間、填寫結束時間、不填所屬主機、填寫所屬租戶、不填IP

增補測試用例： 
5：不填狀態、不填開始時間、不填結束時間、不填所屬主機、不填所屬租戶、不填IP

測試用例減少數：64-5=59

7.基于需求的測試方法

即根據客戶需求、業務和邏輯設計需求、場景和功能需求（比如平臺可用性測試、故障HA測試、后端/前端性能測試）等進行相關的測試。要求測試人員全面清晰地掌握用戶需求；明確測試的目標和任務；設計基于需求的測試用例；建立測試報告通報制度（建立測試報告審批通報制度對于提升軟件質量具有明顯作用。作為一名優秀的測試工程師，應將已經發現的缺陷或錯誤進行分析匯總，用統計數字、圖表等方式說明缺陷或錯誤的根源，及時將測試工作報告提交上級主管領導審議，并通知研發設計人員，使設計人員做到對缺陷心中有數、控制有道，以防患于未然）

基于需求的測試方法五項最佳實踐

1）轉變“編碼后進行測試”的傳統觀念。在軟件編碼開始之前的設計階段就根據需求文檔和設計文檔開發出90%以上的測試用例，盡早發現和排除絕大部分的缺陷。即轉入測試驅動開發的最佳實踐（TDD）。 
2）根據各項應用功能的優先級、重要性制訂不同等級的測試方案、測試用例。重要模塊和次要模塊投入的測試資源。 
3）盡早測試，頻繁測試。測試進行得越早，缺陷發現越早，修復缺陷的代價越??；測試進行得越晚，缺陷發現越遲，修復缺陷的代價越大。 
4）摒棄“經驗至上”的想法。設計系統、嚴謹、合理的測試用例才能使測試達到實效。 
5）加強對測試過程的監控跟蹤。當用戶需求發生變更時，軟件需求文檔和設計文檔都隨之發生變更，相應測試用例也應發生變更。保證測試用例和用戶需求的雙向統一。

8.綜合策略

使用各種測試方法的綜合策略：

1）在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。 
2）必要時用等價類劃分方法補充一些測試用例。 
3）用錯誤猜測法再追加一些測試用例。 
4）對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到，應當再補充足夠的測試用例。 
5）如果程序的功能中含有輸入條件的組合情況，則選用因果圖法或正交表。

界面測試總結（如何針對文本框進行測試）

a、輸入正常的字母或數字； 
b、輸入已存在的名稱； 
c、輸入超長字符；例如在“名稱”框中輸入超過允許邊界個數的字符，檢查程序能否正確處理； 
d、輸入默認值，空白，空格，特殊符號； 
e、若只允許輸入字母，嘗試輸入數字；反之，嘗試輸入字母； 
f、利用復制，粘貼等操作強制輸入程序不允許的輸入數據； 
g、輸入特殊字符集； 
h、輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示； 
i、輸入不符合格式的數據，檢查程序是否正常校驗（判斷）；

例如，程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，則程序應該給出錯誤提示。

為測試用例設置優先級需要采取兩個原則：

1）將使用頻率比較高的測試場景設置為高優先級的； 
2）根據測試場景失敗后對系統、用戶的影響大小設置其優先級；

這樣將兩者相加就得到了每個測試用例的優先級了。根據優先級的排序就可以更有針對性的進行測試用例的詳細設計了。此時，還需要為每個測試用例設計相關的測試數據。對測試數據的設置有兩個要求：

1）正常數據 
2）非法數據

應當優先考慮正常數據，而且正常數據的設計必須是有實際意義的。然后再考慮設計非法數據。這兩種數據中都應該包含邊界數據，因為邊界數據往往是容易出錯的地方。

當我們設計完測試數據后，就可以開始對測試用例進行詳細設計了。在具體的測試步驟中，需要包含的主要內容是：操作步驟，測試數據以及期望結果。當我們完成了這些工作，一個完整的測試用例就寫完了。

當然，除了以上講到的軟件測試用例設計方法（黑盒測試）之外，還有諸如包括語句覆蓋、判定覆蓋（也稱為分支覆蓋）、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、基本路徑分析法等在內的白盒測試方法。這里就不一一列舉了。

原文轉自： http://geek.csdn.net/news/detail/77593