定会议室，开灯，喊人，确认会议结束，关灯。约下一次会议

测试 ld 可以揽问题，毕竟测试要对质量负责的这点责任心要有。但不能全揽在自己头上，测试可以改进，但是问题全甩到测试头上，那以后还怎么搞。其他部门对质量就完全没有一点责任了？测试完全兜底了？
这种问题在我看来，测试就是算有责任也是小责任，可以基于问题做为后续改进的参考。主要责任还是在前期准备，是流程的问题，要罚也罚不到一线测试。如果我是这个测试 ld，要罚就罚 ld 啊，这样大家也会比较信服。

一个业务测试专家对一个公司的价值一定远远大于开发测试工具专家。开发测试工具专家的能力是通用的，而业务测试专家的能力才是这个公司积累的宝贵财富，很难替代的。

先实习比啥都重要，别觉得测试就是这些技术。这些技术说实话都是死的，对毕业生来说最重要的是测试思维，很多应届生没接触过测试，觉得测试就是找 bug，但是对一个新人更多的要求是测试思维的逻辑性。你连测试点都梳理不清楚，会那些都没用。所以先去找家公司实习起来，有了测试的感觉，这才是拉开和其他毕业生的方法

没有业务能力的测试开发，只是一个支撑角色，它的价值在于业务测试团队的认可。
我之前在的大厂，业务测试人员的价值就是要大于纯测试开发的，绩效也是偏向于业务测试人员。因为团队可以没有测试开发，但是不能没有业务测试。
作为测试前三年你可以关注技术，但是至少你工作 3 年以后，你不管做什么你都要开始沉淀业务，足够的业务深度才能体现你的价值

从我个人经历这么多不同的公司来看，说实话没什么测试开发做的事情开发是不能做的，就算要学习，开发的学习成本也比测试低很多。真的如果开发技术很强的测开，没有公司不会考虑把他放到开发位置这样可以发挥更大的作用。
所以测试开发如果只是纯工具开发，其实和测试真没啥关系，就是工具开发。测试开发如果自己都不接触业务测试，真的没必要挂着测试的名头

测试提供自测用例，明显自测用例可以覆盖但是遗漏到测试环节的 bug，标记为自测型 bug。拿自测型 bug 作为开发提测的绩效考核指标

讨论团队学习的问题就像讨论教育一下，教育的本质是为了社会的人员分层，其实团队学习也是。你不能指望你组织团队学习每个人都会很认真的去执行，都提升很大，毕竟这些不是本职工作，但是如果你通过这种方式可以激发几个同学找到学习的方向，激发他的自驱力去学习就已经够了。更重要的是你可以通过这样的方式可以筛选出团队中真正更有发展潜力的同学是哪些，更好的对团队进行分层。
当然不是说不学习的同学不行要淘汰，毕竟团队中总有一些脏活累活需要没那么优秀的同学去做。

coding 测试脚本和开发自动化框架根本不是一回事，说实话，如果一个业务测试人员了解测试模块的系统架构，数据链路，看得懂开发的代码。我觉得他比不接触业务只会 coding 自动化脚本的人强多了。换句话说测试是用来找 bug 的，如何高效和高质量的找 bug 需要你对你测试的产品内部实现有深入的理解，而只会 coding 测试脚本的测试价值有那么大吗？

好的，多谢了

又是一个伪命题，开发能干一辈子吗？产品能干一辈子吗？运维能干一辈子吗？在中国 it 行业从来不愁没新人进入，所以其中的大部分人都干不了一辈子。

以下纯属个人理解啊，其实我看到的趋势，目前国外很多公司都在去测试化或者追求高测开比，因为大部分自动化测试或者测开的工作开发都能做，而且也能做的很好。包括现在 devops 讲究的也是开发可以贯穿测试、运维的工作。
而越来越稀缺的传统测试人员本身的价值就在于如何做专业的测试，就是探索性测试、性能测试、安全测试这些。

