[FZH] 被Abiword 坑了一下

[Szopen Xiao]

既然BUG处理很困难，那么对于条件有限（开发人员有限，时间有限）的项目，应当向开发者建议减少项目功能与特性，减少程序复杂度，降低BUG出现风险，而不是天天解决BUG


在 2014年5月5日 下午3:39，Christopher Meng <cickumqt在gmail.com>写道：

> 本来打字不太方便不想说了，不过同作为包工（Fedora），也趁机谈谈我的看法。
>
> 软件测试究竟谁来做，基本这3（也可以是4）个：
> * 上游（例：https://mail.gnome.org/mailman/listinfo/gnome-qa-list）
>  - unit 测试，integration 测试，regression 测试；
>  - 绝大部分大厂软件出厂或者发行前会有 QA 来做；Google，有委员会；RH 的内核工程师，还有 QA 工程师；
>  - 代码测试，使用第三方测试工具（travis，jenkins，coverity，xxx ）；
>  - 其他 whitebox 测试；
>  - 模拟 blackbox 测试（目前用户上报的问题中不少如果上游考虑细致，这一步可以验出来的，很不幸这一步很不好弄）；
>  - 开源软件一般来路复杂，可能测试者和作者就是一个人，每个人都有脑洞，有时候看不出来 bug；
>  - bug 究竟是什么，也是一个问题，比如马同学；
>
> * 包工（例：https://admin.fedoraproject.org/pkgdb/users/packages/cicku）
>  - 自带测试套件执行通过；
>  - 编译完能够运行。我会使用一下，但不可能都天天用；
>  - 大部分情况包工不是上游，我只负责编译，链接出来的东西不是 corrupt 即可。至于是不是造轮子，是不是渣代码，不管；
>  - 严重的预处理错误会修复并提交；
>  - 严重的潜在语法 bug 会修复并提交；
>  - 追踪上游 trac；严重的 bug 直接上 patch 重新编译提交更新（比如 mate/kde 桌面，mate 的开发者在
> Fedora 有2个，经常看见有更新），不严重的推到下一个版本发布（xfce? XD）；
>  - ABRT 支持的语言如果有 backtrace 提交上来，我会直接开调试工具，能够修复的一般自己修复了然后交 pull
> request，不能修复的直接扔给上游；
>  - 上游也不管就算了 XDDD（上游已死）；
>
> * 下游 QA 组（例：https://qadevel.cloud.fedoraproject.org/）
>  - 一部分人就是包工；
>  - 一部分来自 RH，负责基础包（https://fedoraproject.org/wiki/User:Adamwill，Mandriva
> 前社区经理）；
>  - proventester 测试更新（http://fedoraproject.org/wiki/Proven_tester）；
>  - 发行版发布前 Fedora QA 只测基础包有无严重缺陷（RHEL @base
> 的，4大桌面环境，还能看见人测试），这部分最重要，能否定期发布就看这个。（
> https://qa.fedoraproject.org/blockerbugs）；
>  - 发行版发布后主要测试包更新是否有 regression，比如 upgrade path
> 失效，文件冲突（http://autoqa.fedoraproject.org/）；
>  - 源码完整性审计防止后门（最近一次：
> https://lists.fedoraproject.org/pipermail/devel/2014-January/193537.html）；
>  - RH 安全响应团队监控 CVE（https://fedoraproject.org/wiki/Security_Response_Team）；
>  - Fedora 基础设施有专门的 QA，讨论很多（我能看，你们恐怕不行
> https://phab.qadevel.cloud.fedoraproject.org/）
>
> * 用户（奇葩问题探索者）
>  - 小白鼠发行版用户大部分日常使用说白了就是在做 blackbox 测试，只要看是否 “结果 == 预期” 即可，也就是能不能用；
>  - ABRT 反馈（https://retrace.fedoraproject.org/）；
>  - 胡诌，有些是个人问题，也弄成 bug 差评。
>
> 部分问题就来了：
>  - 我使用的时候是英文环境，某些国际化处理相关的工具，比如文本编辑器，文档管理器，处理 CJK
> 等字符会有问题；上游不是语言学家，也没有人协助上游搞国际化测试；
>  - 抱歉，实话说，你遇到的问题的确是问题，但是之前我遇不到 :)；
>  - 不提交 backtrace，然后指望短短几行问题描述让我解决的；
>  - 有时候维护的仅仅是软件，比如 mldonkey，个人平时用它下载，可是这玩意儿是 ocaml 写的，会的人少，包工解决不了；
>  - ABRT 只不过界面带中文，Bugzilla 照样是英文，看不懂，提交不了；
>
> 于是某倒霉群体就会抛出“怎么这么难用”之类的话语。现实：
>  - 越小众的工具出了问题越没人管；
>  - 软件测试有一本巨厚的书，还出了第二版，可见是门学问（
> http://www.amazon.com/Foundations-Software-Testing-2nd-Edition/dp/8131794768
> ）；
>
> 所以测试真的好复杂的。bug 提交流程短期内不会提高，考虑到用户综合水平，语言表达能力等因素。
>
> 包工如果认真起来可以报的 bug 多了去了，可惜太浪费时间了。
>
> PS:
> - anaconda 等图形界面工具，有 AutoQA 来自动创建虚拟机模拟图形界面来测试，SUSE
> 正在搞（https://openqa.opensuse.org）。
>
> Yours sincerely,
> Christopher Meng
>
> Noob here.
>
> http://cicku.me
> --
> Fedora中文郵件列表：https://admin.fedoraproject.org/mailman/listinfo/chinese
>