测试管理系统设计实现论文.doc

毕业设计（论文）

设计（论文）题目： 美的海外营销系统业务模块的
设计与实现
学生姓名
学生学号
专业班级
指导老师
院长 (系主任)

5 月 25日

毕业设计（论文） 第 I 页
测试管理系统的设计与实现
摘 要
工欲善其事，必先利其器。好的工具可以提高项目人员的测试效率。以MI公司的TestDirector为例，它是一个基于WEB应用的系统，它将管理工具使用对象扩展到软件质量控制部门、用户和其他相关的部分，让更多人员参与测试，有利于项目管理员对项目进度和效率有一个全局的了解。的确如此，市场上的测试工具，尽管提供了强大的功能，提高测试效率，但是其测试管理思想并没有跟中国IT企业结合，很多功能不能灵活使用。因此公司提出一个在.NET环境下，基于WEB服务技术的软件测试管理系统的解决方案。
在本文中，详细介绍公司所开发的测试管理系统的设计和实现过程。它运用公司提供的开发平台的公用模块，并采用面向对象的分析方法，再以先进性，易用性，完整性，扩展性，易维护性等设计原则为指导来完成此系统的设计和实现。
综合开发平台即是提供一个开发平台，其底层和通用功能已经实现，它具有先进的技术和成熟技术框架。因此深入阐述平台的功能，以及其技术框架和框架所具有的特点（MVC框架，动态服务，服务-方法，设计接口，日志）。并以先进性，易用性，完整性，扩展性，易维护性等设计原则为指导来考虑本系统的设计。
最后强调系统的重要功能：此系统有效地控制需求分析覆盖、测试计划管理、制定自动化测试脚本的运行和对测试中产生的错误报告进行跟踪，并确保该缺陷有相应的人员进行修复或制作相应的补丁。

关键词：测试管理，综合开发平台，面向对象，.NET，查询算法

毕业设计（论文） 第 26 页
Testing Management System Design and Implementation

ABSTRACT
Saying goes, we must first sharpen his tools. Good tool for project personnel can improve the efficiency of the test. for example MI testdirector,it is a web_based application system. The Object whose will use the tool extends to the quality control department, and users and other relevant part. It will allow more users to take part in the test, and is conducive to the project manager of project progress and efficiency of a global understanding. So our company offered the Web services technology-based software testing management system solutions in .net environment.
In this paper, introduce the system design and implementation process, we will a brief introduction of the test management system development background, meaning, and some technical background, let people have a general impression.
focus on the overall system framework. Integrated application development platform for system utility module provides some base technology and mature technology framework. So go into the details of the functional and technical framework and the framework of the characteristics (MVC framework, dynamic services, Service-way design interface, and log). Again use advanced, easy-to-use, integrity, scalability, ease of maintenance, and other design principles to guide the system to consider the design.
We also specially explain the important functions of this system. this system effectively control coverage requirement analysis, testing program management, automated test script development of the operation and testing of the tracking error, and to ensure that the corresponding defect repair or staff produced the corresponding patch.

Key words：Testing management，Integrated platform，.NET，Query algorithm

目 录
1. 绪论 1
1.1 国内外研究现状 1
1.2 论文背景以及意义 2
1.3 系统的一些基本概念 2
1.4 系统功能 3
2. 系统总体设计 4
2.1 总体结构 4
2.2 设计思想 4
2.3 设计难点 5
2.3.1 项目管理分析 5
2.3.2 测试流程分析 6
2.3.3 如何组织测试用例 8
2.3.4 如何确定BUG修改权限 9
2.3.5 预留接口问题 10
2.4 设计关键技术 10
2.4.1 MVC框架 10
2.4.2 综合开发平台 12
2.4.3 面向对象分析方法 14
3. 测试管理系统的重要功能实现 16
3.1 测试需求 16
3.2 测试计划 17
3.3 测试执行 18
3.4 BUG管理 19
3.5 附件上传 19
3.6 静态数据维护 20
4. 主要算法研究 1
4.1 查询算法 1
4.1.1 查询条件 1
4.1.2 两种关键字检索方式 1
4.1.3 实现过程 1
4.2 查询算法的改进 2
4.1.4 字匹配程度的可能性 2
4.1.5 匹配项的确定 2
4.1.6 改进算法的实现 3
4.1.7 值得注意的问题 3
总 结 1
致 谢 1
参考文献 2