不针对楼主啊，只是感叹一下，自动化测试成神也就是成为一个开发，那为什么不一开始就做开发呢。事实上大公司那些大型的内部效能平台最后都是有开发人员来实现的，因为测试开发的确和真正的开发人员能力上还是有差别的。我只是想说如果想做测试，是不是重点还是放在测试的角度（毕竟这才是测试不可替代的能力），开发只是辅助，当然有开发能力是必须的，但是别走偏了，脱离业务脱离测试设计本身只讲究开发技术真的没什么价值。

有没有前途是基于你个人的发展规划和个人的能力，和你说的年纪、月薪、岗位没有必然关系，所以不知道你想问啥？

关键要看你希望通过自动化去解决什么问题，如果是提升质量或者提升测试覆盖面，老实说是有很多解决方案。在你看来觉得自动化是测试的一个方向，但是对老板来说它不关心测试的发展方向，只想要最佳解决方案而已。

关键还是看人，没上进心就算是正式员工成长也未必比外包快。以前在大厂的时候我下面外包也有大连理工、重邮这些好学校出来的人，他们工作很认真也很有上进心，虽然没有怎么管他们，但是他们成长一点都不比正式员工差。虽然内部转正很难，但是他们很快就跳到了其他大厂，说到底还是有能力。当然有更多是混日子的，外包工作有时候就和工厂工人很像，给活就干，没活就闲着，想混日子也很容易，关键还是看个人。

哈哈，大家是不是想的有点多了，一般测试妹子都是找开发小哥哥比较多啊

测试的目的是验证质量（验证产品实现满足需求），接口自动化目的是提升效率（基于接口层面实现脱离手工的方式高效执行测试）。所以测试接口做自动化的目的是通过高效的手段实现对产品质量的验证。

为啥觉得功能测试天花板低呢，因为你只考虑操作，点点点而已。从开发层面，数据流向都清楚吗，系统架构了解吗？从产品层面，需求理解的够深吗？这些都是业务测试提升的地方。相反我觉得自动化测试要求才低，懂一个框架或者工具，每天按照模板写最基础的代码逻辑，自动化用例往往也不会做复杂测试设计。很多人觉得做自动化有意思是因为测试没接触过代码，觉得写代码更有成就感，但是做好的测试设计才是测试的灵魂。不管你做自动化测试还是测试开发作为测试的本质都是提高产品的质量和效率，如果你脱离的业务和系统，你只是一个工具外包人员，充其量为低级开发，对团队的价值还不如一个经验丰富的业务测试人员。
以上为个人见解。

接触过不少产品人员，有厉害的也有不厉害的，但是普遍感觉产品人员的平均素质和能力还是要高于测试人员的。当然其实很多测试人员会吐槽产品的需求写的怎么烂，逻辑不严谨。但是当测试人员看到一个需求的时候其实是 1 到 n 的过程，而产品去设计这个需求是 0 到 1 的过程，两者难度还是有差别的。所以我从来不会因为产品需求有漏洞而去吐槽产品能力差，因为假如换做我去从零开始设计，也未必能做的更好。

可以

敏捷测试中，我们更多的是关注每个迭代的变更代码的覆盖率，也就是每次代码提交后，对这块改动代码是否覆盖，至于没有改动的代码，我们可以通过每次自动化去回归保证覆盖率。关于变更代码覆盖率你可以看下我的这篇文章：https://testerhome.com/topics/19077

你是每次拉覆盖率 exec 文件的时候，把之前的覆盖率文件删掉了吧。因为 jacoco-agent 是注入在服务中的，当你服务提交新代码发布重启后，注入的 jacoco-agent 也会重启，之前统计的覆盖率也会被清掉。所以你要每次拉取新的覆盖率后和之前覆盖率结果进行 merge，做增量记录

把测试的工作扔给开发，让开发做充分的单元测试和自测，你想把测试变成 0 也行。所以说测开比多高，关键看这个公司对开发做测试的态度，顺便说下，特别像一些走敏捷流程的互联网公司，理论上测试的活开发都能做，只是他们懒得去做而已。