Octopus自动化工具设计.doc

3

测试自动化
工具Octopus框架设计

作 者 赵椿玉
日 期 2011年10月
版 本 初稿

摘要
本自动化工具主要用于质量部软件测试工作。辅助系统功能测试进行自动化执行，快速实现自动化测试用例，减少测试回归成本，提高工作效率。也可用于开发人员进行本地系统自测，提高开发人员自测效率。
本论文主要针对自动化工具的需求分析，系统设计，实现等方面进行论述。结合开源框架Selenium和Servlet技术，使用MySQL，通过Selenium Grid进行远程请求服务器，实现任务分发和执行，使用资源池人工分发实现用例并发执行，动态生成测试结果和记录系统日志，形成B/S架构的自动化测试工具Octopus。主要特点：系统轻量，不需要安装客户端，通过网站访问，新增和修改测试用例，启动用例执行。测试用例统一使用xml格式编写，在执行过程进行数据解析，生成命令，对象，操作属性列表，顺序执行。通过Selenium原理操作JS页面，实现测试用例自动执行，并实时生成测试报告。适用情况：
1、 公司系统中稳定的核心模块，在系统更新后需要进行核心业务确认，避免因为更新操作影响核心业务造成不必要的损失。
2、 新开发的软件功能，需要定义好操作对象的属性，操作步骤，即可进行测试用例设计。即可实现自动化测试，提高工作效率，缩短测试时间，提高回归覆盖率。
3、 对系统代码更新的情况，在测试阶段无法估计影响范围，使用全业务自动化回归，实现最大范围的覆盖，降低因代码更新而造成其他业务功能失败。
4、 实现系统每日构建。根据测试报告，分析评估更新影响范围。快速发现bug。保证已有业务功能正常。
本文首先是对目前国内主流自动化情况进行分析，总结优缺点，针对分析结果，提出解决方案，并形成此系统设想。接下来根据公司业务现状，内部需求设计实现方案，进行项目规划。然后是根据规划进行系统实现，达到系统预期效果。最后归纳总结，结合本系统实现后的情况进行进一步优化设想和进一步的猜想。

关键字：Octopus，自动化测试，Selenium，B/S架构
目录

第一章 绪 论 5
第二章 需求分析 16
第三章 系统设计 27
第四章 系统设计实现 44
第五章 总结和展望 55
致 谢 57
参考文献 58

