软件自动化测试计划

‘壹’ 软件自动化测试要学哪些工具

qtp：强大的商业自动化工具
selenium：开源的web自动化测试
robotframework：开源的自动化测试框架
如果要选一个，selenium
如果学会了自动化的常用操作，想了解自动化框架：robotframework

‘贰’ 如何制定软件测试计划

制定计划
1. 分析产品
分析什么
用户(他们是谁，他们做什么的)
操作(这个操作是干什么用的)
产品结构(代码，文件，等)
产品功能(这些功能是干什么用的)
产品数据(输入的，输出的，状态，等)
平台(外部的硬件和软件)
怎么分析
走一下产品/原型的主要流程
评审产品和项目文档
咨询设计人员和用户
与类似的产品做比较
可能的工作产出
产品的功能范围概要
注释性的文档
产品的问题列表
执行状态检查
设计人员有没有确认以及批准了产品的功能范围概要?
设计人员有没有认为你已经正确理解了这个产品?
你能不能将这个产品形象化并且预测正确的行为?
你能不能造出产品的测试数据(输入和结果)?
你能不能配置和操作这个产品?
你有没有理解这个产品是怎么样被使用的?
你有没有注意到设计中的漏洞或不一致的地方?
关于这个产品你还有没有未解决的问题?
2. 分析产品的风险
分析什么
产品受到的威胁
产品的易受攻击的地方
失败的方式
失败后的影响
怎么分析
评审需求和规格说明书
评审出现问题的一些事件
咨询设计人员和用户
通过探索性风险分析和质量判据列表来评审产品
识别基本的错误/失败方式
可能的工作产出
组件风险列表矩阵
失败模型概要
执行状态检查
设计人员和用户有没有对风险分析达成一致?
你有没有发现所有的重要的问题，而这些问题是否在测试过程出现呢?
你是否知道在哪些地方要集中测试精力并获得最大的效率呢?
设计人员有没有做一些事情使得重要的问题更容易的发现，或减少其发生的概率呢?
如果你的风险分析是正确的，你是怎么发现的呢?
3. 设计测试策略
基本策略
Domain testing(包括边界值)
用户测试
压力测试
回归测试
Sequence testing
State testing
基于文档的测试
结构化测试(单元测试等)
怎么计划
对于风险和产品功能匹配策略
将特殊的和实际的策略形象化
分析是否可用自动化的机会
使用原型去测试probes和harnesses
不要强加计划，让测试人员自己决定
可能的工作产出
各个类型的报告怎样应用的测试策略文档
风险/任务的matrix
已选择的策略中存在的问题或挑战列表
对产品覆盖比较少的部分提供的建议
测试用例(如果是必须的)
执行状态检查
设计人员对这个测试策略达成一致了吗?
这个策略对于项目每个参与人员以及协助人员都有用吗?
这个测试策略是否很基本了?是否也容易的应用到这个产品中?
这个测试策略是否透露了所以的重要的问题
4. 计划安排
安排的内容
测试时间的评估和计划
易测性的工程分析
测试团队人员(详细的能力)
测试人员的培训和监督
测试人员的任务的指定
产品开发信息的收集和管理
项目会议，沟通，协调的方式
与其他已存在的功能之间的关系，包括开发过程中
测试平台的认购和配置
测试工具盒自动化
需要用到的测试桩和mock
测试套的管理和维护
建立和输出协议约定
测试周期管理
问题报告系统和约定
测试状态报告的约定
代码冻结和增量测试
测试后期的压力管理
项目阶段输出协议约定
测试效率的预估
可能的工作产出
问题列表
项目风险分析
任务和责任matrix
测试时间表
与开发之间的约定和协议
执行状态检查
这个项目所列的安排是否支持测试策略?
是否存在一些问题会阻碍测试的执行?
在可见性的问题面前，这些安排和策略是否适合?
你现在是否开始测试还是以后整理剩下的问题?
5. 分享计划
分享的方式
让设计人员和股东都参与到整个测试计划的制定过程中
更主动的获取关于测试计划的意见
尽最大可能帮助开发人员保持进度
帮助开发人员理解他们做什么会影响测试
与技术支持和写技术文档的人分享产品质量信息
让设计人员和开发人员评审并且批准所以相关的文档
记录并加强与开发之间的约定
让参与人员评审测试计划的细节
在测试计划中尽量减少没必要的信息以增加评审的效率

