#62 优秀哈哈哈

常规测试点加下新旧版本兼容测试。

我想看广州

挺好的，朝着这个要求努努力~广漂想回老家了

团队用 tapd 的话，可以让大佬去申请个公用授权；个人用的话，用 web 自动化去拿数据吧我感觉..

举个例子吧，我这边的项目。
有个接口是用户提交身份认证，有一次测接口，我发现如果不带 headers 里的登录字段，提交一次认证时，该环境所有注册用户的身份认证都被改变到了。
如果这个问题发生在正式环境，有人恶意调接口去做了，影响面多大.....

当然，这种需要根据项目使用人群去决定要不要做，如果你的项目是面向用户，我认为这个是必须做，没时间另说。很多时候做一些安全等层面的测试不是在防常规用户，是在防一些不常规的用户带来的攻击。ps.内部人员用的接口我都是不单独做接口测试的，前端覆盖到啥就测啥。

不太认可楼上 “只有开发写的所有代码，都被我们用例覆盖了，就几乎没有漏测的情况”，具体不细说。

楼主提到的疑惑，看起来组内是分为了做接口测试和做功能测试两部分，“所以要从功能组的同学那边借资源一块编写，前期给他们培训，然后脚本编写，花了挺多资源的，但是结果好像并没有太大的产出，对于功能的同学而言，该执行的用例还是需要执行，并没有减少他们的工作量，反正增加了许多”，分成接口和功能两部分的情况下，我觉得这样借资源的处理确实是对功能测试同事没有太大益处。
一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景，测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子，一个购买接口，功能测试同事测试点都是能从客户端触发的，余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...
二、接口自动化测试。我觉得这个是用来确认每一次代码修改后新旧接口逻辑正确性的一种方式，并不能帮助前端做什么，毕竟前端也有自己的自动化。
PS.我感觉既然内部已经接口测试&功能测试划分比较开的话，就尽量还是不要让功能测试的同学去支援接口测试吧..除非功能测试的时候接口测试同学也去支援了，不然多少有点心里不平衡鸭。而且如果做接口测试的同事水平已经到达测试开发水准的话，写脚本效率应该大大高于功能测试同事，从个人心态、脚本效率、代码质量几方面考虑，感觉都是让接口测试同事亲力亲为合适点。

总结来说：接口测试 or 前端测试，目的都是为了保障整个产品质量，接口测试的存在是为了让前端测试减少工作量的说法我认为很不靠谱。各有各的意义，不冲突，是协作关系。

点赞

有类似经历，在超过自己的忍受范围后果断选择了跳槽，现在过得比之前好太多，各方面。感觉在这样的环境下工作半年我都会讨厌测试这个岗位。

码了码了，研究一下