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

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

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

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

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

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

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

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

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

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

听不懂

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

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

无监督学习

以为会了点代码就想淘汰点工? 公司可以没有会代码的测试, 但是一定不能缺少懂业务的点工;
实际上,很多公司里都是业务测试, 没有写工具的测试 一样生存的很好