1. 绪论
1.1 国内外研究现状
测试管理系统，一般而言，就是对测试需求、测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员 通过一个中央数据仓库，在不同地方就能交互信息。
现在市场上比较著名的测试管理工具有：Testdirector，Bugzilla和ClearQuest。从表1.1中，我可以看出这几种测试工具各自的优缺点：
表 1.1 测试工具比较
名称
Testdirector
ClearQuest
BMS
Bugzilla
流程定制
Y
Y
N
Y
查询功能定制
Y
Y
Y
Y
功能域定制
Y
Y
Y
Y
用户权限分级管理
Y
Y
Y
Y
Email通知
Y
Y
Y
Y
构架模式
B/S
C/S,B/S
B/S
B/S
报表定制功能
Y
强,集成Crystal Report
有标准报表和高级报表,定制功能不够
Y
支持平台
Windows
Windows, Unix
Windows
Linux, FreeBSD
支持数据库
Oracle, M$ Access, SQL Server等
Oracle, M$ Access, SQL Server
SQL Server等MSDE
MySQL
从上可知，在测试管理系统的设计方面，西方国家起步较早，尤其是美国，已经达到了较高的水平。而我国的软件测试还处于起步阶段，各种软件测试的方法、技术和标准都还在探索阶段，更别说测试管理系统的设计了。
但是随着国内IT企业对软件测试的重视，相信在以后不久，我国有一款具有中国特色，且适用的测试管理系统问世。
1.2 论文背景以及意义
就目前这几款测试管理系统来看，大多数比较昂贵。尽管其优势表现在其售后服务好，工具强大，且容易使用。但作为公司的测试人员，可以考虑设计一款测试管理工具。理由有如下四点：
1. 每个公司的情况不一样，那么测试管理方法也不一样。更别说测试流程。公司可根据自己的实情出发，开发一套适合自己的测试管理系统；
2. 本公司的综合平台是一个基于标准、组件化、架构良好、具有很好扩展性的多层的开放的软件体系。提供一个统一、简单、基于标准、易于扩充的基础软件平台，未来需要构建应用、整合应用、扩展应用，都可以在这个平台上实行。虽说作为一个测试人员，对编程知识不是很熟悉，但完全可以胜任此次编码工作；
3. 公司拥有自己的测试管理系统，可公司节省一大笔开支，必要时也有更好的自由扩展度；
4. 建立一个基于WEB的系统，可加强各个部门的沟通，也方便测试人员不管在何时，何地参与整个测试流程。
避免了测试人员和开发设计人员之间面对面的交流，减少了以往难免的摩擦，提高了工作效率，也便于管理者对工作进度的准确评估和工作业绩的考核，工作进程的有效控制和工作进度的及时调整。
1.3 系统的一些基本概念
1．测试需求。是指捕获、记录并管理需求的系统化方案。没有它，三分之二的项目都会因遗漏用户需求，延期或者超出预算的权威报告。其特点是：包含软件需求，具有可测试性。
2．测试计划。主要是针对测试用例。而测试用例是指是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。在我们系统中，牵涉到用例审核问题。
3．测试执行。如同测试计划，通过某种算法，使得两个页面的用例在某种程度上保持一致。
4．Bug管理。软件测试时，发现软件存在的错误。对于如何处理测试中发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。因此，对于每个Bug都要经过测试、确认、修复、验证等环节。
5．静态数据。在系统中，我们把某些公用的，内容相对不变的一类数据称为静态数据。比如，本统中的资源类型和资源格式就是两种典型的静态数据。静态数据实际上是可以动态添加和删除的。静态数据概念的提出是为了数据处理的方便，提高数据的通用性，使得平台各个功能部分的相关数据可以很容易的进行转化。
1.4 系统功能

