实施自动化功能测试的解决方案

摘要

     当今的企业需要掌控其关键业务应用的所有功能测试，以确保所有业务流程工作符合预期。通过实施自动化的功能测试，企业可以极大提高测试速度和精度，从挼间项目中得到更高的投资回报并且显著地降低风险。

     本文简要描述了自动化功能测试的优势和挑战，帮助企业考虑实施最佳测试自动化的方法。

1.介绍

     毫无疑问，严格的功能测试是成功开发应用的关键。开发人员，测试小组和管理人员所面临的挑战是，如何加速测试流程和提高测试的精确性和完备性，同时还不能增加已然很紧张的预算。

     通过将功能测试的关键环节自动化，可以满足有挑战性的发布时间安排，测试得更加全面和可靠，检验业务过程功能的正确性，从而从上线的运营中，获得极高的产值和客户满意度。然而，功能测试的自动化会产生一些新的顾虑：

• 测试过程自动化的成本是多少？其投资回报率（ROI）是什么？
• 哪些应用/过程适合做自动化测试，哪些不合适？
• 是否需要新的培训，这将对当前的开发计划安排产生怎样的影响？
• 自动化测试得正确地方法论是什么？
• 自动化测试时涉及到哪些情况？
• 当比较自动化测试产品时，哪些功能最重要？

     在自动化测试项目开始之前，以上和其他一些问题应该得到全面地调查和了解。

2.功能测试与单元测试

     功能测试是指确保应用按期望运行，也就是按照用户的期望运行。功能测试以一种有效的方式捕获用户的需求，让用户和开发人员对业务过程满足需求充满信心，同时使得QA团队可以检验软件已发布就绪。

     功能测试是单元测试的补充，但有很大不同。简言之，单元测试说明了代码执行是否正确；功能测试说明了完成的应用是否做正确的事情。单元测试往往是从代码开发人员的角度来看，而功能测试是从最终用户和业务过程角度来看。

3.为什么将功能测试过程的自动化？

     现在，IT部门的压力越来越大。管理部门希望IT部门通过软件可以交付新功能，抓住新的商业机会和提供有竞争力的优势。这就意味着需要完成更多的业务应用开发项目，而时间会很紧迫，并不是都有更多的预算或资源。

     同时，管理部门越来越意识到软件和销售额的重要关系。Web Services，联机事务处理和ERP应用不仅是非常关键的，而且，它们直接关系到公司的产值能力。现在企业非常依赖非常复杂的计算机基础设施。如图，一个典型的企业可能依靠多个应用，运行在不同的系统上，使用几种不同的前端客户端，涉及到大量的业务过程并且与很多种数据集交互。

      可能的组合是高度复杂，需要成百上千的测试场景。

组件	数量	事例
平台	1	Intel
操作系统	5	Windows XP, ME, 2000, NT4, and 98
前端客户端	4	Internet Explorer 6, Netscape 7.1 Java, Visual C++
业务过程	5	Login, Search, Order Entry, Order Confirmation, Order Fulfillment
数据集	15	usernames, passwords, search strings, order numbers, ship dates,等的组合
需求的测试数量	1x 5 x 4 x 15	= 1,500 可能的测试场景!!

     当软件出现故障时，其代价是非常大的，包括销售额下降，员工的低效率，客户的不满和开发和QA人员的士气低落。在软件开发周期中，缺欠发现的越晚其代价越高。上线后发现的缺欠的改正成本可能比在设计阶段发现的高出100倍。自动化是提高软件测试过程的速度，精确度和灵活性的关键，使公司可以更早发现和改正缺欠。

4.手工功能测试的挑战

     手工功能测试过程本身存在很多挑战：

• 时间过长。有限的IT资源和紧张的交付时间使得手工测试对于满足业务目标来说过于耗时。采用手工测试，测试和开发人员不得不计划冗长的每步测试过程，然后手工执行，再现问题，快速消耗了有价值的时间和资源。根据Aberdeen Group，一个独立行业分析公司，90%的IT项目交付出现延迟，手工测试是其中一个因素。
• 覆盖不完全。平台，操作系统，客户端设备，业务过程和数据集等的组合对于手工测试过程来说，工作量非常大。需要验证功能的测试用例数量非常巨大。所以当修改完成后手工回归测试花费的时间过长，以至于不能做全面的回归测试。
• 风险更高。手工测试过程比计算机过程的错误和疏忽更多。人们会变得疲倦，输入数据错误，不能总是正确执行测试，并不是总有时间测试所有应该测试的内容。

