编码UI测试工具的扩展及在重构保险系统中的应用硕士学位论文Word文档格式.docx
《编码UI测试工具的扩展及在重构保险系统中的应用硕士学位论文Word文档格式.docx》由会员分享，可在线阅读，更多相关《编码UI测试工具的扩展及在重构保险系统中的应用硕士学位论文Word文档格式.docx（33页珍藏版）》请在冰豆网上搜索。
目录
摘要i
Abstractii
目录I
图目录IV
表目录V
第1章绪论6
1.1引言6
1.2软件测试的意义和目的7
1.2.1软件测试的意义7
1.2.2软件测试的目的7
1.3软件测试的分类8
1.4自动化测试的历史和现状9
1.5论文的课题背景和研究内容9
1.6本章小结10
第2章重构项目的系统概述11
2.1软件再工程的概述11
2.2保险系统简介12
2.3系统重构前后的架构变化13
2.4重构项目中测试工作面临的挑战14
2.5本章小结14
第3章测试难点和解决方案16
3.1测试方法选取16
3.1.1白盒测试16
3.1.2黑盒测试16
3.2获取测试需求的难点17
3.2.1需求文档不全17
3.2.2逆向分析代价高18
3.2.3旧系统即是需求18
3.3对比测试19
3.4回归测试21
3.5本章小结22
第4章自动化测试流程23
4.1自动化测试的工作流程23
4.1.1标准自动化测试流程23
4.1.2对比测试的工作流程24
4.1.3回归测试的工作流程26
4.2本章小结28
第5章编码UI测试工具的扩展和完善29
5.1编码UI测试工具简介29
5.2GUI自动化测试工具介绍29
5.3工具的选取29
5.4自动化测试框架的构想和测试方法实践30
5.5CodedUITest的不足与缺点30
5.6本项目中对该工具的扩展和完善31
5.7CodedUITest在项目中的应用及测试流程32
5.7.1第一步----准备好原始数据库文件和SQL脚本32
5.7.2第二步----配置AppConfig.xml33
5.7.3第三步----创建解决方案和添加工程34
5.7.4第四步----向工程中添加相关的DLL文件36
5.7.5脚本运行模式37
5.7.6自动化测试细节37
5.8常见问题39
5.9本章小结40
第6章结果分析41
6.1自动化对比测试的效果分析42
6.2自动化回归测试的效果分析42
6.3本章小结43
第7章总结与展望44
7.1总结44
7.2展望45
参考文献46
作者简历48
致谢49
图目录
图2.1一般计算机软件系统的生存周期12
图2.2保险系统技术架构图14
图3.1对比测试原理图21
图4.1标准自动化测试流程图25
图4.2对比测试工作流程图27
图4.3回归测试工作流程图29
图5.1代码示例图33
图5.2SQL脚本关联对应数据库34
图5.3配置文件35
图5.4创建工程36
图5.5解决方案路径37
图5.6解决方案视窗37
图5.7测试集视窗38
图5.8数据库还原进度条39
图5.9测试结果视窗39
图5.10日志文件路径40
表目录
表3.1回归测试执行表21
表5.1常见问题及解决表39
表6.1手工测试和自动化测试比较数据表41
第1章绪论
1.1引言
随着个人计算机的广泛普及和互联网的高速发展，各式各样的计算机应用系统逐渐渗透到我们的生活中，给我们的生活带来越来越多的便利。
例如超市购物系统、交通售票系统、保险业务系统等应用软件系统给生活的便利带来了质的飞跃；
而之后出现的网上购物系统、网上银行系统、各种网上金融交易系统等则在结合了飞速发展的互联网之后，进一步给我们的日常生活带来了翻天覆地的变化。
随着时间的推移，计算机技术依然在不断地更新换代，系统所拥有的用户数量更在不断地增长以及系统所涵盖的业务领域也在不断地扩展，最终软件系统原有的架构对新的功能需求渐渐地失去了支持的能力。
到了这一阶段，系统将不得不需要面临重构以适应进一步的发展的状况。
重构就是开发人员对一个现有软件系统的结构进行修改或者重新设计，从而使该系统变得更加容易去增加（或者修改）功能[1]。
有资料表明，二十世纪九十年代以后，先进国家的既存软件的维护性开发量已占软件开发总量的80%以上[2]。
但对于保险系统这种规模庞大；
系统对正确性和安全性要求高；
逻辑结构又非常复杂的金融系统进行重构时，如何来确保重构以后的正确性和可靠性就成为了一大考验，这就需要软件测试的介入了。
软件测试是软件工程的一个范畴[3]，是保证软件质量和可靠性的重要手段[4]，在整个软件的生命周期中占有非常重要的地位，占整个开发成本的60％以上[5]。
特别针对航空航天，军事国防等这类性命攸关的系统，其测试费用甚至于高达所有其它工程开发阶段费用总和的3至5倍[6]。
软件测试是一个复杂的过程，需要耗费巨大的人力、物力和时间。
统计表明,在典型的软件开发项目中,软件测试工作量往往要占到软件开发总工作量的40%以上[7,8]。
测试人员需要设计、执行、分析大量的测试用例，因而测试效率很低，使得软件测试阶段的费用一直以来居高不下。
因此，在保险系统的重构中，提高软件测试工具的自动化程度是确保软件开发质量，同时又能降低软件开发成本的重要手段之一[9]。
1.2软件测试的意义和目的
1.2.1软件测试的意义
测试的意义就是软件测试在软件开发周期中的作用。
测试的意义主要在于以下四个方面：
1.发现软件中存在的缺陷；
2.有效地定义和实现软件成分由低层到高层的组装过程；
3.验证软件是否满足软件需求和系统定义文档所规定的要求；
4.为建立软件质量的模型提供依据。
1.2.2软件测试的目的
测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Dotherightthings），另一方面是确认软件以正确的方式来做了这个事件（Dothethingsright）。
第二是提供数据和信息，比如提供给项目经理关于对整个软件系统的反馈信息，作为风险评估所需要的信息。
第三是不仅要测试软件产品的本身，而且还要包括软件开发的过程。
如果一个软件产品开发完成之后发现了很多问题，这说明这个软件开发过程也很有可能是有问题的。
因此测试的第三个目的就是要保证整个软件的开发过程是高质量的。
软件质量是由几个方面来组成的：
一、在正确的时间用正确的的方法把这个工作做正确（Doingtherightthingsrightattherighttime.）。
二、应该要符合一些应用标准的要求，比如不同国家的用户有不同的操作习惯和要求（用户体验），易用性，项目工程中的可维护性、可测试性，可扩展性等要求。
三、质量就是开发完成的软件要达到项目最开始所设定的需求，而代码的优美或精巧的技巧并不代表软件的质量高（Qualityisdefinedasconformancetorequirements,notas“goodness”or“elegance”.）。
四、质量同时要体现在它符合客户需要的方面（Qualityalsomeans“meetcustomerneeds”.）。
作为软件测试这个行业，最重要的就是从客户的需求出发，从客户的角度去看产品，和客户一样地去使用这个产品，发现在使用过程中会遇到的问题，记录下来。
只有这些问题都解决了，软件产品的质量才能说得到了保证。
测试人员在软件开发过程中的任务：
1.尽量多地找出Bug；
2.避免软件开发过程中产生的缺陷；
3.通过具体的数据来客观地评判软件的品质；
4.密切关注用户的需求，这是永远的参照。
反正最后最终目标就是：
确保软件的质量。
1.3软件测试的分类
软件测试从测试的执行方式上可以分为两种：
手工测试和自动化测试。
传统的手工测试是一个劳动密集型的工作，其优点是可以充分利用测试人员的个人能力。
例如测试员可以根据被测试的代码设计一些有针对性的测试用例，也可以针对边界数据适当增加一些测试用例，有经验的测试人员还能发现很多自动化测试软件所不能预测到的问题。
但是手工测试的缺点十分明显，首先手工测试需要耗费大量的人力资源，且非常容易出错；
此外手工测试的效果在很大程度上要依赖于测试人员的经验；
最后手工测试根本没有办法支持海量的测试案例。
软件自动化测试的优点是可以高效地完成重复性的测试；
同时还能降低因人为因素对测试过程造成的干扰；
充分的测试还能有效地降低随机性和盲目性的风险；
最后还能降低多个测试人员合作时造成的重复率，减少遗漏等。
软件自动化测试就是通过执行某种程序设计语言编制的自动测试工具，控制被测软件的运行，模拟手动测试的步骤，完成全自动或者半自动测试[3]。
其目的在于提高对系统的测试效率，缩短测试周期，提高测试覆盖率等，从而保证软件得到了充分测试，从而使软件质量得到保障。
与传统的手工测试方法相比，自动化测试有以下的优点[6]：
1.大大降低了回归测试的成本。
2.提高了测试效率，并得到更好的测试效果。
3.能完成一些手工测试不可能或者难以完成的测试工作。
4.测试过程中，保持高度的一致性，可重复性也很高。
5.最大化地提高人力资源的利用率。
因此，如今软件测试自动化工具和技术得到越来越广泛的运用。
1.4自动化测试的历史和现状
从上世纪90年代起，针对软件自动化测试的研究就已经开始，相应的工具不断涌现。
总体来说，按照产生的阶段及使用的技术特点，自动化测试可以分为以下几代[5]：
第一代的自动化测试技术始于上世纪的90年代初，通过硬件的方式录制键盘的输入并播放，但是并不具有检查点（checkpoint）的功能，而且测试脚本也非常难以维护。
第二代的自动化测试技术兴起于上世纪的90年代末，这时已经由硬件录制/播放转变成使用软件工具录制/播放（capture/playback）的方式来生成测试脚本（script），并且增加了检查点的功能，用来对软件做验证。
测试的范围较上一代增大了不少，其存在最大的问题就是灵活度不够高。
第三代的自动化测试技术诞生于2001年，我们称之为测试框架（testframework），测试框架的主要思想是是把测试脚本给抽象化，从而提高自动化测试的适用度，复用性和灵活性。
其中具有代表性的工具有：
Rationalrobot和HPloadrunner等。
近年来随着越来越多的软件开源，自动化测试技术进入第四代。
其最大的特点是使用者可以根据自己的实际项目情况进行个性化定制、选取、扩展所需的自动化测试模块，并可以利用一些开源框架，结合起来形成一个完整的自动化测试平台。
1.5论文的课题背景和研究内容
本文针对一个大型保险系统的重构项目中遇到的诸如：
此保险系统业务逻辑复杂，业务范围广泛；
系统测试需要用大量的数据来提高覆盖率；
系统重构项目代码开发量很大，造成工作周期紧张；
还有需求文档缺失严重，开发人员又缺乏关于保险的金融知识背景等种种困难，提出了用自动化测试来尽可能充分地覆盖到整个系统的测试，在尽可能少的人力资源投入下，从而尽可能高效地发现系统的Bug。
另外回归测试实现了自动化执行，进一步提高了开发人员在BugFix阶段的工作效率。
这个自动化测试的实现方案为一些业务逻辑复杂，需要测试工作量巨大、测试难度高、需求又不完整的系统重构项目提供了一种低投入、高产出的自动化测试解决方案。
第二章将会对待测系统的相关背景，系统架构以及重构项目中测试环节所面临的主要的问题进行了简要的介绍。
第三章将会对重构项目所需的测试以及面临的主要难点进行分析，然后提出一个有效的解决方案。
第四章将会就该项目提出的设想的对比和回归测试分析它们的特点和流程，提出自动化的实现方法。
第五章将会就该自动化测试具体实施环节中采用的CodedUITest工具进行扩展和完善，同时介绍整个测试流程和在项目中的应用。
第六章将会就该自动化测试方案在项目的实际运用中产生的效果做客观的分析和估算。
第七章是本文的总结部分，总结了在项目中的具体工作，并指出该自动化测试方案存在的缺陷，有待继续研究的方向等。
1.6本章小结
本章简单介绍了测试的重要性和自动化测试的发展历史和现状，并结合了作者在一个大型保险系统重构项目中利用编码UI测试工具完成自动化测试并对该工具扩展的具体实践，引出了用自动化测试来解决在系统重构项目中测试的问题。
第2章重构项目的系统概述
2.1软件再工程的概述
软件再工程是为了以新形式来重构已存在的软件系统而进行的检测、分析、更替，以及随后对新形式的实现。
这个过程包括了逆向工程、文档重构、结构重建、相关转换以及正向工程等。
它的目的是分析和理解已存在的软件系统，然后对它重新设计实现来增强它的功能，提高它的性能，或者降低它的实现难度，客观上要达到维持软件的现有功能正确并为今后新功能的加入做好准备的要求。
软件维护期的适应性维护、完善性维护和预防性维护都属于再工程范畴。
与从无到有的普通软件开发不同，再工程所要面对的不是原始的需求，而是已经存在的软件系统，是从已经存在的软件起步开发出新软件的过程[10]。
一般计算机软件系统的生存周期如图2.1所示。
图2.1一般计算机软件系统的生存周期
重构（Reconstruction）：
在不改变原有系统功能的前提下，重新安排程序的逻辑和业务流程，使程序的复杂性降低或者可读性相应地提高。
然而它无法从根本上改变软件的功能，只是对流程进行了一定程度地优化，不涉及到系统的数据部分，重构以后的系统的可读性更好。
重构是采用各种各样的技术手段重新处理一个对象设计的过程[10-11]。
逆向工程（ReverseEngineering）：
对已有的软件系统进行分析，然后从源代码出发，逐层抽丝剥茧，明确系统的组成部分及其相互间的联系，最后得到与具体实现没有关系的抽象结果。
逆向工程不仅仅是为了维护，也要研究老系统的算法和设计理念。
目前主要的方法是反编译、反汇编以及对源程序的分析理解等。
正向工程[12]（ForwardEngineering）：
从前期工作生成的抽象描述开始，一步一步地细化至具体实现，最后生成可替代旧软件系统的新系统及相关的详细说明文档。
再工程（Reengineering）：
是对已有的软件系统进行分析，并将其重构为新形式代码的开发过程。
即：
再工程=逆向工程+重构+正向工程。
2.2保险系统简介
该保险系统是为了给保险公司使用而开发的。
其目的是使金融业务的操作变得简洁和高效，同时保证在所有服务区域内的数据同步。
该保险系统分为两大部分，前台和后台。
前台由网页或者客户端程序实现，任务是接收请求并将业务流程和数据以图形和文字的方式呈现给操作者。
操作者可以是服务窗口的操作员、使用特定终端的用户等。
在大型的系统中，前台用户的数量可能会以百万计，且终端类型多样，使用的服务类型多样。
后台一般包括服务端和数据库。
服务端负责接收前台请求，并按一定的业务逻辑进行处理，此外还会定期完成预先安排的任务。
服务端是系统中最复杂的部分，需要处理大量的业务逻辑，而且要与前台和数据库进行交互，同时要保证有足够的稳定性和运行效率。
一个系统的服务端采用分布式负载均衡的进行部署，以此来保证性能。
数据库是用来存储各种数据，其性能取决于硬件配置、并发业务的数量以及服务端对数据库访问的频率和方式。
若要提升数据库性能，提升硬件的代价比较昂贵，所以优化服务端的数据结构和算法，以及客户端和服务器端数据的通讯是一个很好的方法。
过去众多软件系统的架构模型都选择传统的两层体系结构,然而随着系统复杂性的不断提高,两层体系结构在实际应用中已暴露出一些问题。
如：
客户端直接（或通过存储过程）访问数据库,不利于安全控制,难以防止黑客的恶意攻击。
并且,在现在的一些系统中,由于客户端数量日益增多,访问量和数据传输量较大,易形成网络瓶颈,影响数据库的响应速度,降低系统性能。
此外,两层应用体系结构还有维护、扩展方面的问题。
为解决相应的瓶颈问题以及出于安全因素等方面的考虑,往往要采用中间件来组成三层（多层）结构应用体系。
故本项目对原来的VB系统进行了重构，在中间添加了ECI层。
2.3系统重构前后的架构变化
本系统的技术架构可以如图2.2说明：
图2.2保险系统技术架构图
本系统主要分为3部分，分别是客户端（Client）和服务器端（Server），以及在客户端和服务器端之间通信的中间部分（ECI）。
这中间部分（ECI）就是系统架构在重构前后最主要的改变之处。
1.客服端向服务器端发送请求时通过ECI端，并把自己的请求分为2部分，分别是消息头和消息主体。
在消息头中指定在服务器端要调用的接口，ECI根据消息头中的内容在服务器端创建相应的组件。
而除此之外，ECI可以根据多台服务器累计的响应时间来进行负载均衡（LoadBalance）。
2.ECI在收到客户端的请求后会作出一些响应（Response）并以不同的类型返回（比如以XML的形式返回结果，出错的时会FaultMessage的形式返回。
3.服务器端在接到ECI端发来的消息时一般会以Access的形式来存取数据（Access主要用来构建SQL语句），而当构建新的数据时，则通过xxxSource的形式进行插入、删除、更新操作。
DateAccess工程对数据进行封装或者以多线程的访问等方式和数据库进行交互。
而对于一些复杂的逻辑则采用xxxComp专门的组件进行相应的操作。
而LDAP根据专门的LDAPSource组件进行用户操作管理。
服务器端最终将操作的结果通过ECI端返回客户端完成一次完整的操作。
2.4重构项目中测试工作面临的挑战
从上述不难看出，该保险系统重构项目有以下四大特点：
1.该系统是一个业务逻辑复杂，交易流程分支众多的专业保险系统，商业需求复杂，需要深厚的金融知识和背景；
2.重构前后的系统在框架结构上有较大的改变，同时所
升级会员 