入門級----需求的分析以及測試用例的設計與編寫

PDCA循環（戴明循環）plan do check action

1、測試需求的分析和確定

2、測試計划

3、測試設計

4、測試執行

5、測試記錄和缺陷跟蹤

6、回歸測試

7、測試總結和報告

 

1、測試需求的分析和確定

 

1.1需求規則說明書的檢查要點

（關於怎樣才能做好軟件的需求分析工作，以及度量軟件需求，請參考的《探索需求-設計前的質量》一書，《Exploring Requirements : Quality Before Design》）

例子：

1、是否覆蓋了用戶提出的所有需求項（完整性）

用戶的原始需求素材（用戶需求文檔，用戶提供的相關材料，調研記錄，與用戶的溝通記錄）

2、用詞是否清晰，語義是否存在歧義（明確性）

找出諸如也許，可能，大概，大約等關鍵詞，因進一步明確需求，才不會導致后期與開發的理解沖突

3、是否清楚地描述了軟件系統需要做什么及不做什么（必要性）

覆蓋不多不少，少了則是需求覆蓋不充分，多了則可能是不必要，強加給客戶的功能，既浪費人力，也增加軟件實現的風險

4、是否描述了軟件使用的目標環境，包括軟硬件環境（完整性）

應根據實際用戶所適應的軟硬件環境和網絡環境進行測試，

5、是否對需求項進行了合理的編號（可修改性）

為了需求的維護和管理

6、需求項是否前后一致、彼此不沖突（一致性）

比如說明書描述軟件使用環境時沒提到需要在Linux平台下使用，而在描述安裝包的開發時則要求需要支持Linux，會讓人產生疑惑感

7、是否清楚說明了系統的每個輸入、輸出的格式，以及輸入輸出之間的對應關系（可測性）

檢查每一類的輸入是否存在固定的輸出，如沒有則是缺乏判斷和驗證系統正確性的依據

8、是否清晰描述了軟件系統的性能要求（完整性）

有時候必要時還包括安全性的需求，如果確實需要則需要考慮

9、需求的優先級是否合理分配（優先級）

關鍵特效，重要特效，用戶關心的功能，用戶迫切想要的功能優先

10、是否描述了各種約束條件（可測性）

約束條件的完整，合理，與用戶的業務場景一致

單據：輸入大於0的

 

2、測試計划

         --一場對所有軟件BUG展開的殲滅戰

確定測試范圍

制定測試策略

測試資源安排

-------測試難道、時間、工作量、人員

-------由於每個人的思維存在局限性，每項測試最后安排不少於2個人測試，以便交叉測試

進度安排

-------最好能預留一段緩沖時間，用於應對計划的變更，以及讓測試員有時間完善和補充測試用例

風險及對策

-------可考慮建立后備機制

 

3、測試的設計及測試用例

方法：

等價類划分法

邊界值分析法

等價類+邊界值

基本路徑分析法

因果圖法

場景設計法

錯誤猜測法

正交表與TCG的使用

 

 

等價類划分法:

一般可分為有效等價類和無效等價類

 

比如：在一個系統中，填寫一個多少歲的成年人數學考了多少分（假設成年人年齡為x,0<x<=18,數學成績為y：0<=y<=100

那么年齡按照等價類划分可分為x<0,0<x<=18,x>18,有效等價類是0<x<=18，無效等價類是x<0，x>18

 

數學成績按照等價類划分可分為y<0,0<=y<=100,y>100,有效等價類是0<=y<=100，無效等價類是y<0，y>100

 

邊界值分析法：（一般是與等價類划分一起使用）

　　一般邊界值分析是因為程序開發循環體時的取數可能會因為<,<=搞錯。

 

　　比如下面代碼

　　for(int i = 0;i <100; i ++)

