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

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

一、測試需求的分析和肯定

二、測試計劃

三、測試設計

四、測試執行

五、測試記錄和缺陷跟蹤

六、迴歸測試

七、測試總結和報告

 

一、測試需求的分析和肯定

 

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

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

例子：

一、是否覆蓋了用戶提出的全部需求項（完整性）

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

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

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

三、是否清楚地描述了軟件系統須要作什麼及不作什麼（必要性）

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

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

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

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

爲了需求的維護和管理

六、需求項是否先後一致、彼此不衝突（一致性）

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

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

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

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

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

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

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

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

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

單據：輸入大於0的

 

二、測試計劃

         --一場對全部軟件BUG展開的殲滅戰

肯定測試範圍

制定測試策略

測試資源安排

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

-------因爲每一個人的思惟存在侷限性，每項測試最後安排很多於2我的測試，以便交叉測試

進度安排

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

風險及對策

-------可考慮創建後備機制

 

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

方法：

等價類劃分法

邊界值分析法

等價類+邊界值

基本路徑分析法

因果圖法

場景設計法

錯誤猜想法

正交表與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)除了同行評審，應儘可能引入用戶參與到測試用例的設計中來

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