性能是产品的生命线
从一个刻骨铭心的事件说起
09：00-研发接到需求，某公司商城要做一爆款商品的营销推广
10：00-沟通需求后，研发介入，利用原有框架，短时间完成该任务
16：30-测试介入，根据功能点逐一确认功能是否符合，无误后，提交验收
18：00-产品验收，功能满足需求，同意上线
18：30-提交上线，当晚一切正常
次日
8：00-部分用户反馈商品页面打开缓慢
9：30-大部分用户反馈页面响应缓慢且无法支付
10：00-服务器CPU及内存告警
10：30-所有用户都无法进入商城主页
11：00-数据库发出IO预警，出现大量异常写入
11：20-被迫下线商品，研发进入紧急排查，业务受到严重影响，前端客户投诉不断
…………
这种情况做研发的想必都有所耳闻。大家印象中认为一个产品的交付，就是功能和逻辑满足客户的需求，而客户在验收产品后，当下也是以这些指标作为标准来考量，于是当产品涉及的用户访问超预期时，就发生了以上的问题。
这个案例背后的代价如下：
1）原来囤积的商品没有出售，造成大量的经济损失。
2）用户支付后，无法获得商品，引发大量投诉。
3）产品上线后，因访问压力过大，影响了其他产品的销售，同时造成该服务器其他应用不可用。
4）研发辛苦工作的产出付诸东流，换来的是骂声一片。
5）公司声誉受损，以后涉及的活动也因此蒙上阴影。
6）研发心里受到创伤，无法承担责任，团队士气低落，甚至瓦解。
究其原因，还是我们缺少对产品一个关键因素的考量，那就是性能。而性能指标的量化数据的获得，需要经过一个专业验证手段，那就是性能测试。
1、什么是性能测试
所谓性能测试是通过设计的测试手段和工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
2、性能测试的目的
1）评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
2）识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3）系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能；检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
4）验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
3、我们需要关注的主要性能指标有哪些？
1）平均事务响应时间ART：遵循2、5、8s原则（或称页面打开响应时间：2s良好体验，5秒可接受，8s用户忍受临界点）
2）并发用户数：高峰时间段并发用户访问数，如1小时内300万用户访问页面。
3）资源使用指标：CPU使用率，内存使用率，磁盘IO
4）tps值：
每秒处理的业务笔数，如：80%的交易在20%的时间完成，每天交易10万笔，一天8小时，则
tps=80%*100000/（8*3600*20%）=13.89
5）并发交易成功率：大于等于95%
4、如何获得指标需求
1）产品经理描述的需要：如，页面打开不能低于3s；一笔交易必须在5s内完成等。
2）用户访问量预估：如，一个活动的用户量可能有100万，80%集中在高峰时间段的2个小时，所以，用户并发数至少要保障120PV/S的响应。
3）系统经验数据参照：如，原系统可以支持高峰时间200万用户访问，那么要保障1000万用户访问，就可以参照200万用户的真实场景指标，做线性预估。
4）行业参照：如，银行业务的单笔交易必须保证在3s内完成。
5、获得性能指标的主要测试手段有哪些
负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试：通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
这两者的区别是，压力测试是测试系统的忍受上限；负载测试是，在不同压力下，系统的表现，已获得系统健壮性的阈值。
6、性能测试有哪些步骤
1）参与需求评审，了解业务流程。
2）分析系统并与产品沟通，获得性能指标。
3）编写测试用例、流程路径、逻辑脚本及场景模板。
4）性能测试工具选择（测试工具，脚本工具，建模工具，监控工具等）。
5）性能结果分析。
6）系统调优及改善。
7）瓶颈解决及验收。
7、 性能测试通过的标准
1）所有计划的测试已经完成。
2）所有计划收集的性能数据已经获得。
3）所有性能瓶颈得到改善并达到设计要求。
8、什么情况下需要性能测试
1）核心产品及业务。
2）重视用户体验的产品。
3）涉及关键节点的模块（门户，购买，交易，支付等）。
4）指定活动和营销场景。
9、结合案例了解性能测试
以下是性能测试的用例及场景，供大家学习参考：性能测试用例及场景
最后感谢测试团队负责人的精彩分享！
网友评论