| 摘
要 软件测试管理是为了使软件测试项目能够按照预定的成本、进度、质量顺利完成而对成本、人员、进度、质量、过程和风险等进行分析和管理的活动。测试管理关注人员、过程、产品三要素的互动和变化，测试过程和阶段的相互作用，测试与开发团队的相互关联与协调配合，为使这些过程能有序的进行，开发出适合自己项目组的测试管理工具是必需的，同时由于自动化测试的普及，如何将自动化测试融入进来也是一个挑战。本文描述了我们项目组开发的支持自动化测试的测试管理工具的结构和功能实现。
关键字 自动化测试；测试管理；软件测试
1 引言
为了保证软件产品的质量，需要对软件过程进行控制，同时也需要对软件产品本身进行检测，在目前形式化方法和程序正确性证明还无望成为使用性方法的情况下，软件测试在将来的相当长一段时间仍然将是软件质量保证的有效方法[1]。
软件测试管理就是通过一定的管理方法和工具来对整个软件测试过程进行监控，从而提高软件测试的绩效。由于软件测试管理的复杂性，没有特别的辅助工具，只是依靠人工处理是很麻烦甚至是不现实的。
对于测试工具的选择一般来说有自己开发、商业工具和开源工具三种选择。第三方工具包括已经成熟的商业软件和开放源代码的开源工具，它们都是经过证明的可以放心使用的工具，但是最主要的不足之处在于它们往往为了通用的考虑，按照自己的理解标准化了流程，并且价格不菲。但是对刚起步的中小企业来说，购买和使用这样的通用工具而只使用到其中一小部分功能，甚至有些有自己项目组特色的东西还得不到支持，往往不是最合理的选择。
随着近些年测试自动化的呼声越来越高，如何将自动化测试的效率提高到应有的水平，成了各个测试机构首要考虑的问题[2]。我们认为，先进的测试管理流程与一流的自动化测试工具包是实施自动化测试不可或缺的。为更好的对测试流程进行控制，使之能充分利用自动化测试带来的好处，现代测试管理系统应该能支持自动化测试。
结合公司的实际情况，我们选择了自己开发和开放源代码相结合的方式，并采用缺陷跟踪驱动测试的模型开发出了自动化测试管理系统ATMS(Automatic
Testing and Management System)来作为支持自动化测试的基础设施。
本文分析了ATMS的体系结构和各部分组成，并对其中一些关键技术进行了讨论。
2 体系结构
现在基于源代码的软件测试工具已经开始被业界广泛使用，以求提高软件的可重用性，可维护性等质量属性，由于本项目组的软件自动化测试才刚起步，ATMS应该能和以后可预期的测试过程的进一步完善和需求的变更同步，这样，ATMS在设计之初就应该有良好的可扩展性和可重复性。
ATMS在逻辑上采用了以中心数据库为核心的体系结构，ATMS目前分为测试文档管理系统、缺陷跟踪管理和自动化测试支持系统三大部分(体系结构图如图1所示)，为了降低它们之间的耦合性，它们都通过共同的中心数据库进行交互，以后要进行扩展的话只需要围绕中心数据库进行操作即可。
图1
3 测试文档管理系统
软件测试文档是指导和管理软件测试过程的重要依据，测试文档包括测试计划、测试进度、测试用例、缺陷管理文档、进度报告等。这里介绍ATMS中我们主要分为测试用例管理和测试文档管理(包括测试计划，测试进度等测试文件的模板)。
3.1 测试用例组成
ATMS中用例分为三个部分，用例逻辑、用例数据和用例代码。其中用例逻辑和用例数据是文本格式，由用例管理系统负责创建；用例代码由自动化支持系统在CPPUNIT中创建，它是自动化运行的基础。它们的关系如图2所示。
图2
3.2 测试用例存储和执行结果
为更有效组织这些测试用例，采用测试用例数据库进行集中管理。这样就可以按照测试阶段和被测模块清晰地组织测试用例，并可以按照用户的不同查询条件显示不同的数据信息(如测试用例执行状态，执行结果，时间等)。
3.3 测试用例的维护
为保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。包括如下四个方面：
● 删除过时的测试用例
因为需求的改变等原因可能使一个测试用例不再合适被测系统，这时就应该将其删除。
● 删除冗余的测试用例
如果存在两个或更多测试用例针对一组相同的输入和输出进行测试，那么就是冗余的，它们的存在会降低回归测试的效率，需要定期进行整理。
● 添加新的测试用例
如果发现某个关键接口还没有被测试，就应该开发新的测试用例重新对其进行测试，并将新的测试用例合并到测试用例库中。
3.4 测试文档模板管理
为有效进行软件测试管理，在项目准备阶段创建测试过程中用到的各种管理模板，项目测试执行过程中填充和更新模板内容，这样可以保证不会遗漏重要测试内容并保持文档格式一致性。
目前ATMS中存在如下模板：
● 测试用例模板(测试用例逻辑部分)
● 每日进度模板
4 缺陷跟踪数据库
缺陷跟踪数据库DTD(Defect Tracking Database)，是对软件缺陷进行系统管理和跟踪控制的数据库，它记录软件测试、缺陷修正和验证过程的全部缺陷的处理信息，ATMS中的测试是以它为驱动进行的。
ATMS中，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。每个bug都有它的生命周期，从被报告开始到被解决结束。在这个生命周期中它在不同状态中转换。在ATMS中，我们为缺陷设计了如下缺陷跟踪管理状态模型。
4.1 缺陷报告
标识一个缺陷的时候，能正确给它分配严重程度、可视性和优先级别是很重要的。其中严重程度标识了一个bug对系统执行的破坏度，可视性是哪个能观察到这个bug，优先级别标识bug何时修复。
表1、表2和表3分别标识了严重程度、可视性和优先级的可能值。
表1
|
严重程度 |
描述 |
|
0 |
待分配 |
|
1 |
致命---系统崩溃或者不可修复错误 |
|
2 |
严重---功能没有实现 |
|
3 |
一般---功能实现错误 |
|
4 |
轻微---文档/拼写错误 |
|
5 |
待观察----不能重现的错误 |
|
6 |
正常-----系统正确功能，非bug |
表2
|
优先级 |
描述 |
|
0 |
待分配 |
|
1 |
必须马上修改 |
|
2 |
尽快修改 |
|
3 |
有空时修复 |
|
4 |
可修复可不修复 |
表3
|
可视性 |
描述 |
|
0 |
待分配 |
|
1 |
超过75%客户可能面对这个bug |
|
2 |
25-74%客户可能面对这个bug |
|
3 |
10-24%客户可能面对这个bug |
|
4 |
低于10%客户可能面对这个bug |
4.2 缺陷处理
每当一个bug被处理完成的时候，ATMS将给它分配一个处理码，表4是系统所有结束码列表。
表 4
| 结束码
(解决途径) |
解决
与否 |
详细描述 |
| 设计一部分 |
解决 |
非bug，是系统设计组成部分 |
| 不能修复 |
解决 |
由于时间，花费等别的限制暂时不解决 |
| 被报告人取消 |
解决 |
报告人认识不是bug，取消报告 |
| 延期 |
否 |
暂不修复，以后再修复 |
| 重复的 |
解决 |
和现存bug重复 |
| 已解决 |
解决 |
Bug被修复 |
| 不可复现 |
否 |
开发人员不能复现这个bug，需要重新定义bug路径 |
| 需要更多信息 |
否 |
Bug报告中信息不足 |
| |
|
|
4.3 DTD的功能与组成
DTD的功能与组成如图3所示。
图3 缺陷跟踪系统模块组成图
各模块详细说明如下：
●报告模块。用于软件测试人员向数据库报告新的缺陷。
●权限控制模块。为测试人员、开发人员和项目管理人员分配不同的权限，如浏览、报告、修改、查询、统计、分析、删除、备份等。
●分析模块。统计和分析满足条件的缺陷，输入分析结果；分析结果可以存成文件，可以包括数据、文字、表格和统计图形等内容。
●备份模块。备份当前缺陷跟踪数据库的缺陷；全部备份或者备份满足条件的缺陷。
●查询模块。根据查询条件，查找满足条件的缺陷；包括简单条件查询和复杂条件查询。
●修改模块。用于开发人员和测试人员更新缺陷状态信息；开发人员验证报告的缺陷，修改缺陷，更新修改缺陷的信息；测试人员补充缺陷内容，验证和关闭修正的缺陷。
5 缺陷跟踪数据库的缺陷管理
缺陷跟踪数据库(DTD)是一种可以提高缺陷处理效率的工具，要充分发挥它的作用，需要对缺陷跟踪数据库进行有效的管理[3]
。
5.1 角色和权限划分
使用DTD的用户有多种类型，而且他们使用的目的关注的内容也各不相同，为更有效地对DTD中每个缺陷进行正确处理，保证缺陷处理的客观性和安全性，我们对不同的使用者分配不同的缺陷处理权限。
默认情况下，数据库有四个组，测试组、质量保证组、修正缺陷组、项目管理组。可以根据需要随时添加和减少这些组的成员。
各组对应权限如表5所示。专有权限是本组成员才有的权限，公共权限是每个使用缺陷数据库的人员都有的权限。
表5
5.2 缺陷数据分析和显示
本系统具有较为强大的数据统计分析能力，以基于缺陷跟踪数据库的bug信息作为分析的数据来源，以表格和图形的形式表现缺陷的分布情况，并且可以选择统计和分析的频率(每周或者每天)。目前实现的有如下三种。
(1)测试团队每天报告的新缺陷统计和分析。
(2)不同测试人员的缺陷数量统计。
(3)缺陷严重级别和缺陷类别统计与分析。
由于我们采用的是中心数据库的体系结构，当需要以别的方式体现缺陷的分布情况时只需要更改图的表示层就可以，而逻辑和数据库层无需更改。
6 自动化测试支持系统
自动化测试是管理和实施各种测试活动的一种方法，即测试用例的设计，测试脚本的开发和执行，并借助自动化工具来验证测试需求[4]。而缺陷回归是我们软件开发和缺陷管理中的主要问题，也是测试中不可避免的话题。对现有功能更新的同时，也影响原有的行为，这是造成bug的主要原因，避免这一问题的主要解决方法是构建自动化的测试，实现回归测试。
回归测试我们可以采用商业工具、开源工具和自己开发，考虑到开发周期和与本系统的兼容，我们在多种选择方案中选择了在ATMS中内嵌开源自动化测试工具CPPUNIT[5]的方法来支持自动化测试，由于CPPUNIT是个开放源代码的工具，这使得我们可以通过修改其源代码使之符合我们的需要，在本系统中，当每次CPPUNIT自动化测试完成之后，我们加入引导，把相应的运行结果写入ATMS指定的中心数据库中，同时指示ATMS有新的数据更新。这样由于ATMS和CPPUNIT共用相同的中心数据库，能够达成数据上的一致性，并完成所需交互。其数据流如图4所示。
图4
从图4可以看出，当做自动化测试的人员拿到需要自动化的用例的文本描述后，将其按照CPPUNIT的规范写成可以在CPPUNIT框架下运行的用例代码。然后和需要的用例数据一起通过CPPUNIT自动运行，结果自己写到系统的中心数据库，这样，别的模块就能任意查询所需结果。
7 结束语
随着我国软件业的发展和各公司测试管理过程的进一步完善，作为软件质量保证的重要组成的软件测试也越来越受到重视，如何在软件开发项目中有序地管理和分析各种问题对质量控制和过程改进也将越来越重要。本系统支持缺陷驱动的测试过程，但是对自动化的支持还比较肤浅，只是在现有CPPUNIT的基础上做了一些整合，这个是以后需要改进的地方。我们也相信，由于软件自动化测试能显著提高软件测试的有效性和效率，将在越来越多的软件测试管理工具中得到支持。
参考文献
[1] Ron Patton 著．软件测试．周予槟，姚静等译．机械工业出版社，2002
[2]崔启亮著．国际化软件测试．电子工业出版社 2006.4
[3]孙建．软件测试工具的研究与建立．浙江大学，2006
[4]Sam Guckenheimer. The Revolution in Software Testing.
Rational Software. 2002
[5]James Newkirk Robot C. Martin. Extreme Programming
in practice中文版.人民邮电出版，2002年6月出版
| 