5.自动化测试的好处

     自动化测试有很多好处，包括：

• 快速执行。计算机在执行功能测试脚本的时候比人快得多，因此在有限的时间里能测试的更多，在给定的时间里更多的应用可以被测试，可以按时完成更多的工程。并且和人不同，计算机一天工作24小时，还包括晚上，周末和假期；他们不会感到无聊或者疲倦；而且他们从不对该作的事情和不该作的事情自作主张。
• 提高测试覆盖。自动测试产品支持在所有流行的浏览器，操作系统等上执行测试脚本，用自动化的工具对不断变化的应用和环境做回归测试，要比手工测试容易得多。通过整合的数据驱动表单的功能，自动化测试产品允许开发和测试团队执行计算，操作数据集，以及快速创建多种反复的测试，使得扩大测试覆盖范围。使用自动测试工具可以仿效任何混合的事务和任意的用户负载。
• 提高测试精确度并提早发现更多错误。自动化测试给开发人员提供了一种再现和记录软件缺陷的非常容易的方法。这将在所有环境，数据集和业务过程等之间确保功能的正确性，同时对开发过程起到加速作用。
• 提供规范化的过程。自动化测试鼓励测试团队规范化他们的过程，以得到更高的一致性和更好的文档记录。
• 提高测试的重用性。测试一旦脚本化，开发人员可以使用和重用这些脚本，可以将脚本添加到测试套件中，以适应应用的变化。没有必要为每个应用的相同功能而重新创建脚本。
• 支持ERP/CRM。现在越来越多的用户使用ERP/CRM解决方案，对端到端的回归测试的需求正变得越来越频繁和越来越重要。

6.在什么情况下采用自动化测试？

     一般来说，把自动化测试的工作集中在关键的业务过程，复杂应用，以及由这些组成的用例方面（相对于低级别任务，例如系统级的验证）是很有意义的。

     如果一个企业拥有众多每天工作很多小时的软件测试人员，但是产品仍然出现质量和功能问题，那么这家企业肯定能从自动化测试中受益。是否决定实行自动化测试应当充分考虑到投资回报，但是一般情况下，如果一个应用需要多次构造/补丁/修改；需要在大量的硬件或软件配置下进行测试；并且支持众多并发用户等，那么将会是值得采用自动化测试。另外，如果涉及到重复性的工作，例如数据装载和系统配置等，或者应用需要满足特定的服务等级协议（SLA）,那么自动化测试当然也会节约成本。

7.如何确定自动化测试的投资回报？

     任何投资回报都可以从一个简单的计算得出：

     投资回报=投资的净现值/总初始成本

     当采用测试过程的自动化时，成本是切实可见的，但是净现值仍旧包含许多无形的因素。最好的方法就是尽量精确计算直接成本，然后与自动化测试产生的直接和间接的效益进行对比。

     在ROI计算中需要考虑的直接成本包括:

     

• 购买成本：购买自动化测试软件产品的成本。
• 硬件成本：功能测试所必需的硬件成本。有代表性的是，功能测试不需要特殊的硬件，只需带有以太网端口的标准台式电脑或者工作站即可。
• 劳动力成本：培训职员编写测试用例脚本或进行手工测试的成本因素。确认要包括招聘，雇佣，支付工资，和保留熟练的QA工程师的成本。
• 培训成本：依赖于所选择的测试产品，培训使用者精通编写自动测试脚本是值得的。当然，公司可以选择雇用专业的服务公司创建最初的自动化测试。

     当衡量自动化的潜在益处时，考虑隐性效益是很重要的，例如测试人员高涨的士气和对工作的满意度，改进的客户满意度和忠实度，还有因为最终用户使用的可信赖的软件而不断提高的知名度。

8.如何评估自动化测试软件？

     很多商家提供自动化测试产品。每个解决方案都有自身的优势和劣势，独特的功能，和市场环境。每个企业需求的特殊性决定了最适合的一种选择。然而，任何自动化测试产品都应当包含一些关键的性能：

