这样的 “真话” 不听也罢，不过是高高在上的风凉话罢了，没有任何卵用。叫不醒装睡的人，真睡着更叫不醒，反而是没睡得看着不舒服

请联系我 微信号：z_oysters

en，你这个说的是接口用例的设计

怎么断言？

他人都注销了，上面个别辩论就来人身攻击的。别人说的是高一些层次的现实问题，现实很不美好，他要求高，但也是事实。这样的人走了，以后也没几个这类人说这类另一层面的真话了。

这位 “大佬” 在他的实名贴里面可不是就事论事的姿态，而是虽然我菜，但是你们更不行，的听我的的姿态。惹了众怒当然很正常了

感觉这几天发生了好多，错过了。。。。

自动遍历系统，自动生成用例，自动执行测试

替这位大佬简介一下吧，南大电子系，中兴多年测试，先后转行安卓开发、算法开发，最近是去某科研院所，不知道做什么。观点不同正常，就事论事。

看业务吧，技术代替性强，业务一时半会难以代替

纯点工还能辉煌多久？这个问题提的不恰当，测试工程师是一大类，不能片面的看待成点工和非点工，咱们不要进入狭隘的讨论范围，这样的问题其实讨论不出意义，不建议去深究讨论

啥时点工辉煌过，你倒是说说看呐，辉煌是什么样子？

接口自动化的最主要的还是接口出入参的变动对用例的影响，以及不同场景的数据的获取。
先把这两点解决了，再去考虑自动这个事。

自动根据手工用例 自动翻译解析成动态临时脚本并自动执行的功能
是不是这个思路不知道，反正听朋友说为了验证这个功能，写了好多条手工用例，由这个功能自动翻译解析成动态临时脚本并自动执行了

我能想到的思路是：
假设 手工用例是写在 jira 上的，你去 轮询 jira，然后 匹配 关键字 ，生成自动化代码
大概是这么个流程吗 ？

之前做了个自动根据手工用例 自动翻译解析成动态临时脚本并自动执行的功能， 之后维护成本很低，那边在改手工用例，这边用大数据 + 智能 + 手工的方式 维护解析匹配模块。 慢慢的解析的越来越准确，脚本开发成本降低到快没有了，而且维护成本 也大幅度降低。

哪有什么最高境界，只要有 kpi 在，就可以无限进化

估计就是那种无代码化, 或者低代码化了吧. 最近才在自己撸代码写了个接口自动化脚本.

听不懂

代码再牛，场景覆盖不全，拿头上线吗，哈哈

点工还是很重要的，可以减员，但不能缺啊

无监督学习