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

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

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

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

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

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

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

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

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

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

写的很中肯，赞~

a 要算两次 a a c d。。。我是这么理解的

测试用例肯定不是需求文档复制粘贴一遍啦，不然为啥会有 正向 反向 异常 临界 错误猜想 五类 case 的说法？测试方向也分很多种啦，业务类测试（金融对这方面要求更高），数据类测试（数据挖掘，数仓对这方面要求更高），技术类测试（高科技互联网，集成电路等对这方面要求更高），用户体验类测试（游戏方向对这方面要求更高），每种类型做到极致都是不容易的。。楼主想成为哪方面的测试？如果找准自己的定位，这 3 个问题就有答案了

额，首先你们搜索的需求是啥样的？产品如何定义的？有没有涉及到分词？特殊符号等？如果没涉及到这些，其实就检查一下接口返回的每一个 data 是否包含搜索条件，分页的位置注意下。
如果需求写的很详细，有规则排序啥的要求，你又知道对应具体的数据库，按照要求写个脚本，取 sql 里的 data 做断言，也是蛮好的。
如果涉及到分词，特殊符号，相似度等，就得结合算法 + 生活经验来做测试案例设计了。。（不过扯远一点，涉及到算法的话，即使有 bug，也可能会有不修的概率了）

1.开发 83 天是怎么算出来的？是否可以分批次提测？如果可以，那测试时间其实也就不是最后 5 天。而是 83+5-第一次提测时间。
2.功能之间的依赖性确定清楚。先做那个后做哪个。大功能先做，小优化后做。如果全局意识好的话，可以减少很多不必要的测试时间。
3.其次就是测试人员之间的配合问题，谁都有自己擅长的部分。
4.测试用例怎么写也是一个学问，一套有说服力的用例，是可以为自己争取到测试时间的。
这是我自己亲身经历的例子。任何事（面子）都是靠自己挣出来的。

以前无意听过一个广告大佬介绍广告，整个广告系统的业务是非常庞大复杂的。面试时遇到这种题，如果你不是专业做过广告投放测试的，还是别回答了，把话题扯回到你熟悉的领域。说个简单的原因，没做这一块的测试，哪里会去考虑广告的精准投放和地域屏蔽的问题？而这只是其中一个业务场景。

我之前也是做证券类测试的，很赞同你说的~而且我一直觉得，这种业务测试要精通，case 要设计的精妙，是需要靠积累的

他也没给出他是用的什么方法考核，他的考核是否公平，无从谈起，我只看到通篇很主观的调调

有些产品经理方面的书 可以看一下 其实这种用户体验上的事情 本身是产品经理需要考虑的事情 他们的书反而描述这种问题比较多~

互联网行业本来就有 35 岁魔咒，如果是 30 岁才开始做测试，做不了几年感觉又得 “失业” 了吧。。。就是尖子塔上的那 10% 以内的测试，他也不好说，自己就一定能一直干到退休。。。经济社会总是追求最佳性价比的。。。而这个性价比还是一个宏观维度去衡量的

其实我一直觉得这个东西很矛盾，如果一开始就给了特别不足的测试时间，那测试的时候，测试人员很可能直接就偷工减料了，反而比较良性循环的做法是：给测试比较足够的测试时间，然后测试自己去规划是不是可以在这个时间内，做出优化。因为这时候人的本能会觉得节约到的时间，是他自己的。可以用来搞学习或者其他。（而这种学习成本的投入，让测试在下一轮测试中做的更好）

我想问个问题，你能看到 bin 目录下的命令 是因为你的机器有被 root 过吗？

测试用例是基础，每个测试都需要先打好基础。。。当打好基础以后，再结合 case 和 bug 的发生规律，会有一些感想，未来的路上，找 bug 的速度会变的相当快~（也就是说，可以做到，几乎知道 bug 在哪里）

我想问一下，什么叫英文工作环境呢？是指的所有的工作软件是英文的？还是说要使用英语描述 bug，交流 bug？