前言

随着时代的发展，软件规模越来越大，复杂程度越来越高，对测试工作也提出了更高的要求，测试领域也随之涌现出了各种各种的理论、方法和工具。这其中很重要的一个分支便是测试管理工具，它主要解决的是测试过程中团队协作的问题，比如缺陷管理、用例管理、测试任务管理等。

目前市面上比较流行的测试管理工具有QC、Mantis、BugZilla、TestLink、Trac、Redmine、 BugFree等。有开源软件，也有商业软件。这些软件的各自侧重点不同：比如Mantis， BugZilla偏重缺陷管理，TestLink则偏着测试用例管理，QC则更加全面，Trac和Redmine项目管理的概念又更强一些。 我们在总结分析这些软件的优缺点基础上，结合自己日常实际工作的需要，设计了一套测试管理软件，这篇文章就是在设计这款软件过程中的总结和思考，希望可以 给大家一些启发。

在设计的过程中，我们确立的目标是在一套软件里面可以实现测试全过程的管理。那么，哪些功能是在这个管理过程中必不可少的呢？经过激烈的讨论和不断的修正，我们整理总结出以下九大功能，它们分别是：测试需求管理、测试用例管理、测试套件管理、测试版本管理、测试计划管理、测试执行管理、缺陷管理、发布管理和分析报表。下面笔者就这些功能一一阐述。

一、测试需求管理

需求是一款软件产品的灵魂，是开发和测试最重要的参照标准。很难想象一个没有需求的软件如何去设计它的测试用例。无论是测试用例，还是缺陷，都是建立在特定的需求基础之上的。因此，一款好的测试管理软件首先具备的便是测试需求管理。

1.1 需求拆分

传统的项目管理流程中，需求往往以需求规模说明书的形式呈现。需求规格说明书比较全面，但缺点是没有拆分为需求点，无法实现对某一个具体的功能点的跟踪。因此在我们设计的测试管理工具中，需求是以需求功能点的形式呈现。这样有利于针对每一个功能点撰写测试用例，并进行测试的跟踪管理。

大模块拆成小需求，小需求拆成需求点，拆分之后，一层层的分级管理便是必不可少的了。为了适应日益复杂的需求和变化响应，需求的模块还需要实现无限级的划分，这样可以形成一颗树状结构，无论从浏览还是管理上都更为灵活和方便。

1.2 需求管理

有了模块之后，紧接着需要实现的便是测试需求的管理。我们需要一个界面来录入需求，常见的字段包括：标题、描述、优先级等。另外也可以对需求进行修改，删除等操作。

1.3 需求搜索

实现了基本的需求维护功能之后，我们还需要实现需求的搜索功能，这样方便我们找到自己想要的需求。

二、测试用例管理

好，我们现在有了测试需求，我们就可以为每一个需求撰写测试用例了。测试用例的维护涉及到模块划分、测试用例维护、导入导出和搜索等功能。

2.1用例模块划分

类似于需求的模块维护，用例也需要通过模块的划分来维护用例。在我们设计的软件中，测试用例的模块和需求的模块式分开的。读者肯定会问，为什么还要为用力维护一套模板呢？为什么不重用需求的模块划分呢？这是因为在实际项目中，需求是从用户和产品的角度来看，需求更多的是帮助用户如何达成一个操作，实现一个功能。但是用例设计不止要考虑需求，还需要考虑一些异常情况来设计用例，为用例单独开设模块管理就不会影响到原有的需求管理部分。

2.2用例的维护

下面我们要实现的便是测试用例的基本添加，编辑等操作。这个功能在大多有测试用例管理的工具中都会实现，但需要特别说明的是，在绝大多数的管理工具中，测试用例的步骤是没有分开的，每一步的预期甚至也是混在一个字段中。其实这样并不可科学，不仅会降低用例执行的粒度，还会影响后续的一些数据生成，至于是生成什么样的数据,先在这里 卖个关子，后面解释：-）。在我们设计的系统中，用例的步骤和每步的预期是完全分开的。

2.3 用例的导入导出

目前很多公司还是在使用Excel书写和保存测试用例，如果一家公司准备采用一套测试管理系统，将这些用例手工导入将是一项繁重的工作。 因此测试管理工具需要能够将Excel里面的用例导入到系统，同样，也能够将测试用例导出为Excel格式的文件。

从数据库导出Excel的功能还是比较好实现的，Excel的导入功能方面，笔者设计的思路是可以通过excel的VBA编程自动实现数据的获取，并且可以更新回到系统中，这样会更加方便快捷。目前正在研究摸索中。

2.4 用例搜索功能

同需求的搜索功能，我们同样也需要对测试用例进行方便的检索，以便找到自己想要用到的测试用例。

三、测试套件管理

有了测试用例之后，紧接着一个问题就会产生，那就是如何组织维护这些用例。除了上面所说的模块功能、导入导出和搜索之外，测试套件功能也可以非常方便的帮助测试人员来组织整理自己的测试用例。