图1.1系统功能图
2. 系统总体设计
2.1 总体结构
系统总体结构如图2.1所示：

图2.1总体结构图
测试管理系统由三个层面一个管理体系组成：基础网络系统平台、创智基于CRM的开发平台、在公司平台上开发的测试管理应用系统；一个贯穿系统三个不同层面的安全和管理体系。
1．测试管理系统网是由办公的局域网（内网）、对外信息发布和对外公众服务网（外网）组成。
2．创智基于CRM的开发平台采用了2.4.2节中描述的技术开发出来的成功产品。提供了快速而高质量开发应用系统的各种工具、功能组件、集成模块；同时提供系统不同层级的安全与管理措施；
3．在此平台上，采用2.4节描述的系统开发路线，应该能高速、高质量的开发出用户需要的应用系统。
2.2 设计思想
1．先进性。应用系统使用目前成熟、先进的技术，采用符合NET标准的应用服务器体系结构。软件设计思想先进，软件设计方法规范。
2．完整性。系统的整体规划要在充分了解现有管理和技术状况的基础上，努力把握管理和技术的未来发展方向。系统规划要力求思路清晰、目标明确、原则具体、计划可行，既符合现有状况，又能满足未来系统发展变化的要求，为系统的发展变化留有充分的扩展接口。
3．易用性。整体规划的指导下，系统的具体实施必须坚持实用、有效的原则。系统的功能设计不仅要满足现有业务的需要，而且要操作简便、实用，能最大限度地发挥各类资源和技术手段的作用，使管理人员从简单烦琐的事务中解脱出来，提高他们的工作效率和管理水平。在技术路线和技术产品的选择上，应在充分论证的基础上，选择那些能满足要求、成熟的、可持续发展的技术。
4．扩展性。不变是相对的，发展变化是绝对的。随着公司管理体制的变革，测试管理体系也会发生变化，管理人员的学习和提高，许多新的业务要求被提出来，为满足这些新业务的需要，应用系统要不断更新变化，同时随着信息技术的发展，新的技术手段不断涌现，为提高运行效率，改善服务性能，系统的技术方案也要不断发展变化，因此系统的建设和实施必须牢固树立发展的思想，坚持变化的原则，适应发展变化的要求。因此，系统应具有丰富的扩展功能，允许被授权用户自行扩展新文件，配置各种文件格式、查询方法、流程、角色、权限等。
5．易维护性。高度模块化，软件交付使用后，允许被授权用户在不需要读懂源程序代码的前提下，控制和更改几乎所有的表格格式和功能实现。
2.3 设计难点
2.3.1 项目管理分析
项目管理是测试管理的先导, 没有良好的项目管理, 测试管理就不能很好的进行, 系统采用基于角色管理的方法对项目进行管理。涉及到的管理角色有3 种: 系统管理员、项目经理和小组组长。项目管理高层用例图如图2.2所示, 显示了测试管理系统与这3 个管理角色之间的交互关系。

图2.2管理角色
其中系统管理员角色负责基本的配置管理。
用户管理、角色管理和项目管理; 项目经理角色主要负责对项目的管理, 包括项目任务分配、人员的管理、项目进度查看和项目报告生成等; 小组负责人角色主要完成对项目中任务的管理, 包括测试人员和开发人员工作安排等。
2.3.2 测试流程分析
在本系统用，需求，用例，BUG是可以看作独立的部分，但从软件企业的长远发展来看，如果要提高软件质量，必须从流程抓起。尽管目前的测试流程方法很多，但其中最具有代表的是需求阶段流程图和系统阶段流程图。所以需求，用例，BUG并不孤立，可以当作流程中的一个环节看待。
在设计数据库时，考虑到一个需求可以对应多个用例，因此在用例表中，增加了需求ID字段（暂时不考虑需求跟用例的多对多关系）。
同样道理，在BUG表增加了用例ID这个字段（暂时不考虑1个BUG对应多个用例的情况）。
在本系统，就可以很清晰地看出需求、用例和BUG的关系，如图2.3：

