文摘
来源：互联网 发布：废除死刑 知乎 编辑：程序博客网 时间：2024/05/04 02:49
1.1 脚本录制规范：
基本原则是录制脚本要分开、gui文件要合并、批调用回放验证、可移植回放验证。
1.1.1 录制脚本要分开：
脚本太大，不仅不利于以后的维护，并且会导致WinRunner的不可预测的错误产生（具体可以参考WinRunner 的Readme文档）。录制时，可以根据测试用例的流程，拆分为几个小流程，对每个小流程分别录制成不同的脚本。
1.1.2 gui文件要合并：
首先，要在系统参数中，设置gui的录制模式为“Global GUI Map File
录制过程中，WinRunner会自动产生gui文件，一个测试用例要确保生成一个公用gui文件。用一个gui文件主要是为了以后gui对象的维护，脚本回放时gui对象的查找。但是由于我们的测试用例是分开录制的，每个小流程录制时都会产生一个gui临时文件，因此录制完脚本后要把临时gui文件合并到该测试用例的公用gui文件中。但是也要注意，开始新的录制前，一定要先手工加载测试用例的公用gui文件。
如果划分的子流程超过20个，则按每20个子流程录制一个gui文件的方式。Gui文件太大，会影响WinRunner的回放效率。
1.1.3 批调用回放验证：
为了提高脚本的正确性，每录制完成一个子流程后，都要恢复数据库，其他初始环境进行回放，以近早发现脚本错误。
单个测试用例脚本录制完成后，要专门写一个主脚本，进行各子脚本的主次调用处理，然后恢复数据库和其他初始环境进行回放，以验证整个脚本是否可以正确回放。
1.1.4 可移植回放验证：
由于WinRunner 工具的限制，在本机回放成功后，如果把脚本移植到其他机器上，往往无法成功。这其中既有自己编写的脚本问题，又有WinRunner录制自动生成的脚本问题。
自己编写脚本问题：往往是编写的可移植性较差，如加载gui文件时用的是绝对地址，如gui_load(“c://aa//aa.gui”)，这样的脚本换到其他机器必然出错。
WinRunner录制自动生成的脚本问题： WinRunner的录制脚本往往和机器的环境有关，如果换了其他机器环境，往往回放不成功，这就需要手工修改脚本。
因此，可移植性回放是非常必要的。
1.1.5 脚本中使用的ODBC数据源名称统一命名为WR。
1.1.6 录入中文数据时统一使用简体。
1.1.7 数据表列名称规定
录入数据驱动的脚本时，数据表列名称统一采用英文，使用PB数据窗口中列对象的名称。数据表列名称下的第一行用中文对英文列名称做注释，使用PB数据窗口中列对象的中文标签，这一行不作为有效的录入数据。与数据表相关的循环语句请修改脚本从数据表的第二行开始读取数据。典型的例子是将数据驱动脚本中For循环的第一个表达式改为table_Row = 2。
1.1.8 脚本成功回放判定规定
一个子测试录制完成后，一定要及时回放测试，直到测试报告显示测试结果为OK，且子测试明细报告中没有红色的出错提示。如果是回放主测试，回放成功的标准是：主测试的结果报告显示为OK，同时所有子测试的结果报告也为OK,且子测试明细报告中没有红色的出错提示。
1.1.9 WinRuner主脚本中关于设置系统日期时间设置的规定，以保证脚本所描述的业务过程按业务逻辑在时间上有序。
因为脚本回放与脚本录制时的系统日期时间不一致，会导致与系统时间关系密切的测试脚本回放时失败。
为了消除时间差导致的回放错误,要求每一个测试用例的主测试在第一个子测试前加上date_set_system_date(年,月,日,时,分,秒)函数,以修改本地机器的日期时间等于这个主测试在接力式验收回放成功执行后的日期时间.这样再次回放时系统的日期时间就和上一次成功回放时的日期时间一致。
1.2 测试脚本存放规范：
各子测试脚本必须放到同一目录下，即环境目录下的script目录下。这样便于批调用时引用。
1.3 Gui文件的存放：
Gui 文件，必须和测试脚本放到同一目录下，即环境目录下的script目录下。
1.4 WinRunner使用规范：
（1） 必须写上清楚的注释：编写测试脚本，要进行详细的标注，每测试一小段，就要写一段备注，以便于将来修改，格式可以参考如下：
功能描述：描述脚本的功能
前置条件：该脚本在满足什么条件下才可以被执行
步骤描述：描述脚本录制的动作
检查点描述：描述作了对什么的检查，检查条件。
录入人：录制人
录入时间：
备注：
（2） gui文件的加载保存：
每次开始测试用例的录制脚本前，如果该测试用例已经存在gui文件，一定要手工打开gui文件，再开始录制。如果不想手工打开，可以写段自动加载gui的脚本，每次录制前运行一下该脚本。录入脚本后，要注意保存GUI文件，如果测试用例已经存在gui文件，一定要把临时的gui文件合并到该用例的公用gui文件中，然后保存。
（3） 如果机器数据较慢，或者网络较慢、或者数据库运行较慢，需要把等待打开窗口的时间设长。或者在脚本中插入同步点来处理。
（4） WinRunner不支持Fomular One，目前不可以用wr测试Fomular One
使用WinRunner录制时不可以切换不同输入法录制，仅可以用一种输入法。
（5） WinRunner 对shift 键无法纪录，需要特殊处理 ，可以加入如下处理
obj_type "dw_1.fslipbugno","<kShift_L>-";（告诉WinRunner按下Shift键）
中间是选择行的脚本
obj_type ("dw_1.FBugNo","<kShift_L>+";（告诉WinRunner释放Shift键）
（6） 保证录制的脚本干净性：
在录制过程中，不可避免的要进行其他动作，如打开邮件、打开非录制程序等，这些动作也会被WinRunner录制下来，这些动作会严重影响测试脚本的回放（除非作这些动作前停止录制）。
因此，为了保证脚本的干净，在WinRunner的参数中进行如下设置：设置Recode 的“Selected Applications” 为要录制的程序。
（7） 录制脚本时，不允许同时打开两个运行程序（指进行wr测试的程序）
（8） 变量的声明：WinRunner有auto /public /static /extern 四个类型的变量作用域声明，其中public为默认的类型。由于public 是全局的，只要在一个脚本中声明了，在任何其他脚本都可以引用，这就带来一个问题，如果其他的脚本修改了这个public 变量的值，将会引发问题。因此变量声明时必须明确的加上类型（auto /public /static /extern），public 的一般不要使用，推荐使用static /auto 。
2. 异常处理规范：
在录制或者编写测试脚本时，必须进行异常的错误处理。以提高程序的错误检查能力。
2.1 函数异常检测：
对于一些常用函数，必须进行函数执行异常的处理。至少进行如下函数的异常检测：et_window、win_activate、menu_select_item、ddt_open。
发现异常后，要终止程序的执行，并发邮件通知相关人员。
2.2 返回值规范：
模块、函数的返回值约定如下，0 表示成功 ，其他失败。
对于一些函数的返回值，需要进行判断处理：
（1） 每一个call语句都应该检查它的返回值是否为0, 如果不为0则报错退出。
随着软件测试的地位逐步提高，测试的重要性逐步显现，测试工具的应用已经成为了普遍的趋势。目前用于测试的工具已经比较多了，这些测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。
总的来说，测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候，我们也应该看到，在测试过程中，并不是所有的测试工具都适合我们使用，同时，有了测试工具、会使用测试工具并不等于测试工具真正能在测试中发挥作用。
一、JTEST
１、简介：
jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类，然后自动生成junit测试用例并执行用例，从而实现代码的最大覆盖，并将代码运行时未处理的异常暴露出来；另外，它还可以检查以DbC（Design by Contract）规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差，用户可自定义这些标准，通过简单的几个点击，就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。
２、优势：
1）使预防代码错误成为可能，从而大大节约成本，提高软件质量和开发效率
2）使单元测试——包括白盒、黑盒以及回归测试成为可能
3）使代码规范检查和自动纠正成为可能
4）鼓励开发团队横向协作来预防代码错误
３、特征：
1）通过简单的点击，自动实现代码基本错误的预防，这包括单元测试和代码规范的检查
2）生成并执行junit单元测试用例，对代码进行即时检查
3）提供了进行黑盒测试、模型测试和系统测试的快速途径
4）确认并阻止代码中不可捕获的异常、函数错误、内存泄漏、性能问题、安全弱点的问题
5）监视测试的覆盖范围
6）自动执行回归测试
7）支持DbC编码规范
8）检验超过350个来自java专家的开发规范
9）自动纠正违反超过160个编码规范的错误
10）允许用户通过图形方式或自动创建方式来自定义编码规范
11）支持大型团队开发中测试设置和测试文件的共享
12）实现和IBM Websphere Studio /Eclipse IDE 的安全集成
４、价格：昂贵
二、JMETER
１、简介：
JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。使用JMeter进行性能测试
２、特征：
JMeter可以用于测试静态或者动态资源的性能（文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源）。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力，或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。
３、价格：未知
三、JUNIT
１、简介：
JUnit是一个开源的java测试框架，它是Xuint测试体系架构的一种实现。在JUnit单元测试框架的设计时，设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。
２、优势：
2.1)junit是完全Free的。
2.2)使用方便。在你提升程序代码的品质时JUnit测试仍允许你更快速的撰写程序
那听起来似乎不是很直觉，但那是事实。当你使用JUnit撰写测试，你将花更少的时间除虫，同时对你程序代码的改变更 俱有信心。这个信心让你更积极重整程序代码并增加新的功能。没有测试，对于重整及增加新功能你会变得没有信心；因为你不知道有甚么东西会破坏产出的结果。采用一个综合的测试系列，你可以在改变程序代码之后快速的执行多个测试并对于你的变动并未破坏任何东西感到有信心。在执行测试时如果发现臭虫，原始码仍然清楚的在你脑中，因此很容易找到臭虫。在JUnit中撰写的测试帮助你以一种极 大(extreme)的步伐撰写程序及快速的找出缺点。2.3)JUnit非常简单撰写测试应该很简单--这是重点！如果撰写测试太复杂或太耗时间，便无法要求程序设计师撰写测试。使用JUnit你可以快速的撰写测试并检测你的程序代码并逐 步随着程序代码的成长增加测试。只要你写了一些测试，你想要快速并频繁的执行测试而不至于中断建立设计及开发程序。使用JUnit执行测试就像编译你的程序代码那么容易。事实上，你应该执行编译时也执行测试。编译是检测程序代码的语法而测试是检查程序代码的完整性(integrity)。
2.4)JUnit测试检验其结果并提供立即的回馈。 如果你是以人工比对测试的期望与实际结果那么测试是很不好玩的，而且让你的速度慢下来。JUnit测试可以自动执行并且检查他们自己的结果。当你执行测试，你获得简单且立即的回馈； 比如测试是通过或失败。而不再需要人工检查测试结果的报告。
2.5)JUnit测试可以合成一个测试系列的层级架构。 JUnit可以把测试组织成测试系列；这个测试系列可以包含其它的测试或测试系列。JUnit测试的合成行为允许你组合多个测试并自动的回归(regression)从头到尾测试整个测试系列。你也可以执行测试系列层级架构中任何一层的测试。
2.6)撰写JUnit测试所费不多。 使用Junit测试框架，你可以很便宜的撰写测试并享受由测试框架所提供的信心。撰写一个测试就像写一个方法一样简单；测试是检验要测试的程序代码并定义期望的结果。这个测试框架提供自动执行测试的背景；这个背景并成为其它测试集合的一部份。在测试少量的投资将持续让你从时间及品质中获得回收。
2.7)JUnit测试提升软件的稳定性。 你写的测试愈少；你的程序代码变的愈不稳定。测试使得软件稳定并逐步累积信心；因为任何变动不会造成涟漪效应而漫及整个软件。测试可以形成软件的完整结构的胶结。2.8)JUnit测试是开发者测试。 JUnit测试是高度区域性(localized)测试；用以改善开发者的生产力及程序代码品质。不像功能测试(function test)视系统为一个黑箱以确认软件整体的工作性为主，单元测试是由内而外测试系统基础的建构区块。开发者撰写并拥有JUnit测试。每当一个开发反复(iteration)完成，这个测试便包裹成为交付软件的一部份提供一种沟通的方式，「这是我交付的软件并且是通过测试的。
2.9)JUnit测试是以Java写成的。 使用Java测试Java软件形成一个介于测试及程序代码间的无缝(seamless)边界。在测试的控制下测试变成整个软件的扩充同时程序代码可以被重整。Java编译器的单元测试静态语法检查可已帮助测试程序并且确认遵守软件接口的约定。
一段测试的程序代码无法单独的执行，它需要是执行环境的一部份。同时，它需要自动执行的单元测试--譬如在系统中周期性的执行所有的测试以证明没有任何东西被破坏。由于单元测试需要符合特定的准则：一个成功的测试不应该是人工检查的（那可要到天荒地老了啊），一个未通过测试的失败应可以产出文件以供诊断修改。而Junit可以提供给我们这些便利.。这样所有测试开发者所需撰写的只是测试码本身了。跟optimizeit、Jtest那些昂贵而又超级麻烦的tool比较起来，其利昭然可见！
３、价格：免费
四、WEBLODE
１、简介：
webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。
２、特征：
１）用户创建的是基于javascript的测试脚本,称为议程agenda,用它来模拟客户的行为,通过执行该脚本来衡量web应用程序在真实环境下的性能
２）如有需要可以在做负载测试的同时，使用服务器监控工具对服务器端的内容进行记录那样使负载测试更加全面。
３、价格：
五、WINRUNNER
１、简介
WinRunner:强大的企业级自动化测试工具
Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。
如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。
２、特征：
１）轻松创建测试
用WinRuuner创建一个测试，只需点击鼠标和键盘，完成一个标准的业务操作流程，WinRunner自动记录你的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。
２）插入检查点
在记录一个测试的过程中，可以插入检查点，检查在某个时刻/状态下，应用程序是否运行正常。在插入检查点后，WinRunner会收集一套数据指标，在测试运行时对其一一验证。WinRunner提供几种不同类型的检查点，包括文本的、GUI、位图和数据库。例如，用一个位图检查点，你可以检查公司的图标是否出现于指定位置。
３）检验数据
除了创建并运行测试，WinRunner还能验证数据库的数值，从而确保业务交易的准确性。例如，在创建测试时，可以设定哪些数据库表和记录需要检测；在测试运行时，测试程序就会自动核对数据库内的实际数值和预期的数值。WinRunner自动显示检测结果，在有更新/删除/插入的记录上突出显示以引起注意。
４）增强测试
为了彻底全面地测试一个应用程序，需要使用不同类型的数据来测试。WinRunner的数据驱动向导( Data Driver Wizard)可以让你简单地点击几下鼠标，就可以把一个业务流程测试转化为数据驱动测试，从而反映多个用户各自独特且真实的行为。
以一个订单输入的流程为例，你可能希望把订单号或客户名称作为可变栏，用多套数据进行测试。使用Data Driver Wizard，你可以选择订单号或客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件，或从其它表格和数据库中导入。数据驱动测试不仅节省了时间和资源，又提高了应用的测试覆盖率。
WinRunner还可以通过Function Generator增加测试的功能。使用Function Generator可以从目录列表中选择一个功能增加到你的测试中以提高测试能力。例如，你可以选择”calendar”，然后从日历功能的下属目录中选择，如Calendar_select_date(),然后你可以直观地输入参数，把这个功能插入到你的测试中。
针对相当数量的企业应用里非标准对象，WinRunner提供了Virtual Object Wizard来识别以前未知的对象。使用Virtual Object Wizard，你可以选择未知对象的类型，设定标识和命名。在录制使用该对象的测试时，WinRunner会自动对应它的名字，从而提高测试脚本的可读性和测试质量。
５）运行测试
创建好测试脚本，并插入检查点和必要的添加功能后，你就可以开始运行测试。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中，如有网络消息窗口出现或其它意外事件出现，WinRunner也会根据预先的设定排除这些干扰。
６）分析结果
测试运行结束后，你需要分析测试结果。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。报告中会列出测试中发现的错误内容、位置、检查点和其它重要事件，帮助你对测试结果进行分析。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。
７）维护测试
随着时间的推移，开发人员会对应用程序做进一步的修改，并需要增加另外的测试。使用WinRunner，你不必对程序的每一次改动都重新创建你的测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，充分利用你的测试投资。
每次记录测试时，WinRunner会自动创建一个GUI Map文件以保存应用对象。这些对象分层次组织，既可以总览所有的对象，也可以查询某个对象的详细信息。一般而言，对应用程序的任何改动都会影响到成百上千个测试。通过修改一个GUI Map文件而非无数个测试，WinRunner可以方便地实现测试重用。
８）帮助你的应用程序为无线应用作准备
随着无线设备种类和数量的增加，你的应用程序测试计划需要同时满足传统的基于浏览器的用户和无线浏览设备，如移动电话、传呼机和个人数字助理(PDA)。
无线应用协议是一种公开的、全球性的网络协议，用来支持标准数据格式化和无线设备信号的传输。
使用WinRunner，测试人员可以利用微型浏览模拟器来记录业务流程操作，然后回放和检查这些业务流程功能的正确性。
六、LOADRUNNER
１、简介：
LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。
LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。
２、特征：
１）轻松创建虚拟用户
使用LoadRunner 的Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程(如下订单或机票预定)，然后将其转化为测试脚本。利用虚拟用户，您可以在Windows ，UNIX 或Linux 机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。另外，LoadRunner 的TurboLoad 专利技术能。
提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。
用Virtual User Generator 建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。
LoadRunner 通过它的Data Wizard 来自动实现其测试数据的参数化。Data Wizard 直接连于数据库服务器，从中您可以获取所需的数据（如定单号和用户名）并直接将其输入到测试脚本。这样避免了人工处理数据的需要，Data Wizard 为您节省了大量的时间。
为了进一步确定您的Virtual user 能够模拟真实用户，您可利用LoadRunner 控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。
２）创建真实的负载
Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用LoadRunner 的Controller，您能很快组织起多用户的测试方案。Controller 的Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。
而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能---- 包括服务器，数据库，网络设备等----来帮助客户决定系统的配置。
LoadRunner 通过它的AutoLoad 技术，为您提供更多的测试灵活性。使用AutoLoad ，您可以根据目前的用户人数事先设定测试目标，优化测试流程。例如，您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。
３）定位性能问题
LoadRunner 内含集成的实时监测器，在负载测试过程的任何时候，您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据（如响应时间）和其它系统组件包括application server, web server，网路设备和数据库等的实时性能。这样，您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。
再者，利用LoadRunner 的ContentCheck TM ，您可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。
４）分析结果以精确定位问题所在
一旦测试完毕后，LoadRunner 收集汇总所有的测试数据，并为您提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner 的Web 交易细节监测器，您可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能
够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。另外，Web 交易细节监测器分解用于客户端、网络和服务器上端到端的反应时间，便于确认问题，定位查找真正出错的组件。例如，您可以将网络延时进行分解，以判断DNS 解析时间，连接服务器或SSL 认证所花费的时间。通过使用LoadRunner 的分析工具，您能很快地查找到出错的位置和原因并作出相应的调整。
５）重复测试保证系统发布的高性能
负载测试是一个重复过程。每次处理完一个出错情况，您都需要对您的应用程序在相同的方案下，再进行一次负载测试。以此检验您所做的修正是否改善了运行性能。
６）Enterprise Java Beans的测试
LoadRunner 完全支持EJB 的负载测试。这些基于Java 的组件运行在应用服务器上，提供广泛的应用服务。通过测试这些组件，您可以在应用程序开发的早期就确认并解决可能产生的问题。
利用LoadRunner, 您可以很方便地了解系统的性能。 它的Controller 允许您重复执行与出错修改前相同的测试方案。它的基于HTML 的报告为您提供一个比较性能结果所需的基准，以此衡量在一段时间内，有多大程度的改进并确保应用成功。由于这些报告是基于HTML 的文本，您可以将其公布于您公司的内部网上，便于随时查阅。
７）最大化投资回报
所有Mercury Interactive 的产品和服务都是集成设计的, 能完全相容地一起运作。由于它们具有相同的核心技术，来自于LoadRunner和ActiveTest TM 的测试脚本，在Mercury Interactive 的负载测试服务项目中，可以被重复用于性能监测。借助Mercury Interactive的监测功能－－Topaz TM 和ActiveWatch TM ，测试脚本可重复使用从而平衡投资收益。更重要的是，您能为测试的前期布署和生产系统的监测提供一个完整的应用性能管理解决方案。
８）支持无线应用协议
随着无线设备数量和种类的增多，您的测试计划需要同时满足传统的基于浏览器的用户和无线互联网设备，如手机和PDA。LoadRunner 支持2 项最广泛使用的协议：WAP和I-mode。此外，通过负载测试系统整体架构，LoadRunner 能让您只需要通过记录一次脚本，就可完全检测上述这些无线互联网系统。
９）支持Media Stream应用
LoadRunner 还能支持Media Stream应用。为了保证终端用户得到良好的操作体验和高质量Media Stream，您需要检测您的Media Stream应用程序。使用LoadRunner ，您可以记录和重放任何流行的多媒体数据流格式来诊断系统的性能问题，查找原由，分析数据的质量。
１０）完整的企业应用环境的支持
LoadRunner 支持广泛的协议，可以测试各种IT 基础架构。
七、WAS
１、简介：
Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。
２、特征：
1）可以数种不同的方式建立测试指令：包含以手动、录制浏览器操作步骤、或直接录入IIS的记录文件、录入网站的内容及录入其它测试程序的指令等方式。
2）支持多种客户端接口：标准的网站应用程序C++的客户端，使用Active Server Page 客户端，或是使用Web Application Stress对象模型建立您自定的接口。
3）支持多用户：利用多种不同的认证方式仿真实际的情况，包含了DPA, NTLM 及 SSL等。
测试驱动开发(TDD)是以测试作为开发过程的中心，它坚持，在编写实际代码之前，先写好基于产品代码的测试代码。开发过程的目标就是首先使测试能够通过，然后再优化设计结构。测试驱动开发式是极限编程的重要组成部分。xUnit，一个基于测试驱动开发的测试框架，它为我们在开发过程中使用测试驱动开发提供了一个方便的工具，使我们得以快速的进行单元测试。xUnit的成员有很多，如JUnit，PythonUnit等。今天给大家介绍的CppUnit即是xUnit家族中的一员，它是一个专门面向C++的测试框架。
本文不对CppUnit源码做详细的介绍，而只是对CppUnit的应用作一些介绍。在本文中，您将看到：
1、CppUnit源代码的各个组成部分。 2、怎样设置你的开发环境以能够使用CppUnit。 3、怎样为你的产品代码添加测试代码（实际上应该反过来，为测试代码添加产品代码。在TDD中，先有测试代码后有产品代码），并通过CppUnit来进行测试。
本文叙述背景为：CppUnit1.9.0, Visual C++ 6.0, Windows2000。文中叙述有误之处，敬请批评指正。
一、CppUnit源码组成
CppUnit测试框架的源代码可以到 http://sourceforge.net/projects/cppunit/ 上下载。下载解压后，你将看到如下文件夹：
图1
2、将CppUnitTestApp工程设为Active Project（Win32 Debug），编译后运行，则可以看到CppUnit的基于GUI方式进行单元测试TestRunner的界面。点击“Run”，将会看到如图2所示界面：
图2
图3
图4
图5
所有GUI检查点、数据库检查点都应做返回值检查。如果不为0则报错退出。
三、CppUnit开发环境设置 认识了CppUnit的测试环境，想必你已经是在磨拳擦掌，准备在你的开发过程中感受一下测试驱动开发的感觉了。不过，在使用CppUnit前，还需要设置一下你的开发环境。 1、CppUnit的lib和dll CppUnit为我们提供了两套框架库，一个为静态的lib，一个为动态的dll。 cppunit project：静态lib cppunit_dll project：动态dll和lib 在开发中我们可以根据实际情况作出选择。进入src文件夹，打开CppUnitLibraries.dsw。分别编译这两个project，输出位置均为lib文件夹。 另外一个需要关注的project是TestRunner，它输出一个dll，提供了一个基于GUI 方式的测试环境，即前面我们提到的两种测试环境之一。我们也需要编译这个project，输出位置亦为lib文件夹。 为了方便开发，我们把这些编译出来的lib和dll（包括Debug版和Release版） copy 到我们自己建立的一个文件夹中(当然你也可以不这么做)，例如F:/cppunit1.9.0/lib/，同时我们也把CppUnit源代码中include文件夹copy到我们自己的include文件夹下。然后在VC的tools/options/directories/include files和library files中设置include路径和lib路径。最后别忘了在你的project中link正确的lib。 2、在你的VC project中打开RTTI开关。 具体位置Project Settings/C++/C++ Language。 3、为TestRunner.dll设置环境变量 TestRunner.dll为我们提供了基于GUI的测试环境。为了让我们的测试程序能正确的调用它，TestRunner.dll必须位于你的测试程序的路径下。但最简单的方法是在操作系统的环境变量Path中添TestRunner.dll的路径，这样是最省事的。 四、你的第一个TDD example 一切准备就绪，现在我们可以来看看怎样添加测试代码了。前面我们提到过，CppUnit最小的测试单位是TestCase，多个相关TestCase组成一个TestSuite。要添加测试代码最简单的方法就是利用CppUnit为我们提供的几个宏来进行（当然还有其他的手工加入方法，但均是殊途同归，大家可以查阅CppUnit头文件中的演示代码）。这几个宏是： CPPUNIT_TEST_SUITE() 开始创建一个TestSuite CPPUNIT_TEST() 添加TestCase CPPUNIT_TEST_SUITE_END() 结束创建TestSuite CPPUNIT_TEST_SUITE_NAMED_REGISTRATION() 添加一个TestSuite到一个指定的TestFactoryRegistry工厂 感兴趣的朋友可以在HelperMacros.h看看这几个宏的声明，本文在此不做详述。 1、一个实现两个整数相加的类 假定我们要实现一个类，类名暂且取做CPlus，它的功能主要是实现两个数相加（多简单的一个类啊，这也要测试吗？不要紧，我们只是了解怎样加入测试代码来测试它就行了，所以越简单越好）。 假定这个类要实现的相加的方法是:
int Add(int nNum1, int nNum2);Ok，那我们先来写测试这个方法的代码吧。TDD 可是先写测试代码，后写产品代码(CPlus)的哦！先写的测试代码往往是不能运行或编译的，我们的目标是在写好测试代码后写产品代码，使之编译通过，然后再进行重构。这就是Kent Beck说的“red/green/refactor”( 还记得基于GUI的测试环境的状态条吗?)。所以，上面的类名和方法应该还只是在你的心里，还只是你的idea而已。 2、在VC中为测试代码建立一个 Project 通常，测试代码和被测试对象是处于不同的Project中的。这样就不会让你的产品代码被测试代码所“污染 ”。 在本例中，我们将建立一个基于GUI 方式的测试环境。在VC中，我们建立一个基于对话框的Project。别忘了link正确的lib，本例中我们使用静态的CppUnit lib。由于我们希望这个Project运行后显示的是图2这样的界面，所以我们需要在App的 Instance()中屏蔽掉原有的对话框，代之以CppUnit的GUI。
CppUnit::MfcUi::TestRunner runner; runner.addTest(PlusTest::suite()); //添加测试 runner.run(); //show UI /* CCPlusTestDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is // dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel } */ 前面我们提到过，TestRunner输出图2这样的对话框，这也是前面我们为什么要为TestRunner.dll的路径设置环境变量的原因。 注意：PlusTest::suite()返回一个指向CppUnit::Test的指针.这个指针就是整个测试的起点。CppUnit::TestFactoryRegistry::getRegistry()根据TestSuite的名字返回TestFactoryRegistry工厂，然后调用工厂里的makeTest()对TestSuite进行组装,这是个递归调用，将建立起一个树状的测试结构。 namespace PlusTest { CppUnit::Test* suite() { CppUnit::TestFactoryRegistry ®istry = CppUnit::TestFactoryRegistry::getRegistry(plusSuiteName()); return registry.makeTest(); } } 另外别忘加头文件： #include "CPlusTestSuite.h"3、在Project中加入一个类，取名CPlusTestCase CPlusTestCase从CppUnit::TestCase继承，代码如下：
#include <cppunit/ui/mfc/TestRunner.h>
#include <cppunit/extensions/TestFactoryRegistry.h>
class CPlusTestCase : public CppUnit::TestCase { CPPUNIT_TEST_SUITE(CPlusTestCase); CPPUNIT_TEST(testAdd); CPPUNIT_TEST_SUITE_END(); public: CPlusTestCase(); virtual ~CPlusTestCase(); void testAdd(); //测试方法 }; 看到这几个宏了吗？它们可是在这大显身手了一把。 CPPUNIT_TEST_SUITE(CPlusTestCase); CPPUNIT_TEST( testAdd ); CPPUNIT_TEST_SUITE_END(); 通过这几个宏，我们就把CPlusTestCase和testAdd注册到了测试列表当中。 另外，我们需要在Cpp文件中加入另外一个宏： CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(CPlusTestCase,PlusTest::plusSuiteName() );它将CPlusTestCase这个TestSuite注册到一个指定的TestFactory工厂中，这个TestSuite用 PlusTest::plusSuiteName()函数返回的名字来标识（前面介绍的suite()函数中就是通过这个名字来获取这个工厂的）。plusSuiteName()是PlusTest这个namespace下的一个函数，它返回我们为这个TestSuite建立的名字（本例我们取名为“plus”）。其实我们也可以不用这么做，直接在宏里写入“plus“即可。但是这样可以防止硬编码带来的麻烦。 在测试类中，我们添加了一个测试方法：
void testAdd();它测试的对象是前面提到的CPlus类的方法：
int Add(int nNum1, int nNum2);我们来看看它的实现：
void CPlusTestCase::testAdd() { CPlus plus; int nResult = plus.Add(10, 20); //执行Add操作 CPPUNIT_ASSERT_EQUAL(30, nResult); //检查结果是否等于30 } CPPUNIT_ASSERT_EQUAL是一个判断结果的宏。CppUnit中类似的其它宏请查阅TestAssert.h，本文在此不做详述 。 另外，我们还可以覆写基类的 setUp()、tearDown()两个函数。这两个函数实际上是一个模板方法，在测试运行之前会调用setUp()以进行一些初始化的工作，测试结束之后又会调用tearDown()来做一些“善后工作” ，比如资源的回收等等。当然，你也可以不覆写这两个函数，因为它们在基类里定义成了空方法，而不是纯虚函数。 另外，Cpp中要加入头文件： #include "plusSuite.h"4、根据测试代码编写产品代码 编写完上面的测试代码后，进行编译。编译肯定通不过，编译器会告诉我们CPlus类没有声明，因为我们还没有实现CPlus类呢！现在的工作就是马上实现CPlus类，让编译通过。现在你应该嗅到一点“测试驱动“的味道了吧？ 在VC中建立一个MFC Extension Dll的Project，在这个Project 中加入类CPlus,它的声明如下：
class AFX_EXT_CLASS CPlus { public: CPlus(); virtual ~CPlus();
public: int Add(int nNum1, int nNum2); }; 仅有一个方法，就是我们的测试代码要测试的那个方法。来看看它的实现：
int CPlus::Add(int nNum1, int nNum2) { return nNum1+nNum2; } 非常简单，不是吗？现在让前面那个包含测试代码的Project dependent这个Project,include 相关头文件 ,Rebuild All，你会发现编译已通过。你体会到了测试代码驱动产品代码了吗？当然我们的这个例子还很简单 ，没有重构这一步骤。 运行我们的测试程序，你就会看到如图6的界面: 
图6
图7
