說實話，第一次接觸這類
測試，剛開始有些摸不到頭腦，確切的說是摸不到重點，無論是測試還是TC，都讓我很頭疼，后來慢慢的，我就領悟到了這類測試的方法以及技巧，后來覺得真的很簡單，并不像當初想的那么不容易。
首先明確哪些是需要測試的API
研發的代碼中可能實現了很多API，首先必須明確哪些需要測，哪些不必要測；哪些整個迭代不測，下一個迭代再測；有一些接口是可能就直接調用另外一個接口，這些接口有沒有必要測等。這些沒有確定清楚直接導致漏測或者做無用功。
明確每個API實現的功能和設計TC
在確定了哪些接口需要測試之后，就必須明確每個接口實現的功能以及接口的參數、返回值的意義等。理解這些接口參數的含義，這些參數僵尸設計TC的維度，簡單的說，這些參數可以看成一個一個輸入框，李四網頁手工測試一樣，將準備數據輸入即可。用黑盒的方法來為API設計TC和網頁手工測試很類似，無非就是把參數看成輸入框而已。但是
API測試在設計TC的時候還可以'偏白'一點，就是直接去看接口的實現的代碼，特別是一些異常情況的處理，一般程序在異常處理上總是相對于正常情況要脆弱一些，然后對前面用黑盒的方法設計好的TC進行一些補充。
值得注意的是，1）TC設計的時候盡量詳細，粒度盡量的小，測試代碼都是類似的，可能僅僅是傳入的參數不一樣，而測試校驗的
工作是計算機做的，所以一般情況下針對某個接口，10個TC和20個TC跑的花費是差不多的，但是測試粒度方面和代碼覆蓋率方面可能就增加了不少。2）TC也是要進行維護的，在測試執行階段，如果發現需要補充TC，最好不要在現有的測試代碼上改，要新加代碼，同時在TC文檔中也同步更新。如果是TC的缺陷，才去修改對應的代碼，并在TC文檔中做更新。3）在設計TC文檔的時候，測試步驟的粒度最好能夠細到每一步需要調用哪個函數或接口，有點類似偽代碼的風格，這樣在寫代碼的時候就不用怎么思考，僅僅去實現它。
我們做這類測試，是直接拿應用程序在本地開啟service，首先你在啟動service之前，要配置好
web.config文件，這個很重要，包括你測試所需要的
數據庫名字以及相應API測試所需要的特殊配置。我們這里主要配置和外部有交互的一些service地址，以及一些數字電視產品的ID等信息。
API測試除了要測試功能以外還要測試接口。一個API或者函數可以作為一個單元，對這個單元進行
單元測試，可以用黑盒也可以用白盒方法。黑盒方法就是不去看這個單元的實現代碼，只根據中廣核單元的功能說明來設計
測試用例并進行測試。測試的時候可能需要寫一些簡單的代碼來做數據準備，然胡去調用需要測試的接口，一般也需要寫一些代碼來接受或者驗證被測單元的輸出是否正確；
白盒測試方法就是同構分心被測單元的實現代碼，根據不同的測試策略來設計測試用例并作相應的測試。平臺產品的需求很多事來自網站，簡而言之，平臺產品提供API給網站研發使用。我們需要測的就是那些暴漏出來的API，確保這些API在功能上沒有缺陷。
我在做API測試的時候，主要采用的是
黑盒測試方法，用Fiddler工具去調接口，這個方便又明了，很容易看出被測單元的輸出是否正確。不過事先你需要明確的了解需求，以及整個系統的架構，需要了解都和哪些service有交互，都做哪些交互等。