2023年7月16日发(作者：)

软件测试课程实验——稳定性、破坏性压力测试文档

一、实验介绍与目的

本次实验要求通过 LoadRunner对已经完成的自有系统进行性能测试和稳定性、破坏性压力测试。

本次实验的目的在于下列几点，请注意，这也将会作为期末考核演示的评分点：

1、通过实践课程所学，了解性能测试与压力测试的意义。

2、掌握 LoadRunner的基本功能部件的使用方法，包括VuGen，Controller和Analysis。

3、尝试进行有针对性的性能测试与稳定性、破坏性压力测试，其中包括进行测试计划与策略的制定，测试用例（场景与操作脚本）的设计等。

4、依赖测试结果，尝试对被测系统的性能状况（容量与瓶颈）进行分析以及鼓励提出调优的方案。

5、锻炼测试工作组织分配能力与文档编写表达能力。

二、实验原理

本次进行的实验是关于对已经完成的自有系统的性能与稳定性、破坏性压力测试（稳定性压力测试、破坏性压力测试）。

首先必须明白性能测试与稳定性、破坏性压力测试的定义、意义和方法，需要注意的是，性能测试的关注点在于，对系统在不同的负载情况下，获取各个方面的性能参数，如响应时间，CPU占用率，内存占用率；另一方面，压力测试的关注点在于，以长时间恒定负载或以特定时间内的反常负载加载到系统上，以观察其稳定性。

其次，我们需要了解 LoadRunner的性能与稳定性、破坏性压力测试工具的基本使用方法。LoadRunner主要依赖于三个功能部件，实现对各种具有不同交互协议的系统的性能与压力测试。

第一步，通过VuGen录制或编写Virtual User的操作脚本。LoadRunner将测试的层次定义在了虚拟用户交互之上，并为此提供了相关的机制，即任意多个Virtual User的对象，根据预先定义好的脚本，模拟对系统进行交互。我们可以通过录制用例，并且将当中不同的子操作定制为Action。完成录制后，我们可以将其回放以验证，此时可以选择当中的Action并且定义他们的顺序。对于需要添加不同类型的参数，或者需要增加特定功能的测试情况，我们可以添加参数设置，或根据其提供的API直接修改脚本来满足我们的需求。选择并确定好所需要的操作脚本后，即可进入模拟执行脚本的步骤。

第二步，通过Controller模拟实际的交互条件。LoadRunner将一次交互模拟定义为场景（Scenario），通过Controller的Design卡片，我们可以对每一个场景定义其中的虚拟用户数量，并发访问程度，虚拟用户访问脚本，Action的顺序及迭代次数等等。设置完毕后，可以通过Run卡片控制执行测试，并且实时观察相关信息，如虚拟用户的运行状态，预先设置的性能参数图表等等 。如果需要保存，输出并格式化运行的结果数据，我们可以调用结果分析部件Analysis。

第三步，通过Analysis对当前导入的运行结果进行保存和进一步的处理。Analysis可以对当前的测试数据绘制报告，增加和修改图表等功能，大大地方便了对测试结果的发布，汇报和标准化的管理。

我们使用通过 LoadRunner上述的三个主要的功能可以完成性能与压力的测试执行工作，但是测试策略与计划的制定，测试用例（包括单个虚拟用户的操作脚本以及多个用户并发时的访问情况）的设计都需要同学们去思考和实现，根据测试结果作为证据推断分析系统的瓶颈所在。

三、实验步骤参考与操作技巧

1、制定测试计划、设计测试用例，包括人员任务的分配，选择测试的具体流程对象，如何录制操作脚本和加工操作脚本，选择测试需要采集的系统性能参数，采用何种策略通过测试定位系统的瓶颈，如何找出系统的容量（如并发数，吞吐量等），如何定义一组合适的场景，如何设计特定的并发并模拟等等。

2、启动测试对象。启动已经完成的自有系统。

3、使用VuGen录制脚本，将不同的操作归类到相应的Action之中。根据测试用例的要求，如需要，加工脚本，如添加参数，分配参数到虚拟用户等。

