1. API测试要一定要深入了解业务

　　TOPAPI，是对淘宝数据的分装集合，现TOPAPI，已涉及20多条开发产品线，已有近300个API，像个微型的淘宝，这么庞大的业务，连 PD也提供不了详细的需求说明，开发同学也掌握得不完全，通常业务需求需要测试同学们自己来挖掘，但我们莫慌，接到一个任务时，我们首要任务就是仔细分析需求，对于测试工程师来说代码覆盖率远比coding技巧来得重要的多：

　　（1）搞清楚API的应用场景

　　明白API的应用场景，对设计用例非常有帮助。刚入职的同学对这块可能会很模糊，但别怕，我们可以请教该产品线的功能测试同学，可在测试环境中走一下页面上的操作，加强对该业务的理解。

　　且要明确该API的使用对象有哪些？有时对象不一样，API的注意点也有所偏向，如买家、卖家的不同身份对交易类API会有很大的区别。

　　（2）列出该API所有的限制条件

　　限制条件既业务规则，我们也需要根据业务场景来设计用例，使用例设计结构化，其设计思想和设计方法跟功能测试一样，没有太大区别。

　　只是API的业务需要自己挖掘，这对API测试同学的耐心和细心要求程度会更高。

　　（3）逐一分析入参

　　一个任务来时，PD或开发同学已经定好该API的所有入参和返回结果给我们，但我们不要盲目跟从API文档中已列的数据，我们需要把自己的理解融入进去，一一分析每个入参存在的合理性，有时必选参数并不是他们认为的那么必要，可能为可选更合适；可能有些参数是无用参数，可直接删去。

　　如，创建交易的几个API，如果使用对象是卖家，则传入邮费、物流方式、商品价格、优惠金额等都是合理的，但如果使用对象是买家这些值作为入参将是不合理的，这都需要我们从容冷静的分析，相信并坚持自己的想法。

　　（4）抽象出几种对象或方法

　　对于多个入参值的赋值、用例的校验点、数据构造等，这些我们多个用例里都会重复用到的功能，我们可以抽象出几个方法，以供在各用例里调用，这样我们的测试代码看起来会更加简洁易懂，这也方便我们用例扩充，代码也容易维护。

　　（5） 分析数据准备的方式

　　数据准备是接口用例集成回归很重要的一环，现在数据准备一般有2个方法，一是excel文件载入，二是自写方法生成；

　　因随着业务量增多，excel文件变得不易维护，如果我们可以通过调用其它API来生成需要的数据，最好自己写个方法，这样也连带回归了相关联的 API。

　　如，创建交易需要发布一个商品，我们可以在页面上发布一个商品，导成excel表，再在用例里载入；我们也可以直接通过item.add这个API 生成一商品，根据返回的num_id来生成交易。建议采用后者。

　　2. API参数的特殊处理

　　参数有必选、可选 、特殊可选（必选其一）这几种，针对参数本身的特性，我们也要一一设计相关的用例，如用null、””值来校验每个必选参数，如对Number型入参输入 String的值，如特殊可选参数进行组合测试等，这些对API都是必选测试用例，大家勿忘。

　　是否还有其它特别的取值要注意的？欢迎同学们补充~

　　3. 与开发同学的交涉

　　最后说到老生常谈的话题，沟通。

　　沟通无论在哪个行业哪个岗位，都非常重要，到一个新环境时，有摩擦难免。记得我刚加入API测试时，寻问开发同学问题时，也常会得到不耐烦的回答，有时他们也不顾及你新人的身份，讲话内容中包含着很多潜在规则，使你一头雾水，有时会把你推塞到另外一方。

　　如果你也碰到这种境遇，请不要气馁！我们要秉持对事不对人的原则，要以结果为导向，我们一切努力均为了一次次完美的发布。

　　当然，有时我们在面对不同个性的合作伙伴要采取不同的交流方式，但肯定要做的是，在每个需求上先花点时间理清自己的问题，明白自己哪里需要扫盲、哪几点需要确认，带着方案来提问。有时你会发现，很多点其实开发同学也没考虑清楚，到时他会感激你的补充提醒。

　　新人、业务生疏都只是暂时的标签，我们可以通过自身的努力，来证明我们的专业性，像现在开发同学已经习惯向我寻问建议，来跟我确定业务规则，而且偶绝大部分的建议他都会遵循。所以别怕，只要努力，我们都可以！