先讲结论
修bug还要看影响程度 impact/severity
闪退是很严重的问题。 相当于app crash
除非你有权力决定/并扛结果，否则就是看上层要不要修。
或者能说服上层不修
闪退就算是1% 也算严重。
==> 不能假设只有1%的人会遇到，而是假设使用者用100次就会遇到的话，
几乎所有使用者用久一点都有机会遇到
实务上，如果只有出现一两次，而且经过特定时间的追查(例如几天)
经过讨论同意，有可能把case放入观察名单暂不处理。把时间拿去处理其他事情。
也有遇过后期修bug，发现一次把前面几个怀疑的bug close，
因为问题出现时的表现形态不同，导致之前开了几个不同的bug tracking。
举例：当进入某个状态时，A、B、C各自会有不同状况的错误，而开了3个bug。
题外话，机率是个模糊的定义。
Bug触发机率不明，是因为没有找到原因。机制找到就是100%
举例：
某个bug只要符合ABC三个条件 100%发生。
但是平均每100个人，只有一人会操作到发生此问题。
请问此时机率该是 100% 或者 1% ?
这时判断的重点反而是impact。
※ 引述《freebug (Freebug)》之铭言：
: 最近开发一个通讯软件
: 有个闪退的bug自从上周被发现到之后就再也没被观察到
: 也就是这个bug的出现没有规律性，只能靠碰运气
: 出现机率也不高 (出现机率不到10%)
: 这也是我对这个bug感到烦恼的地方
: 如果各位遇到这样性质的bug
: 你会怎么去处理?
: 会去尽可能的钻研，并且制造出这bug出现的可能吗
: 还是会选择直接忽略?