loadrunner 笔记—理论知识
软件系统性能的常见指标：
响应时间：用户感受软件系统为其服务所耗费的时间
响应时间细分为： 服务器端响应时间（可用来度量服务器的处理能力），网络响应时间（网络硬件传输交易请求和交易结果所耗费的时间）， 客户端响应时间
吞吐量：“吞”进去的是请求，“吐”出来的是结果；具体指的是 软件系统在每单位时间内能处理多少个事务/请求/单位数据
资源使用率： 常见的资源有 cpu占用率，内存使用率，磁盘I/O，网络I/O
点击数：该点击数不是表示通常理解的用户鼠标点击次数，而是按照客户端向web server发起多少次http请求计算的，一次鼠标可能触发多个http请求；
并发用户数：并发用户数用来度量服务器并发容量和同步协调的能力；在客户端指一批用户同时执行一个操作；并发数反应了软件系统的并发处理能力；和吞吐量不同的是，它大多占用套接字，句柄等操作资源。
满足用户性能需求，有以下几种方案：
消除软件对时间和空间不必要的浪费
以空间换时间
以时间换空间
软件生产过程的v型图：
需求分析-设计-编码-单元测试-集成测试-系统测试（性能测试）
性能测试为软件系统级测试，可用来做： 识别系统瓶颈和产生瓶颈的原因；最优化和调整平台的配置来达到最高的性能；判断一个新的模块是否对整个系统的性能有影响
作为软件测试的一种，软件测试的规则童谣适用于性能测试中：
确定预期输出是测试必不可少的一部分
必须彻底检查每一个测试结果
穷举测试是不可能的，在性能测试中不可能覆盖每一个功能部分
做性能测试案例时要遵循：
做基本且常用的功能模块测试；做响应时间要求苛刻的模块
常见的性能测试方法：
负载测试：负载测试是站在用户的角度去观察在一定时间下软件系统的性能表现
负载测试的预期结果是用户的性能需求得到满足，此指标体现为：响应时间，交易容量，并发容量，资源使用率
压力测试：考察系统在极端条件下的表现，这个极端条件不一定是用户的性能需求，可能要远远高于用户的性能需求
并发测试：负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的
基准测试：当软件系统中增加新的模块时，要做基准测试，用来判断新的模块对整个软件系统的性能影响；按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能 的影响
稳定性测试：查看测试系统在一定负载下运行长时间后是否发生问题
可恢复测试：查看测试系统能否快速的从错误状态恢复到正常状态；通常结合压力测试一起做
常规的性能测试目标：
度量最终用户响应时间
定义最优的硬件配置
检查可靠性：确定系统在连续的高工作负载下的稳定性级别
查看硬件或者软件升级对响应时间和可靠性的影响
确定瓶颈
度量系统容量
分析性能需求：
要细化需求，找到测试点：
测试的对象是什么，例如“被测系统中有负载压力需求的功能点包括哪些？”；“测试中需要模拟哪些部门用户产生的负载压力？”等问题。
系统配置如何，例如“预计有多少用户并发访问？”；“用户客户端的配置如何？”；“使用什么样的数据库”；“服务器怎样和客户端通信？”。
应用系统的使用模式是什么，例如“使用在什么时间达到高峰期？”；“用户使用该系统
是采用 B/S 运行模式吗？”；“网络设备的吞吐能力如何，每个环节承受多少并发用户？”等问题。
最后得出的性能测试指标标准至少要包含测试环境、业务规则、期望响应时间等。
开发Loadrunner脚本需要经过几个步骤：
创建脚本-完善编辑脚本-场景的指定-独立运行脚本-场景中运行脚本
录制脚本的录制原则： 录制脚本不要有多余重复性的操作；录制具有代表性的功能；选择具有影响的事务