软件测试究竟谁来做，基本这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/SecurityResponseTeam）；
- 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）。
看来指望靠打包者汇报 Bug 来提高软件质量是不切实际的，那么精简特性可行否？
在 Qian Hong 看来事情并没有表面上那么简单：
做加法容易，做减法难。
假设abiword有三个用户：
A说，砍掉支持那么多格式的功能，我只要支持doc就好，我只要支持中文就好！
B说，砍掉那么多语言支持，我只要支持英文就好，支持越多格式越好！
C说，我用abiword编辑xxx格式很多年了，绝对不要砍掉这个功能！
开发者听谁的？
这里有一个误区是，以为减少功能特性真的能减少bug，实际情况却很复杂，没有量化的证据能证明减少功能一定能减少bug，也没有量化的证据能证明相反的观点。
可以做一个思想实验，看看减少功能是否真的一定能减少bug：假设abiword砍掉了二十多种格式支持，只支持一种格式，那么中文支持会不会自动
变好呢？如果没有中文用户/开发者参与开发和测试，那么我认为少几种格式支持并不会让中文支持自动变好，因为原来的开发人员和测试人员仍然不懂中文，并不
会因为格式支持少了，他们就自动懂中文了。（但是，有可能因为格式支持少了，他们有更多的时间陪伴家人，这是好事）
我举一个没有办法量化的佐证，试图证明增加功能和减少bug并不是矛盾的。
以Wine项目为例：
几年前，Wine项目不支持ActiveX控件；几年前，Wine项目中文字体乱码问题非常严重（累计有十几个不同的bug引起不同条件下的乱码）；几年
前，Wine项目几乎没有中国开发者。
2010年，Wine开始支持ActiveX控件，为了解决网银的问题，我开始给Wine项目报bug，后来报了太多bug，遭到了报应，转变为一名
Wine开发者自己面壁修bug，而我最早修复的几个bug都是中文乱码的问题。在这个特例上，“增加功能”吸引了“更多用户”，“更多用户”意味着“更
多潜在贡献者”，”更多潜在贡献者”最终帮助完成“减少bug”这个目标。
你可能觉得这是个特例，不过我认识的其他开源开发者朋友，大部分也有自己的一段从用户转变为开发者的故事，这类故事一般都不违背“增加功能”-“增加用户”-“增加贡献者”-“减少bug”这样的套路。
一个更有说服力的例子是编译器。如果把支持的语言算作功能特性，把支持的平台算作功能特性，那么功能特性越多的编译器，核心功能的bug会越少，因
为功能越多用户群越大，越多人参与测试bug就越容易得到暴露，恰好编译器的用户群又有不小的几率能转变为临时/长期的贡献者。
举这些例子，并不是为了证明“减少功能特性能减少bug”是错的，也不是为了证明“增加功能特性能减少bug”是对的，只是为了说明：事情往往没有一眼看上去那么简单。
关于开源软件质量的讨论还在继续，如果有兴趣，不妨加入进来。不管如何，可以肯定的是一个高质量的 Bug 报告对于开源软件的质量不无裨益。
此外，这里有 tonghuix 近期对于开源社区运营的一些看法，“下载-使用-骂娘”的吐槽风气其实并不可取。 | 
