热门论文
最新论文
软件测试信息管理系统的设计与实现
发布时间：2023-01-03 13:39
目录
第一章 绪论 1
1.1项目背景及意义 1
1.2国内外研究现状 2
1.3本文研究内容 4
1.4本文组织结构 5
第二章 系统技术路线 6
2.1软件测试的一些基本概念 6
2.2敏捷开发中的软件测试 7
2.3信息管理系统的技术支撑 9
2.4本章小结 11
第三章 系统需求分析 12
3.1项目需求背景 12
3.2项目功能性需求分析 13
3.2.1测试需求管理功能分析 13
3.2.2测试计划管理功能分析 14
3.2.3测试用例管理功能分析 14
3.2.4用例执行管理功能分析 14
3.2.5产品缺陷管理功能分析 15
3.3项目非功能性需求分析 15
3.3.1测试报告统计功能分析 15
3.3.2测试人员成就功能分析 16
3.3.3三方系统对接功能分析 16
3.3.4系统设置功能分析 16
3.4数据模型及系统其它需求 16
3.4.1测试系统数据模型 16
3.4.2测试系统其他需求 21
3.5本章小结 22
第四章 系统详细设计 23
4.1系统架构设计 23
4.2系统模块综合 25
4.2.1测试需求管理详细设计 26
4.2.2测试计划管理详细设计 27
4.2.3测试用例管理详细设计 28
4.2.4用例执行管理详细设计 29
4.2.5产品缺陷管理详细设计 30
4.2.6测试报告统计详细设计 31
4.2.7测试人员成就详细设计 32
4.2.8三方系统对接详细设计 33
4.2.9系统设置详细设计 34
4.3数据库表详细设计设计 35
4.4本章小结 42
第五章 系统具体实现 43
5.1系统的开发环境简介 43
5.2系统的总体技术实现 43
5.2.1系统的前端技术实现 43
5.2.2系统的后端技术实现 43
5.3系统的模块具体实现 44
5.3.1系统设置具体实现 44
5.3.2测试需求管理具体实现 49
5.3.3测试计划管理具体实现 51
5.3.4测试用例管理具体实现 53
5.3.5用例执行管理具体实现 56
5.3.6产品缺陷管理具体实现 59
5.3.7测试报告统计具体实现 62
5.3.8测试人员成就具体实现 64
5.3.9三方系统对接具体实现 67
5.4本章小结 69
第六章 系统测试 70
6.1系统的测试环境简介 70
6.2系统的测试类型 70
6.2.1单元测试 71
6.2.2组件测试 71
6.2.3功能测试 72
6.2.4冒烟测试 74
6.2.5集成测试 75
6.2.6性能测试 75
6.2.7稳定测试 76
6.2.8探索性测试 76
6.3 系统的测试结果 77
6.4 本章小结 78
第七章 总结与展望 79
7.1总结全文 79
7.2展望后续工作 79
致谢 80
参考文献 81
附录 84
主要符号表
SOAP
SaaS
E-R图
TDD
ATDD
GPL
API
POJO
WSDL
XP
HTML5
JavaEE
CSS3
VR
AR 简单对象访问协议
Software as a Service（ 软件即服务） 实体-联系图 测试驱动开发 验收测试驱动开发 通用公共授权 应用程序编程接口 简单 Java 对象 网络服务描述语言 极限编程 第五代超文本标记语言 Java 企业版 第三代层叠样式表 虚拟现实 增强现实
第一章 绪论
1.1 项目背景及意义
在对当前的软件开发和软件测试相关领域的工作进行调查，总结发现，软件 开发活动中，长期存在重开发轻测试，不注重测试管理。主要表现在［1］以下几个 方面：
其一，测试人员介入时间晚。软件开发需求阶段，只有项目管理者和产品研 发人员参与需求分析，产品测试人员是在软件开发阶段才被包含进来；
其二，测试用例审阅流于形式。测试人员编写的测试用例，在进行审阅时， 没有有效的回复，导致测试用例修改效果甚微，测试用例需求覆盖不全；
其三，产品测试缺陷记录反映不真实。测试人员对测试工具不熟悉，提交的 产品缺陷，无法真实反应产品的问题级别。项目管理者随意修改缺陷数以满足产 品发布需要；
其四，测试任务分配统计缺乏科学性。测试人员执行的任务（主测试任务和 支援性任务），无法有效记录。测试任务分配和测试任务统计没有有效关联，管 理缺失；
其五，测试资源管理混乱。测试计划、测试用例和测试工具没有有效管理， 新人和测试执行人员无法定位资源，导致测试效率低下；
其六，测试报告格式不规范。测试报告编写效率低下，格式不统一，无法重 复使用。
结合以上问题，期望设计出一款软件测试［2］方面的专业管理软件可以对测试 的各阶段相关信息进行合理的、有效的管理。从而使测试需求明确、测试用例编 写有效、测试资源保存得当、测试进度查询便利、测试报告高效输出、测试成果 记录科学。目前常用的对软件进行测试的工具包括了 QC、Mantis、Bugzilla 和 Testlink等几种，在这些软件中，有部分是开源的，能够免费使用的软件，但也有 部分是收费的，商业性的软件。在这些测试工具中，都有着各自的特点，如 Mantis和Bugzilla工具能很好地对测试的缺陷进行管理，Testlink工具则擅长对试 用例进行管理，而Redmine工具在测试项目的管理方面会显得更加高效一点，QC 虽然全面，但太重量级和商业化。都无法完全满足设计需要，为此，本着开源高 效，着手设计一款通用类型的软件测试管理软件。
由于国家政策鼓励发展软件产业，所以软件产业发展很快，软件企业的数量 迅速增长。但进一步分析这些企业的产品，普遍存在缺少核心技术和缺少高层次 人才（如：软件测试人才和软件分析人才）。也就是是说为提高软件质量［3］和研发 速度，软件测试环节必须加强，软件测试在软件开发中的地位越来越重要。特别 是敏捷概念从国外引进国内后，开发模式的改变，更加需要一个快速响应的测试 过程，但测试上的敏捷，却不是简单的缩短时间，这势必要面临着测试自动化， 持续集成，从而能够开发更多的软件测试工具和技术来提高测试的效率，如建立 质量的反馈系统、质量的检查系统等，产品中的测试等一系列措施，而这一切的 指向结果就是一个完整软件测试信息管理系统，随着中国信息化战略的不断深入， 国内软件市场前景是非常广阔的。现在国外很多著名软件企业已看好中国市场， 纷纷表示要抢占中国市场。因此我们中国的软件企业必须抓紧时机，积极参与国 际竞争，尽可能多地占领国内市场份额。
1.2 国内外研究现状
信息技术的革命最先发源与西方，很多软件领域的标准，规范都是由西方制 定，软件的开发测试成熟度，相对于国内来说,更加完善和精细。软件开发商和软 件应用商都十分重视软件产品的质量［4］。从软件的开发过程中，重视软件的测试， 到软件的交付过程，严格把控软件的质量。由此产生了大量不同的测试管理软 件。
从 2004 年出品的 TestLink 工具是根据 web 所建立的测试系统，其包括了对产 品的管理、测试计划的建立以及对测试的用例进行管理等。除此之外，在 TestLink工具中，还包含了统计模块，能够为用户提供简单的统计功能。TestLink 偏重测试用例管理。同时期的产品，如 Testtrack、Zephyr、IBM Rational Quality Manager、Enterprise Tester，有开源产品，也有商业化的产品，但本身均不包含缺 陷管理功能，都是通过集成第三方产品实现。测试管理软件的另一个功能就是对 缺陷的跟踪功能，目前已经有多种能够完成对缺陷进行跟踪的软件，如 Bugzilla 和 Mantis 等。其中， Bugzilla 能够对测试对象中的 Bug 进行跟踪，包括报告 Bug 的位置、对Bug出现的记录进行查询，从而通过记录来生成报表，并对Bug进行 处理等一系列完善的缺陷跟踪的管理体系。 Mantis 是基于角色和项目模块为划分 的 BUG 跟踪系统。其中 TestLink 可与 Mantis 或 bugzilla 进行集成。
2006 年出品的 Redmine 软件是一款基于 web 开发的主要用于对项目进行管理 的软件，它利用的是ROR框架，能够为客户提供跨平台的项目管理服务。除此之 外， Redmine 还能够与其它系统结合工作，从而对测试对象的 Bug 进行跟踪，如 与 Perforce、 SVN 和 CVS 等软件共同工作。 Redmine 能够通过完成项目而将各种 资源进行搜集和整理，能够实现多成员共同完成一个项目的服务，同时，系统汇 总会以时间为线索，实现实时、动态地向各个参与项目的成员汇报当前的项目进 度，但是， Redmine 最多允许 100 位成员参与，经过研究，发现在 100 名以内成员 所参与的项目中， Redmine 能够很好地完成任务。
到 2010 年微软出品的 Microsoft Test Manager/Team Foundation Server，相比较 testlink 的轻量级，其包含测试的所有阶段措施，如产品规划，探索性测试，测试 用例生成，手工执行，自动执行和持续部署，错误的创建和跟踪，测试结果报告。 但由于其是微软公司 Visual Studio 的一部分，所以属于商业产品，具有明显的局 限性。同时期的产品，如 HP Quality Center、Silk Central Test Manager> TestLodge、 TestRail 均提供全面解决方案，但由于是商业产品，只能免费有限使用。基于云 和移动应用的广泛发展，测试管理工具已经进军移动和 SaaS 领域。目前市面上最 佳的测试管理工具，如 qTest、 PractiTest 都已经做到一个完全的 SaaS 终端到终端 的质量保证和敏捷友好测试管理工具。当然它们同样不开源。
反观国内，从2000年之前，没有任何一家软件公司专门设立软件测试岗位， 到 2003 年后，随着国内软件外包［5］公司的快速发展，测试服务机构犹如雨后春笋 般不断地涌现，而测试的技术也在不断的进步，其能够测试的领域和测试的种类 也在不断的增长着。随着测试技术在各个领域中的应用，越来越多的人开始关注 这种技术，在高校中也出现了测试技术专业及其相关的专业，这能够为测试领域 提供人才的保障。软件测试管理工具的发展明显落后于国外，目前市面上流行的 软件测试管理软件，比如，国内的禅道工具，就是为了完成测试而开发的，禅道 工具属于免费的开源软件，它能够对产品的研发、测试等环节进行管理，利用目 前主流的开发方法 Scrum 技术。同时，又在软件中增加了对系统 Bug 的管理，以 及测试用例的管理，发布管理和文档管理等对软件进行测试过程中需要管理的部 分。禅道测试工具能够囊括了测试过程中的核心流程，为用户提供了集成化的测 试工具，其内部集成的三十多个功能模块，以及两百多个功能节点，能够全面地 对项目各方面进行管理。能够很好地解决由于过于复杂，上手慢，定制能力不足， 不好用层级结构管理用例。Bugtags利用实时性好的问题上报方式，能够提高问题 上报的效率，从而提高对问题解决的效率。与此同时，Bugtags还能够对过期、失 效的信息进行管理，但是，这些功能的实现主要还是出于开发团队的实际需要出 发的。
更多的，比如腾讯优测、百度MTC、阿里云测、搜狗云测等，均属于借力 “云”技术，发展起来的移动应用测试平台，不具有普遍性和广泛适用性。我国 在软件专业测试管理软件研发方面明显落后于同类型国外产品。
结合上面国外软件测试管理软件的发展情况，可以看出，目前的软件测试管
理软件存在，做的好的测试管理软件，一定是商业公司非开源的，开源的测试管
理软件，无法提供一个完整的软件测试行业规范的开发流程的完全解决方案，需 要配合其他开源管理软件集成使用，而这必然会涉及到不同产品的更新换代落后， 不同产品间整合的兼容性问题。
1.3 本文研究内容
软件测试信息管理系统（简称：STIMS）正是分析目前已有的软件测试管理 工具，总结软件测试相关的技术理念和经验，从而能够使工具很好地避免了以往 的工具中存在的不足，通过加入现代化的信息技术，为软件的测试提出完善的方 案。它很好的诠释管理、执行和成果这三者的关系。
STIMS 包括五大基本功能和四大辅助功能：
1） 测试需求管理，对项目的需求分析文档进行管理，把需求添加进去，可以 方便分析测试用例对测试需求的覆盖进行管理。其中，对软件的测试需要对其中 的功能进行测试，如增加、修改、删除和查询等功能。
2） 测试计划制定，为项目新添加一个测试计划，必须要有测试计划才能进行 测试用例的添加和测试的执行。测试计划制定主要实现的功能：测试计划修改、 删除、增加、查询。
3） 测试用例管理，对项目的测试用例进行管理，把测试用例添加进去，方便 测试的执行。其包含测试用例的增删改查。
4） 测试用例执行，执行测试用例，可以在工具上修改测试用例的执行状态， 方便管理。实现的主要功能有执行人员分配、执行工具分配、执行进度查询、执 行结果查询。
5） 产品缺陷管理，根据测试结果，记录产品不同级别的缺陷，方便跟踪问题 状态。其主要功能包括产品缺陷录入、解决人员分配、产品缺陷查询。
6） 测试报告统计，按照一定的模板生成不同的测试报告，方便从不同角度和 级别对产品需求的完成情况进行统计。软件测试信息管理系统该模块包括的主要 功能有报告样式管理、缺陷报告输出、测试报告输出、总体报告输出。
7） 测试人员成就，完整记录测试人员的测试工作情况，如编写测试计划，测 试用例，提交缺陷等一系列成就。功能主要包含成就样式管理、个人成就输出、 团队成就输出。
8） 三方系统对接，按照第三方系统生成测试人员工作数据，提高求职的职位 契合度，增强工作在社交方面的正向作用。该模块主要包括领英系统接口、微信 系统接口、游戏系统接口。
9）系统设置，主要完成系统参数的管理、系统用户管理以及用户的权限管理。
1.4 本文组织结构 第一章，绪论。介绍了论文的目的、意义及本文的工作内容。 第二章，系统技术路线。介绍了系统依赖的关键技术和理论依据。 第三章，系统需求分析。介绍了系统的实现目标，并详细分析了业务流程和 系统功能和非功能需求。
第四章，系统详细设计。介绍了系统的架构，模块，存储，并详细阐述了功 能模块和数据库E-R关系。
第五章，系统具体实现。介绍了系统各模块的开发情况，实现方法以及重要 代码。
第六章，系统测试。介绍了系统不同阶段测试工作，以及测试环境和测试结 果。
第七章，总结与展望。总结了本文的现阶段工作情况，并对进一步的工作进 行展望。
第二章 系统技术路线
2.1软件测试的一些基本概念
对软件的测试是软件开发中不可或缺的一步，它能够通过预设的条件，在这 些条件下运行，并对软件的质量进行检测，主要包括了检测软件程序是否存在错 误、系统是否存在 Bug 等，此外，也对软件的性能进行检测，判断其是否能够满 足设计的要求等。对软件所做的测试目的是为了找到开发的程序中是否有不正确 逻辑而运行程序的活动。在对软件的测试中，能够选用的方法有很多，而对于软 件的测试，尤其是比较复杂的软件的测试，不仅仅是开发过程中的一个环节，还 是对以往技术提出挑战的过程。测试工作的进行，无非是一个质疑和解惑的过程， 这也是产品在不断完善中所需要经历的过程。尽管，在测试的环节中，大部分的 流程都是相同的，基本都包括了回顾、检查，但是，对产品的测试无外乎是保证 产品在使用中的流畅程度和稳定性，因此，其中的稳定性能、实用性能和效率等， 还是需要进行测试的主要指标。
在对软件进行测试的方法中，常用的方法可分为白箱和黑箱两种，其中，黑 箱测试主要是对软件的功能进行测试，而白箱测试是对软件的结构进行测试，下 文将对这两种测试的方法进行介绍。
黑箱测试法，能够用于对软件的应用程序和功能模块进行测试，但这种方法 主要是测试软件的表面层，不能够对软件的内部结构和内部的编码进行操作。因 此，软件的测试人员能够在不对软件的内部结构进行检测的情况下，实现软件的 测试功能，也无需懂得编程［6］语言等相关的知识。在操作中，软件的测试人员需 要清楚的认识软件所要实现的功能，也就是在测试软件工具中输送一个已知输出 结果的命令，并对测试软件输出的结果与已知的结果进行对比，从而达到软件测 试的功能。在黑箱测试方法的安排中，能够对测试的软件的功能和应用进行测试， 根据既定的测试要求和规格，自主实现高效的测试。目前，黑箱测试的方法常常 广泛的被用于集成的测试、接口的测试等对象功能实现的检测。
白箱测试法是对系统的内部结构和运作流程进行测试的工具，因此又能够称 为透明测试法。在使用白箱测试方法的时候，系统的操作界面是程序语言，也就 是说，白箱测试的方法通过对编程语言进行检验，从而能够从软件的内部对其进 行测试。软件的测试人员需要对程序语言有一定的认识，通过在测试软件中输入 相关的数据，从而对其输出进行确定，然后白箱测试软件将自动对软件的内部结 构进行测试。白箱测试的方法能够对系统集成的每一个单元路径的准确性测试， 能够发现很多存在系统结构内部的编程上的错误和 Bug 等问题。目前，白箱测试 的方法主要用于软件的单元测试和集成测试两方面。
下图所示的是 V 模型的测试流程， V 模型是瀑布模型中的一种。
图 2-1 V 模型测试流程
在上图中，能够将软件的测试分为不同的环节进行，并且根据不同的测试对 象的关注点而出现不同的测试类型。
单元测试。对单元的测试是检验组成软件的基本模块开展的测试，检验的目 的是为了对软件基本组成，也就是基础的单位进行检查，能够更加容易地发现软 件组成上的错误。
集成测试。集成测试的方式是将程序的功能模块通过封装的方式来集合起来， 分别对集成后的功能模块进行测试，尤其是功能模块的接口，是集成测试中的一 个重点测试的对象。
系统测试。系统的测试主要包含了对系统的功能、界面和性能等方面的测试， 通过模拟用户在软件中的实际操作来对软件进行完善的测试。
验收测试。验收测试是软件开发流程的最后一个环节，由用户对系统进行最 后的测试和验收，验收测试同时也是对产品确认的一个环节。
2.2敏捷开发中的软件测试
敏捷的开发过程是指在上世纪九十年代流行的一种软件开发模式，它与传统 的瀑布式软件的开发模式相比，有着更加灵活和轻便的优势。在二十一世纪初期， 有部分该软件开发方式的支持者建立了敏捷联盟。在敏捷联盟中，从成立开始就 提出了四条软件开发的四条基本理念，也就是：人员的交流比工具更重要、产品 成效比侃侃而谈更重要、客户［7］的配合比合同的要求更重要和跟随实际变化比终 于传统更重要。
根据这四条理念，使敏捷开发中依照的是自己的开发流程，如下图所示：
敏捷开发有个特殊的地方是任务的交替性很高，有重复的时间规律性，并且 能够快速地、连续地完成客户所要求的变更请求。同样的敏捷测试就是在持续修 正产品质量的指标，正确的确立测试策略，确认客户的有效变更要求能得以完满 实现和保证整个开发的过程安全的、按时的发布出客户期望的最终产品。
敏捷测试与一般测试的区别（参见图 2-3）
1.项目组中开发与测试活动同时进行，项目时间较快。
2.功能实现的提交频率高，测试人员经常有压迫感。
3.计划任务划分明确，工作完成效率高。
4.项目资源比较合理，测试不会出现重测的情况，增加工作量。
5.发现缺陷后需记录，团队中人员都很忙，有问题很容易被遗忘。
6.花时间、或难解决但是对产品影响不大的问题一般会放到下个迭代解决。
7.发现缺陷可以很快的修复，对相关的功能测试影响十分小。
8.版本发布比较频繁，影响到测试的执行速度。
9.常常要与开发沟通。
10.团队成员要了解版本的更新情况。
11.测试人员差不多要参与整个项目组的大小会议。
在运用敏捷活动的软件进行测试的过程中，遵循的是敏捷开发的基本理念， 敏捷活动的流程实际上也是思考了测试各个阶段的开展，因此，敏捷活动的模式 能够为软件的测试提供更多的便利。
2.3信息管理系统的技术支撑
做敏捷模式的开发，如何可以敏捷？我们更多依赖一系列完整的工具帮助我 们快速起来。敏捷开发工具的合适以及挑选，对开发团队起着重要的作用。
首先是服务器的结构，在选择服务器的结构上，我们选用了 B/S 的结构，这 种结构与传统的 C/S 结构不同，用户在进行访问的过程中无需安装任何浏览的插 件，只需要使用用户原本的浏览器就能够对系统进行访问。这种优势能够使用户 和开发者在不同的浏览器中进行操作。在选用服务器端的过程中，选用了高性能 的计算机，并与大型的数据库进行对接，能够保证数据的正常调用。B/S结构能 够简化了软件开发的工作量，它是一种由Internet^发展而来的技术，但是，B/S 的结构对服务器的要求比较高。
Linux是一种自由和开放源代码的类UNIX操作系统。目前运用领域最广泛、 使用人数最多的操作系统之一， linux 系统是上世纪九十年代初的产物，其核心发 布后，在加上用户空间的应用程序之后，成为Linux操作系统。
Ubuntu 是以桌面应用为主的 Linux 发行版， Ubuntu 由 Canonical 公司发布， 他们提供商业支持。它是基于自由软件，该名称来源于小语种，其原意为“人性”， 意指能够为操作者带来更具人性化的操作体验。
Ubuntu计划强调易用性和国际化，以便能为尽可能多的人所用。Ubuntu的所 有发行版本都可以免费获取。自 Ubuntu 12.04 LTS 版本起，针对普通用户的版本 和针对大客户的版本都可以获得长达 5 年的产品支持。
在SSH中，可分为表示、业务逻辑、数据持久和域模块等四个层面。它能够 为开发人员提供架构清晰、便于开发，以及对后期维护流程简化的系统框架。在 SSH中，采用Struts作为基础的模块，主要的职能是分离MV。9】，Struts能够控制 业务逻辑的跳转，并结合 Hibernate 对系统的数据持久层提供帮助。在 SSH 中， Spring 作为框架的管理者，能够对前面介绍的两种框架进行管理，除此之外， Spring 还能够实现分离的功能，能够对系统的业务逻辑和数据持久层进行分离， 这种分离不仅能够减轻系统工作的负荷，还能够提高系统的工作效率。
MariaDB 数据库是 MySQL 的一个分支，主要由开源社区在维护，采用 GPL 授权许可。而开发这个分支主要原因是：甲骨文公司收购了开源的 MySQL 数据 库后，准备将MySQL封闭化，存在不开源的风险，因此原社区采用拉分支的方式 从而避开这个风险。
MariaDB的最终目的是完全兼容现有的MySQL，不仅包括API，同时还有命 令行，使得它能轻松替代MySQL。在存储引擎方面，从10.0.9版本开始，使用 XtraDB （名称代号为Aria）来代替原有MySQL的InnoDB。
Redis 利用 ANSI C 作为基础语言，是一个能够持续性工作的键值对存储数据 库。根据网站 DB-Engines.com 月度排行榜的信息显示， Redis 是使用最多的键值 对内存数据库。Redis是一个高性能的key-value数据库。除此之外，Redis还支持 二进制的数据输入，以及多种数据类型的输入。
Eclipse是常用的开源式的软件开发平台［10］。Eclipse是以Java语言为基础的软 件，但也有通过其它方式进行开发的，如c语言，C++等。实际上，Eclipse工具是 兼容性很强的工具，并通过引入大量的插件，从而成为了软件开发的平台，因此， 开发商以 Eclipse 为框架开发自己的 IDE。
WebStorm 是 Jetbrains 公司的一款 JavaScript 集成开发工具。目前已经中国 JS开发者称赞为“Web前端开发利器”、“最强大的HTML5编辑器”、“最智 能的JS脚本IDE”等。由于与IntelliJ IDEA同源，它也具有IntelliJ IDEA强大的 JS 部分的功能。
Apache JMeter是纯JAVA的桌面应用程序，主要开发用于测试客户端/服务端 结构的软件（例如互联网应用程序）。它可以用来测试静态的和动态的［11］资源性能， 例如：静态文本文件，Java Servlet,CGI Scriptsjava Object，数据库和FTP服务器等 等。JMeter可用于模拟大数据量的负载来测试一台服务器、网络或者对象的健壮 性或者分析不同的负载下系统的整体性能。
而且 JMeter 可以协助测试人员对所测的应用程序进行回归测试。通过测试人 员自定义的测试脚本和断言来检测应用程序返回的值是否如期待的。为了更高的 灵活性，JMeter允许测试者定义正则表达式来创建这些断言。.
Firebug 是一个自由及开放源代码的 Mozilla 基金会火狐网页浏览器扩展，是 一个网络页面的开发工具，开发者可以使用它排错、修改、删除任何网站的 CSS、 HTML、DOM 与 JavaScript 的代码。
Firebug也提供扩展的框架，例如：Yahoo!的网页速度优化建议工具YSlow、 FireCookie、 FirePHP 等。
git是一个分布式版本资源控制的软件。与CVS和Subversion 一类［12］的集中式 的版本资源控制软件不同，它采用了分散式版本资源库的方法，不需要服务器端 的软件，就可以进行版本资源的控制，使得源代码发布和交流变得十分便利。 git 的响应很快，这对于比如 Linux 内核类似的庞大项目来说显得十分重要。 git 最为 称赞的是它的合并追踪(merge tracing)功能。
Apache Maven 是一个软件(特别是 Java 相关的软件)项目管理和自动打包工 具，由Apache软件基金会提供。基于项目管理的模型(缩写：POM)概念，Maven 使用一个中央信息片断就能管理整个项目的编译、打包和文档等步骤。 Maven 项 目使用项目管理模型(Project Object Model，POM)来设置。项目管理模型存储在 名为pom.xml的XML资源中。
2.4 本章小结
本章主要简述了软件测试的一些基本概念，并结合敏捷开发中软件测试不同 之处，介绍了各种不同开源工具，为后面软件开发和测试提供理论和技术支持。
第三章 系统需求分析
3.1 项目需求背景
对所开发的软件进行检验，需要对软件进行系统化的检验，从而能够全面对 软件的质量进行检验。在软件测试的过程中，涉及到对软件的测试管理环节，而 管理环节又包括了对测试流程所进行的环节和模块的管理。目前，常用的测试管 理方法有：传统的笔纸记录方法；程序处理方法和数据表处理方法。在一些规模 大、复杂的软件质量测试的工作中，有条件的用户还会开发自己专用的软件测试 工具，从而能够更好地对软件的质量进行测试。一般而言，大部分的软件质量测 试工作都是通过建立电子数据表来完成。测试的管理是为了能够保证软件开发的 团队在测试的各个环节中能够顺利完成，这些工作不仅仅是一个独立的个体，更 重要的是关注其关联性。从更高的操作层面来看，软件的测试管理工作看上去很 简单，但在实践中会存在着很多的问题，如测试团队人力缺乏问题、资源问题， 以及测试团队并不是总在一个地方，需求方面的难题，与开发保持同步，报告正 确信息。所以为了提高软件的测试管理，大部分的测试管理工作都是在软件开发 前就已经进行规划的，从而使软件测试的过程更快更好地完成。使用基于需求的 测试，协调远程测试资源，定义并执行灵活的测试流程，调整并整合开发的剩余 部分，沟通状态，关注目标和结果，通过自动化来节约时间。在测试管理中对适 当工作的使用工具以使其自动化将极大地提高其价值和收益。
同敏捷开发一样，敏捷测试面临着连续回归过载的负担，并且随着需求的频 繁变化，返工率还可能会倍增，导致测试工作的反复进行。这时，我们需要一个 可以整合一切测试资源，按照开发测试测试流程，能够贯穿起来的一个管理平台， 通过它，能够让测试人员更加清晰的按照明确的需求文档，制定详尽的测试计划； 项目经理可以根据测试的需求，合理分配测试任资源（既包括人员的安排，软硬 件资源的调配），测试执行人员能够按图索骥的执行明确的测试用例；系统根据 测试结果，汇总测试的缺陷情况，以及测试进度，所有流程和工具仅用于帮助敏 捷团队的工作生活更轻松，而不是使流程复杂化或过度转型。敏捷测试人员也应 该花更多的时间来实践测试系统并寻找新的方法来运行，例如使用单线方案，探 索性测试，软件风险测试和错误检查列表，而不是使用测试用例来覆盖测试，创 建和使用足够多的与软件测试或者开发有关的项目文件。敏捷测试人员可以尽全 力通过与客户的沟通来达到完成客户所要求的测试任务。这是敏捷思维价值观念 中核心的一条。让客户满意高于一切。敏捷思维重视客户的需求并要求与客户保 持沟通，以实现对客户需求的完全掌握。而不是通过僵硬的合同条款去框定客户 要求。
3.2项目功能性需求分析
图 3-1 显示了系统的功能模块：
图 3-1 系统模块图
为了满足这样一个良好的目标，现针对以下几个系统需要实现的主要功能进 行了分析：
3.2.1 测试需求管理功能分析
测试需求是整个测试过程的基础，每个参与测试的人员都需要根据测试需求 来分配接下来的工作。所以测试需求对于测试活动来说不可或缺。一般来说，大 部分公司的测试需求，都是文档管理，小一点的公司，会直接使用纸质面对面的 沟通加以聊天软件记录；大一点的公司，会采用 office 办公套件，如 word［13］， excel 来配合记录测试需求计划，并且使用 SVN 等版本管理工具进行管理。后者 虽然比前者在追踪记录有效性方面有改进，但这两种方式都需要人工进行维护， 一旦有人没有及时更新，就会造成执行人员获得的测试需求信息不是最新，从而 导致测试计划的失误。所以将测试需求［14］引入管理软件，会避免版本的不一致， 测试人员可以随时登陆系统维护需求文档，管理人员［15］可以随时登陆系统查询需 求文档，并且系统化的管理，还会为后期测试报告输出时提供极大的便利。从而 避免因为需求文档的管理而对整个项目进度和结果产生不好的影响。
3.2.2 测试计划管理功能分析
测试计划是控制整个测试活动的依据。一个好的测试计划可以完全满足测试 需求的各个需求点，合理安排测试人员和测试时间。然而目前的各大公司的测试 计划都是 PM （Project Manager 项目经理）一个人按照和客户在会议上沟通的 DeadLine （交付时间）来制定和分配的。如果实际参与测试活动的人员未与会， 势必会造成在承诺交付时间上的理解差异。测试计划的制定就会出问题，并且在 任务分配方面，也会出现邮件或者口头指定这种无法完全跟踪的回溯性问题。一 旦后期出现交付理解不一致的问题，再查出处会十分困难。将测试计划整合进管 理软件，会明确该测试计划来源于那个测试需求，即使参测人员未与会，也可以 很好的清楚来龙去脉。并且会方便以后缺陷分析追本溯源。
3.2.3 测试用例管理功能分析
测试用例是测试活动的具体体现，是每个测试人员接触最多也最依赖的指导 测试来源。测试执行人员会根据测试用例编写人员编写的测试用例描述的具体测 试场景来执行测试，然而测试用例的保存，大多数时候却是用纸质文档或者电子 文档来管理，这样在更新文档的内容时同样会存在更新时效性的问题，测试用例 会有TestCase Review meeting（测试用例检视会）这样的活动，如果在会后，检视 建议没有及时正确的更新并反映在后续的测试用例文档上面，就会产生遗漏。也 就会发生需求改了，测试用例没有更改，测试执行人员由于不是测试用例编写人 员，所以也无法发现需求漏测这样测试活动错误。后期来弥补这个错误会耗费较 大的精力。而将测试用例［16］合并到管理系统，会方便用例检视人员，用例编写人 员，用例执行人员对用例的来源都是一处，并且打开系统就可以检视和修改，即 使各个人员不在一处，修改完成后就是最新的。从而提高协同效率，减少需求漏 测这样的错误。
3.2.4 用例执行管理功能分析
用例执行是测试活动中的关键一环，这会与测试的结果相挂钩，从而影响测 试的质量。在用例测试中，测试的人员会通过口头或者邮件的形式收到测试用例 执行的所需要的测试环境，有可能此时整个测试环境还没有从上一个测试活动中 释放出来，测试管理人员（项目经理）没有得到资源的有效信息，从而无法正确 分配空闲的测试环境。对于测试进度的沟通也采用邮件或每日上下班的时间进行 口头沟通，比较好一点的会使用敏捷的 SprintBacklog （每日记录）来同步。如果 测试执行人员未及时更新或者请假，测试的执行情况无法让项目经理及时了解。 引入用例执行管理到管理系统，配合测试计划和测试用例模块，可以更好的了解 测试的执行进度，测试人员每日的执行情况都会反映在测试管理系统的界面上。 项目经理也可以清楚的测试资源的使用情况，做到合理分配。真正做到信息的即 使传递性。
3.2.5 产品缺陷管理功能分析
没有不存在缺陷的产品，对于测试人员来说，发现缺陷是测试工作［17］中的一 个重要活动。围绕缺陷的发现、修复、跟踪也是测试活动中十分重要的环节。将 产品缺陷和测试需求、测试计划、测试用例等有机的结合起来，利于开发人员更 好的了解缺陷产品的原因，该缺陷属于哪个需求，是因为什么操作或前置条件产 生的缺陷，加速了缺陷的修复过程，缩短了花费的时间。另一方面，对于测试管 理人员来说，可以更有效清楚产品的缺陷情况，什么模块产生的缺陷最多，什么 样的测试最有效发现缺陷。大大利于分配缺陷和控制缺陷的增长趋势。
3.3项目非功能性需求分析
为了完善系统的主要功能，势必会有其他非功能性的模块，以下是具体的分 析：
3.3.1 测试报告统计功能分析
一份良好的报告抵过万千文字。测试活动的最好结果展示是一份图文并茂的 测试报告。目前大部分公司的测试报告都是由测试人员根据一定的测试报告模板， 人工对整个系统的测试数据进行整合。整合的时间会根据测试活动的规模大小决 定，少则一两天，多则一周。纷繁的测试结果数据和烦人的纸质或电子文档都会 让测试报告编写人员焦头烂额。而如果拥有测试报告统计这个功能，在测试需求 明确，测试计划制定，测试用例有效执行，这些活动完成后，系统就能按照想要 的报告模板给出一份基本的和定制的测试报告，展现在屏幕上供大家阅览，如果 想归档还可以打印出来，整个过程会变得很轻松。测试人员可以更加关注测试的 本质上面，而不是忙碌于管理者关注的测试报告这一环节上。
3.3.2 测试人员成就功能分析
一个测试活动完成后，除了测试报告的输出［18］，更重要的一点，就是测试人 员本身的自身成就。目前大多数一线测试人员，测试工作虽然被重视，但测试人 员本身没有受到重视，甚至觉得测试人员这个角色能被开发人员兼任。这其中一 个重要的原因就是测试人员自身的产出没有被记录，因为软件活动不是一两个人 可以做好的，而是一个团队。这个原因也往往忽视了作为一份子的测试人员本身。 测试人员成就模块就是一个能在不影响整个测试活动的情况，像游戏中的成就系 统一样，可以关注每个测试人员本身，对其在整个测试活动中的贡献都有所记录。 这样大大增强了个人的自身成就感，也鼓舞了团队士气。对项目管理者更好的了 解测试人员个体打开了一个直接的窗口。
3.3.3 三方系统对接功能分析
目前大多数管理系统都是某一公司或集团为了具体的问题所做的一个私有的， 无法和其他第三方系统对接的内部管理系统。但软件测试活动属于一个流程化、 规范化的活动。这个活动产生的一些公开的数据是可以作为优化和提高该系统的 市场生存能力而存在的。为了增强自身在市场上的竞争性，管理系统引入第三方 对接功能，可以更好利用成熟的通讯工具进行高效的沟通；可以利用知名度高的 求职系统进行个人简历的展示；可以利用交互友好的游戏系统提高工作的轻松 度。
3.3.4 系统设置功能分析
为了各个模块能高效有机的整合在一起，需要一个独立的功能对系统本身的 各项基本参数做到可配置，系统人员做到可管理，系统权限做到可调节。而系统 设置就是将这些功能良好的管理起来，从而使得整个软件测试管理系统可以正常 运转。
3.4数据模型及系统其它需求
3.4.1 测试系统数据模型
图 3-2-图 3-10 为该系统的用例图：
1)测试需求管理
图 3-2 测试需求管理用例图
该图描述了测试需求的添加人员和测试需求具体功能的关系，使用者添加测 试需求，并对测试需求进行修改，还可以按条件查询添加的测试需求，对不再使 用的测试需求可以进行删除操作。
2）测试计划制定
该图描述了测试计划的添加人员和测试计划具体功能的关系，使用者添加测 试计划，并对测试计划进行修改，还可以按条件查询添加的测试计划，对不再执 行的测试计划可以进行删除操作。
3）测试用例管理
该图描述了测试用例的添加人员和测试用例具体功能的关系，使用者添加测 试用例，并对测试用例进行修改，还可以按条件查询添加的测试用例，对不再执 行的测试用例可以进行删除操作。
4）测试用例执行
图 3-5 测试用例执行用例图
该图描述了使用者与测试用例执行的必要条件和情况的关系，使用者针对具
体测试计划，对测试人员和测试工具进行分配，并在测试过程中查询测试进度，
以及测试完成后查询测试的结果。
5）产品缺陷管理
该图描述了使用者与产品缺陷功能的关系，使用者录入测试用例发现的产品 缺陷，并指定具体的开发人员修复相应的产品缺陷。使用查询功能可以查询当前 产品的缺陷列表。
6）测试报告统计
该图描述了使用者和测试报告统计模块的关系。使用者使用指定的报告样式，
可以输出缺陷报告、测试报告和总体报告。
7）测试人员成就
该图描述了使用者和测试成就模块的关系。使用者使用指定的成就样式，可 以输出个人成就和团队成就。
8）三方系统对接
该图描述了使用者和三方对接模块的关系。使用者可以使用预先按照规范定 义好的领英、微信、游戏这三方的不同接口，分别调用具体的接口 API 和不同系 统集成。
9)系统设置
该图描述了使用者和系统配置模块的关系。使用者可以配置系统本身的不同 参数，也可以管理系统的基础用户数据，包括用户信息和权限信息。
3.4.2 测试系统其他需求
除了上述的对系统的测试之外，在实际的操作中，还需要对系统的安全性能 进行测试，在系统的安全测试中，需要对多个层面进行测试，以及结合各种的测 试方法来完成。一般而言，对系统的安全性测试，需要对其功能方面的安全性、 数据方面的安全性等进行考虑，这些方面的考虑需要根据实际的使用来进行设计。 在系统的访问过程中，是相对独立的过程，服务端会根据客户端所发送的请求进 行数据的调用和反馈等。在对系统的安全性考虑方面，最基础的就是对访问系统 用户的权限进行分配，不同的用户系统分配不同的权限，而权限的设置也能够在 一定的程度上保证了系统的安全性，这也是需要充分的考虑来完成的。
对软件性能的测试，能够使得衡量一个软件系统性能的常见指标响应时间
(Response time)，吞吐量(Throughput)，资源使用率(Resource utilization), 点击数(Hits per second)，并发用户数(Concurrent users),而系统出现故障到 自动恢复所经过的时间等，都能够作为系统性能测试的重要的指标。
计算机硬件的选择取决于数据的处理方式和要运行的软件。对于数据处理是 集中式的，则采用单主机多终端模式，以大型或高性能小型机为主机，使系统具
有较好的性能。对于一定规模的企业，如果其管理应用是分布式的，则所选计算 机系统的计算模式也应是分布式的。一般来说，计算机机型选择主要考虑应用软 件对计算机处理能力的要求，在硬件选择时应选择技术上成熟可靠的系统机型。
虚拟化技术是当今企业热门技术之一，虚拟化产品允许一个平台同时运行多 个操作系统。它可以根据虚拟化程度以及虚拟机监控［19］层的实现层次进行不同的 分类，允许多个操作系统相互不影响的运行，有效提高了硬件的利用率和安全 性。
开源产品具有花费很少（如果有的话），许可费用，易于管理，连续，实时 改进，公司独立，实践的探索。充分利用开源软件的长处，使用开源开发工具和 开源社区的产品，自由［20］高效的搭建起一个高可用性，高伸缩性，高安全性的软 件测试信息管理系统。
3.5 本章小结
本章主要对系统的需求进行了背景分析和需求细化，进一步阐述清楚了系统 的模块划分，以及功能性模块和非功能性模块的定义。
第四章 系统详细设计
4.1 系统架构设计
项目使用基于MVC设计思想的SSH框架［21 ］集合。MVC的结构主要是包含了 系统的模型、视图和控制器三方面，因此，能够将系统的结构分为三个层面。
1） 第一层，系统的视图层面，是用户进行操作的平台，也是系统的“外壳”， 直接面向用户。
2） 第二层，系统的控制层面，该层面能够保证系统的正常运作，作为用户界 面和数据核心的过渡层，完成命令的调用和反馈等功能。
3） 第三层，系统的数据层，数据层是系统的核心所在，也是系统开发的基础， 为系统的运行提供了数据支持。
图 4-1 SSH 架构图
SSH结构在上文也进行了介绍，其中：
Struts 主要负责 Web 层的设计：
Struts 能够控制业务逻辑的跳转，并结合 Hibernate 对系统的数据持久层提供
帮助。通过接受到的数据，经过Action的处理后，为ActionServlet的加载提供了
基础条件。
Spring 主要负责业务层的管理：
Spring 作为框架的管理者，能够对 Hibernate 和 Struts 进行管理，除此之外， Spring 还能够实现分离的功能，能够对系统的业务逻辑和数据持久层进行分离， 这种分离不仅能够减轻系统工作的负荷，还能够提高系统的工作效率。
Hibernate 主要负责系统的持久层：
在Hibernate中，定义了 hbm.xml文件和PO，这两个文件都是与系统数据库 里相应的表格相对应的，在软件中实现对数据库调用的功能。
在 SSH 中，其关系和数据调用如下图所示：
1） 系统运行平台。本系统为企业级应用系统。运行在基于开源Linux［22］发行 版本 Ubuntu14.04 LTS 的 X86_64 服务器上，可以确保提供高可靠性，高稳定性， 高性能的服务器运行平台。
2） 程序架构模式。本系统具有较强的协同分布式［23］交互性。为了便于一个项 目的不同地区的项目组可以协调一致的工作，采用了基于 B/S 架构的软件产品设 计，可以确保易于维护和扩展，降低对客户端的要求。
3） 应用服务器。应用服务器是提供服务的平台，运行着JAVA企业级组件。 选用 Jetty 作为服务器实现，是因为该服务器具有比较好的引擎模块，除此之外， 它的框架也比较简单，便于日后的维护和拓展工作的开展。作为一个标准的 Servlet 引擎，它支持标准的 Servlet 规范和 Java EE 的规范。
4） 数据库服务器。 MariaDB 数据库是 MySQL 数据库中的一个分支，也是在 MySQL 6.0的基础上开发的，它与MySQL一样，都属于免费开源的数据库服务器。 选用 MariaDB 作为数据服务器，相比 MySQL 拥有更多的功能、更快、更稳定、 BUG 修复更快。
5） 集成开发环境。Eclipse［24］是一个功能强大的开发环境，能够为插件提供统 一的、集成化的开发环境，除此之外，在Eclipse中的Maven还是一个能够构建项 目的工具，便于对项目的生命周期进行管理［25］。 Git 的快照记录和近乎本地化操 作，为敏捷［26］高效地处理项目提供了可能性。
综上所述，系统采用的软件配置表如表 4-1 所示：
表 4-1 系统软件配置
服务器操作系统 Ubuntu 14.04 LTS
应用服务器 Jetty
数据库服务器 MariaDB
集成开发环境 Eclipse
运行平台 IE， Firefox， Chrome
开发技术 SSH, Git, Maven 等
其软件配置方案如图 4-3 所示。
图 4-3 系统架构图
4.2 系统模块综合
该系统基于JAVA EE的软件测试信息管理系统，根据需求分析和主要业务流 程，该系统是一个对测试的各阶段相关信息进行合理的、有效的管理综合平台。 其中总共设计了九个子模块。包括对测试需求的管理、计划制订和用例管理、以 及测试用例执行模块，产品缺陷管理模块，测试报告统计模块，测试人员成就模 块，三方系统对接模块，系统设置模块。各子模块自身实现高度聚合，模块之间 基于RESTful[27]协议API访问，大大降低了耦合度，有利于系统的维护和升级， 增加的系统的可扩展性。
表4-2说明了各大模块所需要具备的基本功能：
表 4-2 系统模块功能
系统模块 功能
测试需求管理 增加
修改
续表 4-2 系统模块功能
删除
查询
测试计划管理 增加
修改
删除
查询
测试用例管理 增加
修改
删除
查询
用例执行管理 人员分配
工具分配
进度查询
结果查询
产品缺陷管理 缺陷录入
缺陷指定
缺陷查询
测试报告统计 报告样式管理
缺陷报告输出
测试报告输出
总体报告输出
测试人员成就 成就样式管理
个人成就输出
团队成就输出
三方系统对接 领英系统接口
微信系统接口
游戏系统接口
系统配置 系统参数配置
系统用户管理
用户权限管理
4.2.1 测试需求管理详细设计
在对软件的需求管理测试的过程中，最主要的是对软件质量实际需求的测试 方面的要求。该模块会涉及到新旧测试需求的管理，对于旧的纸质化测试需求需 要进行无纸化录入，对于旧的电子化测试需求需要考虑支持导入功能，目前由于 时间有限，暂不在第一版中提供此功能，均会通过测试人员录入管理系统。录入 系统的测试需求信息方便查阅，不需要人工维护文档的版本和存放位置。添加和 删除旧的测试需求信息也可以轻松在Web界面完成。软件测试信息管理系统的测 试需求管理的功能主要包括测试需求增加、修改、删除和查询。
1） 测试需求增加。管理员选择添加需求，打开一个空白测试需求表单供管理 员填写。填写完毕后，点击“提交”，系统显示处理页面，检查各项输入信息无 误后，写入数据库中。
2） 测试需求修改。管理员选择修改需求，系统从数据库中读取用户添加进系 统的软件测试需求，并展现给用户。修改完毕后，点击“提交”，系统校验输入 信息无误后保存。
3） 测试需求删除。管理员选择删除需求，勾选完毕后，点击“提交”，系统 会向操作者提出进一步的提示，提示操作者是否确认对需求进行删除，当操作者 再次点击删除后，系统会对操作者给予“成功删除”的信息提示。
4） 测试需求查询。在该环节中，管理员调用查询的需求，并输入需要查询的 内容，然后点击查询按钮，数据库执行 select 查询命令，即可检索出符合条件的 测试需求进行显示。下图为测试需求实体E-R图
测试需求
厂
图 4-4 测试需求实体图
4.2.2 测试计划管理详细设计
测试计划制定，为项目新添加一个测试计划，必须要有测试计划才能进行测 试用例的添加和测试的执行。该模块包含录入已有的纸质或excel[28]版本的测试计 划，录入成功后，方便后期测试计划的更改，无须再维护原有的测试计划资料。 录入成功的测试计划信息，可以方便测试计划制定者和项目管理者在Web界面上 查询到，又可以方便对测试计划的修改和删除，无须担心所得到的版本不是最新 的。测试计划制定主要实现的功能：测试计划修改、删除、增加、查询。
1） 测试计划增加。管理员选择添加计划，打开一个空白测试计划表单供管理 员填写，管理员填写完测试计划后，选择已有测试需求选项关联，点击“提交”， 系统显示处理页面，检查各项输入信息无误后，写入数据库中。
2） 测试计划修改。管理员选择修改计划，系统从数据库中读取用户添加进系 统的软件测试计划，并展现给用户。修改完毕后，点击“提交”，系统校验输入 信息无误后保存。
3） 测试计划删除。管理员通过选择需要删除的计划，然后勾选删除按钮，勾 选完毕后，点击“提交”，系统会向操作者提出进一步的提示，提示操作者是否 确认对需求进行删除，当操作者再次点击删除后，系统会对操作者给予“成功删 除 ” 的信息提示。
4） 测试计划查询。在该环节中，管理员调用查询的需求，并输入需要查询的 内容，然后点击查询按钮，数据库执行 select 查询命令，即可检索出符合条件的 测试计划进行显示。下图为测试计划实体E-R图
4.2.3 测试用例管理详细设计
测试用例管理，对项目的测试用例进行管理。该模块包含对原有纸质和电子 版本的测试用例进行录入，第一次录入会相对比较耗时，一旦录入第一个用例成 功后，后续的录入可以复制修改。特别是可以缩短修改大量重复前置条件方面。 对录入成功的测试用例可以批量选择，查看具体的测试用例不需要去大量用例里 面肉眼比对，只需要输入指定用例的关键字即可进行模糊查找。大大方便了测试 用例的编写人员和执行人员，提高了工作效率。其主要包含测试用例的增删改 查。
1）测试用例增加。管理员选择添加用例，打开一个空白测试用例表单供管理 员填写，管理员填写完测试用例后，选择已有测试计划选项关联，点击“提交”， 系统显示处理页面，检查各项输入信息无误后，写入数据库中。
2） 测试用例修改。管理员选择修改用例，系统从数据库中读取用户添加进系 统的软件测试用例，并展现给用户。修改完毕后，点击“提交”，系统校验输入 信息无误后保存。
3） 测试用例删除。管理员选择删除用例，勾选完毕后，点击“提交”， 系 统会向操作者提出进一步的提示，提示操作者是否确认对需求进行删除，当操作 者再次点击删除后，系统会对操作者给予“成功删除”的信息提示。
4） 测试用例查询。在该环节中，管理员调用查询的需求，并输入需要查询的
内容，然后点击查询按钮，数据库执行 select 查询命令，即可检索出符合条件的
4.2.4 用例执行管理详细设计
测试用例执行，根据设计好的测试用例，进行人工执行测试。该模块将先前 通过邮件和口头分配的信息，进行了综合管理，用Web界面的方式展示测试执行 人员任务分配情况和测试环境［29］资源可用情况。有效避免了信息的不一致，导致 地资源竞争。并可以根据测试用例执行的情况，展示出整个测试计划的执行进度。 让项目管理人员直观地了解测试总体情况。相对于以往的信息不对等和沟通的滞 后性，使用关键字查询就可以在管理系统中查询到所需要的信息。其实现的主要 功能有执行人员分配、执行工具分配、执行进度查询、执行结果查询。
1）执行人员分配。当新的测试集被创建时，需要分配人员测试，可以选择添 加更多的测试人员，并在选定测试人员后，在数据库中会自动记录测试计划编号 和对应的测试人员。当测试集测试完毕后，所有人可以通过测试报告输出界面查 看测试结果，也可以通过个人成就输出界面查看指定测试人员的测试任务成果。
2） 执行工具分配。当新的测试集被创建时，需要分配测试资源（软硬件）， 可选的测试资源是系统用户管理界面添加的测试资源。测试资源指定后，数据库 会自动记录测试计划编号和对应的测试资源。当测试集测试完毕后，所有人可以 通过测试报告输出界面和总体报告输出界面查看执行工具使用频繁度，一般以红 色或紫色字体在报告中突出显示。
3） 执行进度查询。系统按照测试计划分类，在单一页面上展示每个测试计划 的执行情况，以进度条辅以百分比显示，需要具体查看个测试用例执行进度情况， 点击进度条，即可展开各用例完成情况。
4） 执行结果查询。管理员选择查询结果，输入要查询的测试计划关键字，点 击“查询”，数据库执行 select 查询命令，即可检索出符合条件的测试计划进行 显示。显示结果以颜色区分成功失败，红色表示失败，绿色表示成功。点击查询 结果，即可展开子用例执行结果。下图为用例执行实体E-R图
4.2.5 产品缺陷管理详细设计
产品缺陷管理，根据测试结果，记录产品不同级别的缺陷，方便跟踪问题状 态。该模块会对之前使用的其他系统的缺陷信息，进行人工录入，后期会添加自 动导入功能，对录入的缺陷信息关联上测试用例和测试人员，方便后期测试报告 的输出。项目管理者可以方便的在界面上选择空余开发人员解决出现的产品缺陷， 避免了口头或邮件的信息不一致和时效滞后性。其主要功能包括产品缺陷录入、 解决人员分配、产品缺陷查询。
1）产品缺陷录入。测试人员选择添加缺陷，打开一个空白缺陷录入表单供测 试人员填写，测试人员填写完缺陷描述后，选择已有测试用例选项关联，点击
“提交”，系统显示处理页面，检查各项输入信息无误后，写入数据库中。
2） 解决人员分配。当新的缺陷被创建时，需要分配人员解决，可选的开发人 员是系统用户管理界面添加的开发人员。开发人员指定后，数据库会自动记录缺 陷编号和对应的开发人员。当缺陷解决后，所有人可以通过测试报告输出界面查 看测试结果，也可以通过个人成就输出界面查看指定开发人员的解决任务成果。
3） 产品缺陷查询。所有人可以选择查询结果，输入要查询的产品缺陷关键字， 点击“查询”，数据库执行 select 查询命令，即可检索出符合条件的产品缺陷进 行显示。下图为产品缺陷实体E-R图
4.2.6 测试报告统计详细设计
测试报告统计，是生成测试报告，方便从不同角度和级别对产品需求的完成 情况进行统计。该模块使用系统已有的测试活动数据，可以轻松生成默认的简单 版本的测试报告，提高了报告的时效性，降低了报告数据搜集的难度。对于不同 的报告阅读者，还可以选择不同的样式，来输出信息量不同的测试报告。其包括 的主要功能有报告样式管理、缺陷报告输出、测试报告输出、总体报告输出。
1） 报告样式管理。管理员选择添加报告样式，打开一个空白样式录入表单供 管理员填写，管理员勾选要输出的报告信息选项，本地修改并上传 CSS 样式文件， 点击“提交”，系统显示处理页面，检查各项输入信息无误后，写入数据库中。
2） 缺陷报告输出。所有人选择查询缺陷报告，输入要查询的测试计划关键字， 点击“查询”，数据库执行 select 查询命令，即可检索出符合条件的测试计划的 缺陷报告进行显示。指定样式后，即可显示或打印。
3） 测试报告输出。所有人选择查询测试报告，输入要查询的测试计划关键字， 点击“查询”，数据库执行 select 查询命令，即可检索出符合条件的测试计划的 测试报告进行显示。指定样式后，即可显示或打印。
4）总体报告输出。所有人选择查询总体报告，输入要查询的测试计划关键字， 点击“查询”，数据库执行 select 查询命令，即可检索出符合条件的测试计划的 总体报告进行显示。指定样式后，即可显示或打印。下图为测试报告实体E-R图
4.2.7 测试人员成就详细设计
测试人员成就，完整记录测试人员的测试工作情况，如编写测试计划，测试 用例，提交缺陷等一系列成就。该模块可以有效利用已有的测试活动数据，例如 用例执行模块、缺陷管理模块等这些模块的数据，按照测试人员个人或团队为单 位，生成一个测试人员用例执行情况，缺陷提交情况的详单。从而让管理这更加 了解一个测试团队的每个人的工作情况。生成的图表还可以根据选择不同的需要 变换样式。其功能主要包含成就样式管理、个人成就输出、团队成就输出。
1） 成就样式管理。管理员选择添加报告样式，打开一个空白样式录入表单供 管理员填写，管理员勾选要输出的报告信息选项，本地修改并上传 CSS 样式文件， 点击“提交”，系统显示处理页面，检查各项输入信息无误后，写入数据库中。
2） 个人成就输出。所有人选择查询个人成就，输入要查询的人员关键字，点 击“查询”，数据库执行 select 查询命令，即可检索出符合条件的测试计划的人 员成就进行显示。指定样式后，即可显示或打印。
3）团队成就输出。所有人选择查询团队成就，输入要查询的测试计划关键字， 点击“查询”，数据库执行 select 查询命令，即可检索出符合条件的测试计划的 团队成就进行显示。指定样式后，即可显示或打印。下图为人员成就实体E-R图
4.2.8 三方系统对接详细设计
三方系统对接，按照第三方系统生成测试人员工作数据，提高求职的职位契 合度，增强工作在社交方面的正向作用。其主要是根据和第三方系统约定好的协 议，生成相应的 Provisioning 用户数据。由于领英的提供了较完备的 Restful 接口， 选择领英可以降低系统非功能性修改程度。微信同样也提供了第三方登陆的标准 接口，方便本系统的集成。游戏接口主要选择行业标准协议 SOAP 接口，为产品 二次开发做准备。其主要包括领英系统接口、微信系统接口、游戏系统接口。
1） 领英系统接口。系统提供了满足Restful规范的领英第三方接口，测试或开 放人员自身可以选择授信领英，读取该系统成就管理信息，展示在领英界面，使 得职业信息实时化。
2） 微信系统接口。系统提供了满足联合登录的微信第三方接口，测试或开放 人员自身可以选择使用微信账户登录本系统，使得人员信息管理便捷。
3） 游戏系统接口。系统开放了人员成就信息接口，提供充分的人员信息，为 3D 化，游戏化测试信息管理系统提供了基础数据，同时也可以接入已有的满足 Restful协议，SOAP协议的游戏。下图为三方系统实体E-R图
4.2.9 系统设置详细设计
系统设置，该模块主要是对本系统基本参数、日志管理、用户访问权限、以 及用户基本信息的管理。其主要包含系统参数管理、用户管理以及权限管理。
1） 系统参数管理。系统参数主要是跟全局业务配置相关的数据。系统日志设 置了系统所有操作记录路径。用户希望使用其它数据库来作为系统的数据库时， 可以通过系统数据库配置功能，将系统运行需要表和数据初始化到生产库或者将 添加的表和字段升级到已有生产库中。再连接初始化或者升级后的生产库来使用 系统。口令加密类配置，可以按照配置好的加密算法进行加密，在数据库中存储 加密后的密码，这里的口令加密是不可逆的，在加密后不进行解密
2） 系统用户管理。管理员为系统默认用户，管理员添加使用该系统的不同角 色，开发人员、测试和管理的人员，其中，管理人员拥有最高的权力，能够对系 统的所有人员进行管理，并删除不再使用该系统的人员。
3） 用户权限管理。管理员输入具体用户名，查询出所需用户，对用户权限进 行相应勾选，如开发人员不应有修改用例和修改缺陷的为“已验证”的权限。下 图为系统设置实体E-R图
下图为软件测试信息管理系统的系统E-R图
图4-13软件测试信息管理系统E-R图
4.3数据库表详细设计设计
本系统选用MariaDB作为关系型数据库[30], —方面避免了 Mysql数据库非开 源的不可维护性，另一方面又可以利用新增的功能，便捷高效的实现数据存储。 比如支持更多的存储引擎，像Aria、XtraDB等、速度提升、引入了基于表的多线 程［31 ］并行复制技术、引入了线程池thread pool技术、在处理内部的临时表时，用 Aria引擎代替了 MylSAM引擎。为了实现本系统的设计，除系统配置模块，每个 模块设计一个数据库表，其内容能够包括测试的需求管理、计划管理、用例管理 等，以及产品缺陷管理表，测试报告统计表，测试人员成就表，三方系统对接表， 用户信息表，用户权限表，系统配置表。
软件测试信息管理系统是一个 B/S 结构的重服务端系统，浏览器端只需通过 网络［32］良好地解析服务器传输的信息，数据存储系统也就成了重中之重了。每个 功能模块都需要访问数据库读取和写入该模块相关的信息，不同的数据库表之间 相互的联系就构成了整个测试信息管理系统的数据结构。所有涉及的信息和种类 都会在该数据结构下统一的管理。因此，在下文的内容中，主要对系统中搭建的 各个模块进行详细的介绍。
1）测试需求管理表：是对系统测试所需要的各种需求进行记录，包括了每一 层面的需求和上下层面的需求，该表通常会以树状的［33］结构来呈现，并能够与其 他的功能模块相连接。
主键：需求编号，用来唯一标识需求
需求描述：用来简要描述需求具体内容 需求版本：用来跟踪需求修改版本 需求级别：用来区分需求之间的从属关系，例如1.1.1为1.1的一个子需求 补充注释：扩展字段
表 4-3 测试需求管理表
字段 描述 类型（长度） 主键否 空允许
t reqNo 需求编号 int(4) 是 否
t reqDesc 需求描述 varchar(500) 否 否
t reqVersion 需求版本 varchar(10) 否 否
t reqLevel 需求级别 varchar(100) 否 否
t reqComments 额外描述 varchar(200) 否 是
2）测试计划管理表：记录测试计划的执行时间，以及测试类型。 主键：测试计划编号，用来唯一标识测试计划 计划描述：用来简要描述测试计划 计划开始时间：用来标识测试计划预计开始时间 计划结束时间：用来标识测试计划预计结束时间 补充注释：扩展字段
表 4-4 测试计划管理表
字段 描述 类型（长度） 主键否 空允许
t planNo 计划编号 int(4) 是 否
t planDesc 计划描述 varchar(500) 否 否
t planStartTime 开始时间 timestamp 否 否
t planEndTime 结束时间 timestamp 否 否
t planComments 额外描述 varchar(200) 否 是
3）测试用例管理表：记录测试用例的添加，修改，更新和删除等信息。并给
出一些统计数据
主键：用例编号，用来唯一标识用例 外键：一个或多个测试需求，外键标识 用例描述：用来简要描述用例场景 用例创建时间：标识用例的创建时间 用例创建者：标识用例的创建者
用例等级：按T1，T2，T3区分，数字越大优先级越低
补充注释：扩展字段
表 4-5 测试用例管理表
字段 描述 类型（长度） 主键否 空允许
t caseNo 用例编号 int(4) 是 否
t caseDesc 用例描述 varchar(500) 否 否
t caseCreateTime 创建时间 timestamp 否 否
t caseCreator 创建人 varchar(20) 否 否
t caseComments 额外描述 varchar(200) 否 是
t caseLevel 用例级别 varchar(5) 否 否
t caseReq 需求关联 int(4) 外键 否
4）用例执行管理表：记录测试环节中的进度和任务的执行情况，能够对测试
的内容、用例等信息进行记录，便于操作人员的跟踪和观察。
主键：测试任务编号，用来唯一标识测试任务 外键一：一个或多个测试计划 外键二：一个或多个测试用例 执行描述：用来简要描述测试执行的内容 执行开始时间：记录测试用例执行预计开始时间 执行结束时间：记录测试用例执行预计结束时间 测试结果：按 PASS 或 FAIL 区分
补充注释：扩展字段
表 4-6 用例执行管理表
字段 描述 类型（长度） 主键否 空允许
t runNo 执行编号 int(4) 是 否
t runDesc 执行描述 varchar(500) 否 否
t runStartTime 开始时间 timestamp 否 否
t runEndTime 结束时间 timestamp 否 否
t runComments 额外描述 varchar(200) 否 是
t runResult 执行结果 varchar(10) 否 否
t runPlan 计划关联 int(4) 外键 否
t runCase 用例关联 int(4) 外键 否
5）产品缺陷管理表：记录测试用例执行过程中，发现的产品缺陷信息。主要
包括缺陷状态，提交时间，处理时间，解决时间，提交人员，解决人员等。
主键：缺陷编号，用来唯一标识产品缺陷 外键：测试用例编号，触发缺陷的测试用例 缺陷描述：详细描述缺陷的触发情况 缺陷创建时间：记录缺陷创建的时间 缺陷创建者：记录缺陷提交人
缺陷状态：按 “ Submitted ”，“ Assigned "，‘' Solved ”，“Verified ”， “Closed ”区分
缺陷类型：按 “Requirement "‘“Design”，“ Implement ”，“Not a Fault” 区分
补充注释：扩展字段
表 4-7 产品缺陷管理表
字段 描述 类型（长度） 主键否 空允许
t defectNo 缺陷编号 int(4) 是 否
t defectDesc 缺陷描述 varchar(500) 否 否
t defectCreateTime 创建时间 timestamp 否 否
t defectCreator 提交人 varchar(20) 否 否
t defectComments 额外描述 varchar(200) 否 是
t defectCase 用例关联 int(4) 外键 否
t defectStatus 缺陷状态 varchar(50) 否 否
t defectType 缺陷类型 varchar(50) 否 否
6）测试报告统计表：汇总统计测试用例执行情况，缺陷提交记录，对应需求 覆盖度，小结出测试计划完成情况。
主键：报告编号，用来唯一标识测试报告
外键一：测试任务编号，关联任务 外键二：一个或多个缺陷编号，相关的产品缺陷集合 外键三：一个或多个需求编号，涉及的一个或多个需求 报告描述：简要描述测试报告内容
报告时间：记录测试报告生成时间
报告人：记录测试报告提交人
报告式样： 报告按指定的式样格式输出
补充注释：扩展字段
表 4-8 测试报告统计表
字段 描述 类型（长度） 主键否 空允许
t reportNo 报告编号 int(4) 是 否
t reportDesc 报告描述 varchar(500) 否 否
t reportTime 报告时间 timestamp 否 否
t reporter 报告人 varchar(20) 否 否
t reportComments 额外描述 varchar(200) 否 是
t reportPlan 计划关联 int(4) 外键 否
t reportDefect 缺陷关联 int(4) 外键 否
t reportReq 需求关联 int(4) 外键 否
t reportStyle 报告样式 varchar(10) 否 否
7）测试人员成就表：总结参与测试的人员任务达成情况，其中包含用例执行
情况，缺陷提交情况。 主键：成就编号，用来唯一标识达成成就 外键一：用户编号，一个或多个测试参与人员 外键二：缺陷编号，提交的缺陷信息 外键三：用例编号，执行的测试用例信息 成就描述：简要描述测试成就的内容 成就样式：成就按指定的式样格式输出 补充注释：扩展字段
表 4-9 测试人员成就表
字段 描述 类型（长度） 主键否 空允许
t achieveNo 成就编号 int(4) 是 否
t achieveDesc 成就描述 varchar(500) 否 否
t achieveStyle 成就式样 varchar(10) 否 否
t achieveComments 额外描述 varchar(200) 否 是
t achieveUser 人员关联 int(4) 外键 否
t achieveDefect 缺陷关联 int(4) 外键 否
t achieveCase 用例关联 int(4) 外键 否
8）三方系统对接表：描述系统对外提供的接口，其中包括接口类型，接口地
址，接口描述。
主键：接口编号，用来唯一标识三方接口
接口类型：按RESTful和SOAP区分
接口地址：符合标准的包含默认连接信息的地址 接口描述：简要描述接口使用方与功能 补充注释：扩展字段
表 4-10 三方系统对接表
字段 描述 类型（长度） 主键否 空允许
t interfaceNo 接口编号 int(4) 是 否
t interfaceDesc 接口描述 varchar(500) 否 否
t interfaceType 接口类型 varchar(50) 否 否
t interfaceUri 接口地址 varchar(100) 否 否
t interfaceComments 额外描述 varchar(200) 否 是
9）用户信息表：记录系统增加，修改，删除的用户信息，其中包含用户名称，
用户角色，用户描述
主键：用户编号，用来唯一标识用户信息 外键：一个或多个用户权限编号，描述用户系统访问权限 用户名称：记录系统使用者的登录姓名 用户密码：记录系统使用者的登录密码
用户角色：按“ Developer”，“ Tester”，“ Manager” 用户描述：简要描述用户
补充注释：扩展字段
表 4-11 用户信息表
字段 描述 类型（长度） 主键否 空允许
t userNo 用户编号 int(4) 是 否
t userName 用户名称 varchar(50) 否 否
t userPassword 用户密码 varchar(100) 否 否
t userRole 用户角色 varchar(20) 否 否
t userDesc 用户描述 varchar(500) 否 否
t userComments 额外描述 varchar(200) 否 是
t userPermit 用户权限关联 varchar(20) 外键 否
10）用户权限表：定义用户不同权限，其中包含权限类型，权限描述
主键：权限编号，用来唯一标识权限信息
权限类型：按“ Writable "‘“Readable"
权限描述：简要描述权限类型
补充注释：扩展字段
表 4-11 用户权限表
字段 描述 类型（长度） 主键否 空允许
t permitNo 权限编号 int(4) 是 否
t permitDesc 权限描述 varchar(500) 否 否
t permitType 权限类型 varchar(50) 否 否
t permitComments 额外描述 varchar(200) 否 是
11 ）系统配置表：定义系统自定义配置，其中包含配置名称，配置描述 主键：配置编号，用来唯一标识系统配置 配置名称：系统配置的简称
配置描述：简要描述系统配置的用途 补充注释：扩展字段
表 4-12 系统配置表
字段 描述 类型（长度） 主键否 空允许
t sysConfigNo 系统配置编号 int(4) 是 否
t sysConfigDesc 系统配置描述 varchar(500) 否 否
t sysConfigComments 额外描述 varchar(200) 否 是
依据以上各模块数据库表的设计，现绘制出数据库表之间的实体关系图，如
图 4-15
图 4-14 数据库表 E-R 图
4.4 本章小结
本章主要对系统的各大模块进行了详细的设计与介绍。结合主流技术，详细 描述了系统使用的架构、技术，并根据设计需求，细节化了各个模块的具体功能 定义。由此进行数据库表结构的设计，接下来的章节会基于本章的设计细节详述 产品实现的部分。
第五章 系统具体实现
5.1 系统的开发环境简介
开发主机：高性能PC机一台
操作系统： windows 10 的 64 位版本
开发语言： Java， html5， SQL
客户端： IE11/Firefox58/Chrome64
应用软件： JDK， Eclipse， WebStorm
服务端： JavaEE Server
数据库： MariaDB
5.2 系统的总体技术实现
5.2.1 系统的前端技术实现
该系统前端采用 JQuery+HTML5 编写测试管理系统的页面，一方面借鉴成熟 开源社区成果，缩短开发周期；另一方面减少后期的维护成本和增加系统的生命 周期。JQuery非常轻巧，其占用的存储单元不足30KB，并能够对其进行进一步 的压缩，将其缩小至18KB。Jquery有着很好的兼容性，能够为开发者提供大多数 的选择器。在 Jquery 中对事件处理的机制相当可靠。除此之外， Jquery 还能够实 现封装的功能，令操作者能够专心进行开发，不用考虑客户端浏览器的兼容问题。 Jquery 也能够对数据库实现兼容，使开发者不必在开展项目前建立浏览器兼容库。 JQuery 目前已经有超过几百种官方插件支持，文档非常丰富，如此强大的 JQuery 配合能够跨平台和简化语法并增加组件的HTML5，能让开发更容易些。
5.2.2 系统的后端技术实现
该系统后端目前采用Jetty服务器+MariaDB数据库，配合Redis[34呐存数据库, 在确保数据访问的正确性和稳定性的前提下，提高数据的访问速度。选择 Jetty， 主要是出于管理系统发展的长远考虑。 Jetty 更加容易定制成其中的一部分。 Tomcat 太大太复杂，很多特性根本不需要。 Tomcat 用在小型的项目中绝对是不 错的，性能很好，可如果你的并发访问用户超过 50 了，其性能和稳定性就没有 Jetty好了。Jetty运行于模块化的架构之上，如HTTP和JMX等模块。Jetty能够作 为一个独立的引擎，从而为 web 提供服务，而它也能够与其它 web 实现集成的功 能，因此，它在实际工作中能够提供 HTTP 和 AJP 协议的服务。正式由于这个特 性，初期可以提高测试管理系统的开发效率，只需要知道 Handler 的配置规则， 按照产品需求进行扩展和裁剪，而不需要过多了解这个容器本身的运转原理。随 着后期的功能增多，仍然可以按照责任链模式的规则，配置自己的处理单元，和 原有的模块集成使用。同样的，为了提高消息处理的速度，使用 Redis 作为前置 数据库，在高并发需求时，优先访问内存数据库里面的内容，在闲时进行内存和 实体数据库的信息同步。这可以大大提高整体系统的访问友好性。对那些访问量 大的信息存放在 Redis 里面，比如用户信息、测试用例、执行进度、缺陷信息。 利用Redis能支持超过100K+每秒的读写频率，可以减少对实体数据库的访问次 数。
5.3系统的模块具体实现
5.3.1 系统设置具体实现
用户通过登录模块进入系统，并选择相应模块进行操作，如果用户已经注册 或录入，只需要输入用户名和密码即可。该模块使用Ajax的异步访问机制，会对 用户输入登陆信息和后台Redis读取的信息进行合法性校验。
系统登录分为Login。、Logout()这2个action，它们将会用到实体model的 POJO对象将内存数据固化到数据库里。以下为登陆功能的主要实现：
Login()方法接收到前端来自HttpRequest传来的parameters参数，使用 Parameter 的类定义好的 PASSWORD 和 USER_ID 类型，获得传入的 user_id 和 password。 并对传入的参数进行基本的非空校验。 如果对象为空， 即抛出 Exception错误提示：必要的参数缺失。如果内容为空，即跑出传入参数不合法。
Logout()方法接收到来自HttpRequest传来的parameters参数，使用Parameter 的类定义好的 IS_LOG_OUT、 USER_ID 和 REDIRECT_URI 类型，获得传入的 user_id、 islogOut 和 redirectURI 信息。并对传入的参数进行基本的校验。如果对 象为空，即抛出Exception错误提示：必要的参数缺失。如果内容为空，即抛出传 入参数 不 合 法。 如 果 检查 isLogOut 为真， 即 表示 需 要 登 出 ， 将 调用 chekLogOutUserId()方法对需要登出的userId进行资源回收和其他相关工作。
if (userId == null) {
throw new CommonException(CommonError.REQUIRED_PARAMETER_MISSING, new String[] { userId });
}
if (Utils.isBlank(userId)) {
throw new
CommonException(CommonError.REQUIRED_PARAMETER_INVALID, new String[] { userId });
}
if (password == null) {
throw new CommonException(CommonError.REQUIRED_PARAMETER_MISSING, new String[] { Parameter.PASSWORD });
}
if (Utils.isBlank(password)) {
throw new CommonException(CommonError.ACCOUNT_LOGIN_FAILURE, Parameter.PASSWORD);
} 以上代码主要是对登录的用户输入的用户名和密码在数据库中进行比对，当 用户所输入的信息通过比对是错误时。系统会反馈相应的信息。用户也可以求助 系统管理员进行密码的重置服务。用户登出系统时，会释放用户会话信息。
图 5-1 系统登录界面
该界面展示了系统登录的界面，用户在登录时，只需要输入有效的登录信息 就能够完成登录操作，若忘记了这些信息，也能够在系统反馈的信息中点击寻求 帮助的按钮，联系管理员找回。
用于登录涉及的用户信息属于系统配置模块，为了更好的讲解实现，和系统 登录放在一起。用户信息和权限主要分为 addUser()、deleteUser()、updateUser()、 queryUser()、addAuthorizaion()、deleteAuthorizaion () 、updateAuthorizaion () 、 queryAuthorizaion ()这 8 个 action,他们会按照 POJO 对象 User 和 Authorization 将 内存数据储存到数据库里。系统管理员使用addUser()录入使用该系统的项目人员 信息。项目人员按照从事的项目事务不同，又分为项目/测试经理，开发人员，测 试人员。系统管理员按照Group的定义来区分不同人员拥有的权限，项目/测试经 理具有查阅的权利，开发人员具有查阅用例和修改提交的产品缺陷的权利，测试 人员具有整个测试流程涉及过程的添加和修改的权利。系统管理员在用户管理界 面上勾选带有单选框的 checekbox 控件对不同用户角色给予对应权限。系统管理 员可以使用addAuthorization()分配不同人员对应的权限，以便访问系统不同资源。 由于系统管理员这个角色的特殊性，该用户为内置账户，无法删除和修改，由后 台脚本录入。
图 5-3 新增用户界面
addUser()方法将形参传入的用户基本数据userId、userRole、userDesc、 userComments、 userPermit 进行本地变量赋值，对 isEncryptionDB 进行判断，如果 为True，即表示对存入数据库的密码进行默认加密处理；如果为False,即用指定 的算法对密码进行加密。在保存用户数据之前，对拥有相同 userId 的数据进行删 除，最后调用 dbPlugin 插件进行基本的 SQL 操作。
addAuthorization()方法将 AuthorizationRequest 和 client 传入的 redirectUri、 scopes、 type 等这些数据使用通用 Util 的校验方法 validate 进行基本校验，分别确 保 authorization 的 scope、 type 数据的正确。
if (isEncryptionDB) { userPassword = Utils.encrypt(userId + "_password");
} else { userPassword = Utils.encryptWithAlgorithm(userId + "_password",Constants.DEFAULT_ALGORITHM);
}
SqlRequest sqlRequest = new SqlRequest("delete from USER_INFO where t_userNo = '" + userId + "'");
dbPlugin.send(sqlRequest); dbPlugin.receive(new SqlResult());
以上代码主要是对添加用户的密码是否加密，并选择系统默认加密方式还是 指定加密方式，并且删除系统已有的用户信息，为新添加做准备。
系统参数的设置，主要是对初始化的系统数据库、日志、告警等的配置更新， 包括数据库地址、日志级别、告警级别等。
图 5-5 参数配置界面
updateConfiguration()方法通过形参module指定的配置文件字段，如果配置 字段开头为TIS，即使用默认的tis_service_definition.xml作为配置文件加载，否则 使用用户自定义路径和文件名加载配置文件。如果配置文件不对，结束加载过程 并记录 debug 日志，以便调试。对 xml 文件的解析使用 Jdom 的解析，解析过程会 使用try ...catch块进行捕获，并使用定义的errorCode进行表示。
图 5-6 系统配置流程图
5.3.2 测试需求管理具体实现
测试的需求规划是测试开展的必要条件，因此，在测试开展的前期，我们应 该正确地知道所开发软件的功能实现和需求的规格等信息，并将这些整体的需求 拆分为多个零散的需求。为了更好体现需求的自上而下性，采用文件夹整理的方 式来添加和管理测试需求。
测 试 需 求 的 action 主 要 分 为 addRequirement() 、 deleteRequirement() 、 updateRequirement()、queryRequirement()这 4 个。
sqlRequest = new SqlRequest(
"insert into REQ_INFO(t_reqNo,t_reqDesc,t_reqVersion,t_reqLevel,t_reqComments)value s('" + reqId + "','" + reqDesc + "','" + reqVersion + "','" + reqLevel + "','" + reqComments + ")");
dbPlugin.send(sqlRequest); dbPlugin.receive(new SqlResult());
图 5-8 需求查询界面
addRequirement() 方 法 将 形 参 传 入 的 用 户 基 本 数 据 reqId 、 reqDesc 、 reqComments、 reqLevel 进行本地变量赋值，对 isEncryptionDB 进行判断，如果为 True,即表示对存入数据库的密码进行默认加密处理；如果为False,即用指定的算 法对密码进行加密。在保存用户数据之前，对拥有相同reqId的数据进行删除，最 后调用 dbPlugin 插件进行基本的 SQL 操作。
操作人员能够点击界面中的测试需求按钮，从而形成新的产品测试需求说明 书，简要描述标题，内容。完成编辑后，点击需求创建的按钮，在系统中形成具
体的测试所需目录。具体测试需求项目包括：需求标题、需求状态、需求类型、 覆盖用例数。此处的覆盖用例数是为了便于对测试结果的调用，因此，在结果的 反馈中，需要对需求和用例的匹配程度进行统计。
5.3.3 测试计划管理具体实现
测试的计划能够为测试流程提供指导，在完整的测试计划中，应该包含了测 试的时间和计划的版本等信息。测试人员能够点击系统界面中的测试计划按钮， 进入到计划的创建界面中，在测试计划创建的内容中，包含了该计划的标题和相 关内容。测试人员选择该测试计划下面的版本管理，点击创建的按钮，然后创建 一个新版本的计划。 测试计 划的 action 主 要分为 addPlan() 、deletePlan() 、 updatePlan()、queryPlan()、configureVersion() 。
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
String startTimeString = "unix_timestamp('" + sdf.format(now()) + "', 'yyyy-mm-dd hh24:mi:ss:ff')";
String endTimeString = "unix_timestamp('" + sdf.format(now() + 31536000) + "', 'yyyy-mm-dd hh24:mi:ss:ff')";
addPlan()方法将形参传入的用户基本数据planld、planDesc、planComments 进行本地变量赋值，使用 SimpleDateFormat 获取当前时区的时间，保存为计划开 始时间。在保存用户数据之前，对拥有相同 planId 的数据进行删除，最后调用 dbPlugin 插件进行基本的 SQL 操作。
Utils.responseType(planVersion.getResponseType(), true);
Utils.type(planVersion.getType(), client.getAccess()); Utils.type(CommonConstants.CODE, client.getTypes());
Scopes(validateData(planVersion.getScopes(), client), client);
configureVersion()代码中包含了两个 POJO 对象：TestPlan 和 TestPlanVersion。 TestPlan用来保存测试计划的基本信息，TestPlanVersion用来保存测试计划的版本。 使用addPlan()将新的测试计划添加并保存为TestPlan，使用configureVersion。来添 加不同的测试计划的版本。系统会将 POJO 对象的信息序列化到数据库保存。
图 5-12 测试计划流程图
5.3.4 测试用例管理具体实现
测试用例的管理包含两层，分为新建测试用例套、创建测试用例。在实际操 作中，能够将测试所用的用例与相关的产品功能模块相结合，通过用例对功能进 行测试。在使用测试用例的过程中，能够通过搜索功能，从大量的用例中找到适 合的用例，也能够通过复制将用例放在项目中。测试用例的 action 主要有
addTestSuite() 、 deleteTestSuite() 、 updateTestSuite() 、 queryTestSuite() 、
addTestCase() 、 deleteTestCase() 、 updateTestCase() 、 queryTestCase() 。 以 addTestSuite()和addTestCase()为例，其他修改，删除和添加类似。
for(List case: suites){
Integer caseId = case.getCaseId();
String userName = caseId + "_caseCreator";
SqlRequest sqlRequest = new SqlRequest("delete from CASE_INFO
where t_caseNo = '" + caseId + "'"); dbPlugin.send(sqlRequest); dbPlugin.receive(new SqlResult());
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
String createTimeString = "unix_timestamp('" + sdf.format(now()) + "', 'yyyy-mm-dd hh24:mi:ss:ff')";
图 5-13 新增用例界面
addTestSuite()方法将形参传入的suites进行提取，获得每个testcase，并对传 入的caseDesc和caseComments进行本地赋值。使用SimpleDateFormat获取当前的 系统时间，并保存为testcase创建时间。在保存用户数据之前，对拥有相同caseId 的数据进行删除，最后调用dbPlugin插件进行基本的SQL操作。
addTestCase() 方 法 将 形 参 传 入 的 用 户 基 本 数 据 caseId 、 caseDesc 、 caseComments、 caseLevel、 caseCover 进行本地变量赋值，使用 SimpleDateFormat 获取当前的系统时间，并保存为testcase创建时间。在保存用户数据之前，对拥有 相同caseId的数据进行删除，最后调用dbPlugin插件进行基本的SQL操作。
测试人员能够在界面上点击测试用例的按钮，然后进入到测试用例编辑的界 面，通过创建组件来创建新的用例套。用例的内容应该包含了测试所用测试套的 名称、测试套描述信息，关键字。测试人员选择已经创建的测试用例套，然后创 建测试用例。
测试的用例和需求之间有个覆盖关系，测试人员在创建测试用例时，点击主 页“测试需求”的模块中点击关联产品的按钮，然后在关联的页面上进行操作， 编辑完成后，点击“保存”即可关联。
图 5-15 测试用例流程图
5.3.5 用例执行管理具体实现
测试用例设计后，需要由测试执行人员，按照设计好的测试场景进行执行。 执行测试用例包括执行人，执行开始时间，执行结束时间等。根据测试用例执行 的结果，汇总出系统的测试正确率，如果有缺陷，需要记录到产品缺陷模块中， 并指定相应的开发人员进行修复。 测试用例执行包括 assignTester() 、 assignTestTool()、queryTestCaseProgress()、queryTestCaseResult()这 4 个 actiono if (tester == null) {
String errorInfo = "can not create tester."; logger.error(errorInfo);
throw new CommonException(CommonError.INTERNAL_SERVER_ERROR, errorInfo);
}
ServiceHelper.postCreateTester(tester);
} else {
tester = updateTester(tester, createTester);
if (tester == null) {
logger.error("Update tester in DB fails due to bad request."); throw new CommonException(CommonError.INVALID_USER, "Update user fails.");
}
M軟件测试
信息 2018^：
系銃设置 测试需求管理测试计划管理测试用例管揑 严品缺陷管餐测试报告筑计测试人员成就三方系貌对接
H 用户：admin 賢角包 醐體:用励讓 ＞艙廠配
可用躺履： Peter R
■执确果痢 勰簾求： □k 户誨□»罔 E^wsfflpsesion Ltemsssn □■劇s® 出用户 $啓荷
冏开始时问：
冏碗间：
就 It
图 5-17 工具分配界面
鐵iS置 測述需求曽麗I
图 5-18 进度查询界面
图 5-19 结果查询界面
assignTester()方法将传入的tester基本信息进行校验，如果tester对象为空， 则抛出不合法用户错误，并记录更新teser到数据库失败的信息。如果对象不为空, 则设置Fields和Extention信息，并调用updateTester ()方法对传入的tester用户 进行 POJO 实体化存储。
queryTestCaseResult()方法将传入的 caseId 的查询 caseCreateTime，并对查询 出的结果进行Long类型转换，同时查询出caseCreator，并将查询结果保存在Map 组成的以 caseCreator 为 Key， caseCreateTime 为 Value 的结果返回。
点击主页“测试用例套”模块下的“分配测试用例”链接。能够在当前的测 试计划设计中安排一个测试人员，或者是在测试用例的界面中，从出现的人员下 拉列表中选择合适的测试执行人员，点击确认即可完成测试任务指定工作。
该界面展示了人员分配功能的使用，选择下拉列表中的可用测试人员，指定 需要测试的需求项，可以一个或者多个，并设置好计划开始和结束的时间。
5.3.6 产品缺陷管理具体实现
测试的目的正是为了提前发现产品的问题，并在产品发布之前解决。一个缺 陷的产生一般是从缺陷发现，提交缺陷，重现缺陷，修复缺陷，验证缺陷，解决 缺陷。所以缺陷管理的页面需要包含以下几个主要的要素：
1.缺陷的概述
2.缺陷的描述，包含触发条件和步骤
3.缺陷的严重程度
4.缺陷的提交人员
5.缺陷的提交时间
6.缺陷版本
7.缺陷的解决人员
当测试人员在缺陷管理界面提交一个产品的缺陷时，一定会涉及以上 7 个要 素。产品缺陷管理的 action 主要包含：deffectCreate()、deffectAssign()、 defectQuery()。
String userName = defect.getDefectCreator();
String defectComments = defect.getDefectComments();
String defectStatus = defect.getDefectStatus();
String defectType = defect.getDefectType(); for(List case:cases){
String caseId = case.getCaseId();
图 5-21 新增缺陷界面
图 5-22 缺陷查询界面
defectCreate()方法将形参传入的基本数据对象defect进行提取赋值，使用 SimpleDateFormat获取当前的系统时间，并保存为defectcase创建时间。在保存用 户数据之前，对拥有相同defectId的数据进行删除，最后调用dbPlugin插件进行基 本的 SQL 操作。
用户提交的一个缺陷保存在DefectObject这个对象里面，多个DefectObject会 存储在List里面，以界面列表的方式展示出来。其中调用defectAssign()方法去指 定修复缺陷的开发人员。为了确保有好的产品交互，代码［35］会进行异常处理，使 用try...catch异常块进行捕获，并输出友好的错误提示信息，如“指定人不存 在”。
图 5-23 产品缺陷流程图
5.3.7 测试报告统计具体实现
测试结束后，系统会根据测试结果 success 和 fail 的情况，对用例进行不同类 型和程度的统计。为操作者提供直观的数据，操作者通过对数据进行检查后，能 够点击测试报告的按钮。跳转到测试结果显示的页面中。测试报告统计的 action 主要有 defectReport()> testcaseReport()、overallReport()、configureReportStyle()这 4 个。
Report Report = new Report();
Report.setReportType(Common.DEFAULT_REPORT_STYLE);
Report.setTypeSpace(Common.PUBLIC);
List<Group> group = new ArrayList<FKGroup>();
List<Id> idList = new ArrayList<Id>();
// reportNo
if ((reportNo != null) && !reportNo.equals("")) {
Id idreportNo = new Id(); idreportNo.setName(Common.DEFECT_REPORT); idreportNo.setValue(reportNo);
idList.add(idreportNo);
图 5-27 总体报告界面
testcaseReport()方法将形参传入的reportNo和reporter进行校验，如果不为空, 就对reportNo和reporter进行赋值，并将赋值成功的结果保存在group里面，并使 用 Collection 的内置方法 sor(t )对结果集进行排序，将排序完成并设置好的 Report 对象返回。
通过SQL查询测试报告表，过滤出测试用例执行结果fail和success的，统计 后存放在一个结果集中，通过forward()传递到前段展示层，由前端按指定的样式 显示出来，configureReportStyle()的方法会调用系统配置模块默认的指定样式，重 新 rendering 出来。
图 5-28 测试报告流程图
5.3.8 测试人员成就具体实现
系统测试用例执行的结果，以及发现和修复的产品缺陷记录都可以作为开发 和测试人员的工作输出。测试人员设计了多少用例，覆盖了多少测试需求，执行 了多少用例，发现了多少产品缺陷；开发人员解决了多少产品缺陷。测试/开发人 员的执行用例和解决用例所发现缺陷的时间比例等。这些一方面可以更好综合评 价一个测试/开发人员的劳动成果。另一方面也可以更好展示测试/开发人员。测 试人员成就的 action 主 要 有 personalAchievement() 、 teamAchievement() 、
configureAchievementStyle()这 3 个。
String lineString = null;
while (null != (lineString = bufferedReader.readLine())) { builder.append(lineString);
builder.append(", Name: " + userName);
builder.append(", Result: " + reports.get(0).getResult(userName));
}
bufferedReader.close();
样式舘：
样栽件：
厳 Sg
personalAchievement()方法将定义好的 tis_achieve_definition.xml 进行 xml 解析, 并将传入的 userName 赋值到 report 中，作为 report 中的 creator 。 使用 BufferedReader对写入过程缓冲，并将缓冲结果作为FilelnputStream的输入值。生 成的结果会toString()返回。
通过 SQL 语句查询测试人员成就表，获取指定 userName 的测试/开发人员， 测试任务执行的情况，获取一个HashMap的以用户为Key，执行结果List为Value 的键值对。再调用configureAchievementStyle()方法，设置指定的样式，默认为表 格，传递处理结果到前端html5的页面展示出来。
图 5-32 人员成就流程图
5.3.9 三方系统对接具体实现 三方系统对接是按照标准协议，提供了不同外部系统可访问的接口，从而便 于和其他系统集成，提供数据支持。目前系统支持的外部接口协议是 Restful 和
SOAP。以后会进一步扩展。三方系统对接的action方法有provisionWechat()、 provisionLinkedIn()、provision3DGame() 。
if (null != userId) { reqBody.put("userId", userId);
} if (null != extensions) { for (String key : extensions.keySet()) { reqBody.put(key.getRetrieveTestCaseResult(), extensions.get(key));
}
}
String reqBodyJsonStr = convertToJsonString(reqBody); PostRequest request = new PostRequest(); request.setHeadParameter(reqHeadMap); request.setContent(reqBodyJsonStr); request.setUri(provisionLinkedInUrl);
return request;
图 5-33 领英接口界面
图 5-34 微信接口界面
图 5-35 游戏接口界面
provsionLinkedln()方法将形参传入的 trusted作为 HttpRequest 中 header 的 token, 将userId作为请求id放在requestBody中，并将requestBody转换成Json对象。并 将uri设置为provisionLinkedlnUrl,将封装好的request作为HttpRequest对象返回。
使用retrieveTestCaseResult()获取测试用例的执行结果，获取执行时间和执行 量；使用retrieveDefectsResult()获取提交的缺陷数量，存放到一个POJO对象里。 使用 HTTP 协议或 SOAP 协议传输。由于开发是基于标准协议开发，只需定义出 WSDL文件即可。
图 5-36 三方接口流程图
5.4 本章小结
本章主要介绍了系统开发使用的软硬件平台。详细描述了系统各个模块根据 需求设计的具体实现工作和部分重要代码。基本上实现了该软件测试信息管理系 统的设计意图。系统本身实现了一个完整串起整个测试流程所设计的工作，集用 例管理和缺陷管理于一身。合理运用工作数据展现测试/开发人员履历，并适当增 加了产品的市场竞争性。
第六章 系统测试
软件开发的过程中，同步在进行着测试工作，把每一个模块作为一个目标， 每个模块都会单元测试、容器测试、功能测试、冒烟测试。继而把每个模块组装 起来做集成、一体的测试。在测试的过程中，通过本系统能够真正做到实用性、 高效性。
6.1 系统的测试环境简介
测试环境的搭建均使用现有的资源，服务器为因特尔志强处理器的台式机， 客户机为因特尔酷睿i5系列处理器的笔记本。台式机使用Linux系统安装了 Redis 和MariaDB的数据库以及开发的JavaEE测试信息管理系统。笔记本作为发起请求 的客户端，使用 windows10 系统，安装了三大主流浏览器 IE11、Firefox58、 Chrome64,并安装了适用于性能测试和稳定测试的Jmeter［36］相关应用。主要的环 境配置如下表 6-1 测试环境图所示［37］。
表 6-1 测试环境配置
机器角色 资源类型 资源
客户机 硬件 Corei5, 8gb, 500GB, 10/100m
软件 Win10, Jmeter, Wireshark etc.
服务器 硬件 XeonE3, 16gb, 6T, 100/1000m
操作系统 Ubuntu
应用服务器 Jetty
数据库 MariaDB, Redis
运行环境 Jre
6.2 系统的测试类型
测试工作由于依托在当前的开发系统上,和开发同步进行着测试工作,确保 了问题的早发现、早解决。大部分的缺陷都在功能测试这一阶段即可得到解决。 避免后期陷于缺陷修复,而无法正常开展系统级别的性能测试和稳定测试,大大 提高了产品发布的时效性和可接受性。具体来说,测试的环节主要对软件的性能、 功能、稳定性、集成和单元等方面的测试,除此之外,还会添加探索性［38］测试以 最大限度发挥测试人员的主观能动性,积极发现测试用例未发现或未较难覆盖到 的测试点。
6.2.1 单元测试
单元测试［39］主要是开发人员在功能代码完毕后，使用stub、mock或fake等测 试马甲程序,对单个基类(超类)、抽象类、或者派生类(子类)中的方法进行 正确性验证的测试工作。一般而言，在系统开发的过程中，程序人员在编写程序 时，会将各个功能模块的程序语言分别进行封装，并在编写完一个模块的语言后， 会对其功能进行检验，当该模块能够实现功能后，才进行下一个模块程序语言的 编写。这种方式能够避免程序出现错误，良好的单元测试用例可以做成构建自动 化的一部分。
@Test
public void testLogOutFailedByInvalidUserIdParameter() {
localLogOutRequestParameters.remove("user_id"); localLogOutRequestParameters.put("user_id", "peter"); try {
logOutService.logOut(localLogOutRequestParameters, httpHeaderWithCookie);
fail("should throw exception");
} catch (CommonException e) { assertEquals(CommonErrorEnum.PARAMETER_INVALID, e.getErrorCode());
assertEquals("Invalid value of parameter: user_id.", e.getError().getErrorDescription());
}
verifythrowsError();
}
testLogOutFailedByInvalidUserIdParameter()测试方法，使用 Junit 组件，测测 试了当user_id不对的时，登出时请求资源关闭抛错，并报不合法的参数。
6.2.2 组件测试
组件测试是对特定模块的测试。它可以与系统的其余部分隔离开来。假如正 在测试一个叫做 X， Y 和 Z 三个模块的应用程序，并且认为每个模块都依赖于上 面。如Y取决于X，Z取决于Y。现在如果开发人员开发了 Y模块，并且作为测 试人员要测试它，那么需要使用Stub和driver作为模块X和Z。基于这个例子， 将很容易编写测试用例。
@Test
public void testLogInFailedWithPasswordEmpty() throws Exception { requestParams.remove(ParameterConstants.PASSWORD); requestParams.put(ParameterConstants.PASSWORD, "");
String errorCode = "login_failure";
String errorDesc = "The username or password is not correct."; errorExtendInfo.clear();
errorExtendInfo.put(ParameterConstants.ERROR_REASON,
ErrorMsgConstants.ERR_REASON_EMPTY_PASSWORD);
postJsonBodyAndCheckErrorResponse(Status.BAD_REQUEST, errorCode, errorDesc, errorExtendInfo);
LogTestEntry logEntry = getLogEntry(TYPE_POST); checkFailureLog(logEntry, errorCode, errorDesc); checkLogLogInRequest(logEntry, NORMAL_CLIENT_ID, TEST_USER_ID, null, null);
checkFailureLogInLog(errorCode, NORMAL_CLIENT_ID, "");
}
testLogInFailedWithPasswordEmpty()方法是在登陆时，输入错误的密码信息, 系统提示登陆失败，用户名或者密码不对。同时将登陆错误的信息记录到日志里 面。
6.2.3 功能测试
通过对软件功能的测试，从而保证所开发的软件能够实现预先设计的功能，
也能够满足用户的需求。一般而言，在传统的开发中，对功能的测试是需要长时 间的琢磨，这种测试方法的效率十分低。在 XP Stories 中，能够为用户提供一个 与开发人员直接交流和沟通的平台，并在沟通中完成功能的测试。在单元测试的 过程中，尽管对每一个单元单独和互相联系上进行了测试，能够排除了大部分的 错误，但这对软件的测试来说，还是不够完善的。因此，功能的测试能够将单元 进行封装和集成，从而在用户的层面上对软件功能的体验进行判断。系统包含功 能较多，无法一一列举。现列举登录和测试用例查询功能用例和相关测试及结果 作为举例说明。表 6-2 为登录和测试用例查询功能测试点：
表 6-2 登录和用例查询测试点
功能模块 用例名 前置条件 测试步骤 测试结果
登录 登录成功 1.系统服务已 启动；
2.预设置测试
用户。 1. 输入正确测 试用户名和 正确密码 登录成功，进入
系统主界面
登录失败 1.系统服务已 启动；
2.预设置测试
用户 1.输入错误测 试用户名或 错误密码 登录失败，提示
用户名或密码错
误信息
测试用例查询 用例结果存在 1.系统服务已 启动；
2.预设置测试 用例数据。 1.输入预设置 的存在的测 试用例关键 字；
2.点击查询按 钮 系统显示和关键
字匹配的查询结
果
用例结果不存在 1.系统服务已 启动；
2.预设置测试 用例数据。 1.输入不存在 的测试用例 关键字
2.点击查询按 钮 提示用例不存在
提示信息
// 5. re-login using linked testUser
ui.open(UrlNormal);
assertTrue("no login page show up.", needLogin()); boolean loginSuccess2 = login(desc, password); assertTrue("login failed using linked testUser", loginSuccess2);
int sessionCount2 = countSessionNumForUser(userId, dbPlugin); Assert.assertEquals("no new session", 1, sessionCount2);
testLogIn()方法在本地 mock 了 userid、password、role、permit 的基本测试数 据。调用mock方法提供的ui()方法，模拟用户访问系统，并创建用户，生成相应 的访问session,并对登陆后的结果进行Assert,如果满足期望的结果，则测试成功。
图 6-1 是手动测试登录失败的测试结果。测试人员在系统登录界面，输入错误 的“用户名”或“密码”，点击“登录”，系统登录校验失败，界面会提示错误 信息“用户名/密码 错误，请重新输入”。
图6-2是手动测试用例查询执行信息的测试结果。测试人员在测试用例查询管 理界面，输入错误的查询关键字信息，点击“查询”，系统后台查询不到信息， 界面会提示结果信息“无结果”。
6.2.4 冒烟测试
Smok Test的概念最早源于制造业，用于测试管道。这是一种比较基础和直观 的测试方法。在对软件测试的过程中，冒烟测试的方法能够在对软件的代码进行 正式的测试之前，先消除一部分的错误，能够减少在后期测试环节的工作负担。 目前，常用的软件测试中的冒烟测试主要分为三种：
1.形成集成测试之前的版本
2.形成集成测试之后的版本
3.后期缺陷修复测试的版本 该系统所用的是第一种，即为了形成一个能顺利进行集成测试的预版本。
附录中是 smoke 的 jmeter 脚 本 代 码 ， 其 表 示 的 是 设 置 测 试 的 Traffic_IP,Traffic_Port,并对HTTP请求的头文件参数进行设置，默认使用的是 HTTP 请求。
6.2.5 集成测试
软件集成的测试是软件开发［40］环节中重要的测试环节，其能够对软件的接口、 单元之间的连接的正确性进行检测。在集成测试中，按照一开始所制定的测试计 划，将模块之间的连接和单元之间的进行检测，同时，也会模拟运行软件，从而 对软件的构成进行整体的分析，对其运行中的频率和稳定性进行检测。在集成测 试的方式选择中，能够选择自上而下和自下而上两种方式，这两种方式的选择是 根据软件的各个模块部分所进行的，能够全面地对软件的每一个组成进行测试。
附录中是集成测试的 jmeter 脚本代码， 其表示的是设置测试的 Traf!ic_IP,Traffic_Port, /tis/report/delete/ReportTestl234567/peter。并对 HTTP 请求 的头文件参数进行设置，默认使用的是 HTTP 请求。
6.2.6 性能测试
对系统性能的测试是判断系统整体质量的一个过程，一般而言，在对系统性 能的测试中，会通过加压的方式来对其工作的效率和稳定性进行测试。因此，系 统性能的［41］测试根据其方法的不同能分为对系统的承受压力的测试、稳定性的测 试等。除此之外，对系统所应用的领域［42］的测试方式包括了性能调试和能力的检 验等。一般会对系统的应用领域结合多种方式进行测试，具体如下表所示。
表 6-3 测试类型
功能检验 测试计划 优化性能 错误部位 基准比对
基准测试
负载测试
压力测试
并发测试
稳定性测试
附录中性能测试的 jmeter 脚本代码，其表示的是设置测试的 hostname,port, username,password。并对 PT 的 PASSRATE 进行定义，如果 passrate<PASSRATE， PT测试的结果不达标，反之满足测试要求。默认使用的是HTTP请求。
着重关注响应时间，吞吐量，并发数，资源利用率这几个指标。
6.2.7 稳定测试
对软件稳定性的测试主要是通过使软件跑一段时间，一般为连续一周的运作 或半个月的运作，并对软件连续运作中的表现进行记录，从而到达检测软件运行 稳定性能的测试。稳定性测试是用来验证产品在一定的负载下能否长时间的稳定 运行，其主要目的是验证能力，并在能力的验证过程中找到系统不稳定的因素并 进行分析解决。
附录中稳定测试的 jmeter 脚本代码， 其表示的是设置测试的 TC01_Login_jmeter_success， TC01_Login_jmeter_fail, DURATION 进行定义，如 果 TC01_Login_jmeter_success+ TC01_Login_jmeter_fail/ DURATION 结果为 TPS。 默认使用的是 HTTP 请求。
6.2.8 探索性测试
探索性测试［43］是软件测试中的一个环节，它能够在对软件进行测试的过程中， 探索更多测试的方法，从而为测试的环节提供更多的方案选择。在软件测试的过 程中，软件的测试人员会按照既定的测试计划来进行操作，而探索性测试的存在 会对计划进行动态的修正，从而能够进一步保证软件测试工作的顺利开展。探索 性的测试方法，能够令测试者在测试的过程中不断的学习新的方法，与测试计划 是一种相辅相成的关系。
try:
run_cmd("service proxy restart")
except Exception, e:
try:
logger.info('Try to activate balance')
run_cmd("service proxy restart")
except Exception, e:
logger.error('Fail to restart /etc/proxy')
raise
logger.info('Make sure balance is running')
try:
status, output = run_cmd("service proxy status")
if not re.search('running', output, re.IGNORE):
raise RunCommandError('/etc/proxy not running.')
except Exception, e:
logger.error('/etc/proxy not running.')
logger.info('Finish deploying balance')
setup_balance(self)方法是使用python的语言写的测试linux环境下，通过读取
/etc/proxy/proxy.cfg加载不同proxy，并对proxy的开启和关闭，主要用来对系统流 量测试的。
6.3 系统的测试结果
系统在边开发边测试的情况下，缺陷的发现都及时得到了开发人员的修改， 确保了产品的质量。在整个测试过程中共发现缺陷四百多个，严重级别的错误五 十多个，中等级别的错误一百多个，其他都是轻微级别的错误。严重和中等的错 误基本全部修改，其他错误由于时间关系无法全部修改完成，但总体上可以确保 不会对系统产生功能性影响，基本功能均可正常使用。使用Jmeter+nagios[44]进行 了系统的性能测试和稳定性测试，对产品的并发访问量，访问延迟时间均进行了 记录和绘制。
如图 6-3 为 TPS (Transaction Per Second)的数据绘制图：
Lhi Transactions Per Second
Elapsed Time (granularity:! min)
图 6-3 TPS 数据图
如图6-4为Latency的数据绘制图：
图 6-4 Latency 数据图
该测试选取了测试用例查询场景，使用 Jmeter 工具，设置了35个线程数，模 拟 1000 个 sessions 同时访问系统。从图上的数据可以看出，系统的并发数基本维 持在 1300，响应时间也可以保持在 12。当请求继续增加时系统反应会变慢，响应 时间也就相继增加了，图中所示为经过调优后，系统当前的合适 TPS 与 Latency 关系。基本上满足了系统对性能的要求。界面方面的测试确保了客户端浏览器的 兼容，满足三大主流访问浏览器的适配性，
6.4 本章小结
整个系统经过完整的测试后基本功能均已实现。系统实现了软件测试信息管 理需求定义的九大相关功能，符合了产品使用方面的性能和稳定性要求，可以在 接下来的实际生产和工作中高效的提高工作效率，大大降低了数据整合，流程调 度，圆满实现了软件测试流程的全程跟踪管理。
第七章 总结与展望
7.1 总结全文
该论文的起源来自本人工作中，对软件测试理论的深刻认识，并对目前项目 中使用的测试管理软件的不足。结合国内外现有软件测试管理方面的软件进行了 详细的研究和分析，长达数月之久后，写下了这篇关于国内软件测试信息管理系 统的论文。该系统遵循软件测试流程，极好的整合了测试不同活动，可以用于项 目管理者观察项目进度，产品测试者管理测试用例，产品开发人员分析产品缺陷。 简要介绍系统如下：
系统基于JavaEE，充分使用Struts+Spring+Hibernate的分层设计思想，极大 的加速了开发过程，也方便了后续的维护工作。系统使用Redis+MariaDB［45］的内 存数据库+关系数据库的方式，提高了产品的并发访问量，降低了系统对客户端 的响应时间。界面方面基于HTML5［46］的前端技术也为后续的二次开发工作提供 了良好的技术基础。整个系统的开发过程采用敏捷［47］开发模式，测试和开发同步 进行。每一次小的迭代都是一个成品的产生。缩短了系统的交付风险。整个系统 的开发过程也是验证软件测试流程的过程，开发系统的同时也在使用系统验证自 身。这要是本系统开发的初衷，缩短信息的交流和整合时间。使得测试工作不再 是一项枯燥而乏味的事情，相反，测试工作变得更有趣，更贴近每个具体的测试 活动的参与者。
7.2 展望后续工作
在长达一年的系统开发和测试工作中，深化了我对软件测试的认识。该系统 总体上达到了设计的既定目标，同时仍然存在一些不足的地方，比如系统未考虑 虚拟化问题，目前大多数商业级别的产品都是部署在基于Docker［48］技术的“云［49］ 端”，一方面方便产品开发和部署，另一方面也大大解决了硬件资源的不足。系 统也没有大量运用HTML5的最新技术，比如硬件加速加持，CSS3，3D视觉特性, 这些都可以支持系统本身做成具有 3D 属性的管理系统。当前正兴的物联网技术 和VR,AR技术均可以作为后续系统优化和二次开发的技术支持和方向指示。在论 文完成后的剩余时间，会深入研究系统的可扩展性，更好的升级该系统［50］，以便 将来有机会将本系统投入实际使用。
致谢
伴随着论文的即将完成，我也要再次告别两年的校园生活，告别自己的求学 生涯。值此离别之际，心中充满万分感激。
首先，我要衷心地感谢我的导师高原老师，本论文是在他的悉心指导下完成 的。高原老师在论文的撰写过程中，非常耐心地对我的论文进展情况，总体设计 等方面给予了细心的指导。高老师总是在第一时间会及时回复我的疑问，在论文 完成后，高老师非常细心地检查了我的论文并将论文中的不足之处一一指出，并 耐心地指导我该如何修改。是高老师的责任感和耐心帮助我完成了此篇论文。
其次，我要感谢公司项目组的各位同事对我的帮助，是他们在最初的选题和 搜集意见的过程中，献计献策，使我对软件测试有了更深的了解。同时也感谢我 的企业方导师董向军，在我撰文过程中，对我提出的问题，认真解答，耐心讨论。 使我对问题理解更加深刻，进一步对问题有了深度认识。
此外，还要感谢我的家人，特别是我的父母。感谢他们对我再次求学的无私 支持，使我可以放心大胆的毫无顾虑的完成此篇论文，在此向我亲爱的父母致以 崇高敬意。
最后，对百忙之中为我评阅论文的专家，学者和老师们表示深深的谢意，对 参考文献的作者们致以衷心的感谢。
参考文献
[1]丁智勇.项目质量管理过程中的软件测试问题J].科技创新导报，2009,（02）:175-176
[2]Glenford J.Myers，Tom Badgett， Corey Sandler.软件测试的艺术（原书第 3 版）[M].（张 晓明，黄琳译）.北京：机械工业出版社， 2012,2-5
[3]张妍，傅秀芬.基于多优化目标的软件测试用例约简方法研究[J].计算机应用研究， 2016,33（04）:1111-1112
[4]Sami Torniainen.Improving Effectiveness Of Regression Testing Of Telecommunications System Software[D].Finland：Helsinki University Of Technology， 2008,8-9
[5]Leonard Richardson， Mike Amundsen.RESTful Web APIs[M].（赵震一，李哲译）.北京：电子 工业出版社， 2014,18-20
[6]Martin Fowler.重构 改善既有代码的设计[M].（熊节译）.北京：人民邮电出版社，2010,89-90
[7]肖丽琼.软件测试之魂[M].北京：电子工业出版社，2013,272-273
[8]Randal E.Bryant，David R.O Hallaren.深入理解计算机系统（原书第2版）[M].（龚奕利， 雷迎春译）.北京：机械工业出版社， 2011,14-15
[9]林信良.Spring2.0技术手册[M].北京：电子工业出版社，2007,253-254
[10]邹辉.软件自动化测试开发[M].北京：电子工业出版社，2017,176-199
[11]严千均.编程导论[M].北京：清华大学出版社，2013,19-21
[12]S Cash， V Jain， L Jiang， A Karve.Managed infrastructure with IBM Cloud OpenStack Services [J].Ibm Journal of Research & Development， 2016,60（02）:1-12
[13]李涛.3种常用国产办公软件与微软Office软件的测试对比J].电力信息与通信技术， 2007,5（09）:89-91
[14]Victor Lofgren.Developing and implementing a quality management system in a startup company[D].Sweden： Chalmers University Of Technology， 2012,54-55
[15]袁明磊，付贤政.软件测试管理系统设计[D].安徽：安徽国防科技职业学院，2013,77-78
[16]叶言苓，崔彦军.软件测试管理的研究与应用[J].计算机应用与软件，2003,20（09）:17-18
[17]何玉洁，牛蓓，金颖，方美琪.软件质量保证一测试管理[C].信息系统协会中分会第一届学 术年会, 北京, 2005, 207-208
[18]Mark Kevitt.Best Software Test&Quality Assurance Practices in the project Life-cycle[D].Ireland： Dubin City University， 2008,77-78
[19]葛一鸣.实战Java虚拟机[M].北京：电子工业出版社，2015,139-147
[20]鸟哥.鸟哥的Linux私房菜基础学习篇[M].北京：人民邮电出版社，2010,42-43
[21]吴翰清.白帽子讲Web安全[M].北京：电子工业出版社，2014,280-281
[22]Daniel P. Bovet，Marco Cesati.深入理解Linux内核[M].（陈莉君，张琼声，张宏伟译）.北京： 中国电力出版社， 2007,13-14
[23]Joakim Verona.DevOps实践[M].（高清华，马博文译）.北京：电子工业出版社，2016,1-7
[24]孙鑫.Servlet/JSP深入了解[M].北京：电子工业出版社，2008,541-542
[25]蔡为东.赢在测试2-中国软件测试专家访谈录[M].北京：电子工业出版社，2013,158-159
[26]Mike Cohn.敏捷软件开发实践估算与计划[M].（金明译）.北京：清华大学出版社，2016,17-21
[27]Steve Souders.高性能网站建设指南[M].（刘彦博译）.北京：电子工业出版社，2010,103-105
[28]沈建苗.微软OFFICE2013：新外观，新价位[J].微电脑世界，2013,（03）:30-32
[29]Parawee Pleehajinda.Database centric software test management framework for test metrics [D].Thailand： Technische Universitat Chemnitz， 2015,47-49
[30]李荣国，王见.MySQL数据库在自动测试系统中的应用[J].计算机应用， 2011,31（02）:169-170
[31]苏清伟，高磊，杨坤.一种医疗器械维修信息管理软件的开发[J].中国医疗设备， 2016,31（08）:80-81
[32]杨佳琪，陈思言，高志辉，邓胜利.国外个人信息管理研究综述[J].数字图书馆论坛， 2016,（145）:65-66
[33]Guillermo Rauch. 了 不起的 Node.js[M].（Goddy Zhao 译）.北京：电子工业出版社， 2014,273-276
[34]黄建宏.Redis设计与实现[M].北京：机械工业出版社，2015,1-5
[35]左程云.程序员代码面试指南[M].北京：电子工业出版社，2015,258-259
[36]虫师.Web接口开发与自动化测试[M].北京：电子工业出版社，2017,205-221
[37]Chris Sanders.Wireshark数据包分析实战[M].（诸葛建伟，陈霖，许伟林译）.北京：人民邮电 出版社， 2013,39-40
[38]James Whittaker.探索式软件测试[M].（方敏，张胜，钟颂东，郭艳春译）.北京：清华大学出 版社， 2010,16-20
[39]James Whittaker，Jason Arbon，Jeff Carollo.Google 软件测试之道[M].（黄利，李中杰，薛明 译）.北京：人民邮电出版社， 2013,104-109
[40]林信良.Java学习笔记JDK8[M].北京：清华大学出版社，2015,40-43
[41]Kai Hwang， Geoffrey C. Fox， Jack J. Dongarra.云计算与分布式系统从并行处理到物联网 [M].（武永卫，秦中元，李振宇，钮艳译）.北京：机械工业出版社，2015,188-191
[42]Jenna-Riia Karhunen.Scrum Quality Management： an Empirical Study[D].Finland： TAMK University of Applied Sciences， 2009,12-13
[43]Frederick Brooks Jr.人月神话[M].（UMLChina翻译组，汪颖译）.北京：清华大学出版社， 2015,147-151
[44]David Josephsen.Nagios系统监控实践（原书第2版）[M].（康锦龙译）.北京：机械工业出版 社， 2014,40-45
[45]Russell J.T. Dyer.MySQL与MariaDB学习指南[M].（袁志鹏译）.北京：人民邮电出版社， 2016,1-4
[46]前沿电脑图像工作室.精通Dreamweaver8[M].北京：人民邮电出版社，2007,12-14
[47]徐超.OpenStack最佳实践[M].北京：电子工业出版社，2017,16-24
[48]张馨木.基于云计算的档案管理服务创新J].赤子：上中旬，2016,（01）:135-135
[49]James Turnbull.第一本Docker书[M].（李兆海，刘斌，巨震译）.北京：人民邮电出版社， 2016,1-10
[50]Thomas H. Cormen，Charles E. Leiserson，Ronald L. Rivest，Clifford Stein.算法导论[M].（殷 建平，徐云，王刚，刘晓光，苏明，邹恒明，王宏志译）.北京：机械工业出版社， 2014,129-137
相关标签:
