最近大大小小的节日 那个不可说的yq，让公众号着实水了至少一个月。这里给大家说声抱歉，虽然本人身体仍未恢复(医生说心肺功能至少需要半年才能恢复到生前80%，身体差主要是之前长期拼命卷导致)，但目前其实自己感觉已经不太耽误写作和授课及答疑等了。
所以咱干了这杯鸡血，然后卷起来，一起迎接金三银四！说到金三银四，现在都2月初了，按照往年的情况推断，今年应该是2月底就开始跳槽热了，所以，公众号最近半个月的任务就是更新一些最新的面试题，当然为保护粉丝隐私，面试题中涉及到的具体敏感信息我会选择打码。（当然如果你需要面试题解析帮助，可以加我v:qingwanjianhua，虽然是免费的，但是面试题会脱敏后充公到 http://woqurefan.cn/interview/ 中哦~ ）
问题一：你之前公司是如何不依靠人力排查就能确保重要的接口都做了自动化的？
回答：这个题哈，我前几天刚在群里听到，第一直觉是套方案的，当然大概率并不是，所以我们就不讨论这个阳谋了，在我另一篇公众号中有专门提到过针对套方案的问题的处理方式。
那我们回到问题本身，确保重要接口都做了自动化的手段其实蛮多的，就算不依靠人力排查，也可以通过接口文档，接口日志，接口测试平台等自动化手段确保，毕竟既然做了接口自动化，那么也要有对应的覆盖率统计功能。这些具体的实现办法是五花八门，简单来说，100个接口里有20个接口是重要的，然后你的自动化脚本跑了几个重要接口难道还不知道么？三两句代码就搞定的东西，值得面试官特意问一下么？所以这道题应该另有深意...
深意就是：这道题的真正难点，不在于统计，而在于前提。确保100个接口中20个重要接口都做了自动化的前提是，你凭什么断定这20个接口是重要接口。也许你会回答，根据二八原则，根据接口是否很底层，根据接口关联的功能点，根据接口是否关系到用户生命财产，根据接口宕机引起后果的严重等等标准去划分是否算是重要接口。那难点就来了，刚刚说的这些，人工去判断很简单，怎么不依靠人工，自动化的去断定哪些接口是重要的，这才是难点，甚至可以说目前没什么好的解决方案，所以我第一直觉是套方案。那你的回答应该是什么呢？你回答的太好太神奇太完美，面试官哪怕觉你说的方案可行有道理，但是也不太相信你确实在之前公司实现过。
所以你最好的回答是一半实现一半计划。相当于给面试官一半真的饼，再画另一半饼才是最安全的回答。方法就是按照刚刚我说的那些标准，自动化的去衡量脚本中的每个接口是否算是重要的。比如检查这个接口在项目源码中文件的位置，被调用的次数，日志中出现的频率，和是否涉及到某些危险模块(用户生命财产支付健康等)。有些代码好实现你就说已经实现，难实现的你就说正在实现。
回答完毕
问题二：如何确保在接口有变化的时候对应的测试及时维护自动化用例
回答：这道题要考察的除了流程还有技术。想达到说接口一有风吹草动，接口自动化就能立马跟上同步，那除了流程一定要正确且严格遵守之外，还要有相当的自动化办公技术来配套。否则每次同步都需要耗费大量的人力时间，那么久而久之，这个流程也就没人遵守了，毕竟人天生都有惰性。而我们测开的意义，就是用技术来对抗惰性。技术的提升，可以把复杂麻烦变成简单。那这道题你要回答就是以下俩个方面了：
1. 流程，接口变化，做出这个决定的可能是产品 也可能是开发和架构他们。而我们测试倒逼接口变化的情况太稀少不算了。
那么我们测试知晓接口变化的上游就是开发同事了，那流程上我们要知晓接口变化的办法有这几种：开发主动通知，接口文档更新，git代码提交。好的流程可以一站式解决上述问题，尽量减少大家的沟通成本。
2. 技术，技术方面要从俩个角度发力，一个是自动发现接口变化，另一个是自动同步接口变化至脚本。发现接口变化，可以监控gitlab，或者用Jenkins主动通知，或者让开发同事一键上报，最好持续集成每次代码库更新都自动跑一遍测试环境接口自动化脚本，发现用例失败则通知测试人员。自动同步接口变化至脚本相对来说难很多，毕竟就算再智能，如果不经过测试人员最后过一次，都是危险和不确定因素。那这个角度的关键就在于能减轻多少同步成本上，比如发现接口文档更新就可以自动解析新参数到旧接口上等技术，这些在我之前讲的接口测试平台早就实现的。还比如接口用例失败后把不认识，缺少的，新增的接口参数或路径同步到旧接口上再跑，再跑不通则通知测试人员手动修正。再比如就是成本转移，让开发同事自己改接口用例，但是用例盖起来太复杂和麻烦，开发同事肯定不乐意。所以要把接口骨架和具体用例分开，让开发同事直接改骨架即可，这算给我们测试减轻了相当大成本。但是这样还是不到位，如果能让接口骨架和接口文档合二为一，统一在一个接口测试平台上，那才是最简单的方案，当然，在我的课程里早已实现。
回答完毕
好，你回答的时候，记得结合自己的实际情况做略微修改，咱公众号和题库的流量还是蛮大的，别都千篇一律的...
