累加上次版本：版本 n 未覆盖行，查询版本 n-1，若存在并已覆盖，判断 last diff 是否存在，不存在则设置该行已覆盖，其它则未覆盖； 存在两次遍历，计算比较耗时；

在行级别合并，还是会有些问题
比如本次覆盖率有这条数据

<line nr="69" mi="3" ci="7" mb="4" cb="2" />

这行是覆盖了的
看你的实现逻辑，这行直接就取本次的数据了是吧？
但是其中有些指令和分支是 missed
按理说还是应该合并上次的该行数据

但是如果想累加上次的行数据
又没法实现
比如上次相同行数据

<line nr="69" mi="7" ci="3" mb="2" cb="4" />

并不能简单的累加，因为你没法知道两次 covered 的数值是不是相同的指令或分支

所以我理解是，只能累加出基于行数据的覆盖率数据（行、方法、类）
基于指令的（指令、分支、圈复杂度）起码从 xml 中是没法准确实现的
不过我们最后看报告，实际看的又是基于代码行的
只不过指令、分支、圈复杂度这几个覆盖率数值是不准确的而已

还真是，之前就看了头部的几十行。。。
多谢哈

但是 xml report 是没有源码行数据的吧
只是方法 a 的各种覆盖率数值是多少

比如版本 1 的方法 a 覆盖了 3 行
版本 2 的方法 a 覆盖了 2 行
你怎么做合并呢

那就只能做到方法级别是否覆盖了吧
没法做到源码代码行级别的展现

我们也在做，最后发现也只能这样了

累加上次版本：版本 n 未覆盖行，查询版本 n-1，若存在并已覆盖，判断 last diff 是否存在，不存在则设置该行已覆盖，其它则未覆盖； 存在两次遍历，计算比较耗时

这块你们是如何实现呢，是解析两个版本的 html report 自己计算？
还是解析 ec 二进制文件？

看起来 JD 的基础建设做得很好，对测试开发很友好了

不错，不过代码与用例的关联貌似没关联到单个用例？好像没有拿到每个用例的执行轨迹

顶米老板

这个帖子是论坛上关于接口测试最有深度的

谢谢！华为手机，改后缀名后直接就能安装了，抓包可用。

挺好的，期待完结

看了大家的回复，我会再写一篇 mock server 实现的
其实技术上觉得没什么好写的，只要是搞清楚了整个逻辑就能做出来

原来老大去美团了，有机会去学习学习

#36 楼 @seveniruby 思寒去哪里高就啦

确实，有些 ppt 基本就是个大纲。。。
希望能有视频放出

非常感谢！

关于《一站式网站前端性能测试与 go 服务端接口性能测试》里的一张图
表示疑问

locust 的 tps 怎么会这么低？
并发 10 的时候怎么可能差距这么大呢？
很奇怪啊，虽然 go 的性能最好是一定的，但也应该是高并发才体现优势啊
谁能解释一下么

楼主加油，期待新的系列

这个职位的自由度会比较大
需要有自己想法的人

好文，实在硬货！

#10 楼 @ycwdaaaa 赞！对于个人来说，只要学到新知识了就是进步，都会让以后的职业选择有更大优势。不过对于这个领域的 qa，还是任重道远哈哈。希望有机会能具体讲讲，给我们科普科普

这个领域对于 qa 来说确实是个困难
大家在摸索，是否能摸索出一条道路还不一定

因为核心就是算法
正如你所说，对 qa 要求太高
真有那能力的也就不做 qa 了
至少我肯定是

它更接近科研领域
一个好的科学理论或者假设，需要实验来验证
对科普有了解的就知道
做科学实验的那些人同样是该领域的科学家，也许同样牛逼闪闪
这样才能运用各种原理，设计出极其巧妙的实验

我几个月前面过类似的公司
face++，算是发展非常好的新兴公司了
几轮面试聊得非常好，最后没有去
他们的测试现状也是这样
测试还只能围绕核心的外围做事情（训练数据等）

以 bug 来考核比较扯淡，这应该是大家的共识（最起码是战斗在一线的 tester）

单纯的以结果来考核，如线上 bug 数等，也不会公平
有的团队的产品活跃用户过亿，有的才百万级别
你用绝对数量来对比，显然有失公平

非常认可 @seveniruby 的观点
对测试的考核应该是多个维度的
而且这些数据不应该是死板的，也不是孤立存在的

#9 楼 @seveniruby

非常深刻！

写的很真实！每个测试团队里的核心人员都是具备 lz 这样品质的。