性能测试学习
＊ 性能测试, 一直徘徊在门外
做QA多年了, 手工功能测试, 自动化测试做过的项目不少. 但做性能测试的项目很少.
我感觉性能测试和功能测试, 自动化测试完全不一样, 这种不一样是从测试理论到测试目的, 测试方法, 测试工具等等都不一样. 再加上性能测试本身的知识, 实践都是挺丰富的. 所以功能测试和自动化测试经验丰富, 初次面对性能测试也是两眼一抹黑, 狗咬乌龟, 无从下口.
因为不会, 所以自己对性能测试一直都感兴趣, 平时也不时关注一下相关的信息, 性能测试的书和网友写的文档也看了一些, 甚至也经历了几个性能测试相关的项目. 但感觉这些介绍都有点隔鞋瘙痒, 看完之后只是多了一些零星的知识. 自己对性能测试的理解总有在门外徘徊, 并没有真正掌握的感觉.
＊ 复杂的性能测试
其中一个原因, 就是性能测试看上去比较复杂. 比如 段念的 "软件性能测试过程详解与案例分析" 把测试类型可以细分为 "性能测试, 负载测试, 压力测试, 并发测试 … …"
测试的目标也挺多, 这些目标分别来自于QA, Dev, 客户, 系统管理员… ...
过程也比较复杂, 具体可以参看书 "Web application performance testing".
计数器,报表更是五花八门, 让人眼晕.
对于任何复杂的事物, 我认为一般来说都有一个核心的东西, 核心是比较简单的, 而复杂性是来源于在核心上面加了越来越多特定方面的功能造成的. 要理解和掌握性能测试, 一定要把这些附加功能剥离, 把核心的东西找出来. 那么性能测试的核心究竟是什么呢?
＊ 从简单出发
前段时间, 老大交代了一个任务就是对一个产品做性能测试. 他提出了对性能测试的要求, 比如测试结果要能评估系统的性能, 要能发现性能相关的bug, 要能给Dev提供足够的信息去分析bug, 要能测试新版本的performance downgrade, 等等. 没错,这些都是性能测试中常见的要求, 但我知道要是一开始,就打算满足所有的这些目标, 那我肯定搞不出来, 毕竟我还是性能测试的菜鸟.
所以, 我一开始定了一个最简单(可以说简陋)的目标: 跑完测试, 得到一个性能指数, 用这个指数来表示系统的性能. 具体来说就是我们定一个固定的虚拟用户的值(凭感觉), 然后统计 响应时间的平均值, 用这个值来表征系统的性能. 这个就像常见的pc上的3d性能测试样, 无论显卡性能如何, 都跑同样的test, 用同样的过程, 同样的计算指数的方法. 这真是一个简单得不能再简单的性能测试目标!.
＊ 发现性能测试的核心
具体的工作是另外一个同事在做, 但我一直也在思考, 如何能让目前的性能测试更好更强大. 某天在纸上写写划划的时候, 突然脑袋里灵光一闪, 煞那间, 所有的障眼法似乎都烟消云散, 留下了三个闪闪发光的单词.
1. 虚拟用户(virtual user): 同时使用系统的用户数目
2. 响应时间(response time): 一个用户请求, 从发出到接受, 经历的时间
3. 吞吐量(throughput): 系统单位时间处理的用户请求数目
这三个量,形成了下面两个曲线.
1. 虚拟用户与响应时间的关系曲线,
2. 虚拟用户与吞吐量的关系曲线.
一个特定系统的性能到底怎么样, 就由这两个曲线来描述; 有了这两个曲线, 你就可以回答关于性能最主要的一些问题
这个系统最大能支撑多少用户
用户响应时间不要超过6秒, 最多能支持多少用户
未来半年, 用户数会增加10000, 需要加硬件吗
你给我一个 数值, 我的系统到底性能如何?我不要看那么多的图表
… …
发现自己找到了"性能测试的奥秘", 我按捺不足兴奋. 跑去和一个用Loadrunner做过项目的同事交流, 他肯定了我的观点, 说以前用loadrunner做项目就是这样分析的(为什么不早告诉我啊…:( ). 并且指出统计响应时间时, 一般统计按照正态分布的90%的用户的平均值(所以Jmeter的Aggregate Report里有一个90%line)...
后来同老大的交流中, 他特别强调了request的失败率. 这是一个客户关心的问题. 没有关系, 小case, 只要抓住了问题的核心, 这些附属的指标加多加少, 都不会干扰测试项目的开发, 和对系统性能的分析.
注: 刚看了"应用程序性能测试的艺术", 知道了这个原来叫 关键性能指标(KPI, Key Performance Index).它指出有三个KPI,我觉得是挺有道理的. 他们是:可靠性, 吞吐量 和 响应时间.其中可靠性要求运行性能测试达到一定时间.
* 当前项目新的调整
分成两个子项目
1) 子项目1
首先要把测试vu平均分成n组,
当一组启动后,运行 t分钟, 获取响应的throughput和90%线内的平均值.
启动下一组,
把每一组获取的数据收集, 绘制出两张核心的曲线图
顺便牢骚一下, 当前版本Jmeter对此还没有完美的支持. 我是启动多个Jmeter实例来达到这个目的.
2) 子项目2
根据曲线图, 估计出系统性能最佳时的vu(满足response time的最大throughput的vu数目)
这个vu作为性能regression test的基础
项目还在进行中. 希望这是我进入性能测试领域的一个好的开始.
3) 子项目3
根据曲线图, 估计出系统性能最佳时的VU.
以此VU作为基础, 长时间(2~3天)连续运行测试.
* 性能趋势图
做QA多年了, 手工功能测试, 自动化测试做过的项目不少. 但做性能测试的项目很少.
我感觉性能测试和功能测试, 自动化测试完全不一样, 这种不一样是从测试理论到测试目的, 测试方法, 测试工具等等都不一样. 再加上性能测试本身的知识, 实践都是挺丰富的. 所以功能测试和自动化测试经验丰富, 初次面对性能测试也是两眼一抹黑, 狗咬乌龟, 无从下口.
因为不会, 所以自己对性能测试一直都感兴趣, 平时也不时关注一下相关的信息, 性能测试的书和网友写的文档也看了一些, 甚至也经历了几个性能测试相关的项目. 但感觉这些介绍都有点隔鞋瘙痒, 看完之后只是多了一些零星的知识. 自己对性能测试的理解总有在门外徘徊, 并没有真正掌握的感觉.
＊ 复杂的性能测试
其中一个原因, 就是性能测试看上去比较复杂. 比如 段念的 "软件性能测试过程详解与案例分析" 把测试类型可以细分为 "性能测试, 负载测试, 压力测试, 并发测试 … …"
测试的目标也挺多, 这些目标分别来自于QA, Dev, 客户, 系统管理员… ...
过程也比较复杂, 具体可以参看书 "Web application performance testing".
计数器,报表更是五花八门, 让人眼晕.
对于任何复杂的事物, 我认为一般来说都有一个核心的东西, 核心是比较简单的, 而复杂性是来源于在核心上面加了越来越多特定方面的功能造成的. 要理解和掌握性能测试, 一定要把这些附加功能剥离, 把核心的东西找出来. 那么性能测试的核心究竟是什么呢?
＊ 从简单出发
前段时间, 老大交代了一个任务就是对一个产品做性能测试. 他提出了对性能测试的要求, 比如测试结果要能评估系统的性能, 要能发现性能相关的bug, 要能给Dev提供足够的信息去分析bug, 要能测试新版本的performance downgrade, 等等. 没错,这些都是性能测试中常见的要求, 但我知道要是一开始,就打算满足所有的这些目标, 那我肯定搞不出来, 毕竟我还是性能测试的菜鸟.
所以, 我一开始定了一个最简单(可以说简陋)的目标: 跑完测试, 得到一个性能指数, 用这个指数来表示系统的性能. 具体来说就是我们定一个固定的虚拟用户的值(凭感觉), 然后统计 响应时间的平均值, 用这个值来表征系统的性能. 这个就像常见的pc上的3d性能测试样, 无论显卡性能如何, 都跑同样的test, 用同样的过程, 同样的计算指数的方法. 这真是一个简单得不能再简单的性能测试目标!.
＊ 发现性能测试的核心
具体的工作是另外一个同事在做, 但我一直也在思考, 如何能让目前的性能测试更好更强大. 某天在纸上写写划划的时候, 突然脑袋里灵光一闪, 煞那间, 所有的障眼法似乎都烟消云散, 留下了三个闪闪发光的单词.
1. 虚拟用户(virtual user): 同时使用系统的用户数目
2. 响应时间(response time): 一个用户请求, 从发出到接受, 经历的时间
3. 吞吐量(throughput): 系统单位时间处理的用户请求数目
这三个量,形成了下面两个曲线.
1. 虚拟用户与响应时间的关系曲线,
2. 虚拟用户与吞吐量的关系曲线.
一个特定系统的性能到底怎么样, 就由这两个曲线来描述; 有了这两个曲线, 你就可以回答关于性能最主要的一些问题
这个系统最大能支撑多少用户
用户响应时间不要超过6秒, 最多能支持多少用户
未来半年, 用户数会增加10000, 需要加硬件吗
你给我一个 数值, 我的系统到底性能如何?我不要看那么多的图表
… …
发现自己找到了"性能测试的奥秘", 我按捺不足兴奋. 跑去和一个用Loadrunner做过项目的同事交流, 他肯定了我的观点, 说以前用loadrunner做项目就是这样分析的(为什么不早告诉我啊…:( ). 并且指出统计响应时间时, 一般统计按照正态分布的90%的用户的平均值(所以Jmeter的Aggregate Report里有一个90%line)...
后来同老大的交流中, 他特别强调了request的失败率. 这是一个客户关心的问题. 没有关系, 小case, 只要抓住了问题的核心, 这些附属的指标加多加少, 都不会干扰测试项目的开发, 和对系统性能的分析.
注: 刚看了"应用程序性能测试的艺术", 知道了这个原来叫 关键性能指标(KPI, Key Performance Index).它指出有三个KPI,我觉得是挺有道理的. 他们是:可靠性, 吞吐量 和 响应时间.其中可靠性要求运行性能测试达到一定时间.
* 当前项目新的调整
分成两个子项目
1) 子项目1
首先要把测试vu平均分成n组,
当一组启动后,运行 t分钟, 获取响应的throughput和90%线内的平均值.
启动下一组,
把每一组获取的数据收集, 绘制出两张核心的曲线图
顺便牢骚一下, 当前版本Jmeter对此还没有完美的支持. 我是启动多个Jmeter实例来达到这个目的.
2) 子项目2
根据曲线图, 估计出系统性能最佳时的vu(满足response time的最大throughput的vu数目)
这个vu作为性能regression test的基础
项目还在进行中. 希望这是我进入性能测试领域的一个好的开始.
3) 子项目3
根据曲线图, 估计出系统性能最佳时的VU.
以此VU作为基础, 长时间(2~3天)连续运行测试.
* 性能趋势图
