看了最近的 mtsc，好像大家分享的集中方向在用例生成和 app 测试执行方面偏多。
我们稍微有点国企背景，最近领导兴致来了，大手一挥： 那个谁谁谁，你去调研看看，别人都是咋生成的用例，用啥模型，用什么开源软件，多久能搞定。。。
然后我.... 好的领导....

目前正在推进中，只打算做到覆盖率的增量报告展示，用来做测试辅助。 后面的调用链分析和用例关联不打算搞。

web 开发框架吗？ 找本教程跟着搭个系统运行起来就差不多了
自觉这个东西不需要完全记住，有个大概的轮廓就可以，然后遇到具体问题百度就行

有两个问题想请教下。

1. 能不能直接解析源码，如果可以的话，还省却了编译 class 文件这一步
2. 如果方法的请求参数定义在依赖的其他工程里面，能不能解析出来。

还能上下文关联，有点厉害

不是哦，端口和地址都换过了，还是一样报错。
不过看报错提示是地址占用，如果是端口占用应该会提示占用的进程啥的这些信息。

博主加油，期待尽快开源啊

是的，这种问题的难点，可能就在生产条件的模拟。 不下雨的时候检查，可能没那么有用。 雨天检查，是不是还得考虑雨下多大，积水有多少，踩上去的是个胖子还是瘦子？
如果按照不下雨天的检查结果来保障，那么标准就相当于向上拔高，质量保障没有达到 “刚刚好” 的这个限度，成本会有损失。

同意一楼的回复，
我们这边把回归范围包含两部分，本身修改部分 + 受影响部分。

黑盒测试，确实只能通过需求文档和设计文档评估范围，但这个不太准确，时不时会有遗漏。

目前精准测试还在构建中，调用链路分析没搞定之前，貌似也起不了啥作用。

如果人为去 code diff 代码行，除了对测试人员代码能力要求较高以外，花费的时间估计也不少。
可能折中一下会好一些，还是以黑盒评估为主。在代码提交以后，git diff 获取修改代码的文件，根据文件判断大致涉及功能，然后反馈黑盒，确认是否有测试范围遗漏。 不过这个方法还没实践过，楼主可以参考下

不管啥时候，选择权掌握在自己手上总是没错的，多看看机会，跳出舒适区。说个血的教训， 我去年拿了涨幅接近 70% 的 offer，结果公司说能特批调整下，然后就没走，现在肠子都悔青了。