精准测试我的理解是针对应用代码的变更，更有针对性的测试变更的地方，那么好处提升测试效率，节省测试资源，测试目的更加明确，减少漏测
在说思路之前简单说一下大概用到的东西
被测系统开发语言:java
容器:tomcat
代码管理工具:git
监控工具:jacoco
一、我们的测试流程是测试人员根据提测任务接收测试任务的
我们有一个质量管理系统，下面是一个简单的测试流程:
- 1.首先开发人员在提测系统上进行构建打包
- 2.构建成功之后，会有一个提测按钮在当前的构建包上，提测版本 A的测试
- 3.开发点击提测之后的会弹出来关联需求,关联本次变更的需求
- 4.测试人员接收到提测任务（接收任务的同时本次变更的代码也也获取到存放在我们的服务器上，接收任务采用 JMQ 异步接收，并且邮件推送给测试人员），并且这次任务是带着测试的应用包和关联的业务需求
- 5.测试人员关联已经写好的测试用例，创建测试用例执行任务与本次提测任务关联上，并且执行
- 6.在质量管理系统部署当前的应用包到测试环境
- 7.测试执行完成，查看覆盖率
- 8.测试通过 Or 重新提测
二、查看覆盖率与监控过程
- 1.在测试人员接收测试任务的同时，会获取当前的变更代码
- 2.在部署应用的过程中，针对应用加入 jacoco 监听器,启动 tomcat 时默认加入 jacoco,并且设置监听端口
- 3.测试人员测试用例执行之后，开始收集 jvm 内存中的代码执行轨迹
- 4.因为已经获取了变更的代码，那么用变更代码与 jvm 代码轨迹进行匹配，我们不需要多余的执行轨迹，只关注本次变更的代码是否覆盖全
- 5.推送测试覆盖率给测试人员
- 6.质量管理系统给已经执行的用例打标记和变更代码关联 (这里测试人员不可见的) 以上几个部分用户是无感知的
三、用例推送，实现执行精准的测试用例
因为上面的提测是第一个版本所以暂时无法做到精确定位，那么现在开发又提测版本 B，到质量管理系统，首先我们会根据变更的代码去查找时候有匹配过的测试用例，如果有匹配上的用例，这个时候主动推送给测试人员，告知他这些变更的代码之前执行过测试用例，可以推荐他是否要对这些用例执行回归
四、大概的图
具体的实现代码没有放上来，有些东西也是公司内部正在用的，主要是给大家提供一种思路，欢迎大家一起讨论
这排版，不想看了。
第二版思路挺好的，但我想确认的一点是，测试的用例应该是仅针对接口一层？接口实现中的算法有没对应的写 case？
—— 来自 TesterHome 官方 安卓客户端
语法用错了，用 - 表示列表比较好。
测试用例如何维护？
如果测试用例是自动化的：开发代码改了，精准推送的测试用例一跑全 fail。测试心想可以报一大堆 bug 了，打开一看都是测试用例没更新导致的 fail。
手工测试用例？用这个辅助手工测试？
手工测试也要了解预期结果才能测。也就是手工测试人员先要拿到对应的需求吧。拿到了对应的需求直接就知道这个需求要用哪些测试用例覆盖了啊。
我们这里执行力太差了
ting
回复
这里指的是手工，测试用例可以和需求关联起来确认覆盖率，但是那是预估的可能不会完全覆盖或者有遗漏在或者开发和测试人员和产品经理的理解都不一致，程序是可以帮助人辨识出来的
我们目前在搞的精准测试方案是这样的：通过分析变更代码的调用路径，找到最上层的触发接口，然后测试对应的接口请求。
但是有个比较扯的疑问，我们把所有测试接口跑一边也花不了多少时间，搞这么精确的意义在哪=。=
taki
回复
hmm .顺眼好多
有几个地方请教下，开发有时候用 svn，多余的空格都会导致 svn 认为代码有修改，这种你们如何判定？因为会有冗余推送。或者是代码删除，配置文件修改等
如果代码间的依赖改变了，例如部分重构，或者引入了外部依赖，如何推送？
另外想问下，推行这个工具，在你们内部，有多大的提升呢，比如漏测，或者覆盖率之类的指标
认为这个更适用于需求变更或修复 bug 的验证，并不太适合新需求第一轮测试使用，疑惑在于每次推送的测试用例是怎么与变更代码关联起来的
虚冰丶夜
回复
.这个主要是监控是在容器运行的时候，比如:web 应用，不是单元测试那种覆盖率，主要应用还是人工的操作，我们大部分系统是以业务为主，这里主要是想办法把业务覆盖率和代码覆盖率结合起来，这个东西确实不是很好做，接口级别的还没考虑进去，如果接口自动化回归测试的话，推送肯定是没有意义的，针对接口级别的，@xubin98246你说的是个不错的方案，我们可以借鉴哈，希望深入探讨
苗
回复
无为
回复
确实存在一定的误差，现在只关注代码变更，对于变更的标准是依托于 svn 或者 git 的源代码，外部依赖是不算在内的，具体的指标还没有，也在实践中，这个东西确实不是很好做，针对误差也在考虑咋解决
taki
回复
如果只为手工不遗漏，那么我又有几个问题：
第一，这个系统怎么判断需不需要加新测试用例来覆盖开发的代码改动。
第二，怎么保证这个系统的分析结果是准确的。当这个系统出现 bug，少推送了一个或几个测试用例时，该系统的用户如何发现。
第三，不管是手工还是自动化，都存在的问题，推送的测试用例版本滞后，无法执行，要先更新测试用例。
第四，用了这个系统之后，回归测试人员仍旧不敢在一个回归测试时只测系统推送的测试用例。因为 bug 可能不是来自代码，还可能来自环境。这个系统能检测这次部署和上次部署之间的环境差异，并告诉我们这个环境差异会导致哪些地方有风险，需要追加那些测试吗？
最后，这个系统打算做好后在什么场景下应用？在开发这个系统时，你们会在你这个系统上应用这个系统吗？也就是说，用你这个系统分析及这个系统的代码改动，并且所对应测试。如果你自己也不用，怎样使别人用？如果你自己也用，能分享下使用体验和效果吗？
思路很好呀，我们也在做这个，也是类似的思路，希望最终达到执行用例的范围能更有依据，更准确。不过目前我们在起步阶段，暂时主要用于手机客户端，主要关注覆盖率，根据覆盖率分析测试是否足够，用例是否可以优化。不过目前还没做到文中第二版直接倒推用例的程度（用例管理相关的系统还没搞起来。。。）。
提测时提供需求和代码层面的内容，执行时关联用例层面的内容，这样需求、代码和用例就连接在一起，很赞呀。
Hi，请教一下，“变更代码与 jvm 代码轨迹进行匹配” 这里是如何实现的？
用 jacoco 监控，然后导出 jvm 的内存执行轨迹和变更的代码的 class 匹配就能生成
测试管理思路非常清晰，赞
如何获取变更的代码呢？获取到变更的代码后是单独取出来进行测试 还是怎样呢？想不太通，如果不单独取出来变更的代码，测试的时候又怎么针对变更的代码进行测试呢？不知道表达清楚了没有，望指教
grily
回复
自行搜索下述命令用法
git log
git show
git diff
此外，github 中有将 git log 转 json 的开源项目，自行搜索
不错，不过代码与用例的关联貌似没关联到单个用例？好像没有拿到每个用例的执行轨迹
看起来 JD 的基础建设做得很好，对测试开发很友好了
“精准测试我的理解是针对应用代码的变更，更有针对性的测试变更的地方”。如果是白盒测试，这种思路是有价值的。如果是黑盒测试，我认为这种思路一开始就不对，黑盒测试要 “精准测试” 的话，针对变更的需求而不该是针对应用代码的变更，更新（新增、删除和修改）需求对应的测试用例并执行用例，就已经是 “精准测试” 了。
Thirty-Thirty
回复
我认为你是无法保证开发代码变更仅仅只包含了需求的变更，代码变更的影响范围仅仅从需求变更去理解是不准确的，这样做的目的是从代码层面分析更好的分析变更的范围，从而帮助测试更好更有效率的执行，也可以帮助开发定位问题，只是这个过程中代码，需求，用例三者能精准的关联起来很难，你说的能结合这样的实践才是最好的