9
第一章 绪 论
1.1背景
1.1.1 公司背景简介
本公司属于第三方支付公司，主要业务是进行网上支付交易，为商家和消费者提供专业电子支付解决方案和服务。因此系统每天将会产生大量交易数据，涉及资金交易等敏感数据，为了满足客户的需求，新业务开放，bug修改以及各银行系统的升级。每天会定时对系统进行更新，必须保证系统更新不会对系统核心业务造成影响，保证客户资金安全，交易正常。不能因更新或系统缺陷对交易过程，资金等造成任何损失。
1.1.2 自动化需求来源
随着计算机技术的发展,软件在整个社会生活中的重要性变得越来越高,软件测试的重要性亦随之变得日益突出.在传统手工测试已不能满足软件测试需要的情况下,自动化测试技术孕育而生.软件自动化测试就是希望能够通过辅助工具或其它方法,让测试按照预定计划自动进行,从而达到减轻手工测试劳动量、提高软件质量的目的.。
而公司的每日更新操作，必须对系统已有业务进行完全回归，保证业务不受影响，在业务功能不断增加，测试资源缺乏，回归测试枯燥的情况，开展自动化测试工作成为必然的趋势。
1.1.3 自动化测试优势
简要说明自动化测试的优势，以充分的理由阐述，自动化测试工作是解决手工软件测试的最好解决方案。也是支付行业，涉及敏感数据软件必不可少的一项技术。
1、自动化提高测试质量
每一次版本的更新，都会对系统产生一定的影响，自动化测试能节省大量的重复手工操作，保证测试用例的一致性，避免了人为因素的干扰。从而提高软件测试的质量。
2、自动化提高测试效率，缩短工作时间
对于大规模的软件系统，上千上万个功能点，如果进行人工测试非常耗时间，对于繁琐的测试，测试效率必然会相当低下，而自动化测试可以较好的执行频繁的测试用例，合理利用测试工具，减轻测试工程师的手工测试工作，有效的保证测试质量并缩短测试时间。
3、提高覆盖率
自动化执行，大大缩短的测试时间，于此同时，可以进行更多的测试用例，保证能覆盖的功能点都能进行覆盖，提高覆盖率。
4、更好的重现软件缺陷的能力
自动化测试脚本的一致性和可重复性，而这种一致性人工很难做到，自动化用例脚本的一致性就能更好的发现和定位缺陷。
5、更好的利用资源
理想的自动化测试能够按照计划完全自动化地运行，所以在夜间执行自动化测试，次日查看测试报告，能更好的节约和利用资源。
6、保证核心业务交易正常
对于支付行业来说，核心业务随时都有客户使用，所以核心业务必须时刻正常运行，自动化测试能最大粒度的保证核心业务的正常运行，也保证系统的稳定性。
1.1.4 自动化测试误区
自动化测试工作的开展，也不能解决所有问题，自动化测试只是测试的一种辅助手段，需要明确自动化测试如下几点，才能更好的开展自动化工作，确保领导和相关人员对自动化测试正确理解和合理期望。
1、工具是万能的
自动化工具并不是万能的，不可能完成所有的测试工作，自动化工具也不能自动生成测试用例。在前期，测试用例设计，测试脚本设计，后期的测试结果分析，这些都是需要人工主导。自动化测试永远不能代替手工测试。
2、一种工具可以用于所有的测试
每种工具都可能适用于特定的环境，适用于不同的测试对象，一种工具是不可能覆盖所有的测试需求，一般情况下，需要利用多种测试工具，或者开发适用于本业务的自动化测试框架才能达到自动化测试的目的。
3、能使工作量大幅度减少
自动化测试工具是不会马上减少测试工作，相反，在大多数情况下，前期投入是非常的大，只有合理运用自动化工具，并得到一定积累，才能有效的减少对整个自动化工作的时间投入。
4、实现100%覆盖
自动化工具是不能100%覆盖测试用例，不是所有的测试都可以适用自动化实现，例如，开发周期很短，回归次数很少。也不是所有的测试用例都能使用自动化实现，例如：验证码、声控、光学等。
5、自动化工具容易使用
自动化测试不可能通过简单的录制回放就能达到自动化测试效果的。必须考虑捕捉的操作是否正确，是否能适用于回放，测试数据的动态变化，测试结果的统计，以及脚本编辑是否合理都会影响到测试结果。一个简单上手的测试工具，工具本身必然强大。而强大的测试工具，需要投入更多的技能，更多的培训。
6、自动化测试能发现大量的新缺陷
自动化测试主要用于保证系统正常业务不受影响，反复执行已有的测试用例，所以只能发现原来的缺陷，自动化测试常用于回归测试，而大量的新业务，未形成自动化测试脚本的业务还必须得依赖手工测试。
1.2 软件测试自动化基本概念
自动化测试就是通过测试工具或者其他手段，能够按照预定计划对软件系统进行自动化的测试，它是软件测试的一个重要组成部分，能够完成许多手工测试无法完成或者难以实现的一些测试工作。
自动化测试是相对于手工测试而言的，是通过工具执行测试用例。所以称之为自动化测试。软件测试自动化涉及到测试流程，测试体系，自动化编译，自动化测试等多方面的整合。
1.2.1自动化测试适用场景
开展自动化测试工作必须先明确适用环境，适用对象，不是所有的测试都有必要实现自动化测试。
自动化测试适用于功能趋于稳定，并且可能会存在多次回归测试的情况下。
自动化测试适用场景
1、项目大于3个月，资源有余。
2、界面功能趋于稳定。
3、人工无法完成的大数据量测试。
4、系统执行有明确的预期结果。
5、系统人机交互界面能被工具识别。
6、稳定核心业务的回归测试。
7、资源满足（工具，技术，人员）。
1.2.2自动化测试命门
自动化测试的命门：维护成本
我们可以用一个公式来计算自动化测试的实施成本：
自动化实施成本=前期的开发成本+后期的维护成本
前期开发成本基本趋于稳定，可以预估。后期维护成本，因变更的不确定性。则无法预估。所以最大的成本在后期维护。主要有两个方面：
1. 产品的变更引起自动化测试脚本的变更
UI自动化测试最常见的问题就是页面的变更，因为UI自动化测试脚本的内容是依赖于产品界面的，如果界面变化，将必须进行脚本维护。
2. 运行环境的随机事件引起脚本健壮性的问题
支付行业系统均与银行系统有关，如果银行系统发生变化，自动化脚本就可能需要维护。在B/S架构的UI自动化测试中，主要不确定因素有：
Ø 运行环境中其他因素的干扰，如银行响应超时，Web页面的展现速度，从而导致脚本的超时错误。
Ø 浏览器版本的影响，升级后可能造成页面元素不识别问题。
Ø 浏览器弹出框的影响。
Ø Web Server的性能不稳定导致的问题。
1.2.3自动化测试与手工测试比较
I 对于已经稳定系统
自动化测试的意义在于保证产品的稳定性，而手工测试则是在产品稳定满足的基础上，负责验证容错性，安全性等非核心功能，两者各司其职，互补长短。
II 对于开发中的系统
自动化测试主要保证已有系统功能的正确性，每次集成后的回归测试，及需要大数据量或者大量重复测试的部分。而对于新开发的功能需要进行手工测试，保证正确性后才能进行自动化设计。
1.2.4测试自动化开展流程
对于公司级别的自动化工作，开展流程如下图所示：

图1-1自动化测试开展流程
测试人员提出自动化需求，自动化开发人员根据自动化测试适用场景评估自动化可行性。如果可行则由测试人员设计测试用例，通过评审后，进行自动化脚本开发。开发完成后，测试人员验收，验收通过后投入使用。如不满足自动化测试可行性，则不进行开发，结束流程。
1.3 相关技术简介
1.3.1 Selenium
Selenium是一款基于Web应用程序的开源测试工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。它支持GoogleChrome、Opera、Firefox、IE、Mozilla等众多浏览器。它同时支持JAVA、C#、Ruby、Python、PHP、Perl等众多的主流语言。
特点：
Ø 开源、轻量
Ø 运行在多种浏览器中
Ø 简单灵活、支持很多种语言
Ø IED提供录制功能
Ø 灵活性高
Ø 高速
1.3.2 Selenium Grid
Selenium的插件，提供多种执行机制。允许同时并行地、在不同的环境上运行多个测试任务，极大地加快Web 应用的功能测试。
实现原理如下图所示：

图 1-2 Selenium Gird 实现原理（资料来源：http://seleniumhq.org/）
Selenium Grid是提供了一个Hub，类似于一个用于控制测试的远程控制器，但以显式地将测试请求发送到一个或多个机器上，将的某个有效的Selenium-RC进行实例化。这个Selenium Hub负责以下这些事情：
Ø 将一个SeleniumRC显式地分配给一个具体的测试
Ø 限制在每个RC最大并发测试数
Ø 将测试屏蔽在一个实际的网格结构之外。
1.3.3其他成熟技术
A、Tomcat
Tomcat 是一个轻量级应用服务器， 在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。当在一台机器上配置好Apache 服务器，可利用它响应对HTML 页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展，但它是独立运行的，所以当你使用Apache Tomcat运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。
B、MySQL
MySQL是一个小型关系型数据库管理系统，是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内。这样就增加了速度并提高了灵活性。MySQL的SQL“结构化查询语言”。SQL是用于访问数据库的最常用标准化语言。MySQL软件采用了GPL（GNU通用公共许可证）。其体积小、速度快、总体拥有成本低，开放源码这一特点，为本次开发提供很好的数据库支持。
C、B/S
B/S（Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。
在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现。相对于C/S结构属于“胖”客户端，需要在使用者电脑上安装相应的操作软件来说，B/S结构属于一种“瘦”客户端，大多数或主要的业务逻辑都存在于服务器端。因此，B/S 结构的系统不需要安装客户端软件，它运行在客户端的浏览器之上，系统升级或维护时只需更新服务器端软件即可，这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。
1.4 结构
如下将对本文的结构进行一个简要的说明：
第一章：简介自动化发展趋势和相关技术。
第二章：对国内现有自动化框架进行简述，并分析其优缺点和使用领域。再将结合本公司业务得出一套使用于本公司本行业的自动化框架构想。
第三章：对构想的自动化框架进行需求分析，进行详细的系统设计。
第四章：根据系统设计进行自动化框架实现。
第五章：对此自动化工具进行总结和进一步展望优化构想。

