如何自動生成測試用例方案


資料參考:

組合測試設計PK正交設計總結:https://www.testwo.com/blog/6376

組合測試工具集:http://www.pairwise.org/tools.asp

組合測試方法-配對測試實踐:https://www.cnblogs.com/leeboke/p/5035892.html

 

一、目的

受體:測試經理,測試主管,質量管理員,技術經理

做測試的,不能這樣說,應該是致力於軟件質量監控,就應該清楚的知道一個項目哪些是可測的,哪些是無法測試的,這些可測和不可測的其實都應該得到監控,可以實時觀察到各個監控點的健康正常的運行,而這篇文章就是針對可測的監控。

測試行業,又錯了,應該是質量監控行業,肯定是要有一個指標的,要不然怎么確定哪些是達標的 呢?所以對於測試用例的監控就至關重要,測試的執行結果就是依據測試用例,怎么保證測試用例的質量呢?俗話說啊,一千個人就是一千個哈姆雷特,每個的觀念啊,審美啊都TM的各種奇葩,所以用例制定的再怎么規范,人家就是不去執行,就是搞個小脾氣、小動作之類的,你又能怎么樣呢?把他滅了吧,換個新人,還會面臨這個問題,所以如果能夠自動控制用例的質量就好辦了。所以就有了這篇文章,如何進行“自動測試用例生成”就是這篇文章的目的。

達到自動生成用例,就要分析用例的組成,注意啊,這里說的用例都是API用例,包含:URL、parameters、response

URL就不說了就是一個地址,parameters、response是要自動的對象,還有業務邏輯其實就是URL的組合。

對於parameters,是用例的各種場景組合的依據,parameter會有很多個且每個都會多個值,術語呢是:因素數、水平數

對於response,就是測試后的結果檢查,是用例的最后一個部分。

 

二、parameters組合方法

我通過自己笨拙的Goole搜索,只找到兩種具體方法進行parameters組合:

組合分析方法和正交實驗設計法。

 

一)、組合分析法

組合分析方法(組合測試),依據的是多因素組合測試可以生成測試用例集,以覆蓋任意N個因素的所有取值組合,在理論上可以發現由N個因素共同作用引發的缺陷。簡單的理解就是每一個參數的每一個值只需要和其他參數至少配對一次就夠了。

 

pairwise算法

Pairwise是L. L. Thurstone(29 May1887 – 30 September 1955)在1927年首先提出來的。他是美國的一位心理統計學家。Pairwise也正是基於數學統計和對傳統的正交分析法進行優化后得到的產物。

 

Pairwise基於如下2個假設:

1)每一個維度都是正交的,即每一個維度互相都沒有交集。

2)根據數學統計分析,73%的缺陷(單因子是35%,雙因子是38%)是由單因子或2個因子相互作用產生的。19%的缺陷是由3個因子相互作用產生的。因此,pairwise基於覆蓋所有2因子的交互作用產生的用例集合性價比最高而產生的。

 

那么我們選擇比較好的測試組合的原則就是:

 每個因子的水平值都能被測試到;

 任意兩個因子的各個水平值組合都能被測試到,這就叫配對測試法。

 

 

《微軟的軟件測試之道》,里面也有關於組合測試的介紹,書中建議組合分析從兩因素組合測試開始,逐漸提高組合維度,直至6因素組合測試,因為有研究表明6因素組合測試可以發現絕大多數的程序缺陷。

可以使用工具完成:PICT

The Pairwise Independent Combinatorial Testing tool 

https://github.com/Microsoft/pict

 

二)、正交實驗設計法

正交試驗法,就是從大量的試驗點中挑選出適量的,有代表性的點,合理的安排試驗。也是組合測試法的一種。

 

評價:這種方法對於軟件行業,太不靠譜了,一個接口生成后的用例太TM的少了,還要認為去排查看要加上那些參數組合,太雞肋了

 

可以使用工具完成,常用的工具有:Allpairs(有點像PICT工具使用,dos命令下運行)和ACTS。

Allpairs下載:www.satisfice.com/tools.shtml

 

三)、兩種方法的總結:

說了那么多,其實首選就是組合分析法來組合parameter,生成測試用例,這樣測試用例數量和質量比正交法都TM高的多,具體高多少,待我做下實驗,后文再講啦。(人家是人啦,不可能一直研究技術,生活這么美好,技術那里有家人好呢)

 

三、response判斷

執行用例有了,那如何對用例結果判斷呢?要實現自動化做好的解決辦法,就是規范用例的response判斷,什么場景用什么狀態碼,響應內容去哪個值可以做到對結果的校驗,這些肯定要后端寫清楚,難道要讓我們看代碼啊,那要后端干什么呢。

總結下接口文檔或者是mockAPI需要規定的東東吧:參數是否可選、參數的類型|長度|特殊字符的response、參數的限制是在哪里(盡量是后端限制參數的所有東西)、是否需要token、response信息(不要只是code,還有具體的那個json值)...

比如:查詢用戶信息,我們除了校驗code,還要對查詢的內容是否正確啊。

 

四、組裝戰車(自動生成用例)

1,從mockAPI或接口文檔,獲取UIL、,參數對應的response(使用if,elif,else判斷語言來進行參數組合返回的response的描述,簡單易懂)

(if賬戶為空,返回A;

elif密碼為空,返回B;

elif密碼為錯誤,返回C;)

2,利用PICT工具,組合參數,這里叫參數對

3,編寫工具:對參數對的結果進行邏輯判斷,映射到response

4,編寫工具:自動對用例進行執行

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM