作为测试工程师,大家都会接触性能测试;在我接触的同行朋友里,谈的比较多的话题也是性能测试。一方面因为这个工作需要的技能比较全面,有所挑战,另一方面也正因如此,很多人都想学、想做、想做好!诚然,性能测试在目前的测试行业是个热门领域,很多企业招聘里有所要求和侧重,而对个人职业发展也是个不错的选择。
在我的面试经历中,经常向求职者问道:你们做性能的需求来自哪里?答曰:客户给我们!又问:客户给的需求明确么?答曰:不明确!问曰:不明确的话怎么办?答曰:客户如此要求,满足它既可!我心想:那么你的价值何在?莫非只是被客户驱动型的按照他们提出的目标来做事?
这是个比较极端的例子。实际上国内多数软件公司在做性能的时候有此现象,但是会比较该情况要好;多数人会告诉我:我们按照客户的需求,要模拟500个人并发在系统做操作,每个页面响应时间不超过5秒;或者持续测试5*24小时没有CPU和内存问题…但是我这里想说的是,500个并发用户来自哪里(除了客户因素外)?500个用户如何分配在不同的并发操作上?每批用户行为测试时间持续多久?在一个完整的工作日8小时内,这批用户分别如何分布?…我确信这样进一步的问题,客户不会告知,但是作为测试工程师,尤其是专业的性能测试工程师,在做性能测试的时候,肯定要考虑这样的问题,否则你的测试结果可能不准确,在客户面前没有说服力,甚至即便你发现性能瓶颈,开发团队都会有理由怀疑你,理由就是:你模拟的场景不足以反映真实用户的操作行为!
这篇文章里,我想讲讲性能测试里需求分析的事情。我们国内多数公司是做项目的,也有做产品的,开发技术主要是.NET或J2EE的BS架构,也可能是传统的CS架构。一般来说,一个项目或产品刚立项后,在需求分析阶段,我们总要考虑软件的性能需求,作为后续性能测试的依据。那么这个需求来自哪里呢?
* 客户口述,业务人员搜集编写
* 技术人员自行分析
第一个方式是多数公司和项目团队如今采用的模式,但是大家都很清楚,光靠客户的讲述还是远远不够的,尤其对于一些国企或非IT类客户,他们也许对性能需求没有概念,很可能随口说说,比如“我们系统要支持一万用户”这样的一句话。那么第二个方式就是我要说的重点。虽然专业的客户也普遍存在,如银行、电信、金融行业的大客户,他们有专业的IT部门,可以提出明确、切合实际的需求给软件供应商;但是作为一个专业的软件测试工程师,尤其专注于性能测试的团队,也该有一套自身的性能需求分析方法,作为客户提出明确需求后的一个有力的补充!从而让后续性能测试的结果真实、可信,任何人都提不出毛病。
我们说,性能测试的目的是找出系统的性能瓶颈,并修改它;那么为了让性能测试的执行策略能够捕获瓶颈,就要有有个明确的性能测试目标;达到目标的无瓶颈,没达到则有瓶颈!一般来说,一个典型网络应用程序的性能目标有以下四个维度:
* 响应时间
* 服务器吞吐量
* 服务器资源利用率
* 系统负载量
这些概念这里不做解释,相信同行们都了解。总之在需求分析阶段,这些指标都会根据产品特征、开发技术、客户确认得到明确的值域。接下来就是进一步的事情了:我们为了后续性能测试的时候有一套切实可信的测试策略,要在需求分析阶段去分析系统的用户行为。这也就是我要说的“技术人员自行分析”的工作。为什么要分析用户行为呢?这是我们将来做性能测试时候设计性能场景的依据,否则上述的4个指标如何通过明确的测试得以体现呢?那么为了保证最终性能测试结果准确,就要保证性能测试场景真实;如何达到真实的场景模拟?只有知道真实的客户的行为是什么样,我们就模拟什么样。例如在很多网友写的文章里都讲到,我们需要把一个系统的业务流根据时间轴进行分解,然后逐个开发性能测试脚本去实现它。简单拿51JOB为例,如要对51JOB整个系统进行性能测试,我们要把51JOB拆分出若干业务流:统计时间为正常工作日的8小时,有500用户在录入简历,1000用户在搜索招聘职位,300用户在搜索简历,100用户在浏览广告…后续就是开发脚本去模拟录入简历、搜索招聘职位、搜索简历、浏览广告的操作而已。那么问题来了,凭什么知道8小时内是500用户录入简历?1000用户搜索招聘职位?….这些数据从何处来?答案很简单了,从客户的历史日志来!