• 自动化测试的“Scriptless”表示法：产品应该提供一个可点击的界面，在测试时与应用组件进行访问和交互——而不是呈现出一行行的脚本。测试者应该可以可视化每一步的业务过程，并且直观的观察和编辑测试用例。这将减少测试者在学习上走弯路，并帮助测试团队面对紧迫的最终期限。
• 集成的数据表：自动化功能测试的一个关键的好处就是可以使系统快速产生大量数据。还有一个重要的功能就是操作数据集，执行计算，并以最小的代价快速创建数以百计的重复测试和组合。企业应该寻找拥有提供强大计算能力的集成电子数据表单的产品。
• 清晰明确的报告：如果测试结果不容易理解或解释，那么即使运行大量测试数据也不会有什么好处。测试产品应当自动的产生并显示所有测试运行方面的报告，并用易读的格式解释结果。报告应当提供的细节包括：应用在什么地方发生了失败和使用了什么样的测试数据；为应用的每一步提供高亮或有差别的屏幕显示；并提供每个检查点通过和失败的详细解释。当然还应当能够在不用修改的情况下，在测试和开发团队之间共享报告。

9.要点列表：自动化测试成功的五个关键

     即使已经证明了测试的自动化是经济有效的，然而如何确定转变到自动化测试过程上的最佳方法依然是困难的。这部分略述了执行自动化测试过程的五个基本原则。

• 1.完成一个测试计划文档。理解被测应用的目标是任何测试成功的基础。这包括全面的预先计划以确保测试需求被正确的实施。测试工具应提供为所有被测应用管理测试用例和需求的能力。
• 2.将测试细分为自动测试用例。一个组织自动执行一个测试计划的所有方面是不可能的。自动化测试应该集中围绕在需求设计的复杂应用上和急迫的业务过程功能上，许多组织发现他们使用自动化测试只占总测试用例的60%，而余下的40%为手工测试。
• 3.创建自动化测试。测试工具极大简化了准备测试数据和脚本的过程。这使得更多的完全测试可最佳地使用测试资源和结果。使用测试工具，使用者可以不必作任何实际脚本而创建测试。测试工具应能自动捕获目标应用的业务过程，并允许使用者创建一个可以被保存的而且可以被管理的测试流程。
• 4.提高测试覆盖的数据驱动测试。测试者就可以为应用创建一个使用储藏在Excel电子表格里的特殊关键字的依赖于数据的测试。这就允许测试者通过应用驱动大量的测试数据。
• 5.给测试增加验证。需要在测试中添加了“通过或失败”的测试标准。这包括了应用的前端，中间层，或后端数据库的验证。内置的数据库验证使数据库值的存储得到确认，并确保处理的精确性和已更新、删除或增加的数据记录的完整性。

10.总结

     功能测试可以不是耗时或高成本的问题。采用自动化功能测试，企业可以将重点放在改进自动业务过程方面。开发和QA组可以增加测试过程的速度和精确度。整个IT部门可以获得更高的投资回报，而且降低了大量风险。

成熟的软件测试是确保软件质量的一种重要手段，自动化测试技术的出现，对于提高测试单位绩效比起了重要作用，被广泛应用于回归测试中，但是由于被测试系统的不确定性和复杂性，使得软件自动化测试变得异常困难。本文基于商业工具结合实际项目，分析自动化测试实施期间出现的各种问题，以提高大家对自动化测试项目的真正认识与理解。

现在自动化测试工具很多，商业的或者开源的，以对象识别为基础的或者以语言特性为基础的等等。在挑选的时候，首先我们要明确被操作软件的范畴和特性，可预知风险，培训潜在成本及是否具备被虚拟化等一系列问题，这些问题可制成标准检查列表，以便确定一个解决一个。在本次自动化测试实施中，首先可知的是被测试软件属于行业金融软件，使用Borland C++Builder语言开发，测试范畴锁定在软件前台需配对后台数据验证，前台由RedHat Linux服务端、自研发中间件和Oracle数据库支撑。一般来说，这种软件应用架构比较清晰，但是GUI层使用了大量的非标准第三方控件，有可能会导致部分对象无法捕获造成实施困难，所以在进入真正的实施前作充分、快速的实验性评估是非常重要的。

