[FZH] 被Abiword 坑了一下

[Felix Yan]

On Monday, May 05, 2014 12:11:31 Szopen Xiao wrote:
> 先抛开我没有提交BUG问题来说，软件部分测试工作，有没有可能由发行版出版商或者打包人来完成呢，特别是对于那些小型项目来说。还是测试了但是无法达到产品质量
> 控制标准？

其实已经有很多 Bug 是这样完成的了. 但是你也应该明白, 一个复杂到 Abiword 这样的软件, 如果没有那种需要跑较长时间的集成测试, 几乎是没什么
办法测到所有功能的 (这种测试写起来费时费力, 所以我遇到的开源项目很少会提供); 而且即使有了, 也不能完全保证是没问题的, 毕竟图形显示等各种其他因素也
会影响实际体验.

作为发行版打包人, 我们一般会保证:

1. 项目能跑过自己的 self-test, 如果跑不过, 至少要保证上游知道这个情况.
2. 我们在打包发行之前, 自己会去用这个软件. 但是就如刚才所说, 我们是完全不能保证会用到所有功能的.
3. 如果我们在测试中发现了问题(无论是项目自己的单元/集成测试, 还是自己使用体验中), 通常是肯定会向上游提交 bug 报告的. 如果涉及的 bug 比
较重大 (比如启动时 segfault 等使得软件完全无法使用的问题), 我们会暂缓发布直到上游给出解决方案, 或者我们自己有时也会尝试寻找解决方案. 这里
的解决方案包括提供 patch 给下游打上, 或者直接发布新版本.

至于"产品质量控制标准", 通常完全是由项目管理人员的喜好决定的. 有的项目比较随意, 对提交的 patch 几乎是来者不拒. 这种情况下, 如果项目本身没
有带测试, 或者测试覆盖太少, 会经常产生质量方面的问题.

> 用户提交BUG除非用户对这个软件十分关注并且十分熟悉BUG提交流程，并且用户十分热衷干这个事，并且用户时间比较宽，有没有什么办法改善这些问题？ 

有很多努力改善这个问题的方案了, 比如 Ubuntu 的 Apport 会在软件崩溃/升级失败等问题时产生相当详尽的错误报告, 并且以图形界面引导用户报告. 
不过这样的方案也有比较明显的问题:

1. 这类方案会大幅加大发行版 Bug Tracker 的维护难度, 因为很多用户 (包括我以前) 都会在懵懵懂懂的状态提交一个几乎只有 Apport 收集
的信息的错误报告, 而且由于自己不知道这个问题是不是和别人一样, 面对同一问题的这样的错误报告会出现很多重复. 因此 Launchpad 上有相对较多的 
Bug 分类/整理人员来应付这种情况.
2. 大量用户并不跟进错误报告. Qian Hong 同学曾经在某篇巨著(忘记是哪篇了 :P)里提到过, 跟进错误报告需要的时间精力比报告还要多, 而且通常
是直接决定错误报告处理速度/结果的重要因素. Apport 虽然引入了方便的报告 Bug 的流程, 但是对跟进 Bug 的流程没有做出任何帮助 (也的确是很
难帮上忙), 所以导致 Bug Tracker 上报告但不跟进的 Bug 明显变多了 (普通用户不知道/懒得跟进的还是相当多的).

不过总的来说, Apport 依然是对用户报告 Bug 困难问题的一个相当有效的解决方案.

Regards,
Felix Yan
-------------- 下一部分 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/chinese/attachments/20140505/94074e06/attachment.sig>