1. 如何用python做自动化测试
用python做自动化测试，主要是接口测试和UI自动化测试。
一、接口测试：
http协议的举例:
可以用python自带的urllib\urllib2模拟，模拟前端向服务器发送数据，获取返回值后，进行校验和判断来进行接口测试。
网上的例子也比较多，这里简单说一下，
比如request中data的边界值测试、字符测试、非空为空测试等等，都可以做
二、UI自动化测试：
html页面（python+selenium）或者一些安卓app(python+appiun)可以用。
主要是页面元素的检查、输入等。
比如可以写一个脚本，自动登录网络页面，搜索某一个关键字，并且获得此关键字的网络搜索数量。
2. c#winform关于动态显示tooltip提示信息的方法
增加一个ToolTip控件toolTip1，设置需要提示的按钮btn1的tooltip属性为true，通过toolTip1.SetToolTip(btn1,
"提示信息1");实现
3. 网页的动态消息提示、消息监听要怎么做
有人给力留言或者回复了你就把这条记录存在数据库中并设置状态为0（未读）
然后在前端页面用js写一个定时器 每个10秒钟向后台请求一次查看有没有对应你这个用户id的并且信息状态为0的信息，如果有处理一下返回信息，没有就算了，一般来说信息系统都是用定时器的功能实现的
4. java自动化怎样校验应答包字段的值
从二进制开始检查，最常用的SUM校验。。。。。。各二进制位累加，再&0xff
~~~~
5. 在html中怎样实现表单验证并在控件后面输出动态提示
你好 做个例子给你 但是纯html是不可能的 必须附带js 我这里用的jquery方便点
<input type="text" name="checkname" id="a"/>
<div id="b" style="width:20px;height:20px;border:1px solid red;display:none;"></div>
下面jquery 假设验证必须为数字 并为6位数
function check(){
$("#b").show
var reg = /^\d{6}$/
if(!reg.test($("#a").val())){
$("#b").text("错误")
}else{
$("#b").text("正确")
}
}
$(function(){
$("#a").blur(function(){
check();
})
})
效果就是 本来提示都是隐藏的
然后文本框失去焦点时触发 提示的div显示 并且 若文本框中的值不满足6位数字 显示错误
否则 显示正确
另外 楼上的朋友说的也没错 不过 动态验证需要ajax 如若是这种定死的 则不需要
而且 格式验证是不会用ajax做的 都是js做 不然浪费多少服务器资源？ 只有判断用户名是否重复 这种才会用ajax去数据库中间查询返回结果
希望能帮到你 谢谢
6. 西门子气动调节阀如何校验手动校验与自动校验详细过程
一、自动校验，按着进入键几秒后自动进入校验菜单，第一个是选择角行程还是直行程的，第二个是行程的转角. 第4个就是自动校验了，选择了，按最后一个键几秒钟自动执行，定位器会自动校正量程限位，力矩等等，大约2分钟左右自动校正完成，直接按第一个键几秒后退出校正清单。
二、手动校验，同上，第5个菜单就是执行手动校验的，手动校验，你将阀门关死，上面输入0 全开100（反作用的相反）作个5点连校就可以了。
(6)怎样用自动化校验动态提示信息扩展阅读
1、西门子气动调节阀自动校验：按进入键进入校验菜单， 第4个是自动校验菜单，选中，按最后一个键执行，定位器会自动校正量程限位，力矩等，自动校正完成后，按第一个键退出校正。
2、手动校验，同上，第5个菜单是手动校验菜单，手动校验时，将阀门关死，上面输入0 全开100（反作用的相反）作个5点连校。
3、气动调节阀就是以压缩气体为动力源，以气缸为执行器，并借助于阀门定位器、转换器、电磁阀、保位阀、储气罐、气体过滤器等附件去驱动阀门，实现开关量或比例式调节，接收工业自动化控制系统的控制信号来完成调节管道介质的。
4、流量、压力、温度、液位等各种工艺过程参数。气动调节阀的特点就是控制简单，反应快速，且本质安全，不需另外再采取防爆措施。
特点：
A、气动调节阀的用途与特点用途 是一种直角回转结构，它与阀门定位器配套使用，可实现比例调节; V型阀芯最适用于各种调节场合，具有额定流量系数大，可调比大，密封效果好，调节性能灵敏，体积小，可竖卧安装。适用于控制气体、蒸汽、液体等介质。
B、特点：是一种直角回转结构，由V型阀体、气动执行机构、定位器及其他附件组成;有一个近似等百比的固有流量特性;采用双轴承结构，启动扭矩小，具有极好的灵敏度和感应速度;超强的剪切能力。
C、气动活塞执行机构采用压缩空气作动力源，通过活塞的运动带动曲臂进行90度回转，达到使阀门自动启闭。它的组成部分为：调节螺栓、执行机构箱体、曲臂、气缸体、气缸轴、活塞、连杆、万向轴。
D、气动调节阀的工作原理：气动调节阀由执行机构和调节机构组成。执行机构是调节阀的推力部件，它按控制信号压力的大小产生相应的推力，推动调节机构动作。阀体是气动调节阀的调节部件，它直接与调节介质接触，调节该流体的流量。
E、有在用的调节阀，配的西门子定位器SP2，手动开或关动作正常。参数检查设置正常，自动校验时候总是到第二步run2 ，出现故障显DLU，后不动了。
7. 如何实现接收手机短信验证码的自动化测试
搞一个广播，监听手机是否收到短信，然后根据手机短信内容，根据里面的关键字来判断短信是否是短信验证码的信息，然后根据正则表达式来获取到连续几位的数字。
8. 在玩网络游戏时，挂机会出现验证窗口，这样的验证要怎样用VC++编程自动化啊， 游戏窗口验证怎么编程自动化
没有这样的函数。
在游戏里，这个验证是为了防止长时间挂机的一个方式。
出现验证正常的方式应该是这样的：客户端长时间无操作，会向服务器发送消息，服务器接到消息会向客客端发送图片，客户端由人来识别图片，给客户端输入，客户端给服务器发送，最后是正确还是错误(包括未发送等)的处理。
这个过程有两个地方可以利用，1长时间无操作，2由人来识别图片。
先说2，现在没有一个很好，很完善的图像识别系统或内置模块，更没有函数可以让你调用。你可以从网上找一找大家编写的图像识别相关的东西，看看有没有帮助。
另外，有一些游戏，由其是棒子的游戏，好多都是客户端验证，就是说会把图片对应的字符串从服务器端发到客户端，甚至还有从生成到验证整个过程都从客户端完成的。这样其实挂机验没意义不是很大。如果是这样的话，你可以找到内存地址，读出数据，进行模拟输入就行了。当然这样的毕竟是少数，但棒子游戏居多。不妨可以试试。
再说1，其实长时间无操作，这个很好办了吧。一个一直玩着游戏的人是不会看到这个验证窗口的吧？就是在出验证窗口之前，以模拟方式，模拟用户操作。sendmessage(…)等，最好是全局的键盘模拟keybd_event(…)或鼠标模拟mouse_event(…)等。
说的还算明白吧？其实一个…过程，从头至尾分析每一个环节，就不难看出哪个环节可以利用了。
等你采纳了。
9. 如何进行接口自动化测试
曾经有一段时间，人们习惯于在MSExcel里面编写单元测试用例，然后开发人员就按照单元测试用例一步一步的来实现用例。这通常是很耗时的漫长的过程，尤其是如果应用很大或者UI很复杂的话。这一套单元测试的执行过程常常成为瓶颈，因为任何代码修改都会带来手工执行大量单元测试，以确保新的修改没有破坏原有功能。如今是个快节奏时代，人们希望工作能够无需人工介入、自动化的快速完成。每个人都喜欢执行一个命令就能把工作搞定，而且在执行期间不需要人工介入。需要做的仅仅是检查一下最终的输出结果。当这个世界正在迈向自动化时，自动化测试也不甘落后，不论是在功能测试方面还是UI测试方面。每天我们都能听说自动化测试方面涌现出的新软件。本文提供了一些信息给那些想用CodedUI自动测试框架来进行应用界面自动化的.Net开发者。什么是CodedUI?最近我一直在寻找一个自动化的用户接口测试的解决方案。用户接口测试需要用户多次进行手工输入操作，这是一个既枯燥又费时的过程。因此，我想寻找一种更智能的自动化UI测试的方案，这种UI测试在不需要人工干预下，能够被保存，记录并提供支持，快速测试代码的改变。CodedUI采用用户接口来驱动应用的进行自动化测试。这些测试包括UI控制的功能性测试。他们使你可以验证整个应用的功能是否正确，其中包括了用户接口。CodedUI尤其适合用于用户接口中存在校验或者其它的登录方式的测试，比如网页。CodedUI也可以用于人工测试用例的自动化。CodedUI测试帮助用户测试应用程序的用户接口。这些测试允许用户验证应用程序的功能。CodedUI多数时间用于帮助验证在UI层本身的有效逻辑。它能够验证值对用户接口的控制的正确性。其它方案市场有许多自动化用户接口的方案，比如HP的QuickTestProfessional,IBMRationalFunctionalTester.其它着名的，易于使用的开源工具解决用户接口自动化问题的有Selenium，也能够记录测试，需要的时候回放。市场上还有来自Microsoft的也能不需要太多努力做同样的事。用VisualStudioMicrosoft还有CodedUI的方案用于单元测试。CodedUI适合在哪儿用?大多数安装了VisualStudio的开发者都喜欢在VisualStudio的环境里进行单元测试，而不是使用第三方工具。由微软提供的CodedUI，在VisualStudio环境里可谓上手即用。在开发者的机器上无需另外安装任何东西。一旦你安装了VisualStudio的Premium版或者Ultimate版，你就同时也安装好了CodedUI。CodedUI可用性为了使用CodedUI，需要安装VisualStudio2010/2012/2013的Premium版或者Ultimate版。CodedUI测试的组成CodedUI测试的组成容易理解。它可分成下列文件：UIMap.uitest这个文件是UIMap类的XML表示。UIMap类包括视窗，控件，属性，方法，断言和动作。UIMap.cs对UIMap的自定义部分都存在这文件里。如果修改直接存在UIMap.designer.vb文件的话，那些修改都会在记录结束后丢失，因为这个文件重新创建了。给每个在测应用程序中的每个模块创建一个独立的UIMap文件。UIMap.Designer.cs这是部分类表达各种类。这各种类是给多样的控件和他们的范围，属性，方法的类。提示：不要直接修改UIMap.Designer.cs。加入你这样做，这个修改会被覆盖掉。CodedUITest.cs这类表示的实际的CodeUI测试类，方法调用，和断言调用，所有的方法和断言默认都是从UIMap.Designer.cs文件调用的。这类有具有【codedUITest]属性TestClass和包含具有【TestMethod]属性的多种方法。CodedUI的特性/好处进行用户界面测试的同时进行校验.生成VB.Net/C#代码.测试用例可以被记录和重放.集成了ALMStory能够作为每日构建的一部分来运行.根据需要进行高级扩展.和VisualStudio集成在一起，所以无需单独购买许可.CodedUI对Web和Windows应用同样适用.着名的Microsoft支持.创建CodedUI测试CodedUI测试可以用下列方式创建使用MTM进行快速自动构建从现有的记录(从手动测试中记录下来的操作)中创建CodedUI在CodedUITestBuilder创建的底稿的基础上创建一个新的CodedUI测试.自己写CodedUI.这个白皮书的范围仅限于“在CodedUITestBuilder创建的底稿之上创建一个新的CodedUI测试”。小贴士:尽量使用CodedUITestBuilder。CodedUITestBuilder每一个CodedUI测试的生成都需要遵从下列步骤.记录/停止/暂停编辑记录下来的步骤添加断言生成代码创建CodedUI测试创建新的CodedUI项目要开始使用CodedUI，首先我们需要创建一个测试项目，用来保存所有CodedUI测试。创建一个新的CodedUI项目包含下列步骤打开VisualStudio2012选择File>New>Project选择需要的语言模板(C#orVB.Net).我们选择了C#.选择CodedUIProject输入一个名字点击OK按钮添加CodedUI测试VisualStudio默认配置为创建CodedUI测试使用""提示：在测试的应用程序中，当你创建UI控件时尽量使用有意义的名称，从而对于自动生成的控件显得更加有意义和可用。一旦CodedUI测试工程创建完成，将会自动打开生成CodedUI测试代码的对话框，请给出以下选项的设置。记录操作，编辑UI地图或添加断言使用一个已经存在的操作记录默认情况下选择记录操作,编辑UI地图或添加断言，无需做任何操作，然后点击"ok"CodedUITestBuilder选择了上述选项后，CodedUITestBuilder就会被打开，同时VisualStudio窗口被最小化。这意味着我们已经为记录操作做好了准备。正如之前描述的，CodedUITestBuilder基于下列4个操作来做记录(AddAssertions)GenerateCode小贴士:如果用户界面(UI)变化了，就重新记录测试方法或断言方法，或者重新记录一个既有测试方法中受影响的部分。记录一个序列的操作.记录一个操作主要需要下列几步.StartRecording,通过选择Record按钮即可.PauseRecording,用来处理记录过程中的其它操作，即GenerateCode.Edit/Delete操作,以防错误的操作被记录。Generatecode为记录下来的操作创建编号。会给每一个记录下来的操作都生成编号。AddAssertions用来校验结果。小贴士:创建断言最好使用CodedUITestBuilder，因为它会在UIMap.Designer.cs文件中自动添加一个断言方法。为记录动作做计划任何事情的成功都取决于它计划得有多好。较好地计划最大限度保证了任务成功完成。这样总是比较好，在开始记录动作之前，我们计划好所有的所有要计划的步骤。这里我们将要使用应用程序Windows计算器来记录步骤。我们要自动地加和减两个数字。在记录加和减两个数字的时候，下面的步骤将会用到。。点击“开始记录”控件。到开始，点击执行。在执行窗口，输入”calc"。停止记录，看记录的步骤。删除错误的步骤（存在的话）。产生代码；提供和动作相匹配的名字。比如，打开计算器。提示：当你产生一个方法时候，使用一个有意义的方法的名字，代替默认名字。有意义的名字帮助识别方法的木的。。重新记录，提供第一个数字，暂停记录产生代码。重新记录，提供操作（加或者减），暂停记录，产生代码。重新记录，提供第二个数字，暂停记录，产生代码。。加断言提示：产生你的测试作为一系列记录的方法提示：可以的时候，限制每个方法小于10个动作。这模块化的方法让UI改变时候容易替换方法。我们已经看到了CodedUI可以使开发者的生活变得多么轻松，尤其是遇到每次都需要进行很多输入的复杂页面的时候。这时，测试用例只需要被记录一次，就可以按照需要执行任意多次。使用CodedUI比使用其它工具的好处是，它能自动适配Web页面和Windows窗口应用。CodedUI测试可以用VisualStudio2010来运行，也可以用任何版本的VS来运行，它们的功能正变得越来越强大。无需多说，CodedUI是一个由技术领导者提供的强大工具，想要体验CodedUI测试的强大，我们应该开始在项目中使用它看看它能带来多少ROI，我确信CodedUI不会让你失望。
10. 什么是自动化测试
一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
基本信息
中文名称
自动化测试
外文名称
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或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。