摘要

随着开源软件的兴起，其使用范围也越来越广泛。开源软件本着"不要重复造轮子"的原则，与商业软件相比，拥有使用成本低、可定制性高等特点。然而开源软件在质量保证上仍然存在诸多的问题。本文将从开源测试工具、开源社区测试能力短板等方面来展示测试人员参与开源社区贡献的必要性。

1、开源测试工具概况

测试工具是质量保障中的"武器"，而测试工具的设计者则是精良武器的"兵工厂"。利用优秀的测试工具可以提高测试效率，发现隐藏较深的软件缺陷。根据测试工具的功能，我们将其划分为测试管理、缺陷管理、持续集成、功能测试、性能测试、测试框架、测试设计、安全测试等类别。下面列举了这些分类中一些典型的测试工具。

· 测试管理：TestLink，Testopia

· 缺陷管理：Redmine，Bugzilla，Mantis

· 持续集成：Jenkins，Buildbot

· 功能测试：Selenium，LTP (Linux Test Project)

· 性能测试：lmbench，Sysbench，Iperf，Fio

· 测试框架：JUnit，Autotest

· 测试设计：Xmind，StarUML，UML Designer

· 安全测试：Metasploit，Nessus，AppScan

在新的开源测试工具不断涌现的同时，很多曾经优秀的开源测试工具因为缺少必要的维护而无法持续进行新功能的添加和已有功能的增强与维护。Lmbench是一款优秀的linux性能测试工具，可以获取系统CPU、内存、磁盘、网络等资源的带宽和延时的性能数据。近年来由于缺少必要的官方维护，没有新功能添加，该工具在行业内的影响力在逐步下降。另一个例子是Rth，其是一款优秀的测试需求管理、测试过程跟踪的测试工具，由于多年来缺少必要的维护，该工具已经无法满足当前项目的需求，逐步淡出了大家的视野。早先原本使用该工具的程序员，不得不将目光转移到其他工具中，而熟悉新的工具需要额外的时间投入，增大了项目运作的成本。

2、当前开源社区测试能力的短板

本章我们以Kernel和Docker社区为例展示当前主流开源社区的质量保证中有待改进的方面。

2.1、Kernel开源社区

Linux kernel是迄今为止最为成功的开源社区，有很多一流的公司和程序员参与其中，平均每月的代码补丁合入量在一千以上，社区的代码量在千万行的数量级。面对如此庞大的代码量，做好质量保障工作是一个严峻的挑战。而目前社区没有精准测试方案，修改一行开发代码时不得不运行全量的测试用例才能充分保证质量。

操作系统运行分为内核态和用户态。当前内核态的测试用例和功能代码存放在一个Git仓库中，代码路径在kernel/tools/testing/selftests中。而用户态的测试用例与开发代码相对独立，单独存放在Ltp开源社区中。

Kernel社区采用的是迭代式开发。不幸的是，很多开发者在提交完功能代码后并没有同时添加文档和对应的测试用例。而社区也没有一种有效的机制保证文档和测试用例得到及时的更新。文档的输出相对滞后，使得很多内核的特性难以理解，很多时候其他程序员不得不通过阅读源码来推测该代码所实现的功能。而测试用例的滞后输出更为明显，很多内核特性在功能代码合入后的几个月甚至一年以上的时间都没有对应的测试用例。以user amespace内核特性为例，其是在2013年2月18日随内核3.8版本正式发布的，然而直到2015年5月21日，社区才拥有第一个该特性的测试用例。二者时间间隔在两年以上，也就是说，在这两年中使用该内核版本的用户都无法获取到有效的测试用例来验证该特性，版本的质量保证令人堪忧。社区中有很多类似的待测点，需要大家参与社区来补充必要的测试用例。

另外Kernel还维护着LTS的长期稳定版本，即在某一个特定的Kernel版本中不添加新的功能，只修改已有的软件缺陷。据笔者所知，因为测试资源的缺乏，在LTS版本发布前，并不是每个版本都进行源码编译、全量测试执行等测试工作。很多时候验证工作往往只包含源码编译和OS启动冒烟测试。这很可能导致大量软件缺陷遗漏到下游开发者手中。

2.2、Docker开源社区

Docker是当前流行的云计算开源工具，其社区也吸引了大量的开发者参与社区贡献。Docker社区采用的是测试驱动开发的策略，即在开发者提交功能代码时需要同时提交对应的测试代码和进行文档的修改。这种开发方式很大程度上解决了文档和测试用例滞后的问题。然而，Docker社区中并没有专职的测试者，测试用例几乎都是开发者提供的，他们更关注开发代码的质量，对于测试代码的质量就显得有点"漠不关心"了。用例在设计过程中往往缺少测试思维，使得输出的测试用例缺少边界异常点检查。开发者输出的用例几乎都是单点的功能验证，无法覆盖全面的代码路径，更缺少一些专项测试(性能测试、压力测试、长稳测试、安全测试等)。

很多开发者通常是为了应对测试驱动开发的策略被动的添加测试用例，很多重要的特性只使用有限的用例来进行验证。这很难保证软件发布后的质量。在近期发布的Docker1.12版本中，就出现了软件稳定性差的问题，引发了很多争论，社区又不得不亡羊补牢。

3、专业测试人员参与开源社区贡献的必要性

从心理学的角度来看，开发者不愿意看到自己编写的代码存在缺陷，也就没有足够的动力去发现软件缺陷。在版本发布临近、任务紧急的情况下，当开发者本人发现了自己编码中的缺陷，而解决该缺陷又需要大量时间并且自己不得不加班时，开发者有两种方式应对。第一种是积极的投入时间，加班加点把问题解决掉来确保版本发布的质量;另一种是保持沉默，默默的祈祷其他人不要发现这个缺陷。经过调查，绝大部分人会选择第二种方式，因为人性即如此，我们做任何事的时候都不要去轻易的挑战人性。而查找软件缺陷是测试者的本职工作，他们会尽最大可能的发现软件缺陷。一旦缺陷被发现，测试者绝不会保持沉默，这有助于最大限度的暴露软件缺陷。 除此之外，开发者设计的用例往往只限定在单元测试中，而集成测试、系统测试、验收测试往往需要测试者的参与。一些专项测试(性能测试、压力测试、长稳测试、安全测试等)也是测试者所擅长的，他们会站在用户的角度上思考软件的可用性、用户体验等方面的内容。