目标
对于测试过程达到一致的理解

来自：领测软件测试网。我本人觉得挺赞的。

‘叁’ 软件测试的工作计划和目标

每天在忙忙碌碌的维持生计的工作中，甚至没有好好想过我在这个阶段应该做什么？而不是被要求去做什么。
经过这么几年在软件测试行业的折腾，也有好好的想过这个问题，在特殊的阶段我们应该做好什么？尤其在软件测试行业。
大家都比较看好软件测试行业，只是因为表面上看起来：钱多事少加班少。其实这个都是针对个人运气好的童鞋才会有此待遇。在不同的阶段做好不同阶段的事情，才有可能离这个目标更近，作为一枚软件测试人员，也许下面才是我们最真实的写照。

{第一年}

当年也是一头撞进了软件测试行业。迫切的想要了解这个行业，它的升职模式，如何才能薪资更高。但是以过来人的经历，告诉你：做好当前的事情。把上司交给你的每一份任务都仔细认真的去完成，体现你作为一个初入职场的新人的价值。新人进去，不奢望你能够做多大的贡献，只希望交代给你的事情，不用给你擦屁股就行。
第一年，如果你每天都很积极，迫切的想要完成更多的任务，那么这一年的你将会进步最快。对功能业务逻辑的整体把握感，对测试用例的编写能力，对功能测试进度把握，这些都将会成为你以后工作的坚实基础。这一年，请打好你的基础，暂时忘记自动化代码工具这些，你没有坚实的软件测试行业内知识和接触到的一些专业名词，你拿着工具也都是徒然。

{第二年}

经过第一年的努力，你已经具有比较牢靠的软件测试基础，已经完成了一轮一轮的重复的手工测试，对，在这个阶段我们应该做什么？是每天上班等下班还是利用这段时间做点有意义的事情？毋庸置疑，如果你是积极向上的请你，那答案肯定是后者。
建议是：把你每天做的重复的功能测试，利用工具来做。
不建议大家过早的接触代码或者是性能这块，如果你还是职场第二年，因为你还见识的太少，根本达不到写代码和性能的这个阶段，要能够写脚本和做性能，需要你对整个测试框架和业务逻辑都有一个比较强的把握能力，否则，你做的事情，就会是无用功。就好比你学写代码，却发现自己永远停留在print（“hello world”）的水平；你学性能，缺发现自己永远停留在录制脚本的水平。
可以接触的工具：QTP/Jmeter，这两款工具都可以帮助你减少相对的劳动力，把一些重复的工作都利用工具来进行。学好了用活了，下次升职加薪或者是换工作，幸运之神都不会错过你。

{第三年}

终于迈入了第三个年头，恭喜恭喜，还能够坚持说明你没有被这个行业淘汰。经过两年的基础打底，如果你不是混混过日子，那么你的基础会让你的工作效率大步提升，你也会有更多的时间来做的别的事情，毫无疑问还是：学习。
这个时候，我们可以尝试着接触一些代码和一些框架，把你自己所学的知识融入到你自己的项目中去。能够把自己的项目整理出一个测试框架，那么你就是对这个公司的工作是有非常大的推进作用的！
建议：学习Python，selenium等。

{第四年}

有了代码基础后，发现你的工作量又被简化&优化了。这个时候我们应该对网站的架构，代码知识，数据库知识，网络瓶颈，系统优化等各个方面都有了比较深入的了解，我们终于可以进一步来做性能测试了！这个时候，我们突然明白：做性能测试不仅仅是录制脚本了！你需要去优化脚本，去设计场景，去获取目标用户量，去执行压力测试，去分析压力结果，做好这些之后，去综合分析发生性能瓶颈的是数据库优化问题，还是网络瓶颈问题还是本来的架构就存在问题？
推荐：LR/Jmeter

