独立性：每个用例应该是独立的，没有依赖的。需要在一个用例里处理好前置条件，而不是多个用例相互依赖。
可重复：用例测试可重复执行，所以需要注意参数的生成方式。
可持续性：如果代码修改导致已有接口测试执行失败，必须修复代码问题或者测试代码逻辑。
四、接口断言
在设计测试用例时，还需要关注的是针对断言的设计，好的断言能够帮助我们发现问题，没有断言的用例（脚本）就是耍流氓，完全没有意义。
在审核脚本时，会重点关注这个。
从接口层面看，我们至少需要验证两点：
数据结构验证：验证接口返回的数据结构是否与事先定义的一样。调用方在处理数据时，肯定是根据事先定义好的数据结构来解析数据的辅助卡盟，如果数据结构发生变化，那对调用方来说，是灾难性的（契约测试考虑下）。
核心数值的验证：根据业务场景的不同，可以有目的性的验证某些key的值是否与预期的一样，可以结合数据库查询的方式来验证（不同的自动化测试框架有不同的实现方式）。这个就比较依赖测试人员对业务的了解。根据实际情况灵活的设计验证点。
除了以上两点外，还有一些额外的验证点在需要的时候可以进行，如涉及到其它方的数据流转、返回的URL是否可被访问，返回的数据是否真的是必要的（这点很重要，过多的返回会导致很多意外的问题），等等。根据实际情况进行补充。
这样，通过一系列的方法设计出来的接口用例，才会有一定的业务价值，能够真正的帮助到团队，提升测试效率，对于这样的测试脚本，全部PASS的结果才会让人安心。（你能想象没有断言的脚本全部PASS，你还放心的么）
五、脚本的维护
测试用例（脚本）编写完成后，并不意味着接口测试的成完。
在其它的测试环节中，如果发现因为接口问题而产生的BUG（如响应异常、无数据返回等情况），我们需要适当的补充到接口用例中，避免类似的情况再次发生而我们没有验证到。
在积累到一定高质量的用例（脚本）后，可以进一步挖掘这些东西的价值，如转化成线上业务监控的脚本，转换成精准测试的依据等。还有更高端的玩法，是借助混沌测试的思路，独立拉个分支，故意修改一些异常出来，让测试用例验证，能否发现这些BUG，以验证测试用例的有效性。
如果不能发现，那就需要我们去思考如何改进测试脚本（业内已经有类似的平台出现了）。
六、测试数据准备
多聊下测试数据准备的事，这其实是接口测试中很重要的一个环节，想要脚本可以在多个环境中运行，那么测试数据就不能写的太死，需要根据环境去自动获取一些数据值。
公共参数：通过不同作用域及标识的区分，有个专门的文件来处理一些共用数据的存放，例如不同环境下的用户名。
数据集合：通过特定的API或者SQL事先生成所需要的数据，然后放到一个指定的集合（参数或者文件都可以）中，在需要的时候，从这里获取对应的数据值。
数据模板：这个是数据集合的升级版，根据业务数据流，只需要填写一些简单的信息，就可以自动生成一整套的业务数据。
七、总结
如果你要想成功、要想追求所企望的美梦，就千万不可有这样的信念，因为那会扼杀你的潜能，毁掉你的希望。
目标的坚定是性格中最必要的力量源泉之一，也是成功的利器之一。没有它，天才也会在矛盾无定的迷径中徒劳无功。
做任何一件事，都要有始有终，坚持把它做完。不要轻易放弃，如果放弃了，你就永远没有成功的可能。如果出现挫折时，你要反复告诉自己：把这件事坚持做下去。
来源：【九爱网址导航www.fuzhukm.com】 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