{

　　int j = i+1;

　　System.out.println("循環第“+j+"次")//循環地做某件事情

}

　　這里的程序是循環了100次，所以會做100次;

　　如果程序員不小心，把i <100寫成i <= 100，則會溢出，這時候邊界值檢查是一個很好的測試方法。

 

比如：在一個系統中，填寫一個多少歲的成年人數學考了多少分（假設成年人年齡為x,0<x<=18,數學成績為y：0<=y<=100

　　　根據上面的等價類划分法我們可知，年齡的有效等價類是0<x<=18，所以邊界值就是0，1，18，19

　　　　　　　　　　　　　　　　　　數學成績的,有效等價類是0<=y<=100，所以邊界值就是-1，0，100，101

 

基本路徑分析法：（一般根據流程圖）

比如審批合同：

　　編輯合同-提交-審核通過-建帳套

　　編輯合同-提交-審核不通過-修改-提交-審核通過-建帳套

 

因果圖法（一般與判定表一起使用）

案例：

 

（1）分析原因及結果

 

 

（2）畫出因果圖

 

（3）編寫決策表

 

（4）設計測試用例

 

場景設計法

　　如果需求規則說明書是采用uml的用例設計，那么可以比較輕松地通過把系統用例影射成測試用例的方法來設計測試用例。需要覆蓋系統用例中的主成功場景和擴展場景，並且需要適當補充各種正反面的測試用例和考慮出現異常的情形。

　　場景設計法需要測試人員充分發揮對用戶實際業務場景的想象。

錯誤猜測法

　　錯誤猜測法是測試經驗豐富的人喜歡使用的一種測試用例設計方法。

一般這種方法是基於經驗和直覺推測程序中可能發送的各種錯誤，有針對性地設計。只能作為一種補充。

　　例如，對於一個調用excel的程序，直覺告訴測試人員，它可能發生的錯誤是在調用的前后過程，比如，用戶的計算機沒有安裝excel,則可能調用失敗，甚至拋出異常，因此要做一下環境測試；又如調用了excel后忘記釋放對excel的引用，從而導致excel的進程駐留，因此需要檢查一下進程的列表看excel進程是否在程序關閉后仍然存在。

 

技巧：最重要的是要思考和分析測試對象的各個方面，多參考以前發現的bug的相關數據，總結的經驗，個人多考慮異常的情況、反面的情況、特殊的輸入，以一個攻擊者的態度對待程序，就能設計出比較完善的測試用例來。

 

正交表法與TCG的使用

　　正交表法是一種有效減少測試用例個數的設計方法。

　　通過根據不同的輸入參數，而設計出的不同的用例。

　　例如：我們現在創建客戶，輸入以下的3個參數：

　　編號：空、中文

　　名稱：空、中文

　　性別：男、女

 

以下是用TCG工具映射出來的對應正交：

 

 

 

 

 

 

 

 

 

 

 

 

 

利用均勻試驗法設計測試用例

　　該方法是與正交表法類似的一種測試用例設計法。

 

組合覆蓋（PICT使用）

　　了解組合覆蓋： http://www.pairwise.org/

　　微軟的PICT小工具下載：http://msdn.Microsoft.com/en-us/testing/bb980925.aspx

　　PICT接受一個純文本的Model文件作為輸入，然后輸出測試用例集合：

　　Model文件格式:<ParamName> : <value1>,<value2>….

　　比如，輸入的文件分別有不同參數選擇：

　　　　Type:Span,Mirror,Single

　　　　Size:10,,100,500

　　　　File system:FAT,FAT32,NTFS

　　　　把上面的內容存為Model.txt，存儲在D:\PICT

　　　　在命令行輸入以下命令（先進入該文件夾）： “D:\PICT\Model.txt”

　　　　可產生所有可能的組合。

　　　　如果想把產生的測試用例存儲到某個文件，則可輸入以下命令：“D:\PICT\Model.txt” > “D:\PICT\OutPut.txt”

　　　　還有很多類似的工具，可參考：http://www.pairwise.org/tools.asp

 

分類數與TESTONA的使用

　　http://www.berner-matter.com/en/products/testona/index.html

　　TESTONA下載地址：http://www.testona.net/cms/upload/3_Raw/testonaLightSetup_4.1.1.exe

 

測試用例設計的自動化

　　目前，測試用例的設計大部分是需要手工的，這也是由於設計的復雜性和靈活性決定的。在自動化測試領域，測試的執行是首先被自動化的一個方面，目前已經取得了長足的進度。但是在測試用例的設計方面，自動化程度非常低。

　　目前在測試用例設計方面的自動化主要集中在測試數據的生成方面，一些工具也是集中在幫助測試人員產生數據和篩選數據方面，例如TConfig，PICT等。另外，像DataFactory這樣的工具則專注於產生大批量的數據表數據。

注意：不要認為測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟件開發的不同階段都 要回來重新審視和完善測試用例。

測試用例的評價（評審）

　　測試用例設計出來了，如何提高測試用例設計的質量？

　　（1）同行的評審：通過討論，協作來完成測試用例的設計，盡可能全面的覆蓋需求。（一個人的思維性有局限性）

　　  (2)除了同行評審，應盡量引入用戶參與到測試用例的設計中來

注意：參與到測試用例評審的人除了測試人員自己和管理層外，還應該包括最終用戶或者顧客代表，還有開發人員。