{第N年....}

未完待续.......
如果你能坚持到第五个年头，我希望是对软件测试行业而言是个有用的人；对软件测试行业有点点推动的人；对公司软件测试工作有建树的人。

‘肆’ 如何使用TestLink管理软件自动化测试过程

首先，创建项目-创建测试计划-创建需求-在需求中创建测试用例（这样需求就直接可以和用例关联了）-创建套件-将测试用例与测试计划关联，接下来就可以执行测试用例了
这里可以你也可以将testlink和mantis集成

‘伍’ 软件开发各个阶段可以实施的自动化测试技术有哪些

1. 单元测试自动化, 包含: 用例代码自动化生成, 测试数据生成, 被测代码的静态分析, 测试覆盖率统计等
2. 接口自动化测试, 包含: 测试数据的生成, 调用参数并发起请求, 验证请求返回的结果等
3. 基于页面的GUI自动化测试, 包含: 根据不同平台和业务场景, 选择合适的自动化框架和测试执行框架等
更多实战小技巧可以到网络上找下黑马程序员相关视频。很高兴我的回答能对您有所帮助，谢谢您的采纳

‘陆’ 什么是自动化测试

一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

基本信息

• 中文名称

  自动化测试

• 外文名称

  Test

• 定 义

  人为驱动测试为转为机器执行过程

• 应 用

  软件测试的自动化

• 工 具

  QTP

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

折叠编辑本段工具介绍

折叠QTP

全名HP QuickTest Professional software ，2012年12月6日发布11.5版本，并更名为Unified Functional Testing

QTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等

QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括:创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。

折叠WinRunner

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。

折叠RationalRobot

是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational Test Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

折叠AdventNetQEngine

AdventNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。支持对于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发，因此便于移植和提供多平台支持。

折叠SilkTest

是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使用户能够高效率地进行软件自动化测试。这些功能包括:测试的计划和管理;直接的数据库访问及校验;灵活、强大的4Test脚本语言，内置的恢复系统(Recovery System);以及具有使用同一套脚本进行跨平台、跨浏览器和技术进行测试的能力。

折叠QARun

QARun的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同

折叠TestPartner

是一个自动化的功能测试工具，它专为测试基于微软、Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，用户可以调用VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。没有编程知识的测试人员也可以通过TestPartner的可视化导航器来快速创建测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。

折叠Holodeck

-强大的故障植入软件测试工具

Holodeck is an advanced fault-injection tool that gives you the power to attack an application while it monitors and logs everything your application does - every function call, registry entry, piece of data read or written.

折叠TelelogicTAU

TAU第二代包含三个最新的、最强大的技术用来加速大规模软件开发和测试:统一建模语言(UML)及它的许多最新修订版本中的特性，UML2.0;功能强大的测试语言TTCN-3和新的构造系统的方法:Model Driven Architecture(模型驱动构架)。这三个新的业界标准结合成TAU的已经过认可的软件开发平台，形成了一个系统，一个一流的稳定可靠的工具解决方案。TAU第二代是系统与软件开发解决方案的一个突破，它把业界从使用了太长时间的手工、易出错、以代码为中心的方法中释放出来，自然而然地迈向下一步，一个更加可视化、自动化及可靠的开发方法。Telelogic TAU/Tester是基于通用测试语言TTCN-3,用于自动化的系统和集成测试的强大工具。TAU/Tester以现代化的开发工具为基础，提供高层测试功能，支持整个测试生命周期，加速自动化测试。TAU/Tester可使用户特别关注于测试的开发，因为TTCN-3语言是独立于开发语言或测试设备的，且是抽象和可移植的。

折叠AutoRunner

AutoRunner是黑盒测试工具，可以用来完成功能测试、回归测试，可以提高测试效率，降低测试人工成本。

产品可以对以下类型对象进行GUI功能性测试:

