“精准测试我的理解是针对应用代码的变更，更有针对性的测试变更的地方”。如果是白盒测试，这种思路是有价值的。如果是黑盒测试，我认为这种思路一开始就不对，黑盒测试要 “精准测试” 的话，针对变更的需求而不该是针对应用代码的变更，更新（新增、删除和修改）需求对应的测试用例并执行用例，就已经是 “精准测试” 了。

使用 git 命令便可以获取到 git 变更记录

谢谢你的回复

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

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

我认为你是无法保证开发代码变更仅仅只包含了需求的变更，代码变更的影响范围仅仅从需求变更去理解是不准确的，这样做的目的是从代码层面分析更好的分析变更的范围，从而帮助测试更好更有效率的执行，也可以帮助开发定位问题，只是这个过程中代码，需求，用例三者能精准的关联起来很难，你说的能结合这样的实践才是最好的

这排版，不想看了。

第二版思路挺好的，但我想确认的一点是，测试的用例应该是仅针对接口一层？接口实现中的算法有没对应的写 case？

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

语法用错了，用 - 表示列表比较好。

在看看

测试用例如何维护？

如果测试用例是自动化的：开发代码改了，精准推送的测试用例一跑全 fail。测试心想可以报一大堆 bug 了，打开一看都是测试用例没更新导致的 fail。

手工测试用例？用这个辅助手工测试？
手工测试也要了解预期结果才能测。也就是手工测试人员先要拿到对应的需求吧。拿到了对应的需求直接就知道这个需求要用哪些测试用例覆盖了啊。

我们这里执行力太差了

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

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

执行力确实不太好办

我们目前在搞的精准测试方案是这样的：通过分析变更代码的调用路径，找到最上层的触发接口，然后测试对应的接口请求。

但是有个比较扯的疑问，我们把所有测试接口跑一边也花不了多少时间，搞这么精确的意义在哪=。=

请问下，覆盖率分析过程是自动分析么？然后又是怎么和用例关联的呐？能提供下思路不？多谢。

认为这个更适用于需求变更或修复 bug 的验证，并不太适合新需求第一轮测试使用，疑惑在于每次推送的测试用例是怎么与变更代码关联起来的

hmm .顺眼好多
有几个地方请教下，开发有时候用 svn，多余的空格都会导致 svn 认为代码有修改，这种你们如何判定？因为会有冗余推送。或者是代码删除，配置文件修改等

如果代码间的依赖改变了，例如部分重构，或者引入了外部依赖，如何推送？

另外想问下，推行这个工具，在你们内部，有多大的提升呢，比如漏测，或者覆盖率之类的指标

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

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

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

如果只为手工不遗漏，那么我又有几个问题：
第一，这个系统怎么判断需不需要加新测试用例来覆盖开发的代码改动。
第二，怎么保证这个系统的分析结果是准确的。当这个系统出现 bug，少推送了一个或几个测试用例时，该系统的用户如何发现。
第三，不管是手工还是自动化，都存在的问题，推送的测试用例版本滞后，无法执行，要先更新测试用例。
第四，用了这个系统之后，回归测试人员仍旧不敢在一个回归测试时只测系统推送的测试用例。因为 bug 可能不是来自代码，还可能来自环境。这个系统能检测这次部署和上次部署之间的环境差异，并告诉我们这个环境差异会导致哪些地方有风险，需要追加那些测试吗？

最后，这个系统打算做好后在什么场景下应用？在开发这个系统时，你们会在你这个系统上应用这个系统吗？也就是说，用你这个系统分析及这个系统的代码改动，并且所对应测试。如果你自己也不用，怎样使别人用？如果你自己也用，能分享下使用体验和效果吗？

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

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

思路很好呀，我们也在做这个，也是类似的思路，希望最终达到执行用例的范围能更有依据，更准确。不过目前我们在起步阶段，暂时主要用于手机客户端，主要关注覆盖率，根据覆盖率分析测试是否足够，用例是否可以优化。不过目前还没做到文中第二版直接倒推用例的程度（用例管理相关的系统还没搞起来。。。）。

提测时提供需求和代码层面的内容，执行时关联用例层面的内容，这样需求、代码和用例就连接在一起，很赞呀。

用 jacoco 监控，然后导出 jvm 的内存执行轨迹和变更的代码的 class 匹配就能生成

Hi，请教一下，“变更代码与 jvm 代码轨迹进行匹配” 这里是如何实现的？

自行搜索下述命令用法

git log
git show
git diff

此外，github 中有将 git log 转 json 的开源项目，自行搜索

如何获取变更的代码呢？获取到变更的代码后是单独取出来进行测试 还是怎样呢？想不太通，如果不单独取出来变更的代码，测试的时候又怎么针对变更的代码进行测试呢？不知道表达清楚了没有，望指教

测试管理思路非常清晰，赞