16
第二章 需求分析
2.1现状
2.1.1国内支付行业自动化现状
软件测试发展快速进行，自动化测试成为软件测试必然趋势，自动化工具也出现了很多，下面对市场主要流行的自动化工具进行说明。
1、QTP
自动化测试技术在国内也刚开始，很多小公司测试资源不足，也就没有精力投入自动化测试工作。在测试人员充足的情况下，才会涉及到自动化测试。自动化测试在前期投入比较大，对技术要求也比一般测试人员高。从公司的投入和人员方面都可能会是一个瓶颈，自动化测试覆盖范围还是比较小，大部分公司都是处于起步阶段。
国内最流行的测试工具是QTP如：中国农业银行。市场40%左右，
QTP是QuickTest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。
优点：
Ø 趋于成熟的自动化工具，入手简单，有成熟的培训机构。
Ø 支持录制回放功能。
Ø 功能强大，使用于多种系统。
缺点：
Ø 一个脚本只支持相同环境下回放功能。很难满足兼容性测试。
Ø 需要安装庞大的客户端，必须在指定环境下运行。
Ø 采用对象识别方式，对象识别的支持还是有些欠缺。
Ø 维护成本大，需要专业维护。
Ø 工具价格昂贵。
2、TestComplete
TestComplete 一款自动化工具，价钱便宜，支持web测试，如用友，市场10%左右
3、Selenium
Selenium 开源自动化工具，如：支付宝 市场20%左右。关于此工具的介绍，请查看1.3.1
4、其他
如Rational，E-Test Suite，Watir，WebKing，Tellurium等适用于不同的系统的自动化框架。在此就不做详细介绍。
2.1.2第三方支付产品特点
第三方支付行业与项目类系统有很大的不同，系统已经投入使用，主要是新功能开发和线上系统维护。主要特点：
1、更新频繁
为满足客户需求，和各银行接口的变动，新功能上线，已有系统bug修改等。所以需要对系统进行频繁的更新操作，每天均有上线操作，进行系统更新。
2、快速响应：
市场需求必须在最短时间内响应，银行系统切换等，在不影响交易的情况下，必须进行快速响应。满足市场需求，也需要快速实现需要功能，这样才能更好的占有市场。
3、安全性：
主要是涉及大量敏感数据，需保证数据安全性。
4、正确性：
涉及客户资金交易，必须保证交易过程的正确性。
5、兼容性
涉及多浏览器，主流IE6,IE7,IE8,Firefox，必须保证市场主流浏览器能正常使用，满足不同环境需求。
2.1.3第三方支付自动化需求
自动化需求完全来源于第三方支付的特点。
1、频繁更新，只要代码发生改变，就可能会影响其他代码，所以更新后必须对已有业务进行回归测试，保证已有业务不受影响。一旦影响了其他业务，可能会造成不可预知的后果和巨大的损失。
2、市场需求需要在最短时间内响应。当市场需求急迫的情况下，进行人工回归会占用大量的资源，一旦市场需求功能实现，将会快速上线。为保证线上已有系统正常，必须进行自动化测试。
3、涉及大量敏感数据，交易金额等。系统每次更新就需要保证业务正常，交易金额正确。由于人为操作失误导致的金额验证错误或者测试遗漏时而发生。而自动化测试将对需要校验的金额进行有效的验证，通过自动脚本执行来屏蔽人为操作风险。
4、涉及多系统多浏览器兼容，系统本身业务较多，回归工作量很大，对多系统多浏览器的回归测试更是枯燥和漫长。而自动化测试可以很好的解决此问题。
2.1.4本公司自动化系统目标
现状：
公司的自动化测试工作为初级阶段，投入资源不足，对自动化测试了解的也不够深入。对自动化测试带来的效益没有明确的数字衡量，所以只能从探索阶段进行。
自动化目标：快捷、轻量、兼容性、方便。
快捷：实现快速执行和脚本快速开发及维护。实现测试用例快捷，因系统本身更新频繁，所以对自动化测试用例的维护必须快速响应。因涉及到交易，在服务器切换时，需要在指定时间内完成所有关键业务的自动化执行，避免长时间系统维护。
轻量：自动化工具执行效率高，工具本身资源利用低。
兼容性：B/S系统必须满足Web端的正常使用，满足不同操作系统下不同浏览器的正常运行。所以兼容性是必不可少。工具实现的自动化脚本需要在多环境下能回放。
方便：使用和维护方便。前期自动化测试工作，不会投入太多的人力和技术，要推广自动化必须在现有测试人员可培训技术的基础上进行实现。工具不需要复杂的操作或者培训，即可让大部分人员使用该系统执行自动化测试。
2.2自动化框架模型形成
要实现测试自动化，光靠自动化工具简单的录制回放是不行的，需要搭建一个实用的测试自动化框架，以下是经过分析形成公司测试自动化框架的过程。
2.2.1自动化系统需求
根据上述目标和支付行业的特性，现有产品内工具不能满足此需求。如下将结合实际情况，逐步分析，形成一套适用的自动化测试工具。
1. 频繁更新：
系统的频繁更新，需要使自动化测试脚本能更好的维护，能快速适应更新操作，否则维护成本将会很大。
要求：以最少的元素准确定位操作。
2. 对多浏览器的兼容性
对于兼容性，要求测试用例一次设计，就能在多浏览器，多系统的环境下运行，QTP是不能实现的，他通过对象定位，而对应不同浏览器的对象属性有可能就不同，所以使用QTP将会维护多套脚本。
选择Selenium，他使用页面元素id，name或者Xpath定位，而这些元素在不同的浏览器上是固定的，本公司系统使用java开发，Selenium也是使用java实现，能更好的结合到本公司系统中，Selenium原理使用给js中元素赋值的原理实现自动执行。能够满足一次设计，多浏览器回放的要求。
3. 测试脚本的复用性
对公司业务，主要是交易，而交易流程基本相同，大多测试主要测试各个银行接口是否正常，所以，主要是测试数据不同，流程相同，这样为了提高用例复用性，要求将可以复用的脚本进行封装调用。
Selenium 不能友好的实现此功能，Selenium使用junit框架，测试用例不便于直接维护，也不便于一般测试人员使用。需要在Selenium的基础上进行二次开发，设计一种能适用于一般测试人员看懂，修改，执行的测试用例表现形式。
用例使用XML文本是比较简单也比较通用的语言，可以定义标签，自动化执行的每个操作最多设计到三重属性：操作、操作对象、值。这样xml就能更好的表现操作步骤。
4. 测试结果输出
Selenium 只是一个开源的自动化工具，没有适用于本公司的完善框架，测试结果将需要结合业务，动态生产不同模式的测试用例。可以通过java实现测试结果报告。
综上所述：要满足公司对自动化的要求，本次自动化工具实现将结合Selenium实现一套B/S架构的自动化工具。
2.2.2功能需求
根据公司业务，对自动化工具的功能需求如下：
1. 用例定制执行：在多个用例的情况下，可以按照需求，选择性的执行测试用例。
2. 用例维护：能直接对用例脚本进行增删改，而不需要重新部署。
3. 测试执行报告：每个用例执行完成后，生成指定的测试报告。
4. 测试结果邮件功能：在一次自动化任务执行结束后，将最终测试报告以邮件方式发送给指定测试人员。
5. 测试并发进行：多个自动化测试用例能并发执行，互不影响。
6. 系统日志功能：实时记录操作记录，将日志存放到数据库，方便缺陷跟踪和问题排查。
2.2.3框架设计
根据需求的模块说明对整个系统进行结构说明，系统分三层：
展现层：直观的界面，用于测试人员的所有操作，包括：初始化参数、定制测试用例、测试用例编辑、查看测试结果、查看执行日志等页面。
控制层：主要接收参数，对测试用例的解析、对测试结果的分析等。
执行层：接收控制层参数执行测试用例和多个支撑组件的功能实现。
2.2.4展现层
主要面对自动化使用者（测试人员，自动化执行人员）实现数据输入和输出功能。
功能展现：测试用例文档、测试控制文档、测试结果报告、测试过程日志。
功能说明：
a) 测试数据管理：测试用例管理（增删改）、控制执行文件。
b) 控制执行文件内容：执行业务名称、执行业务顺序、多线程执行、执行开始时间、执行触发条件、测试报告模式和邮件地址。
c) 测试结果报告。
d) 测试过程日志。
2.2.5控制层
主要用于数据解析、测试结果分析。如下图所示：