图2.3需求测试流程

图2.4系统测试流程
2.3.3 如何组织测试用例
软件测试不仅仅包括对开发程序进行测试，也包括对需求，设计以及文档进行测试。以下重点列举开发程序测试的分类：
按照开发阶段划分，可分为：单元测试，集成测试，系统测试，确认测试，验收测试；
按照测试实施组织划分，可分为：开发方测试，用户测试，第三方测试；
按照测试技术划分，可分为：白盒测试，黑盒测试，灰盒测试；
按照测试类型来分：可分为：性能测试，功能测试，界面测试等等；
由上可知，测试分类是繁多的。如何组织一个思路清晰，没有冗余的测试框架，这是设计时后，必须要解决的问题。
因此提出一种综合的处理办法：增加一张目录表，让测试相关人员自己去管理测试用例。
2.3.4 如何确定BUG修改权限
在软件测试管理活动中，BUG状态修改的活动比较多。通过参考一些资料，结合公司的具体情况，本系统的BUG状态有如下几种：new（新的BUG），open（激活），resolved（解决），postponed（推迟解决），fixed（修复），won’t fixed（无法修复），by design（设计引起），not repro（不重现），closed（关闭）。

图2.5 BUG修改图
其中resolved（解决），postponed（推迟解决），fixed（修复），won’t fixed（无法修复），by design（设计引起），not repro（不重现）是测试人员提交BUG后，程序员处理这些BUG的原因。然后测试经理根据实际情况，判断此BUG是否要重新激活。
2.3.5 预留接口问题
根据需求，本系统将来可能要实现需求导入的功能，这样就必须在现有系统中扩展此系统。虽然我们现在没有实现此功能，但是在数据库已经预留了接口。在数据库需求表中，已经预留了需求的来源这个属性。
2.4 设计关键技术
2.4.1 MVC框架
MVC模式是“Model-View-Controller”的缩写，中文翻译为“模式-视图-控制器” 。MVC应用程序总是由这三个部分组成。Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。类似的，只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己。在现在软件开发体系中，MVC的框架结构已经得到了淋漓尽致的应用。因为在业务扩展上、人员架构上都得到充分优势体现。

