从前面的描述,我们可以看到, 性能测试的参数, 输入场景, 关键性能指标都是和性能测试的目的密切相关。 比如, 为了验证是否满足一个重要客户的性能要求, 性能测试可以很复杂, 测试环境包括应用服务器Cluster, DB Cluster, 专用的存储服务器,测试耗时一个月; 为了验证是否在版本之间有性能下降, 性能测试也可以很简单, 所有软件都部署在同一个机器上, 且测试集成在DailyBuild里面。
不同的性能测试目的决定了不同的性能测试方法。 好的性能测试不是求大求全, 而是用最小的成本, 满足测试的要求。
下面是对性能测试目的的总结。
|
性能参数 |
输入场景 |
目的 |
执行成本 |
执行者 |
性能基准 |
在一个给定的性能影响参数集合上,, |
运行一个给定的输入场景 |
获得一个性能基准。 这个基准可以作为性能比较的基准, 或者参考的数值。 |
中 |
QA |
性能验证/性能规划 |
通常是在一个贴近客户的软硬件平台上, |
运行贴近客户系统的输入场景 |
验证客户系统能否满足客户的要求。 |
高 |
QA/Support |
性能调优 |
通常对基础软件硬件无特别的要求。 对某个系统本身的参数,或者应用服务或者数据库参数进行变化。 |
输入场景可以灵活变化, 根据调优的关注点不同。 |
发现瓶颈, 优化性能 |
低 |
QA/Dev |
使用性能测试模型分析方法的性能测试流程如下。
|
Task |
输出文档 |
计划 |
确定软件性能模型 确定性能测试目的 确定性能测试参数 确定输入场景 确定关键性能指标和选择性能计数器 |
测试计划 测试案例 |
准备 |
开发测试脚本 部署测试环境 |
脚本 测试环境清单 |
实施 |
执行TestCase |
性能计数器原始数据 |
报告 |
分析测试结果 制作测试报告 |
测试报告 |
======================================================
后记:
真实世界的性能测试项目是复杂的。 这是我半年性能测试的体会, 其中最令人纠结的是如何能让性能测试让各方满意。 当性能测试项目刚开始的时候, 每个人都在提出自己的意见, 那时我入道尚浅, 所以分不清轻重缓急, 识别不出重点, 因为自己对性能测试理解不深, 所以工作中总是被外界牵引得团团转, 每天很忙的工作, 想让每一个人都满意, 结果却是大家都不满意。
慢慢的, 在失败和挫折中吸取教训, 不断的梳理思路, 总结出来了这样的性能测试模型分析方法。 我希望能通过这样的分析方法在性能测试中能够抓住主线, 能够知道要做什么和不要做什么,能够设计出有效率的性能测试案例。
因为自己的性能测试经验范围其实还是相当窄的, 所以文章的内容是相当粗糙; 而且这样的分析方法可能在其他的项目并不一定适用。无论怎样, 希望能对阅读过这些文字的你有所启发, 并欢迎任何指正和交流。