图2-1 控制层结构

提供功能：测试数据文件解析、测试控制参数解析、测试结果分析、测试结果整理。
功能说明：
a) 数据解析接口：解析测试数据XML文件、解析任务执行控制参数。
b) 测试结果分析模块：分析测试结果、比对测试实际测试结果与预期结果。
2.2.6执行层
主要执行测试用例，也包括一些支持组件，如下图所示：
图2-2 执行层结构
各个模块说明：
A、功能测试模块：
1、初始化测试环境：根据初始化参数，初始化测试环境，主要是浏览器，
2、测试用例执行：将解析完的测试用例，按照序列顺序执行。
B、支持组件模块：为自动化框架提供支持功能模块
1、用例维护：用于用例的增删改操作。
2、报告定制：在测试用例执行完成后，按模板生成测试报告。
3、邮件服务：在一次自动化执行完成后，使用邮件服务，将测试报告发送到指定用户。
4、日志功能：记录系统的操作日志，包括：脚本执行，测试用例编辑，报告生成等系统操作。
2.3 执行流程
框架执行流程如下图所示：

图2-3 框架执行流程
流程简介：
测试人员发起测试用例请求：请求中包括测试用例和配置测试用例参数。
配置测试用例参数包括：服务器地址、浏览器、测试地址、并发执行等。
各执行流程说明：
1、 执行控制文件：根据所传送的参数，初始化测试环境，控制执行层执行测试用例。
2、 控制用例执行：将参数请求发送给执行层，根据参数执行测试用例。
3、 测试数据：执行层执行测试用例，从数据库中读取测试数据给控制层，解析后发送给执行层执行。
4、 临时数据：在执行过程中，需要临时保存的测试数据存放在数据库中。
5、 日志文件：将一个测试用例执行完成后的测试文件存放在数据库中。
6、 测试结果：每个测试用例执行完成后，将测试结果存放在数据库中。
7、 测试结果：一个测试用例测试完成后，动态生成测试报告，测试数据从数据库中读取。
8、 测试报告：将生成的测试报告发送到展现层。
整个流程执行完毕。
2.4小结
本章分析市场，结合第三方支付的特点，形成了一套适用于公司需求的自动化框架，
主要从框架组成，模块结构进行说明，包括各个模块需要实现的功能，组成部分，执行流程等，本章只是一个框架的结构，对于具体实现，工具选择没有涉及到，框架勾画出一个蓝图，告诉我们需要做什么，要达到什么效果。接下来一章就是详细设计，我们选择什么样的工具去取支撑，做成什么样的系统。