图2.6 MVC框架结构图
我们来了解一下MVC三个部分在net架构中处于什么位置，这样有助于我们理解MVC模式的实现。MVC与net架构的对应关系是: :View处于Web层或者说是客户端，通常是aspx页面，即页面显示部分。Controller也处于Web 层，每个aspx对应了一个后端代码aspx.cs，可以通过aspx.cs方便地来实现Controller，即页面显示的逻辑部分实现。Model处于中间层，通常在服务端的实现，即业务逻辑部分的实现。
尽管构造MVC需要额外的工作，但它带来的好处却是不容置疑的：
1. 提高代码重用率
最重要的一点是多个视图能共享一个模型，无论用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于已经将数据和业务规则从表示层分开，所以可以最大化的重用代码。
2. 提高程序的可维护性
因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变数据层和业务规则。例如，把数据库从MySQL移植到Oracle，或者把基于RDBMS数据源改变到LDAP，只需改变模型即可。一旦正确的实现了模型，不管数据来自哪里，视图都会正确的显示它们。MVC架构的运用，使得程序的三个部件相互对立，大大提高了程序的可维护性。
3. 有利于团队开发
在开发过程中，有利于更好的分工，更好的合作。良好的项目架构设计，将减少编码工作量 ：采用MVC结构 + 代码生成器，是大多数Web应用的理想选择。部分模型(Model)、和存储过程一般可用工具自动生成。控制(Controller)器比较稳定，一般由于架构师（也可能是有经验的人）完成；那么整个项目需要手动编写代码的地方就只有视图(View)了。在这种模式下，个人能力不在特别重要，只要懂点语法基础的人都可以编写，无论项目成员写出什么样的代码，都在项目管理者的可控范围内。即使项目中途换人，也不会有太大问题。在个人能力参差不齐的团队开发中，采用MVC开发是非常理想的。
2.4.2 综合开发平台
综合开发平台，顾名思义就是提供一个开发平台，此平台可以提供综合的功能；开发者在上面只是进行特殊业务模块的编写，而底层、通用的部分已经通过此平台得以实现。通过为各应用系统提供公用模块，简化应用并规范各应用系统的开发；为各应用系统提供相似技术及成熟技术框架。下面分别介绍平台的功能，技术框架和技术特点。
1. 平台功能
(1) 系统管理平台：系统管理平台是“综合开发平台”的基础，每个系统都有系统管理部分。其包括部门、岗位、人员的管理；角色建立以及角色的授权；系统窗口、菜单的生成以及窗口局部模块的控制等。还有一部分不能忽略，就是静态数据的维护。系统管理平台主要包括以下功能：部门、岗位、人员；角色，授权；窗口，菜单，模块；静态数据。
(2) 数据库管理平台：数据库管理包括数据库对象的管理（如表、视图），还包括数据库的备份、恢复。这里要着重考虑的问题是不同关系型数据库间的区别。数据库管理平台还包括通过配置生成报表生成系统：数据库表基本属性 ：包括表、视图、基本定义、列表字段顺序（字段列表、排序字段、排序方式）显示布局调整、权限设置（添加、编辑、删除）等；多数据库；报表生成系统；备份、恢复。
(3) 工作流管理平台：工作流程自动化在近年已成为通俗的流行用语，市场上有许多产品都宣称是工作流程，而大部份的客户也把工作流程和公文或请假差别划上等号。工作流不仅是简单的审批而且可以复杂到不同系统的流转，可以称之为业务流。真正的工作流应该拥有如下的特性：以图形化方式设计流程图，且不需编写程序就可以定义复杂流程逻辑与数据交换；能将外部应用软件纳入为流程自动化的一个步骤；提供完善的流程评量机制与內建报表：包含每一流程、案件、步骤的成本、工时、等待时间分析与统计；提供流程即时监控功能；能提供完善且不需 Coding 的流程触发 (Trigger)机制，可直接从外部软件触发流程，并将数据带入；必需具体工作和负荷管理、逾期自动处理机制、工作权限控制； 能支援多种收件人模式以满足企业內流程应用：指定任务、群组、部门、队列、相对任务、相对关系；具体流程测试与模拟功能，并提供流程管理员的管理概念。
2. 技术框架
综合开发平台定位为C#语言开发，利用C#语言的面向对象属性等特性，完成系统功能的开发。综合开发平台系统采用COM组件技术，并采用了系统框架的设计思想，整个系统将由业务逻辑层和系统框架层有机组合而成。在综合开发平台上进行信息系统的开发时，利用了比较流行，也比较成熟的三层结构――页面层，逻辑层，数据层。页面层只负责数据的收集和展示，而逻辑层则负责数据的业务逻辑处理，数据层主要是完成数据库操作。
3. 技术特点
(1) 动态服务：开发信息管理系统，其不像系统软件，具有复杂的业务逻辑的不多，其主要是面向数据库的操作，包括增、删、改、查等。此框架就是基于这些不复杂业务逻辑的特性完成了统一的操作处理（通过数据库或XML来完成配置）。这样配置的结果是极大的增强了平台构件的复用性，节省了大部分工组量。比如说，我们需要读取一个SQL查询的结果集合。那么，我们在平台里面只需要输入SQL查询语句，设置执行SQL所需要的参数和返回数据集合的名字。这样，我们在ASP页面上，根据数据集的名字，就可以直接读取出SQL语句的返回值。
(2) 服务—方法：系统把业务逻辑的实现归结成一个服务，此服务可能面向一个或几个页面调用。而服务在系统中的体现就是C#类的一个方法。这样设计的好处就是当添加或修改一个业务逻辑时对应的就是添加或修改一个类的一个方法。
(3) 设计接口：此框架的设计与编码严格实现了三层乃至N层，从而在设计、编码、美工等人员架构上得到层面的体现。设计人员在设计的时候，要考虑UI设计。前后台编码人员都是参考此文档进行编码。在设计规范中，包括数据库设计的规范、代码书写规范、变量命名规范、逻辑层次规范等等。
(4) 日志：日志在框架中体现两种日志。一种是系统日志：系统日志采用先进的体系框架，在系统的开发不同阶段对日志进行处理；另外一种是用户日志：用户日志就是用户可以看到的日志，其分为提示与错误警告等两种。提示就是数据不合法、操作不合理等提示。错误警告就是系统在处理的时候出现了底层异常信息。信息的打印方式分为两种，一种就是Alert窗口，一种就是直接在页面打印出来。信息提示时有一个信息提示号，信息提示号可以快速定位错误发生的位置，这样在修改系统以及与客户交流的时候非常方便。
2.4.3 面向对象分析方法
面向对象虽说没有一个明确的定义，最初专指软件程序设计，后来扩展到数据库系统设计，交互式界面，应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。它很早就在软件工程中推广，使得传统的测试技术和方法受到很大的冲击。由于面向对象的引用，原有的测试技术已经无法应用于系统中，面向对象技术它有更好的系统结构，更规范的编程风格，极大的优化了数据使用的安全性，提高了程序代码的重用。因此一些人推断，那么面向对象技术开发出的程序无需进行测试。
但是我们应该看到，尽管面向对象技术的基本思想保证了软件应该有更高的质量，但实际情况却并非如此，因为无论采用什么样的编程技术，编程人员的错误都是不可避免的，而且由于面向对象技术开发的软件代码重用率高，更需要严格测试，避免错误的繁衍。因此，软件测试并没有面向对象编程的兴起而丧失掉它的重要性。
由于面向对象的重要性，因此采用此方法来分析系统管理。
3. 测试管理系统的重要功能实现
3.1 测试需求
我们需要对需求进行必要的维护。包括需求的添加，需求的删除，需求的修改等等。
默认的是系统管理员，项目管理员，项目经理等用户具有添加需求的权限。
在删除中，我们设置了这样一个规则——只有当一个需求下面没有子需求的时候，也就是该需求为叶需求的时候，才允许管理员删除需求。
实现的时候，需求维护界面分为左右两个框架。左边框架为现有框架的树型图，可以任意收拢和扩展。如图3.1所示。

