像这种对于服务端环境有强依赖的，又没有把代码托管在阿里云的，用这种方案是不是不太可行？感觉本地客户端恐怕也解决不了本地环境负责的问题

嗯，改源码也是个方式，我们也是这么做的，二次分析相对来说更简单容易上手一些

Jacoco 不是有现成的方法和行的统计吗？如果需要统计增量的话，二次分析结果即可

虽然行业很多公司在 996，但是薪资要给到位，入职的时候如果薪资不满意，而你又恰好最看重这一点的话，三思而后行吧

楼主，图都挂了。另外社区支持优酷视频的内嵌哦

这篇文章建议社区同学多多阅读，欢迎留言讨论

学会了读书的方式

最快的话这周

这个很有意思

已经开通，试试吧？

这周也要试玩一下

比我们做的好

楼主排个版吧，密密麻麻很多字

已开通，试一下？

教学习能力，解决问题的能力最关键。

不止是一个图啊

图片挂啦，Q

我们刚刚才把代码覆盖率体系建立起来，对于缺陷覆盖率和需求的度量统计还没有找到科学的计算方式，对于需求和 tag 进行关联，楼主公司做的很严格了，在一些公司，需求如果没有很好的管理系统来制约的话，会有五花八门的提交方式，比如我们就有用 word、excel、在线文档地址、axure、email、IM 聊天软件口述讨论等等，诸如此类的需求来源渠道。个人觉得目前最有效的方式应该是通过代码覆盖率来反推 case，做到增量代码提交没有重大的逻辑遗漏，这个我们是通过 code review 来保障的。另外就是对一些项目做冗余代码清理，这个我们目前收效还可以。

你好，新注册用户建议多逛逛社区发发帖子再申请开通

楼主你这个代码就像单身汉的屋子一样，哪怕乱如麻也能很快找到要找的东西，因为你已经非常熟悉了。但是在多人协作的时候，你这个代码就不忍直视了，一坨一坨的堆积在一起无从落脚。
再说 PO，其实 PO 设计模式是一种指引，而不是枷锁。在指引的帮助下可以很好的帮助我们梳理项目结构，优化层级，让协作更流畅，新人上手更容易，维护起来更方便。但是楼主提到的业务情况也会存在特殊性，比如我们之前也纠结过 “断言要不要放到 test 方法里面”，“业务方法到底拆到什么颗粒度”，元素剥离、数据分离、方法分层到底收益如何度量，这些经历过阵痛的人会理解的更加深刻一些。

老同事的公司，顶一个

大家喜欢的议题排列跟我个人的预期还有些出入

是要评估整个测试部门的绩效，还是想了解测试团队每个人的绩效应该如何考量？
如果是团队的话，建议看看这个帖子：
https://testerhome.com/articles/17888

已经延长有效期

我们直接插耳机