資料參考： 組合測試設計PK正交設計總結：https://www.testwo.com/blog/6376 組合測試工具集：http://www.pairwise.org/tools.asp 組合測試方法-配對測試實踐：https://www.cnblogs.com/leeboke/p/503589 ...
資料參考：
組合測試設計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，編寫工具：自動對用例進行執行
