这个东西确实不是很好搞，也是希望放出来我们的想法，和大家一起讨论

嗯，有 github 一直没用，后续再有东西放到 git 上

CSV 取的，才发现参数化文件少写了一个 Dbmap 变量

是的，才发现参数化文件少写了一个 Dbmap

是的，很多问题存在，各种各样的情况用的环境可能也很苛刻，我们是肯定用的，并没有非要使别人使用，只是说一下思路

vars 是 Jmeter 的内置变量，相当于 map , DbMap 是从测试用例里面拿到的数据库值的预期结果

抽出来模板有些东西也要重写的

用 xsl 也可以弄，我没抽出来模板

对，所以文章开头说了适合单个接口的简单场景，断言复杂的直接在 beanshell 里面加，Jmeter 本身自带的断言也不是很好，预埋数据之类的可以在前面加上前置处理器或者在抽出来个取样器可以做，真正的灵活还是代码，这个适合即来则用

确实存在一定的误差，现在只关注代码变更，对于变更的标准是依托于 svn 或者 git 的源代码，外部依赖是不算在内的，具体的指标还没有，也在实践中，这个东西确实不是很好做，针对误差也在考虑咋解决

@link1220 @miao 这个确实更加适合需求变更和 BUG 验证，我们这的系统确实是需求变更比较做，新的系统只能在覆盖率这块做文章，具体怎么关联，我们提测的时候会给测试 3 个东西:1 变更的需求。2:变更的代码。3:提测的应用包。剩下的就是流程这里，测试用例集的执行针对这次测试，每执行一个用例，我们可以从 jvm 中 Load 内存用于匹配当前的测试用例，这个需要严格按照流程去做，这个是有一定误差的，我们也在想如何减少误差

.这个主要是监控是在容器运行的时候，比如:web 应用，不是单元测试那种覆盖率，主要应用还是人工的操作，我们大部分系统是以业务为主，这里主要是想办法把业务覆盖率和代码覆盖率结合起来，这个东西确实不是很好做，接口级别的还没考虑进去，如果接口自动化回归测试的话，推送肯定是没有意义的，针对接口级别的，@xubin98246你说的是个不错的方案，我们可以借鉴哈，希望深入探讨

执行力确实不太好办

在看看

这个主要是针对手工测试，并没有区分接口或者 UI，我们部门目前算法项目很少，只有最近才会开始一个算法的项目，到时候可以分享

这里指的是手工，测试用例可以和需求关联起来确认覆盖率，但是那是预估的可能不会完全覆盖或者有遗漏在或者开发和测试人员和产品经理的理解都不一致，程序是可以帮助人辨识出来的

本身 dubbo 是一个运行中的应用，难点在于不嵌入研发的代码，还要拦截住请求，并且不能设置代理之类的，netfilx Zuul，做不了吧

${row}是一个变量的引用吧，不能参与计算

—— 来自 TesterHome 官方 安卓客户端

您说了邮件报警，并且截图，所以会不会关注得问你哈，我觉得报警首先没问题，我想问的是报警是否给能排查方向，是大概什么原因引起的，如果某个应用挂了，自己分析出来为什么挂，而不是告诉我应用挂了，单纯的网络、接口不通的当然也是有意义的

#90 楼 @abcdefg 看了贵公司的监控体系还是比较完善啊，不知道贵公司是否到了方法级别的监控，线上出现问题，是否有监控报出是什么原因导致，而不是发个邮件报警截图，比如内存溢出，报警的邮件直接给出是什么原因导致的，另外监控这个事和公司量级也有关系是否值得去做

—— 来自 TesterHome 官方 安卓客户端

你把 gui 和 非 gui 运行 都输出 jtl ,然后在解析两个 Jtl 看有区别没

非 gui 模式下结果是 jtl 吧，上面那个是你自己计算的吗

多试几次，有可能是网络抖动，两次压测要有时间间隔，等系统指标平稳在进行

厉害

哇哈哈