#62 优秀哈哈哈

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

我想看广州

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

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

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

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

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

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

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

点赞

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

码了码了，研究一下

看起来你现在的测试方法是黑盒且偏用户角度。
换做是我的话，整体思路可能是：了解技术实现，从每一部分的技术实现去分析测试点
另外，如果开发有找出一些你没发现的测试点，可以深入咨询下 bug 详情，了解 bug 产生原因，分析复现手法，复盘为什么自己没有发现，然后往自己脑子里的测试池添加内容。
我觉得是先有思路，再结合复盘提高自己的测试质量。

2021 年了~坐等大佬更新~

我也好奇这个问题很久了。如果每个接口单独的功能都是正常的，是不是能认为一套流程下去相关的接口一定没问题？

涨知识了

关注一波，我这边写脚本的时候也是遇到类似问题。
我需要用到的参数在 conftest 里，但是在调试中发现 pytest.mark.run 会在 conftest 之前运行，导致无法拿到我需要的参数。

我这边列出来的主要是 web 侧，服务端的应该就是另一个故事了

试试 pipenv 叭

这个可以有

极客是美国俚语 Geek 音标 [ɡiːk] 的音译。随着互联网文化的兴起，这个词含有智力超群和努力的意思，又被用于形容对计算机和网络技术有狂热兴趣并投入大量时间钻研的人。≈ 加班就完事！

我只想等帖子更新

我是来找高分答案的，中奖答案不会公布咩

盲猜会有 ApiPost 的同学过来

至尊欧皇.............................我慕了

我平时就验证 method，url 不验证。
我想问，如果接口文档写了该接口需要使用 post 方法，你会去测 get 时的表现吗？我会去测是担心 get 或者其他请求 method 下系统出现一些异常情况。

“输入当时报名 “MTSC 2020 深圳站” 使用的手机号”
白嫖视频希望破灭