1 Windows类型对象，一般为用C++/Delphi/VB/VFP/PB/.NetForm等技术开发的桌面程序。

2 IE网页对象，一般性的网站，比如大的门户类网站。

3 Java对象，一般为用AWT/Swing/SWT等技术开发的桌面程序。

4 Flex对象，网页的内容是用Flex开发的。

5 Silverlight对象，网页的内容是用Silverlight开发的。

6 WPF对象，一般为用WPF技术开发的桌面程序。

7 QT对象，一般为用QT技术开发的桌面程序。

折叠PhoenixFramework

Phoenix Framework是一款基于 Selenium，Webdriver，autoIt研发的一款集资源管理和测试于一体的Web自动化测试工具。最新版本是1.1.8，该工具支持无脚本执行模式，无人值守执行模式，自由定制模式。不仅执行模式可以定制，功能模块也支持定制。使用该工具的界面创建用例，组装脚本，启动执行。使用该工具其他开放的接口，可手动创建脚本，组装并执行。它支持两种部署模式，第一种是Server-Client方式，Server与Client均为EXE程序，通信协议是Socket;另一种是WEB版部署，方便与现有系统集成，支持Linux，将Server与Client放到Tomcat或Weblogic服务器下部署，通信协议为Http，通过WEB页面控制并监控Client端的执行。

折叠编辑本段前提条件

实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件:

1) 需求变动不频繁

测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

2) 项目周期足够长

自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

3) 自动化测试脚本可重复使用

如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

折叠编辑本段适用场合

通常适合于软件测试自动化的场合:

(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费;

(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具;

(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性;

(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖。

随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本期所要讨论的话题。

软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化(如单元测试、功能测试以及性能方面)。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率;其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测试中尤其具有意义;此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据OppenheimerFunds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。

折叠编辑本段选型原则

然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢?也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台;或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。

以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议:

●选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本;

●测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求;

●在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑;

●在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性;

●尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;

●应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。

折叠编辑本段过程

自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具(相当于软件开发工具)，经过对测试需求的分析(软件过程中的需求分析)，设计出自动化测试用例(软件过程中的需求规格)，从而搭建自动化测试的框架(软件过程中的概要设计)，设计与编写自动化脚本(详细设计与编码)，测试脚本的正确性，从而完成该套测试脚本(即主要功能为测试的应用软件)。

1) 自动化测试需求分析。

当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

2)自动化测试框架的搭建。

所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。

而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素:

a. 公用的对象。

不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。

b. 公用的环境。

各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。

c. 公用的方法。

当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。

d. 测试数据。

也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。

在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

折叠编辑本段脚本编写

该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为，以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。

折叠编辑本段测试运行

事实上，当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。

因此，脚本的测试与试运行极为重要，它需要详查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的脚本试运行，以保证测试结果得一致性与精确性。

自动化测试引入的原因是就把软件测试人员从枯燥乏味的机械性手工测试劳动中解放出来，以自动化测试工具取而代之，使测试人员的精力真正花在提高软件产品质量本身。

折叠编辑本段注意事项

首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100%的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、OracleERP等测试库规划十分完善的套件，其测试自动化率也不会超过70%。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。

折叠编辑本段实战模拟

折叠背景介绍

A公司是一家大型保险公司，拥有近20个城市的分公司，并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右(新业务系统和原有业务系统的主要版本发布)。A公司的专职测试团队人数不足30人而且测试团队的测试人员技能参差不齐测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段，主要依靠手工测试。由于已上线应用系统的问题，开发团队必须分出一部分资源去维护和修复上线应用，而同时测试团队的测试成果和效率却无法和这些应用质量挂钩，也更无从谈起对软件质量的控制。所以，A公司决定在软件质量和测试方面进行投入，他们考虑以下几方面:

●引进软件测试流程管理的自动化，提高软件测试过程的管理水平，使软件测试和软件开发一样可被评估、被衡量。

●实现性能测试自动化，所有应用上线之前必须有应用性能风险评估报告和相关部门的确认

●逐步实现功能测试的自动化，在目前人员配置的情况下，把部分手工测试变成自动化测试，提高测试可信度，降低人为错误。

●通过软件测试自动化，管理软件测试中的案例、缺陷、报告等资产，进一步提升软件测试的效率并建立测试基础库。

●在规划中，将来的2~3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。

折叠系统的情况

由于保险公司的业务种类繁多，同时在经过了几十年的经营后，公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有，鱼龙混杂。IT部门已经建立的3年规划，即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构，但当前仍然需要对这些旧应用系统进行维护，以保证业务的顺利进行。对于开发部门来说，新应用开发基本上已经以B/S架构为主，主要是基于J2EE架构的WebHTTP应用和部分Window.NETForm的应用。

折叠公司现状

企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定，缺乏实事求是的理性思考。

测试部门仅负责系统测试和对用户验证测试进行管理，对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段，测试部门也无法收集和确定集成测试和单元测试的完成情况，在整个软件测试过程中，业务需求是由开发部门通过RationalRequisitePro进行管理，但测试需求尚没有提出要求，测试案例主要通过在公司公用的文件服务器中的目录管理方式管理，对测试中缺陷流程等管理主要依靠邮件的流转进行处理90%以上的测试是通过Excel和Word等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在"记录+回放"的认识上。

折叠方案

方案A:A公司可以采用美科利(Mercury)公司产品为主的软件测试自动化方案。

●依照原先的邮件流转过程配置TestDirector缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，取消原有邮件方式。

●部署MercuryQuickTestProfessional，以便完成应用程序相关功能测试。

●部署MercuryLoad-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组，和业务部门协调，建立A公司应用系统上线性能指标，通过LoadRunner给出测试指标。

●建议A公司成立专门的质量控制部门，对TestDirector中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。

方案B:A公司也可以采用IBMRational产品为主的软件测试自动化方案。

●采用RationalTestmanager来进行整个测试流程的管理，为相关开发和测试小组成员分配相应权限，改变以前通过邮件以及Word、Excel文档管理测试的工作方式。

●部署RationalRobot，用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外，RationalRobot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。

●部署RationalPurifyplus，使测试工作前移到开发阶段。由于Purifyplus能较好地支持白盒测试，编程人员在编码阶段引入的错误能尽早被检测到，这大幅降低了后期测试的开销。

●建议A公司成立专门的质量控制部门，对Testmanager中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。

方案C:A公司也可以采用开源软件为主的软件测试自动化方案。

●采用Bugzilla来进行Bug跟踪管理，采用BugzillaTestRunner进行测试用例管理，采用CVS进行测试资源的配置管理。

●采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。

●采用DBMonster、Open-STA、LoadSim进行性能相关测试。

●可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。

●建议A公司成立专门的开源软件维护小组，以解决可能会碰到的工具维护工作。

●建议A公司成立专门的质量控制部门，对Bugzilla、TestRunner、CVS中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。

折叠方案评价

由于不同客户在组织架构、员工素质以及流程管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性。在上面的例子中，笔者给出了3种可行的方案，具体选择哪一个，需要仔细权衡。这里笔者给出一般性的意见，对于不想受制于某个测试自动化厂家的企业，开源绝对是一个理想的选择。此外，它不需要支付成本，工具的源代码可以随意修改，因而具有较好的灵活性。但开源工具的弊端也是明显的:缺乏使用培训和技术支持，工具的用户界面一般也较为粗糙。而对于那些比较看重培训和售后支持的企业，笔者建议选择IBMRational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。

‘柒’ 自动化测试基本流程是什么

自动化测试基本流程

1、制定测试计划

在展开自动化测试之前，最好做个测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，下发给用例设计者。

2、分析测试需求

用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时能够覆盖所有的需求点。一般来讲，基于Web功能测试需要覆盖一下几个方面：

1）页面链接测试，确保各个链接正常；

2）页面控件测试，确保各个控件可靠；

3）页面功能测试，确保各项操作正常；

4）数据处理测试，确保数据显示准确、处理精确可靠；

5）模块业务逻辑测试，确保各个业务流程畅通。

3、设计测试用例

通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时，要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。

4、搭建测试环境

自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等。

5、编写测试脚本

根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据惊醒参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后，需要反复执行，不断调试，知道运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。

6、分析测试结果、记录测试问题

应该及时分析自动化测试结果，建议测试人员每天抽出一定时间，对自动化测试结果进行分析，以便尽早地发现缺陷。如果采用开源自动化测试工具，建议对其进行二次开发，以便与测试部门选定的缺陷管理工具紧密结合。理想情况下，自动化测试案例运行失败后，自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间，确认这些自动上报的缺陷，是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。

7、跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对此问题执行回归测试，就是重复执行一次该问题对应的较薄，执行通过则关闭，否则继续修改。如果问题的修改方案与客户达成一致，但与原来的需求有所偏离，那么在回归测试前，还需要对脚本进行必要的修改和调试。

8、自动化脚本的维护

如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。

‘捌’ 软件自动化测试的意思是什么具体价值体现在什么方面能做些什么事情

软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。
一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。
项目测试管理
1。帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。
2。提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。
3。 结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一
软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。
软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。
一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。
在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。
项目测试管理
1。帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。
2。提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。
3。 结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一手信息。
测试计划
软件系统不仅变得越来越庞大，但是也变得越来越复杂。复杂的代码是很难阅读、理解和修改的；必须化更多的精力去测试、维护和再测试。
测试复杂性分析能帮助软件工程师容易并精确地去计划他们的测试活动。 提供系统级复杂性分析和过程级复杂性分析去精确地测量复杂性，帮助工程师更好地计划他们的测试活动。帮助工程师更好估计和使用测试复杂性度量，为满足不同层次的测试覆盖的要求，必需提供：块测试复杂性、分支测试复杂性、段测试复杂性、条件-判定测试复杂性、条件-段测试复杂性。

‘玖’ 软件测试自动化测试面试题

自动化测试面试题
1. 你比较熟悉那种自动化测试工具？
2. 你在你以前工作中是如何使用自动化测试工具的？
3. 介绍一下你在利用自动化测试工具的过程中遇到的一些问题
4. 你是如何计划自动化测试的？
5. 自动化测试能提高测试效率吗？
6. 什么是data-driven automoation(数据启动自动化)？
7. 测试自动化的主要特征有哪些？
8. 自动化测试可以代替手工测试吗？
9.自动化测试的好处是什么？
10. 自动化测试容易出现的误区有哪些？
11. 介绍一下测试自动化的常见问题？
12. 你知道哪些测试自动化的脚本技术？
13. 测试用例的设计可以自动化吗？
自动化测试框架都有哪些?
答：自动化测试框架主要分为以下几种，可以根据项目需要进行选择
1.模块化框架(test script molarity)。
2.函数库结构框架(test library architecture)。
3.关键字驱动测试框架(keyword-driven/table-driven testing)。
4.数据驱动测试框架(data-driven testing)。
5.混合型框架(hybrid test automation)。
请列举你曾经做过的自动化功能测试项目的相关经验
你认为什么情况下适合进行自动化功能测试?请解释原因
请问自动化测试在实现过程中会遇到的难点有哪些?
请问：怎么在自动测试中实现数据驱动?
你会计算自动测试工程的投入回报比吗?怎么计算?
请比较 Rational Robot 与 MI QTP 的优缺点
你认为 Robot 在数据参数化的时候有什么不便之处吗?
请问 QTP 中如何不用录制的方法启动 IE ，并对 IE 窗口进行操作
在用自动测试工具制作测试脚本的时候，当需要对某个界面上的对象进行操作时，如何保证操作成功?
请选择一个自动功能测试工具并用该测试工具的脚本语言写一个脚本：每天早上 9 点弹出对话框，提示“现在 9 点了”。说明在测试工具中使用你的脚本的方式