最近在做接口测试，可头疼的是接口测试用例一般如何设计？这个问题想了许久，最后设计出来的和功能测试用例差不多了，求大神帮忙指点下。

举例：用如下的接口来设计接口用例？可以写出多少条接口用例呢？

1. 接口地址：/Home/Api/Interface/addPost
2. 接口名称：发帖/回帖
3. 方式：POST
4. 参数： token:登录标识 posts_head：目标帖 id（可以为空，回复时为回复的目标贴的 id） patient_id：版面 id（圈子 id） pid:主贴 id title：标题 cont：内容 img_desc:图片简介数组（需要与图片数组位置对应） img：图片数组 vote_ask：投票问题 vote_type：投票选项类型（1：单选 2：多选） vote_item：投票选项数组 reward：奖励 disease：疾病 id 数组 is_anon:是否匿名 5.返回值：成功：{"status":1,"message":"success"}失败：{"status":0,"message":"parameter token error"}

说下我设计接口用例的方法：我目前只是将参数的内容进行了变更；如果是对 “发帖/回帖” 做功能测试的话，我的做法仍是将参数的内容做下变更；所以请大神指点下，如上的接口例子，要是你们的话，你们会怎么设计这个接口用例呢？迫切期待，谢谢.......

========================================================================================================
通过社区大神们的指点，下面说说我对接口测试和 app 功能测试的认知。

接口测试

参考：https://testerhome.com/topics/4059
http://www.cnblogs.com/puresoul/p/5388586.html

1. 接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

2. 接口测试一般分为上层服务对下层服务的接口调用，服务之间的接口调用以及系统与系统之间的接口调用

   <2.1> 上层服务对下层服务的接口调用：主要是 controller 层提供给 view 层的接口，涉及的是 http 协议接口
   <2.2> 服务层之间的相互调用：主要是 model 层提供给 controller 层的接口
   <2.3> 系统与系统之间的接口调用：如调用第三方登陆、支付接口

3. 接口测试要点：

   <3.1> 检查接口请求是否正确，返回数据的正确性与格式【 比如：数据库的增删改查，当 post 接口操作完成后，通过列表页的接口查看新的数据是否与刚才 post 的数据一致；或者当输出参数有联动性时，需要校验返回两参数的实际结果是否都符合需求】
   <3.2> 检查接口入参的默认值、参数类型、非空校验、以及边界值【 比如：接口有翻页时，页码与页数的异常值测试 】
   <3.3> 检查接口的容错性，如传递数据的类型错误时是否可以处理
   <3.4> 所有功能都需要考虑兼容老版本，列表页的接口需考虑排序值
   <3.5> 检查接口的性能以及安全性
   

4. 接口测试意义：

   <4.1> 确保主要流程和系统稳定性
   <4.2> 将 bug 控制在项目前期阶段
   <4.3> 缩短产品的研发周期
   <4.4> 检查服务器的异常处理能力

   app 功能测试

   
   app 功能测试用例的设计，我看到一个非常有意思的帖子，我搬运一下，目的增强记忆，https://testerhome.com/topics/4664
   Q：有一个移动 app 电影票，现有个活动，能以 20% 的价格买入 1000 张电影票，每人限购 1 张，作为测试负责人如何设计这个测试？

产品特性
关键字：电影票、活动、20%、1000 张、每个人限购一张，那么接下来就从业务来分析这个特性

1. 电影票有选电影院，选座，选场次，选地区等等，那么这个其中的等价类，边界值都是需要去考虑的。场景我们可以认为从 PRD 中都可以获取
2. 活动，既然是一个活动，那么肯定是一个 hybrid 的应用，但是至于哪些 webview，那么活动本身包括怎么上线，怎么下线，就是动态相关的一些功能点也是需要去测的（如：前端是否可以实时刷新，前端提示是否友好，活动时间范围检查）
3. 20%：购买方式（网银、支付宝、微信）是否正常？多少价格的 20%？整数？小数？数据库需要传哪些参数？退款时退款数额是否正确？购买时提交异常数据能否正常处理？
4. 1000 张：1000 张的等价类划分；如何处理并行，N 个人同时付款一张票；如果有允许等待 30min 内付款，那等待付款时这张票能否允许其他人付款？1000 张需要从性能测试角度来做测试了。
5. 每个人：ok，这其实是个很重要的点。我们怎么来定义每个人。app 可能有独立的账户体系，也可能是第三方登录系体系。也可能两种并存，但是无论哪种，是否能够保证我们的应用可以识别每个人是不是就是同一个人呢？
6. 限购：根据什么信息限购，eg 手机号、app 账号？那么我们从几个方面来考虑。重复购买能否成功？买了后退款重新买是否正常;如果有允许等待 30min 内付款，那第一张不付款，购买第二张会怎么样…；能否通过抓包修改参数购买多张？比如混合去买活动＋非活动的票？比如买了退票，再买？比如我看完了，用完了，再买？

移动端特性

1. 功能可以和移动端的本身的特性，比如 home，menu，电话呼叫，闹钟等各种功能结合
2. 兼容性：在不同设备，不同系统版本该 “活动” 的兼容性检查
3. 可靠性：模拟ｍｏｎｋｅｙ测试１００００次检查活动页面的可靠性
4. 弱网测试：不同网络 wifi,3G ,4G 浏览的情况
5. 该活动界面的 CPU,GPU，耗电量，流量消耗检查等
6. 安全性测试：数据注入、篡改（fiddler 抓包，篡改数据后重新发包，看后端的处理）、敏感数据