性能测试杂谈【转】

玻璃房

性能测试越来越吃香，所有测试人员都成为这方面的高手，我个人觉得掌握一种测试工具必不难，只要花上个一周甚至更少的时间就Ok了。难在哪里，难在性能需求获取、分析、设计和性能测试结果分析、定位、优化。那我们今天来先说说如何做好性能测试需求获取。    获取，如何真正的获取。
    我记得有一次，客服中心反馈：“某某客户公司某某系统收费业务有时很慢”，这个需求看起来好像很完善，但是作为性能测试员怎么下手呢，拿起LR就冲锋一把，肯定解决不了问题，除非瞎猫碰到死老鼠。
    后面我拿到客户的电话简单又沟通了一下，大体内容如下：
    我：“是一直很慢，还是有规律的，慢的体现是怎么样。”
    操作人员：“4点以后就开始，点结账功能要等好久。”
    我：“4点以后，你们那时还有哪些事情再做。”
    操作员：“交接班，个人要做个人日报，部门领导要做汇总日报等”。
    这时提交性能小组的需求是：某系统在做个人日报和汇总日报时，收费业务点击结账时要等很久。
    从上面的例子可以看出，我们在性能需求获取时，需要跟客户最好是实际的操作人员交流，在了解功能的基础上，还要交流一些非功能需求，如：什么时候做，有多少人做，每天有做多少次，每次提交哪些信息，有的甚至要了解他们工作性质，如什么时候上班，是否24小时值班，交接班是什么时候，每班几个小时。
    要了解业务同时还要获取到当前系统网络架构，网络结构时怎么样，什么数据库，什么中间件，是否能连接外网，系统是什么开发的，当前已数据库有几GB等。当前性能需求业务涉及哪些表，结构是怎么样的。
    如何做性能测试用例设计
    我在前几次性能测试杂谈已经简单描述了性能测试需求获取和各操作系统的一些监控指标，那现在一起来看看如何进行性能测试用例设计吧。
    前面我们做了很多工作主要是为测试用例设计做准备，如果需求都不明确，咱们如何设计呢。测试用例设计的时候要把握这几个关键环节。
   1. 确定目标
    这里的目标指的当前测试系统的目标值，或者说是客户的期望值，也有可能业内的标准值。这里设定的时候一定考虑测试执行环境的影响，因为一般情况测试时不可能是在真实或上线的环境中测试。这个时候我们一定根据测试执行环境和真实、上线的环境进行比较，将我们原有目标值换算成我们测试参考值。一般受影响的环境，有服务器的配置、网络环境、数据量等。
2. 场景设计    我个人认为场景设计是性能测试用例设计最关键环节，很多人会想“大傻”你又来忽悠我们了，这还不好设计，就是模拟用户的场景就行了。我们还是拿【性能测试杂谈一】中的例子来说明一下。【某系统在做个人日报和汇总日报时，收费业务点击结账时要等很久】，我会设计以这种场景。
    为什么这样设计，主要为执行考虑，如果我测试场景2的时候，我就发现问题了，我还有必要再去执行场景3和场景4。但是又有人会有疑问，如果第一次就选择场景4，一次就Ok，但是大家要想到业务组合越多，对后测试执行时脚本调试、数据准备和恢复的工作量是巨大，发生错误的概率更大，而且为我们测试结束定位和分析更为困难。测试用例场景的设计一定考虑测试的执行，场景设计一定从简单到复杂。
    什么是最好的性能测试用例，就是在最短的时间内能快速准确的定位到系统瓶颈。





上一篇：嵌入式系统软件的全过程质量保证
下一篇：【转infoq】架构师--软件测试路在何方，有电子书下载

吴梦婷

最好的性能测试

paulonewman

很有借鉴意义，先收藏了，谢谢楼主。

卢红冉

还不错哦，如果再能多分享一些就perfect了！

憂殇丶已落幕

其实，很多情况下都是这样的，习惯就好。

陌南尘

这么强,支持楼主，佩服

吹个五彩的泡泡

路过 帮顶 嘿嘿

昔。

我了个去，顶了

雨一直下

没人回帖。。。我来个吧！

失恋的小草儿

不错 支持一个了

摇滚乐狂

众里寻他千百度，蓦然回首在这里！

画砂°

支持，赞一个

残羽

打酱油的人拉，顺便赚点金币

迷蝶香。

看起来好像不错的样子

最后

不错 支持一个了