在建行新一代核心系统建设中，非功能测试为建行数百个系统的高效性能保驾护航，但非功能测试案例的执行仍处于手动执行阶段，目前还没有显著提高测试执行效率的方法。手动执行存在着几大问题：一是手动执行需要测试人员全程跟踪，对于需要经常恢复数据的交易操作繁琐；二是面对测试版本的频繁更新，测试人员需要进行多次回归测试，手动执行的复杂操作尚不能做到快速回归；三是测试案例执行结果和监控结果较多，手工收集整理工作量大。
鉴于以上问题，本文基于流程化的测试案例执行过程，以新一代系统非功能测试标准案例为基础，以自动化测试为导向，提出了一种可视化的案例自动执行的方法，研究并开发相应的非功能测试自动执行工具。解决了现有手动执行需要人员全程跟踪、不能迅速回归测试、收集结果工作量大的问题，以人性化的界面和简单易用的操作，帮助测试人员节省测试执行时间，提高工作效率。
本文的研究重点包括LoadRunner Automation API的研究使用、场景的自动生成、一键式nmon部署、性能容量案例自动执行、可用性和可维护性案例自动执行、自动结果收集功能实现、可视化交互设计、软件设计与开发等。
关键词：LoadRunner 非功能测试 测试案例 性能容量测试 可用性和可维护性测试
目 录
1 绪论 2
1.1 研究背景 2
1.2 研究意义 2
1.3 研究内容 3
1.4 论文结构 4
2 非功能测试技术理论及LoadRunner Automation API 5
2.1 非功能测试介绍 5
2.1.1 非功能测试的概念 5
2.1.2 非功能测试流程 7
2.1.3 测试案例的主要执行步骤 8
2.2 LoadRunner Automation API的研究使用 10
2.2.1 LoadRunner软件概述 10
2.2.2 LoadRunner Automation API概述 10
2.2.3 基于.net框架的项目配置 10
2.2.4 场景配置与场景控制 11
2.2.5 场景的启停 13
2.2.6 运行结果收集 14
3 可视化自动执行工具的需求、设计 15
3.1 软件需求 15
3.2 功能设计 15
3.3 类设计 18
4 可视化自动执行工具的实现 21
4.1 界面设计 21
4.2 场景配置模块设计 22
4.3 环境列表模块实现 22
4.4 案例自动执行模块实现 24
5 总结与展望 29
5.1 总结 29
5.2 展望及改进建议 30
致谢 32
1绪论
1.1研究背景
众所周知，我行在确保安全稳定运行的基础上，重点推出了“新一代核心系统”建设。“新一代核心系统”是对我行当前应用系统的一次全面重构，目标是建立起统一集中的信息技术平台，建立起保障业务创新、流程再造、技术革新的长效机制，支撑和引领未来综合性、多功能、集约化经营。以此助力实现建设银行“国内最佳、国际一流”的发展愿景。
随着我行“新一代核心系统”建设工作的逐步展开，大量针对老系统改造和新系统的测试工作也紧锣密鼓的进行着。在这个前所未有的紧张时刻，非功能测试作为软件测试工作的重要部分，肩负起了为建行数百个系统的高效性能保驾护航的重任。
非功能测试是针对非功能性需求进行的测试和验证。非功能性需求指的是软件产品为满足业务需求而必须具有且除功能需求以外的特性。非功能需求一般包括系统的性能、容量、可用性、可维护性和可扩展性等。而非功能测试团队工作的主要内容也正是确保系统上述特性满足设计要求。一个项目的非功能测试过程包括项目调研并编写测试方案和测试案例、方案案例评审、测试实施、测试报告编写，报告评审等步骤。其中测试实施占非功能测试总时长的90%以上。非功能测试实施包含很多类型的案例，例如单交易基准、单交易负载、容量、稳定性等性能容量测试、一键式启停等可用性和可维护性测试案例等等。目前的测试实施工作仍然是由测试人员一步一步手动执行的，往往需要借助测试工具或者开发测试脚本，模拟执行典型的用户行为，监控关键性测试结果是否符合能够达到期望的目标。在实际执行时，要求首先启动监控，确定测试场景。在测试实施过程中，测试人员就需要按照测试场景的要求，使用压力发起工具发起压力，从而模拟生产上的日常或高峰时段业务运行情况。执行结束后收集执行结果和监控结果，观察系统性能是否满足指标要求。
1.2研究意义
目前，非功能测试案例的执行仍然处于手动执行阶段，还没有可以显著提高测试执行效率的方法。手动执行案例存在着以下问题：
（1）手动执行需要测试人员全程跟踪，不能充分利用测试人员的工作时间，且虽然是测试工具在执行测试案例，但是我们却不能有效利用下班时间进行案例执行。
（2）在测试过程中，我们经常会遇到需要频繁恢复数据的交易。手动执行对于这类交易操作繁琐，需要人工不停地隔一段时间恢复一次数据。
（3）由于非功能测试执行中发现的很多系统问题需要修改代码来解决，这时就会发生版本变更，而版本频繁更新需要做多次回归测试。手动执行的复杂操作不能做到快速回归。
（4）在非功能测试执行结束后，我们一般需要整理测试执行结果、监控的资源使用情况以及一些执行命令的截图等用于编制报告。手工收集整理这些结果资料工作量较大。
为解决上述问题，本课题提出了一种可视化的案例自动执行的方法，并开发相应的测试执行工具。来帮助测试人员摆脱手工执行测试案例带来的诸多烦恼。通过本自动执行工具使得测试人员能够解放双手双眼，不必总盯着执行过程，将时间用到别的工作上去。同时，本文工具将代替测试人员自动恢复交易数据，并且能够在下班时间执行测试案例，测试人员只需要在早上上班后整理测试结果，进行进一步的分析和处理。充分节省测试执行时间，有效提高工作效率。
1.3研究内容
本文将主要从测试实施工作和辅助测试工具两个角度，探讨使用本文工具帮助测试实施工作的构想以及实行情况。
一方面介绍现有方法完成测试实施工作的过程，调研各测试工作人员执行过程中的痛点，总结其不足和可以改进的地方。
另一方面，充分分析对现有方法改进的可行性，提出本文的工具设想。开发基于人性化的界面，讨论软件工具的设计与实现。包括软件需求、功能设计、类设计、界面设计等内容。
本文的主要研究内容包括：
（1）实现非功能测试场景设计，实现对环境列表中所有服务器一键式部署Nmon并可视化地显示部署进度，同时提供自动检查部署成功与否的功能，生成检查报告和问题修复建议。
（2）研究性能容量测试、可用性测试和可维护性测试案例执行步骤的共性和个性，实现案例的一键式执行，同时可对每个执行步骤单独执行（自动启停监控、自动LoadRunner场景执行，定时shell脚本执行）。
（3）支持常用的性能、可用性和可维护性测试标准案例，支持可扩展的测试案例以及可定制的案例执行步骤。
（4）支持执行过程中需要穿插命令或恢复数据的案例。
（5）实现案例复用和迅速回归测试，支持案例维度的断点续跑。
（6）实时显示并辅助测试人员收集测试结果和资源使用趋势图，作为测试报告编制的原数据。
1.4论文结构
本论文共分为五章。
第一章，绪论（即本章）。介绍论文的研究背景、研究意义、研究内容以及论文的组织结构。
第二章，非功能测试技术理论综述以及LoadRunner Automation API的概述与研究。介绍我行北开非功能测试工作流程现状及本文工具开发需要的技术理论基础。
第三章，可视化自动执行工具的需求与设计。介绍本文工具的软件需求、功能设计、类设计等。
第四章，可视化自动执行工具的实现。介绍本文工具的界面、场景配置模块、环境列表模块、案例自动执行模块的设计与实现。
第五章，总结与展望。总结软件运行效果和用户使用效果，评价其可以发挥的作用。指出不足，提出未来的改进方向和工作展望。
2非功能测试技术理论及LoadRunner Automation API
2.1非功能测试介绍
2.1.1非功能测试的概念
我行测试部门涉及的工作包括测试任务实施、测试管理、测试工具研究、测试环境与版本管理四大部分。
具体工作内容如下图所示：
图1.测试部门整体工作图
在我行北开非功能测试部门《非功能测试实施管理细则》中，非功能测试定义为“非功能测试工作主要是指系统性能测试、可靠性测试及其它与系统非功能性特征相关的专项测试工作”。针对一个被测系统，非功能测试分为组件绿灯测试、组件组装非功能测试、应用组装非功能测试、应用总装非功能测试和版本检验非功能测试五部分。具体测试内容如下图所示：
图2. 非功能测试工序图
如上图所示，非功能测试实施包括性能容量测试、性能诊断测试、性能调优测试、性能拓展性测试、软件可靠性测试、系统容错性测试等。
性能容量测试：通过测试分析获取应用软件系统在特定的测试环境中应用性能指标值，如最大并发用户数、联机交易处理能力、数据库记录数等。同时要保证应用系统在负载状态下没有出现任何软件故障，并保持主要功能正常运行，判定软件系统是否满足预期的性能需求。
性能诊断测试：寻找系统可能存在的性能问题，定位性能瓶颈并解决问题。
性能调优测试：通过进行测试验证，对系统参数和配置进行调整，提高系统性能。
性能拓展性测试：验证系统的性能扩展能力，找出扩展系统能力的要素，给出扩展系统性能的建议。
软件可靠性测试：指软件的可靠性评估，根据软件系统可靠性结构、寿命类型和、各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。
系统容错性测试：主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
非功能测试主要参考的指标包括：TPS、平均响应时间、并发用户数、资源使用率。
TPS：Transaction Per Second，即每秒交易量，系统每秒完成的交易数目。TPS的值直接反映了系统的处理能力。
平均响应时间：系统对请求作出响应所需要的平均时间。
并发用户数：用虚拟用户模拟真实用户的操作行为，依靠脚本对系统进行操作访问，观察系统在不同虚拟用户数下的性能表现。测试中使用的虚拟用户数量，就是我们说的并发用户数的概念。这种并发的概念通常在性能测试（Performance Testing）方法中使用，用于从业务的角度模拟真实的用户访问，体现的是业务并发用户数。
资源使用率：运行程序期间，系统的资源使用情况，包括CPU、内存、IO等等。
2.1.2非功能测试流程
非功能测试在整个测试过程中的工作时序如下图所示：非功能测试紧跟功能测试之后，按照顺序依次进行组件组装、应用组装、应用总装、版本检验非功能测试。
图3. 非功能测试整体时序图
以组件组装非功能测试为例，测试流程如下图所示：
主要分为三个阶段：准备阶段、实施阶段和收尾阶段。在准备阶段中，一般包括测试需求分析（测试目的、测试范围、测试系统非功能指标、测试系统业务场景分析等）、测试方案设计（测试环境设计、测试指标设计、测试方法设计、测试数据使用方案设计和测试方案编写等）、测试案例设计、环境及工具确认、测试数据准备、测试脚本开发、绿灯测试（交易调试及测试数据验证）；在实施阶段，一般包括测试案例执行、记录测试结果、提交缺陷、测试报告编写与评审。在收尾阶段，主要包括撰写非功能测试档案和资产归档。
图4. 非功能组件组装测试工作流程图
2.1.3测试案例的主要执行步骤
在测试案例实施阶段，性能容量测试按照进行的先后顺序，由以下五部分构成：
单交易基准测试：针对每支选定的交易或操作，在系统无压力的情况下，单个用户迭代若干次，获取每个交易或操作的平均响应时间，以此作为多用户并发测试的基准。
单交易负载测试：在完成单交易基准测试后，针对测试模型中每一支交易或每一个操作，采用多个（5-10，视具体情况而定）虚拟用户数进行负载测试，获取其业务处理性能和系统资源利用率等数据，并验证交易是否存在并发性问题。
混合负载测试：在既定的测试模型下，在给定的测试限制条件下，通过在被测系统上逐步增加并发用户数，梯度增加压力，获得系统诸如响应时间、吞吐量、CPU和内存使用等性能数据，确定在各种工作负载下系统的性能指标，直到达到或突破限定条件，获取在不同压力下的性能表现，并获取交易的TPS、响应时间，系统资源利用率等指标数据。然后，经过测试分析获取应用系统在该测试环境下的最大处理能力。
稳定性测试：一般是根据混合场景负载测试结果，采用系容量统峰值60%-80%的压力负载，稳定运行8～12个小时（根据5*8或7*24的系统业务特征而定），检验应用系统在测试环境下的稳定运行能力，获取系统长时间运行的稳定性指标。
极限负载测试：极限负载测试是在不考虑限定条件的情况下，在一定的测试环境中，获取单交易或者混合场景在极限或苛刻的环境中系统的性能表现，关注是系统在超越极限后的表现，测试过程中不必严格按照梯度增加的方法。
在性能测试通过之后，将执行可用性和可维护性测试案例，一般包括超时有效性、RAC有效性测试、服务一键式启停测试、集群有效性测试等。
以日间批处理集群有效性-停服务为例，测试执行步骤包括：
1、选取一般交易日测试场景，以被测试系统最大处理能力的50%作为负载压力向被测试系统施压；日间批处理交易保持运行状态；
2、场景交易稳定运行5~10分钟左右，在日间批处理集群上手工停一台AP应用服务或kill -9 应用进程；
3、手工停止一个节点后，观察日间批处理交易是否切换到备用的日间批处理服务器上；观察场景联机交易是否收到影响；
4、恢复被停日间批处理AP的服务或重起被停的进程后，场景继续稳定运行10~15分钟，观察交易运行情况情况；
5、场景测试结束，分析和记录测试结果数据。
2.2LoadRunner Automation API的研究使用
2.2.1LoadRunner软件概述
LoadRunner 是一种适用于各种体系架构的，预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过模拟实际用户的操作行为和实行实时性能监测，帮助用户更快的查找和发现问题。它能预测系统行为并优化系统性能，加速应用系统的发布周期。
我行非功能测试使用LoadRunner作为测试工具，通过脚本模拟真实用户的行为，执行LoadRunner场景对被测系统发起并发压力。通过分析TPS、平均响应时间等指标，以及结合系统CPU、内存等资源利用率，评价被测系统的性能，并对测试中出现的错误报告进行分析，定位和解决问题。
2.2.2LoadRunner Automation API概述
LoadRunner通过在Virtual User Generator中编写LoadRunner脚本来模拟对系统的业务操作；通过在Controller中配置和执行LoadRunner场景来对被测系统发起压力；通过Analysis分析由LoadRunner自动收集的测试结果和数据。
LoadRunner Automation API允许不通过LoadRunner Controller图形用户界面就能够执行测试场景（Scenario）。通过LoadRunner Automation API可以在应用程序代码中定义和执行场景。
本文讨论的是一种自动配置和执行LoadRunner场景的工具，而这种自动配置和执行功能正是LoadRunner Automation API所能够提供的。因此，工具的自动配置、执行和结果收集功能均通过LoadRunner Automation API来实现。整个API的核心对象是LrEngine。在创建LrEngine之后，应用程序可以连接到LoadRunner Controller的一个实例，或者创建一个LoadRunner Controller实例。
在程序设计中，可通过LrEngine对象来访问Scenario对象，在Scenario对象中配置场景的各种参数，控制场景执行，收集执行信息。
2.2.3基于.net框架的项目配置
在Windows平台上安装LoadRunner之后，执行loadrunner\bin目录下的regtlb.exe来注册wlrun.tlb库。使用如下DOS命令：regtlb.exe "d:\loadrunner\bin\wlrun.tlb"。
本论文所述的非功能测试场景自动化交易配比工具使用基于.net框架的C#语言开发。开发工具选用Microsoft Visual Studio 2010。点击“项目”->“添加引用”来添加LoadRunner Automation Library，名称为Wlrun。在代码中，添加using Wlrun，即可调用LoadRunner Automation API中的有关函数。
2.2.4场景配置与场景控制
（一）LrScenario配置
首先新建LrEngine并获取LrScenario的对象：
LrEngine _engine = new LrEngine();
判断Controller是否被打开：
_engine.Scenario.IsOpened()
判断Controller是否正在运行：
_engine.Scenario.DidScenarioRun()
上述条件检查完毕后，新建场景：
_engine.Scenario.New(true, LrScenarioType.lrVusers);
然后清理场景并设置场景的输出目录、是否覆盖等。由于本工具进行场景配置仅仅是为了试验参数配置的效果，故使用一个临时的输出目录，并覆盖结果。
_engine.Scenario.RemoveAllOutputMessages();
_engine.Scenario.ResultDir = "temp";
_engine.Scenario.SetAttrib(LrScAttribs.lrScAutoOverwriteResult, 1);
（二）LrGroup配置
首先添加脚本，通过传入一个脚本名及其对应的脚本路径：
_engine.Scenario.Scripts.Add(scriptPath, ref scriptName);
然后添加压力发生器。本工具中的压力发生器是可配置的，如使用本机，loadGen的值为“localhost”。调用Connect函数连接压力发生器。
_engine.Scenario.Hosts.Add(loadGen, LrHostPlatform.lrWINDOWS);
LrHost loadGenHost = _engine.Scenario.Hosts.Item[loadGen];
loadGenHost.Connect();
最后通过组名、脚本名、压力发生器、Vu数量4个参数来添加LrGroup到LrScenario中，从而完成LoadRunner场景的组配置，即初步完成各交易的配置。
_engine.Scenario.Groups.Add(groupName);
LrGroup lrGroup = _engine.Scenario.Groups.Item[groupName];
lrGroup.AddVusers(scriptName, loadGen, numOfVusers);
在这里我们就可以通过设置Vu数量来对交易配比进行控制了。
（三）Run-time Settings配置
工具需要通过LoadRunner Automation API来关闭Log、取消Think Time和设置Pacing。由于LoadRunner场景中每个LrGroup的运行时配置是存储在一个键值对形式的字符串中，因此需要首先获取当前配置，包括Run-time Settings（rts）和Action Logic（actionLogic）。通过下面语句：
string rts = "", actionLogic = "";
lrGroup.GetRunTimeSettings(ref rts, ref actionLogic);
获取得到的rts和actionLogic内容分别如下表所示：
表1. Run-time Settings（rts）和Action Logic（actionLogic）字符串内容
Run-time Settings（rts） Action Logic（actionLogic）
[Iterations]\r\nRandomMax="90"\r\nRandomMin="60"\r\nIterationPace="IterationASAP"\r\nStartEvery="60"\r\nNumOfIterations="1"\r\n[General]\r\nAutomaticTransactions=0\r\nContinueOnError=0\r\nautomatic_nested_transactions="1"\r\nXlBridgeTimeout="120"\r\nUseThreads=1\r\niter_ends_val=fixed\r\nDefaultRunLogic="uspM4d.445"\r\nAutomaticTransactionsPerFunc=0\r\niter_begins_val=fixed\r\nFailTransOnErrorMsg=0\r\n[FILTERS]\r\nIncludeFiltersInList=\r\nFilterType=0\r\n[Log]\r\nLogDetail=0\r\nMsgClassParameters=0\r\nMsgClassData=0\r\nLogOptions=LogDisabled\r\nMsgClassFull=0\r\nAutoLog=0\r\n[ThinkTime]\r\nOptions=NOTHINK\r\nFactor=1.000000\r\nThinkTimeRandomHigh=150\r\nThinkTimeRandomLow=50\r\nLimit=1\r\nLimitFlag=0\r\n [RunLogicRunRoot]\r\n
RunLogicPaceConstTime="60.000"\r\n
RunLogicRandomPaceMax="90.000"\r\n
RunLogicActionOrder="Action"\r\n
RunLogicAfterPaceMax="90.000"\r\n
MercIniTreeFather=""\r\n
RunLogicPaceType="ConstAfter"\r\n
MercIniTreeSons="Action"\r\n
RunLogicNumOfIterations="1"\r\n
RunLogicAfterPaceMin="60.000"\r\n
Name="Run"\r\n
RunLogicPaceConstAfterTime="0.00"\r\n
RunLogicRunMode="Sequential"\r\n
RunLogicObjectKind="Group"\r\n
RunLogicActionType="VuserRun"\r\n
RunLogicRandomPaceMin="60.000"\r\n
MercIniTreeSectionName="RunLogicRunRoot"\r\n
需要配置的内容包括Run-time Settings中的LogOptions（设置为LogDisabled）和Options（设置为NOTHINK），还包括Action Logic中的RunLogicPaceType（设置为ConstAfter）和RunLogicPaceConstAfterTime（设置为我们需要的Pacing）。这样就可以通过设置Pacing来调整交易配比了。
字符串修改完成后，通过下面语句使配置生效：
lrGroup.SetRunTimeSettings(rts, actionLogic);
（四）Scenario Schedule配置
为了能够同时启动所有Vu，又为了能够设置场景的执行时间，需要通过LoadRunner Automation API来对LoadRunner场景进行Scenario Schedule配置。
要达到第一个目的，我们需要将默认的Real-world Schedule改为Basic Schedule。
通过调用_engine.Scenario.ManualScheduler.get_Schedule("schedule")来获取一个LrManualScheduleData对象，再通过调用LrManualScheduleData对象的GetScheduleData(out scheduleXML, out errStr)方法获取具有XML内容的string，修改此XML即可完成Scenario Schedule配置。
通过XML中的路径LoadTest->Schedulers->Scheduler->Manual->Global->Scheduling来找到我们要修改的XML内容，改为如下表所示的内容，即可将Run Mode设置为Basic Schedule。
表2. 将Run Mode设置为Basic Schedule所需的XML
<Scheduling>
<IsDefaultScheduler>true</IsDefaultScheduler>
<IsClassicScheduler>true</IsClassicScheduler>
<DynamicScheduling>
<RunAll>
<StartCondition>
<PrevAction />
</StartCondition>
</RunAll>
<Duration>
<StartCondition>
<PrevAction />
</StartCondition>
<RunFor>300</RunFor>
</Duration>
<StopAll>
<StartCondition>
<PrevAction />
</StartCondition>
</StopAll>
</DynamicScheduling>
</Scheduling>
将XML中的RunFor节点中的值设置为需要的场景执行时间（秒），即可完成场景执行时间设置。
通过调用LrManualScheduleData对象的scheduleData.SetScheduleData(scheduleXML, out errStr)方法，并通过调用_engine.Scenario.ManualScheduler.SetCurrentSchedule("schedule")来完成设置。
2.2.5场景的启停
使用下面语句运行场景：
_engine.Scenario.Start ();
使用下面语句停止 / 立即停止场景：
_engine.Scenario.Stop (); / _engine.Scenario.StopNow();
2.2.6运行结果收集
当场景正在运行时，通过下面语句获取运行时各交易的统计信息：
string statisticsDetails = "";
_engine.Scenario.GetTransactionStatisticsDetails(out statisticsDetails);
获取到的统计信息为XML形式。本交易配比工具中主要通过匹配各个Transaction的name属性，获取其TPS属性的值。
表3. 场景运行时获取到的各交易统计信息
<TransactionsDetails>
<Transaction name="search" TPS="1.48" Passed="37" Failed="0" Stopped="0" />
<Transaction name="Action_Transaction" TPS="4.04" Passed="101" Failed="0" Stopped="0" />
<Transaction name="vuser_init_Transaction" TPS="0.08" Passed="2" Failed="0" Stopped="0" />
<Transaction name="list_letter_a" TPS="2.56" Passed="64" Failed="0" Stopped="0" />
</TransactionsDetails>
3可视化自动执行工具的需求、设计
3.1软件需求
本文工具主要是通过自动代替手动来执行非功能测试案例，包括场景设计、环境列表、服务器一键式Nmon部署，案例自动执行等。其中场景设计和服务器一键式部署Nmon是案例自动执行的前提，即在执行案例之前，需先添加案例覆盖的交易，填写各交易需要定期恢复数据的脚本，从而设计案例执行场景。再添加测试环境的服务器列表，并对每台服务器部署监控工具Nmon。最后选择一个或多个不同的测试案例，包括单交易基准、负载、容量、稳定性、可用性、可维护性案例等（需要说明的是，本文的自动执行工具不是可以执行所有的非功能测试案例，对于需要环境组配合的测试案例，例如宕机、宕网卡这种需要特殊权限的案例，本文工具还无法执行），点击“执行”，能够帮助测试人员一键式执行测试案例，测试人员不必像手动执行案例时一直待在电脑前，直至案例执行结束。真正做到无人值守。
除此之外，为了测试方便，本文工具也支持对案例步骤中的单个步骤的执行，包括启停监控、启停LoadRunner场景、启停shell脚本等。本文工具不仅包含测试常用的标准化案例，还提供了自定义测试案例和自定义案例执行步骤，方便测试人员开发更多的测试案例，使得非功能测试更加充分。同时为了方便测试人员复用案例执行回归测试，本文工具也提供了测试案例全部执行步骤的保存与加载功能。最后为了帮助非功能测试人员快速上手，本文工具开发简洁易用的用户界面，提供可视化的结果展示界面，帮助测试人员快速定位执行过程中出现的问题，从而高效率地利用工具完成测试案例的执行。
3.2功能设计
本文工具的设计时在充分分析性能容量测试和高可用测试案例执行步骤的共性和个性的前提下，制定出案例自动执行步骤的通用模板。
依据软件需求，设计出软件四个模块的功能：
（1）测试场景设计模块：实现打开场景、保存场景、添加脚本、删除脚本、添加交易恢复脚本等功能。界面设计上通过放置一张可编辑列表以及有关功能按钮来实现。测试场景是由多个Group组成，每个Group代表一种交易。每个Group带有一个脚本，需要配置脚本路径、压力发生器和Transaction名。
（2）环境列表模块：实现添加服务器，删除服务器，保存环境列表、打开环境列表、一键部署Nmon、配置检查等功能。界面设计上通过放置一张可编辑的列表及相关功能按钮来实现。环境列表包含IP地址、用户名、密码、系统类型、协议类型、服务器类型等字段。其中系统类型包括Linux、HP-UX、AIX三种。“一键部署Nmon”按钮可实现在列表中所有未部署Nmon的服务器上部署Nmon，并以拓扑图的形式显示安装部署的进度。“配置检查”按钮可帮助检查当前环境列表中所有服务器是否已完成监控工具Nmon的部署安装。需要说明的是：在一个测试项目中，该模块只需使用一次，即可在案例执行模块选择相应的服务器IP进行测试相关的工作。
（3）案例自动执行模块：针对整个案例列表，实现保存和打开所有案例脚本、新增案例、自选案例、一键执行、一键停止等功能。新增案例功能使得测试人员可以增加标准案例集以外的测试案例，实现可扩展的测试案例。自选案例功能使得测试人员可以选择多个测试案例显示在案例列表中，从而一键式顺序执行。一键执行功能实现顺序执行案例列表中显示的所有案例。
针对单个案例，实现单案例执行、停止、新增shell脚本以及单独执行每个测试步骤的功能。所有案例分成三种案例执行模板，即单交易基准模板、单交易负载模板和其他测试案例模板。单交易基准、负载模板包含选择场景功能、填写参数、执行和停止按钮，页面中间显示场景交易脚本列表。其他测试案例模板包含三+N个执行步骤，分别是启动监控、LoadRunner场景执行、定期执行shell脚本（1+N个）。其他测试案例包含新增定期执行shell脚本的功能，此功能可实现可定制的案例执行步骤。
（4）测试结果展示模块：实现可视化的结果展示界面，包括各服务器CPU资源使用趋势图等，帮助测试人员尽早发现资源瓶颈。
四大模块及相关功能如下图所示：