职业化的自动化测试团队，应当非常熟悉当前主流的商业或者开源测试工具，这种团队的定义是：技术让位与成本控制，快速实施且能快速递交，精确控制每12周为一周期，项目延时误差小于2天。考虑到脚本会被移交给其他团队执行，所以我们选择了目前在国内应用范围比较广、相关技术资料比较丰富的HP Winrunner和HP QuickTestPro。第一个被评估的是QuickTestPro 9.5版本不带任何插件，结果大量的GUI对象无法被捕捉，不能捕捉意味着不能被操作，所以团队快速转换到Winrunner 9.2版本不带任何插件，实验结果是基本可以正确识别和捕获我们所要操作的GUI对象，满足了对工具的需求。其实QuickTestPro 9.5版本带Delphi插件也可大大增加捕获率，但是使用插件违反了团队定义的工具应用管理规范，也不符合“有对象即可操作”的强硬编程作风。

在工具定义后，需要立刻选择2组典型业务进行试验性测试，这时需要业务专家和脚本专家一起工作。带GUI界面软件测试用例的设计核心问题是：需要精确区分正常测试用例和异常测试用例，按照先异常后正常的实际执行方式，组织最终的测试数据存放关系，一般合适的比例控制在异常75%—正常25%范围内。脚本专家需要快速处理对象识别库，如果涉及到重定义则需要在指定文件中加以注明，因为这部分工作可被复用到后续的项目实施中，避免造成人力成本重复投入。通常实验性阶段主要产生的问题是：

● 该阶段是否会产生脚本框架?答案是否定的，首先自动化测试不一定要有框架，框架产生的唯一目的就是牺牲一部分脚本性能，而对测试数据进行高效、有序的管理。不过在试验性阶段可以考虑这个问题，如果框架是个平台，那么我们可以在这个平台上放置一些我们需要的单位脚本性能监视器或者其他一些东西。由于 Winrunner的描述性编程机能不够，那么在后续正常项目实施中，框架更多被定位于为可测量、可伸缩、可动态、可智能解析测试数据的执行管理。

● 该阶段是否需要考虑测试数据存放问题?答案是否定的，没有必要浪费太多的时间在这种地方，一个文本文件或者干脆不要文件的数据存放形式都可以，关键是成本。

该阶段对于人员的要求是什么?答案是人员需要精干，一个业务专家，一个脚本专家，一个统计专家足够，自动化测试实施非常注重绩效比，绩效比不够根本没必要执行后续的项目，你必须通过实验性测试得出一个准确的结论，就是重复执行多少次脚本，总绩效才可以由负转正。

● 该阶段是否需要考虑环境的问题?答案是的，在这之前就应该安装好虚拟系统了，如果脚本专家的一边开着即时通讯工具一边录制脚本，我们认为这是非常不专业的。系统环境的清洁程度如同医院的手术室，需要提前对各种必须的软件(例如杀毒软件，网管软件等)做好适应性选择，有干扰的，或者影响系统机能的坚决卸载掉。

● 该阶段的硬件是怎么规划的?前端的测试主机需要有同时承受开2—3个虚拟系统的准备，不能产生明显的切换和操作停顿甚至系统假死。虽然 32位的 Windows XP系统不支持4G物理内存，但是经验告诉我们内存容量多多益善，至于CPU和显卡处于正常水平即可。后端使用的硬件需要稳定，因为不是性能测试所以不作太多要求，一切为了成本。

● 该阶段的管理模式和输出是什么?答案是没有太复杂的管理模式，实验性评估一般都会在1周内被关闭，唯一重要的就是实施评估报告，报告内容大致包含：周期定义、工具定型描述、应用软件描述、系统框架描述、可能采用的框架描述、可能递交工件描述、可加入业务列表、预测脚本规模、

可实施技术分析、评估人/时分析、预测实际人/时分析、评估脚本价值、预测实际脚本价值、可能遇到的问题警告等，这些条目都必须一一做出详实而且准确的描述。

实验性评估结束后，需要确定自动化测试实施项目的时间及周期里程碑，我们采用12周为一个周期里程碑，快速发布快速递交的方式以确保整个测试项目的实施成功。在开始的1周内，管理专家需要快速定义对象控制表、项目跟踪表、需求跟踪表、周/发布项目进度、日/问题跟踪表、配置管理须知，脚本专家需要快速定义代码规范、脚本设计维护手册、数据作用说明及填写规范，环境专家需要快速定义虚拟环境配置手册、维护与复制手册，培训专家需要制定实施阶段课程培训体系等，专家都是角色可复用，工作都是实打实的，需要认真对待，缺一不可。