图3.1需求维护树
而右边框架则显示被选择需求的子需求，以及其附件信息如图3.2。在详细信息的基础上，提供删除，添加等操作，如图3.3所示：

图3.2需求列表

图3.3添加需求页面
3.2 测试计划
测试计划和需求一样，需要对其进行维护。包括用例的添加，修改，删除等操作。
默认的是所有人都有添加，修改的权限。
一个测试用例可包括多个测试步骤，因此在设计数据库时，单独把测试步骤从测试用例表中分离出来。因此用户对测试用例修改后，可单独对测试步骤进行修改
也采用框架图，左边框架是目录和用例维护树，如图3.4。而右边显示被选中目录的用例，其界面如图3.5所示：

图3.4目录和用例维护树

图3.5用例列表
也可以添加测试步骤，如图3.6：

图3.6添加测试步骤页面
3.3 测试执行
由于一个用例可能被执行多次，再加上用例设计者可能和用例执行人并不是同一个人（可以通过本系统的角色授权，达到用例执行者没有添加用例子的权限）。所以单独把执行作一个模块。包括用例的添加，删除，修改，查询，排序等功能，如图3.7。用户可以根据测试用例名称，来查询其执行的历史,如图3.8：

图3.7测试执行列表

图3.8添加测试执行页面
3.4 BUG管理
BUG管理是对测试的核心环节问题跟踪阶段的相关工作进行统一管理，方便开发人员，测试人员等相关人员即时了解项目测试情况。提供添加，删除，修改，查询bug，打印等功能
不同角色，对BUG所做的操作也不一样.
当然这并没有已经定好，项目管理人员可根据需要，对重新对用户角色授权。
其模块界面如3.9：