测试套件(Test Suite)可能是一个分歧比较多一个概念，在我们看来，测试套件就是一个集合，可以方便的将某一些用例按照某个特征组织在一起，方便后续的管理和维护。因此从这个角度来实现测试套件的功能就包括测试套件的创建、关联测试用例、测试套件的浏览维护等功能，不再细述。

四、测试版本管理

在目前的软件开发流程中，代码的版本控制已经得到了普遍的应用。 而由此我们可以引申出测试版本这个概念。 一个测试版本可以是对应一个Build，也可以对应一个时间点，测试版本的概念很重要，通过它我们可以明确我们目前测试的范畴，知晓我们需要执行哪些测试 用例。同时开发人员在修复bug的时候，也可以明确当前的修复工作会影响到哪个版本。

4.1 版本和需求、bug的关联

首先我们需要实现的便是测试版本和需求、bug的关联。也就是我们在创建一个测试版本的时候，需要确定这个版本都完成了哪些需求，解决了哪些bug，这样就界定了我们测试的范畴。下图是我们设计的系统中实现的创建版本时，需求和bug的关联页面。

4.2 版本和源代码管理系统的集成

一个版本肯定对应到源代码管理系统中的某一个路径，一般是对应到类似tags/xxx.1.0.build1类似的 目录。细心的读者可能已经注意到，我们上面图中的源代码和存储地址是以文本框的形式呈现的。这也是我们正在计划实现的一个功能，就是源代码的版本可以自动 从源代码管理软件中获取。 比如我可以从Subversion的某一个路径中获得对应的代码版本，这样就可以将测试管理系统和代码管理系统进行有机的结合。

五、测试计划管理

现在我们有了测试需求，有了测试版本，有了测试用例，还有了测试套件，那么我们接下来就可以开始执行测试了吧？ 先别急，做什么事最好都有一个计划，测试工作也不例外。 所谓测试计划，其实就是如何来测试某一个版本，保证其代码质量。 站在测试组织管理的角度来看待，这里面包括这样几个工作：

5.1 提交测试，创建测试任务

当一个测试版本创建之后，我们就可以提交测试进行测试了。提交测试主要注明要测试哪一个版本，预期开始和结束的时间是什么，还可以有一些备注的信息。

5.2 测试用例的确定

当一个测试任务创建之后，我们需要为这个测试任务确定好都要执行哪些测试用例。由于每个测试版本都有注册这个版本所完成的需求或者解决得BUG，因为确定需要执行的测试用例的过程，就是根据相应的需求或者BUG筛选测试用例的过程。

5.3 测试用例的分派

那么通过上述的用例筛选功能，确定好这一次测试需要执行的用例之后，下一步的工作就是将测试用例做好分配。当然，如果某一个测试任务只有自己来进行，那么这个工作就可以省却。但如果一个测试需要很多人一起完成，或者是需要外包给第三方公司进行，那么就可以通过这个功能来指派测试用例。

六、测试执行管理

测试计划做完之后，每个人头上负责执行的测试用例也就都非常清楚了。这时候每个人要做的事情就是执行自己头上所负责的测试用例

6.1 测试用例执行

首先我们来看下测试用例的执行页面：

由于我们设计的测试用例是分开步骤地，所以在执行测试用例的时候，可以非常清晰的确定每一个步骤执行的结果。

在测试任务的用例列表界面，可以查看每一个用例最后的执行情况。

6.2 从测试结果创建BUG

当一个测试用例执行失败之后，就可以从测试结果中直接创建一个BUG，指派相应的开发人员进行解决。

大家可以看到，我们可以自动生成BUG的重现步骤：-） 这就是将测试用例步骤分开的好处。

七、缺陷管理

缺陷管理是一个测试管理工具中最重要的功能了。当测试过程中产生了bug之后，开发人员和测试人员的互动就通过bug来进行。这里面包括基本的创建bug、解决bug、编辑、验证关闭，激活等功能。这一块的功能和逻辑大家都比较熟悉，不再赘述。

我们想特别和大家分享的一点是bug到测试用例的转化。有的bug非常的经典，也非常重要，但是在这个bug出现的时候，当前系统里并没有用例 覆盖它，所以我们需要将其放在用例库里面，以保证后续的版本不再重返类似的问题。因此我们设计的系统中还提供了bug转为用例的功能。

将Bug的步骤自动计算为用例的步骤，是不是很酷？

八、发布管理

当开发人员解决了若干bug之后，就可以重新创建一个测试版本，然后提交测试，然后又是测试计划，测试执行... … 如此往返，直到最后一个阶段测试工作终结，我们就可以创建一个发布了。

在创建发布的时候，需要选择一个测试版本(build)，而这个测试版本又关联了这个发布所完成的需求、所设计的用例以及所提交的bug，由此与前面的工作完美的形成了闭合。