我们通常将项目在快要接近380个可操作对象或者脚本代码接近25000行的时候称之为一个“混乱点”，之所以称为“混乱点”完全是这种项目执行过程中的必然现象，如同飞机速度超过音速时产生的音障一样，正确的对待和处理有助于后续项目实施的健康成长，否则后果不堪设想。

● 经典问题一、文档混乱了。这里的文档混乱并非指文档丢失、残缺或者缺少维护这些低级错误，事实上这里的文档混乱是多个文档内产生了部分内容相同的冗余数据，且这些冗余数据在可控制范围内。“冗余即懒惰”，所以对应的解决方案就是将所有文档转交EPG团队，由专人看管做日终处理，只要不增加本团队的成本我们是非常乐于这么做的。

● 经典问题二、培训热度过高。为了确保脚本周递交转移速度，我们在每周末需要对接应团队做一定培训，很多人(非合作团队)都想增加自己在这方面的知识，所以原来的2小时培训时间被延长到4小时，原来一场25人小团队培训被扩展为二场各180人的培训，很累。直接造成的后果就是很多人要内部转岗来我们团队，这也违背了“简单既是美”。

● 经典问题三、脚本的增加突出了性能的缺失。一旦对象突破380 个(不包含描述性对象)，脚本突破25000行(不包含注释及空行)，不优化，那么在一台机器上的综合运行时间超过了4个小时，所以对代码优化的工作在后续几周的实施中急待解决。对于脚本性能调优，需要综合考虑语言特性、数据结构、外调和对象识别处理，这里需要对TestPackage – TestSuite – TestCase的组合模式进行事务级的时间分析，精确到毫秒。调优的处理有多种，每个团队的方法各不一样，经过综合处理，现在我们能做到35532行脚本、451个对象、37个虚拟对象，合计78个综合处理包全部一台机器上运行，时间可控制在2小时之内。继续压缩时间的资源投入大于产出，这不符合成本控制团队的初衷，所以最终放弃。

● 经典问题四、原来工具的函数有BUG。实际上大规模的代码运用对测试工具本身也是一种考验，一切软件皆有问题，随着时间的推移会逐渐暴露出来。我们发现了测试工具部分函数的会在某些特定环境下出现问题，所以替换这些函数是非常必要的。替换的方法是，使用第三方开发工具(例如VC)开发出可被脚本直接调用的函数(例如各种动态库技术)，以替换原自带问题函数，这样既增加了整体代码的稳定性，又提升了团队的研发能力。例如Winrunner偶尔出现的菜单丢失的问题，都可用自研发函数给予解决。

另外测试工具本身提供的语言也可能存在某些局限性，所以测试团队具备自我开发能力也关系着项目是否能被顺利实施。

● 经典问题五、脚本不动了。实际上这是最让人讨厌的问题，可能涉及的方面非常多，例如系统交互、网络环境、本机环境、软件冲突等等，我们总结了一条处理该类型事件的方法，先排除系统本身，排除干扰软件，再分析比和对卡死位置数据，最后分析脚本本身，例如我们发现部分问题跟字符处理函数有关，这对提高脚本本身的健壮，提出了很高的要求。

项目进行到距离里程碑最后一周，大部分的问题列表需要被提前被关闭，相关递交工件需要被整理评审，脚本经过验证被最终集成转交，这里都需要配置管理来提供良好的控制环境。必须指明的是，日脚本构建和测试是贯穿整个项目周期的，这种做法能使脚本的开发状态得到频繁的更新，以及尽早发现设计和集成的缺陷。为了充分利用时间与设备资源，夜晚21点后，脚本的自动执行测试(这里多数指的是系统测试或回归测试)是一个非常行之有效的方法。一切都顺利的话，等到第二天上班时，测试结果就已经在相关人员的邮箱里面了，通过这份报告，你可以知道那些脚本是必须修改的，如果不太清楚还有一份更详细的截图列表辅助定位，准确告诉你当时软件究竟出现了什么现象导致了问题的产生。

最终该项目第一阶段在12周且延长6个小时后被准确的关闭，并且通过了严格的部门验收，6人参与到这个项目中，合计2916个有效工作时。经过计算每行代码价值为1.77元，总的来说还算是成功的，那么接下来第二个阶段里面，我们能否将每行代码价值控制在1元以下，请各位拭目以待。

转载：http://blog.csdn.net/zbyufei/article/details/3888909