自动化测试.docx
《自动化测试.docx》由会员分享，可在线阅读，更多相关《自动化测试.docx（39页珍藏版）》请在冰豆网上搜索。
自动化测试
摘要
当今的企业需要掌控其关键业务应用的所有功能测试，以确保所有业务流程工作符合预期。
通过实施自动化的功能测试，企业可以极大提高测试速度和精度，从挼间项目中得到更高的投资回报并且显著地降低风险。
本文简要描述了自动化功能测试的优势和挑战，帮助企业考虑实施最佳测试自动化的方法。
1.介绍
毫无疑问，严格的功能测试是成功开发应用的关键。
开发人员，测试小组和管理人员所面临的挑战是，如何加速测试流程和提高测试的精确性和完备性，同时还不能增加已然很紧张的预算。
通过将功能测试的关键环节自动化，可以满足有挑战性的发布时间安排，测试得更加全面和可靠，检验业务过程功能的正确性，从而从上线的运营中，获得极高的产值和客户满意度。
然而，功能测试的自动化会产生一些新的顾虑：
测试过程自动化的成本是多少？
其投资回报率（ROI）是什么？
哪些应用/过程适合做自动化测试，哪些不合适？
是否需要新的培训，这将对当前的开发计划安排产生怎样的影响？
自动化测试得正确地方法论是什么？
自动化测试时涉及到哪些情况？
当比较自动化测试产品时，哪些功能最重要？
在自动化测试项目开始之前，以上和其他一些问题应该得到全面地调查和了解。
2.功能测试与单元测试
功能测试是指确保应用按期望运行，也就是按照用户的期望运行。
功能测试以一种有效的方式捕获用户的需求，让用户和开发人员对业务过程满足需求充满信心，同时使得QA团队可以检验软件已发布就绪。
功能测试是单元测试的补充，但有很大不同。
简言之，单元测试说明了代码执行是否正确；功能测试说明了完成的应用是否做正确的事情。
单元测试往往是从代码开发人员的角度来看，而功能测试是从最终用户和业务过程角度来看。
3.为什么将功能测试过程的自动化？
现在，IT部门的压力越来越大。
管理部门希望IT部门通过软件可以交付新功能，抓住新的商业机会和提供有竞争力的优势。
这就意味着需要完成更多的业务应用开发项目，而时间会很紧迫，并不是都有更多的预算或资源。
同时，管理部门越来越意识到软件和销售额的重要关系。
WebServices，联机事务处理和ERP应用不仅是非常关键的，而且，它们直接关系到公司的产值能力。
现在企业非常依赖非常复杂的计算机基础设施。
如图，一个典型的企业可能依靠多个应用，运行在不同的系统上，使用几种不同的前端客户端，涉及到大量的业务过程并且与很多种数据集交互。
可能的组合是高度复杂，需要成百上千的测试场景。
组件
数量
事例
平台
1
Intel
操作系统
5
WindowsXP,ME,2000,NT4,and98
前端客户端
4
InternetExplorer6,Netscape7.1Java,VisualC++
业务过程
5
Login,Search,OrderEntry,OrderConfirmation,OrderFulfillment
数据集
15
usernames,passwords,searchstrings,ordernumbers,shipdates,等的组合
需求的测试数量
1x5x4x15
=1,500可能的测试场景!
!
当软件出现故障时，其代价是非常大的，包括销售额下降，员工的低效率，客户的不满和开发和QA人员的士气低落。
在软件开发周期中，缺欠发现的越晚其代价越高。
上线后发现的缺欠的改正成本可能比在设计阶段发现的高出100倍。
自动化是提高软件测试过程的速度，精确度和灵活性的关键，使公司可以更早发现和改正缺欠。
4.手工功能测试的挑战
手工功能测试过程本身存在很多挑战：
时间过长。
有限的IT资源和紧张的交付时间使得手工测试对于满足业务目标来说过于耗时。
采用手工测试，测试和开发人员不得不计划冗长的每步测试过程，然后手工执行，再现问题，快速消耗了有价值的时间和资源。
根据AberdeenGroup，一个独立行业分析公司，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部门可以获得更高的投资回报，而且降低了大量风险。
自动化测试的7个步骤
文章出处：
作者：
BretPettichord译者：
王威发布时间：
2005-10-19
【摘要】我们对自动化测试充满了希望，然而，自动化测试却经常带给我们沮丧和失望。
虽然，自动化测试可以把我们从困难的环境中解放出来，在实施自动化测试解决问题的同时，又带来同样多的问题。
在开展自动化测试的工作中，关键问题是遵循软件开发的基本规则。
本文介绍自动化测试的7个步骤：
改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计（designforsustainability），有计划的部署和面对成功的挑战。
按照以上7个步骤，安排你的人员、工具和制定你的自动化测试项目计划，你将会通往一条成功之路。
一个故事:
我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。
本文将提供若干方法规避可能在自动化测试中出现的问题。
我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。
以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。
软件项目的经理是AnitaDelegate。
她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。
她委派一位员工——JerryOverworked负责自动化测试工作。
Jerry除了负责自动化测试工作，还有其他的很多任务。
他尝试使用刚刚购买的自动化测试工具。
当把测试工具应用到软件产品测试中的时候，遇到了问题。
这个测试工具太复杂，难于配置。
他不得不给测试工具的客户支持热线打了几个电话。
最后，Jerry认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。
在打过几个电话后，测试工具厂商派过来一位技术专家。
技术专家到达后，找出问题所在，测试工具可以正常工作了。
这还算是顺利了。
但是，几个月后，他们还是没有真正实现测试自动化，Jerry拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。
项目经理Anita把项目重新指派给KevinShorttimer，一位刚刚被雇佣来做软件测试的人员。
Kevin刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。
Anita送Kevin参加工具培训，避免Kevin步Jerry的后尘——由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。
Kevin非常兴奋。
这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。
一个主要的版本发布后，Kevin准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。
他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过，Kevin使整个测试工作开展的很顺利。
他用已有的测试套测试新的产品版本，并且确实发现了bug。
接下来，Kevin得到一个从事软件开发职位的机会，离开了自动化的岗位。
AhmedHardluck接手Kevin的工作，从事自动化测试执行工作。
他发现Kevin留下的文档不仅少，并且没有太多的价值。
Ahmed花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。
这个过程中，Ahmed经历了很多失败，并且不能确信测试执行的方法是否正确。
测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。
一些测试执行看起来仿佛永远没有结束。
另外一些测试执行需要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。
后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有BUG，导致测试执行失败，发现产品的BUG后，每个人都很高兴。
接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。
按照计划，产品的下一个发布版本有几个主要的改动，Ahmed立刻意识到产品的改动会破坏已有的自动化测试设计。
接下来，在测试产品的新版本中，绝大多数测试用例执行失败了，Ahmed对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。
经过商讨，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。
最后，大家根据新接口修改自动化测试，测试都通过了。
产品发布到了市场上。
接下来，用户立刻打来投诉电话，投诉软件无法工作。
大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。
虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。
这个产品终于失败了。
这是我的故事。
或许您曾经亲身经历了故事当中某些情节。
不过，我希望你没有这样的相似结局。
本文将给出一些建议，避免出现这样的结局。
问题
这个故事阐明了几个使自动化测试项目陷入困境的原因：
自动化测试时间不充足：
根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。
这使得自动化测试无法得到充分的时间，无法得到真正的关注。
缺乏清晰的目标：
有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。
但是，自动化测试不可能同时满足上述的目标。
不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。
缺乏经验：
尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。
由于缺乏经验，很难保证自动化测试的顺利开展。
更新换代频繁（Highturnover）：
测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。
对于绝望的反应：
在测试还远没有开始的时候，问题就已经潜伏在软件中了。
软件测试不过是发现了这些潜伏的问题而已。
就测试本身而言，测试是一件很困难的工作。
当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。
测试什么时候后结束？
当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。
如果不需要测试，那该有多好呀！
在这种环境中，自动化测试可能是个可以选择的解决方法。
但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。
不愿思考软件测试：
很多人发现实现产品的自动化测试比测试本身更有趣。
在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。
由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。
关注于技术：
如何实现软件的自动化测试是一个很吸引人的技术问题。
不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。
遵守软件开发的规则
你可能了解SEI（软件工程研究所）提出的CMM（能力成熟度模型）。
CMM分为5个界别，该模型用来对软件开发组织划分等级。
JerryWeinberg（美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别。
很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别[Weinberg1992]。
恰恰在这类组织环境中，经常采用自动化测试方法。
因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。
这是解决测试自动化的核心的方案。
我们应该像运作其他的开发项目一样来运作软件自动化测试项目。
像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。
像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。
像其他软件开发项目一样，测试自动化也会出现BUG，因此，需要有计划的跟踪BUG，并且对修改后的BUG进行测试。
像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。
本文中不对软件开发做过多讲述。
我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。
我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。
本文按照在软件开发项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。
• 改进软件测试过程
• 定义需求
• 验证概念
• 支持产品的可测试性
• 可延续性的设计（designforsustainability）
• 有计划的部署
• 面对成功的挑战
步骤一：
改进软件测试过程
如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。
然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。
同样的，上述过程也是用于自动化测试。
我更愿意把“测试自动化”这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。
运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。
例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。
回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。
回归测试需要反复执行，并且单调乏味。
怎样才能做好回归测试文档化的工作呢？
通常的做法是采用列有产品特性的列表，然后对照列表检查。
这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。
不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。
在你开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。
如果测试掌握了基本的产品知识，这会更好。
确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。
太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。
这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。
在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。
测试设计是测试自动化最主要的测试需求说明。
不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。
但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。
我以前负责过一个软件模块的自动化测试工作。
这个模块的一些特性导致实现自动化非常困难。
当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。
我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。
我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。
在完成上述工作后，我没有机会完成测试自动化的实现工作。
不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。
依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了BUG。
从某种角度看，这实际上是一次很成功的自动化测试。
在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。
后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。
不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。
另
升级会员 