第二章 性能测试初体验

    性能测试是一项综合性的工作,致力于暴露性能问题,评估系统性能趋势。性能测试工作实质上是利用工具去模拟大量用户操作来验证系统承受的负载情况,找出潜在的性能问题,分析并解决;找出系统性能变化趋势,为后续的扩展提供参考。测试显然不是录制脚本那么简单的事情(而且现在很多系统还无法录制脚本),本章主要阐述性能测试涉及的IT知识、角色、视角、流程及面临的挑战。

2.1 性能测试的价值

[案例1]2012年11.11 某宝和某东为首的电商赚足了眼球。某宝双十一网络瘫痪诟病,其宝被"抢瘫",好不容易进入支付过程,某宝提示系统繁忙,经过反复尝试,用户花费很长时间才能实现支付。

[案例2]12306订票网站

[案例3]2008年奥运会票务系统

[案例4]亚马逊网站瘫痪

    下面是软件测试分类,如图2-2所示。

    从图2-2可以看到性能测试在整个软件测试环节占了50%的内容,如测试内容中,负载测试、压力测试、性能测试、大数据量测试、恢复测试、内存泄漏测试、竞品测试(比较测试)和可靠性测试。一共14个测试内容,性能的测试占领8个,可想而知性能测试在软件测试中的重要程度。

    软件业大部分软件开发之初一般考虑的是软件功能的市场需求契合度,是否能被市场认可。这个前提成立之后,才会有较大的用户群体去使用,从而出现性能问题。然而根据金字塔理论,到了后期在进行修改,投入和产出不成比例。一般公司在做出确定可以盈利的产品后,会对产品进行再次开发,来达到这个性能要求。所以第一个产品(试验)的性能要求和真正的推广产品(成熟)的性能要求不是一个量级,企业发展到一定程度就得关注性能,重视性能。

    性能测试的价值就是保障系统的性能,提供良好的用户体验;尽可能地找出性能薄弱环节,帮助进行性能优化。

2.2 性能测试流程


(1)业务学习:通过查看文档,手工操作系统来了解系统功能。

(2)需求分析:分析系统非功能需求,圈定性能测试的范围,了解系统性能指标。

(3)工作评估:工作量分解,评估工作量,计划资源投入(即需要多少人力,多少工作日来完成性能测试工作)。

(4)设计模型:圈定性能测试范围后,把业务模型映射成测试模型。

    什么是测试模型?比如一个支付系统需要与银行的系统要进行交互(充值或者转出),由于银行不能够提供支持,我们会开发程序去代替银行系统功能(这就是挡板程序,Mock程序),保证功能的性能测试能够开展;这个过程就是设计测试模型。

    再比如,后面要讲到的实例项目Jforum论坛,根据需求我们了解到一般大家发帖或回帖前都会登录,那么我们在开发脚本时就要把登录与发帖或回帖场景绑定在一起进行测试;这就是测试模型。通俗点说就是性能测试用例设计家性能测试实现方案,用例只关注业务,模型还需关注如何实现,是否具有可操作性,可验证性等问题最后我们还得根据不同的测试目的组合成不同的测试场景。

(5)计划编写:计划测试工作,在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。

(6)脚本开发:录制或者编写性能测试脚本(现在很多被测系统都是无法录制脚本的,我们需要手工开发脚本),开发测试挡板程序,开发测试程序等。有时候如果没有第三方工具可用,甚至需要开发测试程序或者工具。

(7)测试环境准备:性能测试环境准备包括服务器与负载机两部分,服务器是被测系统的运行平台(包括硬件与软件,比如应用服务器需要8Core,32G内存,中间件是Jboss7等),负载机是我们用来产生负载的机器,用来安装负载工具,运行测试脚本。

(8)测试数据准备:根据数据模型来准备被测系统的主数据与业务数据(主数据是保证业务能够运行畅通的基础,比如菜单、用户等数据;业务数据是运行业务产生的数据,比如订单;订单出库需要库存数据,库存数据也是业务数据。我们知道数据量变会引起性能的变化,在测试的时候往往要准备一些存量/历史业务数据,这些数据需要考虑数量与分布)。

(9)测试执行:测试执行时性能测试成败关键,同样脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。

(10)缺陷管理:对性能测试过程中发现的缺陷进行管理。

(11)性能分析:对性能测试过程中暴露出来的问题进行分析,找出原因。

(12)性能调优:性能测试工程师与开发人员一起来解决性能问题。











































猜你喜欢

转载自blog.csdn.net/yongchaocsdn/article/details/80336867