我觉得楼主只是想表达说法方式可以改变对方的工作态度~有些测试确实很厉害，但和开发"互怼"搞得工作关系很紧绷 (对方觉得你在 “怼 “他)。。。~尤其是对于一个新入职的测试，能使用一套双方能接受的沟通手段做敲门砖，只要测试技术确实过硬，做了一段时间，开发也会觉得测试很厉害，开始尊重测试的意见了。

继续追问细节呀~难道业务测试不可以追求技术么？一个懂业务又懂技术的测试，多棒呀~

我觉得前后端分离测试，应该指的是后端开发和测试先行，后端交付之后，前端根据后端的稳定版本，进行开发和测试。前端测试可以使用 mock，来模拟各种异常场景，也可以直接对接后端稳定版本来进行测试。
如果前端仅根据接口协议使用 mock 调试/改包的策略，做界面上的测试，确实会存在几个问题。1。后端最终交付接口实现和约定不一致。2.前端入参传错了，访问 mock 正常，但访问实际服务是不正常的。3.因为使用假数据，一些交互问题引起后端的异常可能忽略掉了。
（前后端联调测试确实是很重要的环节）

我以前也是顶着测开头衔做测试，想出去找工作，猎头给推的都是测开，而且因为我曾经是测开，给推的都是资深测开的工作（我理解的测开应该是写测试平台类的，实际和开发没区别），以至于达不到预期。个人觉得实事求是一点确实好，所以挺赞同楼主观点的，可以找到心仪的工作，从此也没有了因为这个测开 title 和面试官解释半天的尴尬。

对于经常重构的开发团队来说，我觉得自动化回归的 case 真的很有用。。。

这个得你自己想了，每个领域都有自己的特色，你得扎到你自己的业务里面去做这方面的思考的。别人给你的都是很空洞的建议。

怎么用更少的 case 验出更多的问题

你单独在 dos 命令行里执行（不通过 jenkins）估计也会报这个错吧。。。你可以先检查一下 你的全局变量配置是否按照 python 的要求都做好了？

无意闯入，看着 edit_text 是一个 listView。。。是个列表，9 是列表的第三个 object。。。但你代码里面没取这个 index=3 的元素。。。你瞅瞅你的图，里面也有一个 index=3 的

督促开发删除冗余代码 + 精简代码 + 完善测试用例（尤其是条件覆盖之类的是否完全）是我们目前引入覆盖率测试看来下比较好的地方吧，当发现开发写了 “废话” 的时候，以覆盖率为由，让他改。当然了这种针对是否满足业务需求，没啥用。