JavaCodeCoverage-JaCoCo，爪哇岛上的可可。

第一点，没有接口文档那叫攻击，哈哈。
第二点，在确定你发的请求，地址正确、参数正确、加密算法正确、文件正确、服务在线的前提下。拿着你的证据跟开发先沟通，后提 bug。

Jmeter 3.0 之后的图表改善了很多啊，基本 LR 有的它都有。时间轴都是从开始时间作为零点，这个所有的图表都一样，不会有什么困扰啊。

LR 可以动态调整并发用户数，这个 Jmeter 不好做。而且 Jmeter 分布式测试要配置的东西多，容易出错。没有 LR 那样有个 Controller 管理所有的压力端。

的确是没有必要百分百覆盖，做到七八十就已经很利害了。再上做花得时间成本太高，不划算。我的经验是关键路径、关键函数 100% 覆盖，其他的不作要求，只作数据记录。不过也就是要定个度量的单位，代码行、条件判定、独立路径选一个。不然给出的数据太多，容易分散看报告的人的注意力。

其实，只要先定义好需要收集的覆盖数据，是代码行？条件覆盖？判定覆盖？还是独立路径覆盖？不同语言的覆盖报告也是可以整合来看的。我比较纠结的是一些配置文件的覆盖，像 mybatis 下的 SQL 语句配置 XML 文件，这些不好弄。

同意，抽象成数据驱动最好。

简单实用，我回家也试试。

T4 到 T5 之间，层级真不少啊。按这个做 KPI，每年很有压力啊。这个模型有点全能的意思，对于性能/自动化测试专家有点累。

51testing 现在都这样，要么抄袭。要么丢个文件模板出来，一堆人在那里好，赞，棒，牛……一点讨论和技术含量都没有。

如何保证一个接口的覆盖率

对接口的各个参数，如参数类型,是否必填,参数最最大/小值进行全对偶组合测试，那么一个接口可能就会测试多次

参数比较多的话，可以使用正交表的方法来减少用例数量。

你是需要同时跑起来？还是每台机都同步跑呢？同时跑起来的问题貌似你已经解决了啊。如果需要同步跑，需要看看多进程同步的东东。另外，问一下为什么要同步跑？

优秀的测试人员的确是需要在测试用例设计的基本功上专研的，无论功能测试还是自动化测试。

不过，自动化测试更加需要考虑的是哪些用例自动化的收益是大于投入。就如楼主所说，IE 所有最简单的开启、关闭，以及最基本的每个下拉菜单的打开，这类最最基础的脚本很多人用，属于高频功能，而且实现简单，应该自动化。
需求经常变动，使用频率不高的功能，实现复杂的，不应自动化。

不是选自楼主的书《深入理解 Android 自动化测试》

思路清晰，赞！期待后续内容。

我也点点点了一年。由于偷懒是科技进步的源动力，后来自己研究脚本帮我点，我自己看书。
其实当时写自动化脚本完全没有章法，没用例，没设计，没注释，纯粹为了偷懒。
后来跟科班出身的同学交流，才知道软件工程的东西。再去找测试基础理论的书，系统的书，网络的书，编程的书来看（当时网上资源没那么多）
动手实践，慢慢成长。

不要为了自动化而自动化，monkey 这种随机测试效率没有人工测试来的高。

你的 influxdb 的配置文件里要把 Graphite 项打开。Jmeter 的 Backend Listener 配置如何？

棒棒哒，解决大问题。

#12 楼 @chenhengjie123 story 风格不一致这个问题我也遇到，所以说要先定好一个 feature 编写的规范，界面、页面、动作、查找关键词、分隔符这些都要约定好，不然写粘合代码会吐血。公共的粘合代码也要做封装，减少重复劳动。是挺多东西要先想好，才会有好的效果。

#4 楼 @chenhengjie123 正在推，解决了 story 写得比较模糊的问题。也在探索更好的实践。有人说这份 feature 由测试来写，产品或客户来确认。

谢谢组织者们的辛勤付出，测试思想上大家交流不少，收获不少。

看看人家的地铁，多么空啊。一线城市上下班时间，地铁里能挤上去就不错了。