1、性能测试需求分析
需求:1)我们希望所有的功能都能进行性能测试,所有的功能模块都进行性能测试是不可能的,根据80-20原则,用户经常使用的功能模块大概占系统所有功能模块的20%,对参数设置这种功能进行性能测试是没意义的,性能测试的最终内容通常就是结合用户真实的应用场景,客户应用最多,使用最频繁的功能。2)用户登录响应时间小于3s,如果不指明是多少用户的情况下,这句就是一个功能测试的需求,如果加上了在n个用户访问时,响应时间小于3s才是一个性能需求。3)系统支持10W用户并发访问,系统的可扩展性是我们需要考虑的重要内容,在满足当前和未来用户应用系统性能要求的前提下进行测试,能够节省客户的投入,也是真正的从客户的角度出发。
2、性能测试计划
产品、项目的背景,明确性能需求,软硬件环境,网络拓扑结构,操作系统,服务器,数据库及硬件配置
3、性能测试用例
用性能测试的理论知识配合测试工具
4、测试脚本编写
1)协议的正确选用
2)脚本语言的选择
3)最好将登录和登出脚本分别放在vuser_init()和vuser_end()中
4)提高编写脚本的能力,关注脚本质量
5)注重脚本的复用
5、测试场景设计
如需并发操作,则姐啊如集合点;考察某业务的处理响应时间,则需要插入事务;检查系统是否正确执行了相应功能,则需要设置检查点;输入不同的业务数据,则需要进行参数化。
6、测试场景运行
注意测试机的内存。性能测试之前运行一下应用服务器的功能。注意测试环境的独立性。沟通。每个测试用例最好执行3遍。
7、场景运行监控
1)如果性能测试负载机有多台,要保证负载机的时钟同步。
2)场景的监控也会给系统造成负担,没必要的参数就不用监控了
3)注意测试系统的权限,监控时要用管理员权限登录。
4)监控是一门学问,要对监控的数据指标有非常清楚的认识,充分熟悉测试工具。
8、运行结果分析
拐点分析是一种利用性能计数器曲线图上的拐点进行性能分析的方法,例如随着压力的增大,系统性能出现急剧下降,这样就产生了拐点现象。只要得到拐点附近的资源使用情况,就能定位系统的性能瓶颈。
9、系统性能调优
测试人员提出性能瓶颈,相关人员对系统进行调整,测试人员进行第二轮、第三轮的测试。对系统进行调优时最好是每次只调整一个一项内容或一类内容,以免调整多项后性能提高了却不知是调整哪一项而导致的。系统调优由易到难的顺序:硬件(CPU不能满足复杂的逻辑运算,硬盘容量小、速度慢),网络(网络带宽),应用服务器、数据库配置,源代码(源代码被调整后功能也要重新验证,引入缓存)、数据库脚本(对数据库建立索引),系统构架(慎重对待)。
10、性能测试总结
1)需求覆盖情况
2)测试过程中出现的问题
3)如何分析调优解决的
4)测试人员、进度控制与实际执行偏差
5)测试过程中遇到的风险是如何控制的
6)有哪些经验和教训