27
第三章 系统设计
本章将对由需求而来自动化框架进行详细设计，针对框架中各个模块的具体实现，进行详细说明。主要包括：模块功能，模块结构，实现技术。
3.1系统分析
根据以上一章节的阐述，本系统实现构想如下：
1、 采用B\S架构，测试人员通过浏览器发送请求、进行测试用例维护、查看测试报告、日志等功能。
2、 使用开源自动化工具Selenium内核，进行二次开发，满足快速，多浏览器回放需求。
3、 使用MySQL数据库保持测试用例、测试结果、临时测试数据、测试日志文件。
4、 采用XML进行测试用例设计。语法简单，使用直观方便。
5、 使用本公司邮件服务系统，方便内部邮件发送。
6、 采用Windows 服务器，方便服务器端多浏览器回放。
7、 系统支持并发，串行，服务器端执行，客户端执行。
根据以上分析，如下进行详细的系统设计。
3.2系统设计
本自动化工具将命名为Octopus，以下将以Octopus代替此自动化工具。Octopus系统结构：如下图所示：

图3-1 系统结构图
系统结构包括：
页面展示：执行用例页面、编辑用例页面、测试结果查看页面、日志查看页面。具体页面功能将在下面进行详细说明。
系统主体：数据解析、测试报告生成、核心容器（用于执行测试用例）、邮件系统功能。
数据库：测试用例、测试结果、临时测试数据、日志文件等功能。
用例执行流程图如下图所示：

图3-2 用例执行流程

