【SIP】OPEN API測試用例之正交驗證法

  我在上篇關于OPEN API測試用例編寫方法中寫到，由于OPEN API是相對于設計層面的測試，是以測試用例的編寫方法是多種多樣的，此所謂不管黑貓白貓能抓老鼠就是好貓。本次在SIP5.4的測試中更是印證了這個道理。在SIP5.4的測試中我采用了正交試驗法。

    原始需求如下：SIP對使用者通路的權限做了新的定義。對ISV的應用（APP）做了等級劃分。規定了屬于某個等級（APP_LEVEL）的應用隻能通路這個等級管轄的API群,而且受該APP_LEVEL的通路頻度限制。

    新增概念：

    API群：指由ISP提供的所有服務+需要單獨增添的服務-ISP服務中不可以通路的服務

    需求分析。

    從原始需求中，我們可以提煉出原始需求其實分為兩個部分的内容。

1.     應用對API的通路是否被APP_LEVEL授權的機制。

2.     授權的應用是否被頻度控制正确的控制。

再來分析授權機制的影響因素，主要有以下幾點

1.     由于主要是通過APP_LEVEL中包含API群的情況來限制對某個API的通路權限。

是以群的因素（A群的個數，B是否在群中）影響測試的結果。

2.     由API群本身組成的機制，又可以得出實際上通路授權機制還受以下的因素影響

C. ISP提供的所有服務(ISPS);D.需要單獨添增的服務(INCLUDE_APINAMES);F. 需求排除的服務(EXCLUDE_APINAMES)

我們再深入分析，發現測試的步驟其實都非常簡單，不影響測試的結果。也就是說測試結果隻和測試的前置條件A,B,C,D,E,F相關。而且條件直接的組合可以産生很多種結果。為此我們想到了正交驗證分析法（方法本身的定義詳見轉載），實戰隻是采用了它的思想并未完全遵循理論。實際測試用例中把第一點和第二點也分開了測試。實戰測試用例如下。

授權測試用例1

授權檢查測試用例2

  由于SIP的頻度控制，之前就有機制。是以必須測試和之前機制的相容性。這裡先介紹一下本次APP_LEVEL對API通路頻度的控制和之前的頻度控制的關系。如下：應用定制API頻率（SIP_CUSTOM_CONFIG本次新增）優先于 API設定頻率 （SIP_API原有需求）優先于 預設應用級别頻率 （SIP_APP_LEVEL本次新增）優先于 系統預設頻率（配置檔案原有需求）。

 在文章的結尾，感謝一下我們公司的文初同學對本次測試用例的建議和對測試工作一貫的支援！

本文轉自elbertchen 51CTO部落格，原文連結：http://blog.51cto.com/linkyou/282654，如需轉載請自行聯系原作者