图3.9 BUG列表
3.5 附件上传
有时候，文字描述并不能很清楚表达用户的意思，这时候附件可发挥了重大作用。如在测试一个功能，出现很长的错误，单靠文字描述，既累人，又不好表达。就可以考虑先通过截图工具将这个错误截到WORD文档中，再将此文档当作上传。因此本地上传是需求，用例，BUG的重要来源方式之一。所以，附件上传的实现，对于本系统来说，是非常重要的。下面我们来详细描述附件上传的实现过程：
步骤一：在附件上传页面，选择所需要的附件。
步骤二：在上传文件提交后，系统首先会自动判断整个上传文件的大小及每个文件的大小。如果有文件大小超过系统允许的最大值，那么系统则判断是哪个文件过大，然后提示出错信息，返回。文件大小的限制由XML文件设置。在这个XML文件中，包括文件上传路径，单个文件上传最大容量，所有文件上传最大容量等三个节点。每个节点的值系统管理员是可以根据系统需要手动修改的。如果文件大小检测通过，系统会检测这个文件名是否存在。如果已经存在，则会提示管理员修改文件名再上传。
步骤三：在上传文件通过检测后，系统就会读取附件文件。附件文件在这一步中会上传到本地硬盘上面，同时将附件信息保存到附件表中。
整个上传过程的流程图3.10所示：

图3.10附件上传
3.6 静态数据维护
静态数据在我们系统中是一类比较特殊的数据。我们在系统中存储静态数据的时候，并不是把每类静态数据作为一个表，而是把所有类型的静态数据存储在一个表中，每种静态数据类型作为这个表中的一个属性，所有这种分类下的静态数据，都作为这个属性的值。这点和我们平常的数据存储方式有点不同。但是，为了用户的操作习惯，在操作界面上，用户仍然会感觉到操作静态数据和操作平常数据没有什么不同。数据格式的转换由系统在后台完成了。
静态数据操作的界面如图3.11所示。