对执行流程说明：
测试人员在页面请求执行测试用例－—＞系统将请求发送到核心容器－—＞解析测试数据－—＞访问数据库－—＞解析测试用例－—＞调用Selenium服务－—＞执行测试用例－—＞记录日志－—＞记录测试结果－—＞生成测试报告。
3.3模块设计
如下将对系统模块中的各个模块功能进行详细设计说明。包括系统设计中支撑模块。
3.3.1核心容器
核心容器：主要用于对测试脚本的解析，并动态执行测试用例，结合Selenium的技术实现。
实现技术：Selelnium提供多种编程语言，而核心服务包只有一个，可以对核心包进行二次封装，形成一套适用于xml语言的B/S自动化系统。在将Selenium提供的API进行重载，或者封装成新的API，用于脚本命令执行。

3.3.2用例脚本设计
测试用例设计规范，统一用例格式。便于系统解析和用例设计，用例模板xml语言。
<ROOT>
<step1 description="对脚本执行的初始" >
<operate>操作</operate>
<object>对象</object>
<value>值</value>
</step1>
</ROOT>
本系统使用步骤级处理测试过程，故每个步骤均有三个参数：操作，对象，值。
操作: 中填写需要进行的操作命令，及对对象的处理。
对象：填写需要处理的对象，使用对象的唯一表示，如name或者id 也可以使用xpath抓取方式：
1、使用Selenium的IDE进行录制抓取。
2、使用xpath分析工具抓取。
值：对对象赋值。如填入的卡号，金额等操作。
注意事项：
如果操作只有对象没有值，则去掉<value></value>标签。
如果操作没有对象，只有值，则去掉<object></object>标签。
标签顺序不能进行改变。
Step步骤级不能有重复标签。否则将不会解析重复step标签。
Step步骤级中的description是对当前步骤的注释，编译过程不解析，可选。
操作命令：
I 直接适用的API
直接适用的api 主要是由Selenium提供的一些简单操作，这些操作命令可以直接使用。
II 二次封装API
二次封装的api主要是由于Selenium所提供的api不能满足测试业务使用，或者不能完成一个简单的操作等，将这些重新定义方法，方法中包含一个或者多个Selenium语句和一些算法等。
测试用例解析：
测试用例通过如上设计规范，系统将解析成可执行的用例序列。采用map存储模式，核心容器通过map按顺序循环执行测试脚本。
3.3.3用例脚本管理设计
测试用例使用xml格式设计，脚本管理包括测试用例的添加，测试用例的修改，删除等操作，展现形式均为网页形式，测试人员通过访问指定网页，程序从数据库中动态读出或写入数据。
测试用例添加页面：原型如图：

图3-3 用例添加页面

页面说明：
作者：用例设计者
业务名称：用例名称
简介：对用例的简要说明，主要包括用例数据，使用范围，测试功能等。
用例属组：用例所属组，方便用例查询，归类到不同组，也方便选择执行。按业务和产品线分组。
XML：用例正文。
编辑状态：用例描述用例是否可以编辑，是：可以编辑，否：不可以编辑。
测试用例编辑页面原型如图：

图3-4用例编辑页面
页面说明：
用例id：测试用例的唯一标示，可以在执行页面进行查看。
编辑状态：标示是否可以编辑，1为不可编辑，0为可编辑。依赖用例创建的是否可删除。
操作类型：选择操作类型，提供两种操作类型，删除和修改。
3.3.4用例执行模块设计
测试用例，采用页面触发，选择所要执行的测试用例，请求服务器执行，服务器根据所传输的参数，进行解析，并调用测试用例执行。
分组页面原型如图：

图3-5 用例分组页面
按不同的类型的用例进行分组，各组负责不同的产品线，按组进行分类，测试环境和生成环境各不相同，模块用例组用来查询所有可以复用的模块，方便调用的模块，相当于汽车的各种可使用的零件。
执行页面原型如图：

