我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第n篇文章，点击查看活动详情
一、测试场景举例
论坛里面创建评论 POST /api/comment/creat
修改评论 POST /api/comment/edit
删除评论 POST /api/comment/delete
查询评论列表 GET /api/comment/{id}
二、接口测试用例设计的一些建议
1>测试用例应该是完整且独立的，每条测试用例都应该可以独立运行；
2>测试用例由测试脚本和测试数据两部分构成：
测试脚本：测试脚本只关注被测的业务功能逻辑，包括前置条件、测试步骤、预期结果等；
测试数据：是对应测试的业务数据；
3>测试数据和测试脚本分离：方便实现数据驱动测试。通过对测试脚本传入一组数据，实现同一业务功能在不同数据逻辑下的测试验证。要注意参数的取值的可用性，不因为时间或数据状态的变化引起脚本不能正常运行，降低脚本维护成本；
4>接口脚本需要一定的自动化校验能力，除请求http状态的判断外，还需要对核心内容的正常性做判断。
三、测试用例设计
如果简单串联的话，设计一条用例就可以将四个接口串联起来验证：
创建-编辑-查询-删除
但是如果某一个接口出了问题，这个脚本就跑不通了，我们需要一一排查是哪个接口的问题，费力耗时。
本着第一个建议，需要测试四个接口，每个接口都要有自己独立的用例，而不建议只设计一条用例。每条用例是完整的且可以独立运行的。
要测试创建接口，那么用例需要是：
创建-查询以验证创建成功-删除以清除测试数据
要测试修改接口，那么用例需要是：
创建->修改->查询以验证修改是否成功-删除以清除测试数据
要测试删除接口，那么用例需要是：
创建->查询以确认创建成功->删除->查询以验证删除成功
本着第二、三、四个建议，测试数据是需要专门为用例设计的，且长期可用。比如创建时，文本是固定还是随机；如果核心是这个文本，那么验证的时候也要用创建时使用的值进行验证。
不同的产品设计，不同的接口设计，不同的使用场景，接口测试用例的设计也不同，上面只是举了一种常规的例子，仍需具体问题具体分析。万变不离其宗，准备好数据，做好断言验证，接口测试就完成了大半。
从测试金字塔来看，接口测试的投入产出比相对是比较高的，相对容易实现自动化持续集成，减少人工回归成本与时间，缩短测试周期，给平台做质量监督。