4、使用Controller执行测试。可设置如下参数，如Action在场景中的顺序，相关的并发模拟参数，所需观察的虚拟用户状态以及系统性能图表等，然后运行测试，观察结果。

5、使用Analysis分析测试结果。可加工相应的图表，最后导出报告，作为其中提交成果的一部分。

6、通过Analysis的结果分析，表述系统在一次场景中的表现及其原因，归纳一组多个场景的表现，尝试判断系统的瓶颈所在与容量。

关于操作的技巧详情，可参见实验材料包中的References/loadrunner演示视频.avi。

Ps：最好是从VuGen修改好了脚本以后直接打开Controller，如果需要再修改脚本，请先关闭Controller。

四、例子：如何录制脚本与定制场景

下面将会讲解演示两个压力测试的例子，一个对登录功能的测试，另一个是对订票功能的测试。这里，我们会采用一些技巧，即录制一次然后调整里面的Action就可以进行两次不同的测试。

首先，我们需要清楚，是否需要为每一项功能都录制一次操作脚本？实际上，每一个操作脚本都包含了三部分，即前置条件，功能操作与后置条件；特别地，除注册功能以外的绝大部分功能都需要以成功登录为前置条件，甚至是退出系统为后置条件。因此，大部分的录制当中就会包含了重复的前置或者是后置条件了，这将大大地增加工作量和降低了工作效率。

LoadRunner的机制为我们提供了方便。我们只需要一次的录制和执行时的操作顺序与迭代配置，就可以完成对多个功能的不同操作组合的脚本定制。在一次录制中，我们可以把一组具有相同前置与后置条件的测试的操作，录制到相应的Action之中，而将前置与后置条件，分别录制到vuser_init和vuser_end两个Action之中。在对某一功能进行测试之前，只需选择与该功能相关的任意个Action进行顺序编排和迭代设置（甚至是嵌套迭代），即可完成实现该功能的操作脚本定制。特别地，我们也可以只对前置条件或后置条件单独地进行测试。

用我们的例子而言，我们可以进行一次这样的录制：

1、从Action vuser_init开始录制，录制用户成功登录到系统的操作。

2、然后新建一个Action bookticket来录制用户订票功能（订票成功并返回到用户欢迎界面）。

3、然后新建一个Action checkticket来录制用户的查询功能（查询成功并返回到用户欢迎界面）。

4、最后将退出系统的操作，录制到Action vuser_end之中，并结束录制。 这时，我们会发现已经存在着4个Action，其中vuser_init和vuser_end是另外两个Action共同的前置与后置条件。现在，我们保存这一用例文件，并以此打开Controller执行我们的测试。

在Controller中，我们可以在Design卡片里面单击Runtime

settings按钮，其中的Run logic就会清楚地描述Action执行的顺序与迭代情况，只需要通过上移、下移、插入和删除Action等操作就可以编排你所需要的操作执行顺序和迭代区域与次数，更重要的是，我们不需要关注前置与后置条件了，LoadRunner将会自动为我们完成，当然也可以只留下前置与后置条件。

现在我们再介绍一下参数设置的做法。假设现在我们需要在登录的测试中，使用多个用户的登录信息，包括他们的用户名与密码。我们可以这样处理：找到脚本中的记录相关登录信息的位置，将其replace为一个新建的参数（Param），并且选定其类型。详细的操作请查看References/loadrunner演示视频.avi。

六、实验要求

1、各组根据上述的测试步骤提要，通过 LoadRunner独立完成对已经完成的自有系统的性能与稳定性、破坏性压力测试。要求小组每个人都要完成2个测试用例的工作和报告。

2、需要提交的文档包括相关测试的测试计划、测试用例设计以及测试报告。要求画出测试物理架构图，依赖测试结果，尝试对被测系统的性能状况（容量与瓶颈）、系统稳定性边界和破坏性边界进行分析以及鼓励提出调优的方案。

3、通过期末的考核演示，各组需要介绍说明自己的工作成果，以及与其它小组分享测试过程中的体会心得。