图3-6 用例执行页面
页面说明：
1、选择需要执行的测试用例。
2、配置启动参数：
主机: 测试用例所要提交到的服务器地址。
端口：用例执行测试用例的端口，服务器开启多个端口，支持不同用户同时使用，以支持并发执行测试用例。
浏览器：测试用例回放使用的浏览器，一个用例支持多种浏览器回放执行。
开始网址：测试用例起始网站，用于初始化浏览器。
报告邮件：将测试结果发送到指定用户邮箱中。
启动开始：发送请求，执行所选择的测试用例。
3.3.5测试报告模块设计
报告模块通过网页形式展示，在测试用例执行完成后，实时生成测试报告，包括：测试通过数，测试失败总数，测试结果详情。可配置的进行邮件发送到指定测试人员。
数据流图如图所示：

图3-7测试报告生产数据流
数据流说明：
1. 启动执行。
2. 执行过程记录测试结果数据，实际结果为NOCHECK。执行完用例后在数据库中修改实际测试结果。
3. 执行完一个用例后，从数据库中读出数据，生成测试报告。
4. 循环执行测试用例。整个用例执行完成后，发送测试报告邮件。
页面原型如图：

图3-8 测试报告
页面说明：
报告生成时间：每次执行完一个测试用例，生成测试报告，记录当前系统时间。
成功总数：两天内测试用例执行的成功总数。
失败总数：两天内测试用例执行的失败总数。
用例信息：两天内用例执行成功详细列表，包括：用例执行时间、用例名称、状态。
3.3.6日志功能设计
在测试用例执行过程中进行日志记录，方便查看运行动态和错误定位，包括内容：系统执行信息、用例执行步骤、报错信息。日志分为两种，一种是当前系统执行日志；一种是历史系统日志。展现形式通过网页形式，测试人员通过访问指定网址查看系统日志。
使用技术：log4j
3.3.7邮件功能设计
邮件系统，为测试人员发送测试报告，方便及时查看测试结果，在测试计划执行完成后，生成测试报告，然后通过邮件发送到指定测试人员。
使用技术：集成本公司邮件服务。
3.3.8数据库设计
在整个测试过程中，所有测试数据均通过数据库管理。包括测试用例的维护，测试结果的记录，临时数据存储。
测试用例表：CASES 用来保存测试用例文件。
表说明：
CASES
测试用例表

名称
字段
类型
描述
说明
编号
ID
INT NOT NULL AUTO_increment
唯一标示，自增，非空
主键
创建日期
CREATEDATE
TIMESTAMP
当前系统时间,编辑时间

作者
AUTHOR
varchar(50)
创建者姓名

用例名称
CASENAME
varchar(50)
用例名称

简介
INTRO
varchar(150)
简要说明，用例用途描述

用例
XML
longtext
用例xml文件

编辑
ISDELETE
int not null default '0'
可编辑标志
0表示可以编辑，1表示不能编辑。
属组
CTYPE
varchar(50)
用例类型
*1表示正式用例，*0表示测试用例。*表示所在组。如一组生产用例：11 二组测试20；

测试结果表：RUNRESULT 用例记录测试运行结果。
表说明：
RUNRESULT
测试结果

名称
字段
类型
描述
说明
编号
ID
INT NOT NULL AUTO_increment
唯一标示，自增，非空

运行时间
RUNDATE
TIMESTAMP
脚本运行时间
系统自动创建
业务名称
BUSINESS
varchar(50)
脚本运行名称

测试帐户
CUSTOMER
varchar(50)
测试帐户

订单号
REQUESID
varchar(50)
订单号，可以为空

预期结果
EXPRESULT
varchar(50)
预期结果

实际结果
ACTRESULT
varchar(50)
实际结果
默认为：NOCHECK。成功为：SUCCESS。否则未：FAILED

临时数据数据结构 交易表RECOEDDATA 记录交易相关信息。
表说明：
RECOEDDATA
测试执行详情

名称
字段
类型
描述
说明
编号
ID
INT NOT NULL AUTO_increment
唯一标示，自增，非空

交易时间
TRADATE
TIMESTAMP
交易创建时间

交易订单号
REQUESID
varchar(50)
交易订单号，也可以为用例执行过程的唯一标示

交易类型
TRATYPE
varchar(50)
交易类型，描述交易类型，可为脚本业务名称

测试用户名
CUSTOMER
varchar(50)
业务执行的测试帐户

密码
PASSWORD
varchar(50)
测试帐户密码（可不填）

交易金额
AMOUNT
decimal(18,4)
记录订单交易金额

退款金额
REFUNDAMOUNT
decimal(18,