测试 bug 的时候来回切浏览器好麻烦，开发改 bug 来回切浏览器也很麻烦，于是我陷入沉思。。。。设想一种无敌的 bug 可视化工具，让测和改成为一种享受。。。

[renxiangbin]

测试了一天好累 截图、描述、指派、优先级、提交、跟踪、关闭... 改一天 bug 的也很累 看描述，定位，看代码，改掉，指派... 可不可以直接在 web 产品上提 bug 然后登录后就能看到属于自己的 bug 改好后，标记 bug 并指派，好没好直接就看到并解决 等等等...

---

累的都写不出诗一样的感觉了... 洗洗睡。

[fancyistyle]

多屏不就是用来解决这个的么

[zjb861107]

不能只看眼前效率，建议楼主再想想。
其实看起来好像一句话就说清楚的事，为啥还要写那么多步骤，填各种字段。
但是，当你遇到复杂的环境时，就知道这有多么重要了。举几个例子，多地联合开发，多个 feature 并行，有损发布、延迟解决，实在太多太多了…主要还是根据实际情况做取舍。
你要是能保证开发随时可以当面沟通，并且每个问题都能马上解决，极端一点你只记录还没解决和以解决的 bug 数都行。
另外，如果你的字段设置合理、描述清晰，将来是可以做 bug 分析的，对你优化流程、优化用例等等都是有参考价值的

[zjb861107]

我的感觉，目前各大厂如果想控制成本，首选都是裁掉测试，主要还是我们的价值没有在团队中合理体现，还有就是测试工作易学难精。做了几年测试，看着周围的同学在技术方面越来越放松、安于现状，导致的后果就是眼界越来越窄，用不了几年就遇到瓶颈，跨不过去的最后转岗了。

[twor]

可以做一个 火狐插件

[zjb861107]

扯远了，楼主的描述说实话我是有点没看懂得，但是我还想提醒一点，开发一个工具需要开发测试和后期不断的维护，这个成本一点都不小。为了提升测试效率和准确度而开发的工具，然后因为工具的 bug 引发新的问题，这种情况也不少见。

[Zzde]

你这个标题真的长，搞得客户端都出 bug 了

[renxiangbin]

@Zzde @fancyistyle @twor @zjb861107 谢各位 v 友深夜回复。
本来就是想吐槽加抱怨一下
我也是很久以前看到这个东西 https://www.hotjar.com
心里想是不是可以和缺陷管理系统结合一下
我觉得缺陷管理系统一点也不简单
后续的跟踪，分析都是重要的功能 @zjb861107 (你说的对)
只是梦想把这种易用性提高一点

如果测试都喜欢用它提 bug
开发都喜欢用它改 bug
世界真美好

我继续瞎琢磨一下
如果有进展
会给大家分享，哈哈
谢谢各位 v 友

[someclip]

一楼完美解决问题