目前正在推进中,只打算做到覆盖率的增量报告展示,用来做测试辅助。 后面的调用链分析和用例关联不打算搞。
web 开发框架吗? 找本教程跟着搭个系统运行起来就差不多了
自觉这个东西不需要完全记住,有个大概的轮廓就可以,然后遇到具体问题百度就行
有两个问题想请教下。
还能上下文关联,有点厉害
不是哦,端口和地址都换过了,还是一样报错。
不过看报错提示是地址占用,如果是端口占用应该会提示占用的进程啥的这些信息。
博主加油,期待尽快开源啊
是的,这种问题的难点,可能就在生产条件的模拟。 不下雨的时候检查,可能没那么有用。 雨天检查,是不是还得考虑雨下多大,积水有多少,踩上去的是个胖子还是瘦子?
如果按照不下雨天的检查结果来保障,那么标准就相当于向上拔高,质量保障没有达到 “刚刚好” 的这个限度,成本会有损失。
同意一楼的回复,
我们这边把回归范围包含两部分,本身修改部分 + 受影响部分。
黑盒测试,确实只能通过需求文档和设计文档评估范围,但这个不太准确,时不时会有遗漏。
目前精准测试还在构建中,调用链路分析没搞定之前,貌似也起不了啥作用。
如果人为去 code diff 代码行,除了对测试人员代码能力要求较高以外,花费的时间估计也不少。
可能折中一下会好一些,还是以黑盒评估为主。在代码提交以后,git diff 获取修改代码的文件,根据文件判断大致涉及功能,然后反馈黑盒,确认是否有测试范围遗漏。 不过这个方法还没实践过,楼主可以参考下
不管啥时候,选择权掌握在自己手上总是没错的,多看看机会,跳出舒适区。说个血的教训, 我去年拿了涨幅接近 70% 的 offer,结果公司说能特批调整下,然后就没走,现在肠子都悔青了。
allure 本身就支持生成报告,最后的结果是 html 格式的。 一般生成报告都是集中存放,然后启动一个 httpserver,然后其他人只要拿到测试报告的地址,可以通过浏览器直接访问测试报告。
报告的地址可以在消息通知的时候推送出去,比如钉钉,企业微信,邮件等。 我们目前就是这么干的,很方便。