图3.11静态数据维护
对于每一种类型下的静态数据，我们可以执行添加、删除、修改等操作，而且，我们还可以任意新增一个静态数据类型。这些操作对于用户来说，是非常方便的。
4. 主要算法研究
4.1 查询算法
4.1.1 查询条件
根据需求，用户查询的条件是可以分为两类的。第一就是需求/目录分类；第二，是需求，用例，BUG等详细信息查询。
这样，每个用户可以发送的查询请求从本质上来说是分为两种类型的。第一，就是根据分类来检索所有符合条件的结果集合；另外一种，就是根据输入关键字来进行某次检索。当然，实际情况下，这两种检索往往是综合起来进行的，也就是说，我们的检索往往是一次检索结果在某个分类下的映像。
4.1.2 两种关键字检索方式
第一种是根据用户选择的与或条件来决定关键在在查询条件的匹配方式。目前大部分的系统都是采用这种关键字处理方式；第二种就是根据关键字的匹配程度来返回结果结合。这种模拟百度返回结果结合的方式，无疑是比较合理和人性化的。
本系统的初步实现中，采用的是第一种匹配方式。
4.1.3 实现过程
具体算法实现步骤如下：
1. 获取用户选择的分类；
2. 判断用户选择的分类是否是叶子分类，如果是，则返回分类ID，跳转到第6步；如果不是，则到第3步；
3. 根据树的前序遍历，获取此分类下的所有叶子分类，以字符串的形式返回；
4. 处理第三步返回的字符串，获取所有返回的分类ID；
5. 根据预先设置的关键字规则，生成关键字序列；
6. 根据与或条件和前面步骤返回的分类ID，生成SQL检索语句；
7. 执行SQL语句，将结果集合返回。
4.2 查询算法的改进
4.1.4 字匹配程度的可能性
在这里，我们首先需要考虑的问题，就是对于一个关键字集合，我们如何确定其匹配的可能性。如果只有一个关键字，这是显而易见的事情。匹配情况只有一种，即C11 种可能性；如果是两个关键字，就有三种可能的匹配情况了。假设关键字为A和B，则三种匹配情况为如下：
1. 匹配A&B；
2. 匹配B；
3. 匹配A。
上述匹配情况有3种，即C21 + C22 种可能性。
如果有三个关键字，则匹配情况稍微有点复杂了。设关键字为A,B,C。我们把匹配情况列在下面：
1. 匹配A&B&C；
2. 匹配A&B；
3. 匹配A&C；
4. 匹配B&C；
5. 匹配A；
6. 匹配B；
7. 匹配C。
上述匹配的可能性有7种，即C31 + C32 + C33种可能性。
所以一个关键字集合有N个关键字条目，那么它匹配的可能性有Sn种：
Sn = Cn1+ Cn2+ …… + Cnn (1)
4.1.5 匹配项的确定
在每个关键字集合中，关键字可能有多少种匹配的可能性。在这里要确定同种匹配程度中的匹配项，也就是说，每种情况中，关键字条目中的匹配关系。
还是以一个实例来讨论这个问题。假设关键字结合中的条目为：A，B，C，D。最先返回的结果集合应该是匹配A&B&C&D；其次回的结果集合应该是匹配(A&B&C)or(A&B&D)or(A&C&D)；再其次返回的结果结合应该是匹配(A&B)or(A&C)or(A&D)or(B&C)or(B&D) (C&B)or(C&D)；最后返回的结果结合应该是匹配A or B or C or D。
这样，匹配项的问题就转化为了一个求幂集的问题。求幂集一般采用递归调用。
4.1.6 改进算法的实现
当解决求幂集的问题后，生成SQL检索语句相对而言比较容易。实现步骤如下：
1. 获取关键字集合，转化为字符串数组；
2. 获取字符串数组中值的个数；
3. 对getsubset算法进行必要修改，生成所有可能的匹配项，返回值为KeySet；
4. 将KeySet转化为字符串数组，其元素个数必定为2^n-1；
5. 生成SQL基本检索语句；
6. 将KeySet中所有元素按照长度拆分为n个数组，长度相同的元素归类为同一个数组，并且按照递减排列。设新数组为KeySet_i；
7. 对于每一个KeySet_i数组，将其中元素作为限制条件添加到SQL基本语句中。如果KeySet_i中元素不止一个，那么各元素之间以或的关系来作为SQL语句的限制条件；
8. 将生成的n条SQL语句用union关键字连接，执行检索语句。
4.1.7 值得注意的问题
提交查询信息的效率，除了从算法上改进之外，对数据库结构的优化也是相当重要的。因为在这样的本系统中，执行最多的操作还是对数据库的操作。读取数据库资源的性能直接影响到整个系统的性能。我们知道，索引是从数据库中获取数据的最高效方式之一。各种研究结果表明，95%的数据库性能问题都可以采用索引技术得到解决。根据数字图书馆的业务需求，按照检索的建立规则，我们可以考虑把常用查询条件字段建立索引。如在查询需求，就可以对需求编号，需求名称，编写者，是否审核等五个属性建立索引。
总 结
通过此次编写毕业设计论文，可以用收获颇多来形容：
1．以前都是看别人怎么管理测试，现在却面临测试管理系统来设计的任务。为了弥补自己测试知识不足，找了大量的文献来充实自己。
2．到公司后，接触开发技术很少，这次开发此系统，让我重新温习了编程知识。虽说自己会走测试这条路，但对一些需要编码的测试工具大有益处。
3．开发出来的系统，虽说不能算是很完美，但在基于WEB服务基础下，却支撑了整个测试流程（需求，用例，执行，BUG管理）。
4. 由于公司的测试人