最近刚开始接口测试，但由于没经验再加上接口文档的不完善，一直进展不起来，有几个问题求大家解惑，谢谢了
问题 1：我们项目有 web 端和 app 端，web 端是后台，app 是产品
app 首页显示文章是由后台控制的，即后台已发布的文章才能才 app 端显示
那么我测 app 首页接口时，应不应该考虑后台，首页接口有个 pagesize 的参数，参数的意思是首页显示的文章数
这个参数应不应该按照后台已发布的文章数量做对比设计用例？还是接口测试用例只需要考虑单个接口返回，不需要考虑逻辑
下面是我的接口测试用例，这样写可以吗
问题 2：基于问题 1，如果一般接口测试只需要测单个接口，那接口自动化一个用例需要考虑多个接口吗？
例如下单，需要考虑购物车，库存，余额这些接口吗？如果不需要考虑逻辑，那接口自动化作为回归有什么意义呢？
求大佬们解惑啊，困扰我很久了，公司就我一个测试，很难受
这种问题我也在纠结，学完了但是想拿公司实际演练一下，发现公司的业务主要依赖定时器工程，真正的核心业务流程全部都是定时任务。然后就是接口关联的，上接口的部分响应数据做下接口的入参数据，如果全部使用 python 中的动态属性去做的话感觉总是差了那么点，但是如果使用 mock 只是为了做接口而做接口的话感觉没有必要，个人感觉核心的业务流程来做自动化回归更重要。不知道有没有大佬有好的答案，期待 ing、、、
当然要考虑逻辑
按道理来说，接口测试是能够 cover 掉你所有的手工测试逻辑的，那为什么不呢？
仅限个人的一些看法，欢迎交流
问题 1：app 和后台是分不开的，如果你要测试 app 接口的话，预设条件就是后台已经初始化好，置于你的首页接口有个 pagesize 的参数，你只要针对 pagesize 进行校验，看 app 接口返回是不是你预期的结果，但这一步也是依赖于你后台已经设置好了文字数量，可以为 0 也可以多篇。
问题 2：看你的目标是什么，是为了实现单接口校验还是为了流程性校验，对于单接口而言，一个接口就应该考虑各种场景，而对于流程性校验而言，只要保证我下单前库存存在，有余额即可，详细的校验可一步步添加
JIMMY
回复
我跟群里的测试讨论了一下，他们说测单个接口，不用考虑逻辑，只需要看返回就可以了。但是 pagesize 的值的设定还是应该根据后台的文章数量进行比对。
第二个问题，涉及到回归，如果接口自动化只是为了单个接口校验，感觉失去了自动化的意义，已经写好的接口基本上不会更改，因此不太能理解。我觉得自动化就是为了回归，新功能加入的时候，有逻辑关系的接口应该都有相对应的改变。
个人愚见， # 问题 2 的情况假如一个业务是由多个接口来实现的，需要对单个接口做接口测试还要多个接口串起来做自动化测试。 比如购买会员或者下单这种业务。
如果是，不考虑逻辑的前提下，那覆盖率能达到多少呢？如果覆盖率足够高也有一定意义
这样业务逻辑上可以通过 UI 自动化补充实现
测试zzZ
回复
单接口的回归有下面这种情况, 是我真实遇到的:
1, 新功能的迭代可能影响老功能 (degrade), 这种时候跑一边单接口可以检验老功能是否降级;
接口测试我个人感觉是既需要单接口测试, 还需要流程测试 (上下文依赖的情况), 结合项目实际情况和人员配比 (你说你们就你一个人, 那么也许你不能有足够的精力维护过多接口) 以及项目实际周期来定夺到底要设计怎么样的接口测试用例, 宗旨我感觉就是尽可能的用现有的资源更大的保证产品质量.
第一，针对问题 1 的接口问题，首先你要确定 APP 请求的接口 response 有什么数据，然后你在看 web 请求的接口 response 又是什么数据，打个比方，如果 APP 接口返回的 response 里有文章的数量节点 number，还有文章的排序节点 sort，那么你一定要校验 web 接口返回的文章数量和排序是否一致做对比；其次你还需要对 APP 接口获取到的内容与 web 端获取到的内容做对比（一般都是存数据库，内容对比意义不大，翻到是 id 对比有意义）。
第二，针对问题 1 的用例设计，首先提示不要用功能用例的设计思维去设计接口用例，你要明白接口测试的核心是什么（最简单是 4 个点：1.接口的格式是什么，2.接口的数据怎么动态，3.接口的业务怎么关联，4.接口的响应怎么验证），如果你用 Excel 这种功能用例方式来维护接口用例，灵活性差不说，维护成本非常高（建议你前期直接用接口工具维护测试用例，利用工具输出测试报告作为留本。后期熟悉了技术上来了再用数据驱动的方式管理用例）。
第三，针对问题 2，接口测试如果仅仅关注单接口的格式和数据验证，那么接口的灵魂就没有了。所谓接口测试，1.是为了在功能测试之前提前规范和消灭 bug，减少功能测试的负担和盲点；2.是作为回归，减少测试人力的同时保证系统每日的稳定运行，同时也在系统出问题是得知问题所在（打个比方，一个系统有很多个接口，如果你的接口脚本每天都在线上定时跑，A 接口报错了，但是用户没有返回，说明暂时没人发现，这个时候你们就可以在用户发现前解决问题）。所以，接口的业务关联性是最重要，这点取决于你对系统的熟知程度来设计业务场景，也能体现出你的测试嗅觉。
综上所述，这都是我的一番废话而已，接口这条路好好走下去吧。
Test44
回复
看过其他测试人员的接口测试用例，好像只是对单个接口做数据验证
一般接口文档比较晚上，包括参数的数据类型，是否必填，以及返回数据都有详细描述，他们的用例就是，输入正常或异常的参数，看是否返回预期结果。
按照这样的话，接口自动化用例是不是要分两类，一种是不考虑逻辑，只跑单个接口。一种是考虑逻辑，即修改上个接口，会对其他接口产生影响的用例，感觉最后还是回到了功能测试的逻辑。
现在接口测试用例写的怎么样了
测试zzZ
回复
我打个比方，单接口的数据验证=高中的英语难度，多接口的业务关联验证=考过 GRE 的英语水平，接口全自动化=你在华尔街工作的英语水平。难度，技术，关注点和认可度，以及对项目的作用，可想而知。
接口是为业务服务的，如果接口最终的闭环回不到业务上，那么这个接口测试就没有了灵魂