说实话，第一次接触这类测试，刚开始有些摸不到头脑，确切的说是摸不到重点，无论是测试还是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有交互，都做哪些交互等。
最新内容请见作者的GitHub页：http://qaseven.github.io/