文章目录
前言
最近,看到一些测试群里聊性能测试相关的业务内容,有些小伙他们认为使用不同的工具去进行数据收集/记录,然后就觉得自己会性能测试了,个人觉得这个想法稍微欠妥,虽然我也是在性能测试之路上不断探索的前进者;刚好这两天有小伙伴在问我怎么去搭建一个简单的性能测试业务框架,和小伙伴讨论一个晚上。趁着心血来潮那股劲,我就把这些内容梳理成文档,以便各位大佬进行阅读与指点。
我们在进行性能测试工作的过程中,肯定是需要借助工具的辅助(自研工具+市面工具)来帮我们完成一些工作,但性能测试工具≠性能测试,工具永远是一辅助的工具,而不能认为会用工具就会性能测试了!希望看到这里的小伙伴,可以改变这个观念。以前我也是有这样的错误观念。
接下来,咋们就聊一下,一个简单的性能测试框架是如何搭建起来的吧。 欢迎各位大佬指正。
一、准备工作
1、稳定的系统功能
游戏的性能测试,作为测试的小伙伴来说我们应当在项目的哪各阶段去介入才比较好,大数据表明,只有在功能测试验证完成、整体系统趋于稳定的情况下,才会进行性能测试,否则提早介入性能测试是无意义的。
第一方面:根据该项目的具体情况,组建一个测试中台,其中实验基地是必不可少的,然后人员配置需要1-3人的开发人员(对应前端、后端等),还有性能测试设计和分析人员、脚本开发和执行人员;在正式开始工作之前,应该对脚本开发和执行人员进行一些培训,或者应该由具有相关经验的人员担任。人员数配置(固定团队人数:3-5人)
另一方面:需要一名测试相关经验的测试主导者,根据项目当前的现状,进行竞品数据收集,与开发进行沟通去制定性能的测试标准;团队开发提供测试工具,或者根据项目类型再结合市面上主流的测试工具,逐步组合去搭建测试的业务流程,测试主导者还要兼顾性能测试设计点和以及数据分析,以及脚本的编写;同时更多的是利用半自动化+手动去进行对应的业务测试;执行人员,在正式接触业务之前,应该需要统一给他们进行一些培训。(1名测试主导者+团队测试人员)
综合以上两种形式,第二种形式居多,但部门发展到一定规模和程度的时候会逐步向第一种形式过渡,那么今天的主要还是围绕是第二种形式去讨论。
3、
工具的选择
综合功能系统设计、工具成本、测试团队的技能来考虑,选择合适的测试工具,最起码应该满足一下几点:
①支持手机端的测试工具;
②工具运行在Windows平台上;
③支持对前端、后端服务器的性能计数器进行监控;
注意:前端和后端的性能监控工具,和性能监控指标是不一样的,所以自己要明确监控的目标才能选好对应的工具部署测试环境。
为了对游戏性能建立直观上的认识和分析,应对功能较重要和玩家体验较多的功能进行分析,针对性的进行分析,以对接下来的测试计划设计进行准备。
测试计划(前端)
游戏测试最重要的阶段就是制定游戏的性能测试标准,那么为了这个标准我们需要进行以下环节。
根据目前的潮流趋势,需要对市场上的客户流量进行设备的数据收集,确定我们性能测试主流设备是哪些,目前有哪些设备系统已经逐步的流失在市场上,在挑选机器的时候可以均匀合理的搭配,这有助于我们提高测试的质量以及针对性的测试。
确定项目的类型后,在项目demo的前期阶段,利用该时间段可找相同类型的竞品项目2-3款,然后对这些产品进行性能相关的数据收集,这有助于我们后续制定性能标准有一个参考的依据。
要制定性能的测试指标,首先要知道我们需要测试什么(哪些功能业务),关注点是什么(哪些性能);确定性能目标(指标),其中需要和开发去沟通这些指标,最终我们确定的测试目标是哪些,fps,cpu,卡顿率,温度流量等;比如:
①从点击手机游戏icon加载到游戏首帧耗时不能超过8秒;
②该app运行的总体内存占比不能大于800MB的比例;
③整体运行过程种低于25fps的比率不能小于15%;
④服务器的CPU平均使用率小于70%,内存使用率小于75%;
⑤运行一段时间后手机的温度差不能大于5摄氏度;
根据业务制定的指标,结合当前效率,成本,难度,人员能力,开始部署最合适的测试工具。
5.制定测试计划的实施时间
评估本次性能测试功能的起止时间,耗时,参与人员等等。
三、测试脚本设计与开发
性能测试中,我们根据不同的业务类型,灵活的手工+自动化脚本搭配,设计测试流程,设计测试脚本和维护脚本需要的时间和精力性价比比较低,所以我们要灵活的变通。
本次性能测试的目标是需要验证功能在实际运行环境中的性能外,还需要考虑到不同的手机硬件配置是否会是制约系统性能的重要因素!因此在测试环境中,需要部署多个不同的测试环境,
在不同的手机硬件配置上检查手机的性能,并对不同配置下的手机性能的测试结果进行分析,得出最优结果(最适合当前项目的配置)。
这里所说的配置大概是如下几类:
①手机运行内存/核数
②cpu型号,操作系统
③手机机型
在选择设备的时候, 那么我们要考虑手机的机型(高、中、低的设备),然后再结合主流设备进行环境的搭建。
2、测试业务设计
结合功能,业务所需玩家的操作,制定测试场景(例如:某地图,某副本),监控其性能的指标等。还有一些业务场景,某商城频繁打开多次,副本联系闯关等,这些是否会影响性能的指标。
业务方向确定之后,我们要根据思路去进行用例的设计,使其执行步骤更加明确,覆盖更全,执行流程更规范和专业化。
其一:按照用例描述,可利用第三方工具进行脚本的编写,然后结合性能监控工具去使用,自动化节省劳动力;其二:利用性能监控数据,人工去进行数据的收集,在数据收集过程中可以及时的发现问题并且给予反馈和跟踪;
四、测试执行与管理
在这个阶段,只需要按照之前已经设计好的业务场景、环境和测试用例/脚本,部署环境,执行测试并记录结果即可。
后端性能:按照之前已经设计好的测试环境,部署对应的环境,由运维或开发人员进行部署,检查,并仔细调整,同时保持测试环境的干净和稳定,不受外来因素影响。
前端性能:所有一切的准备都是测试来负责检查,部署与调整。
记住:前端性能和后端性能测试还是有稍微不一样的地方的
2、执行用例
按照用例的去运行脚本,去执行操作从而去实现性能指标的监控。这里重点区分一下手工测试和脚本运行的业务,建议综合结合,能全自动化那当然是最好的状态。
根据测试采用的工具不同,结果的记录也有不同的形式;现在大多的性能测试工具都提供比较完整的界面图形化的测试结果,当然,对于服务器的资源使用等情况,可以利用一些计数器或第三方监控工具来对其进行记录,执行完测试后,对结果进行整理分析。
五、测试分析
根据我们之前制定的性能测试指标,与预定的性能指标进行对比,确定是否达到了我们需要的结果;如未达到,查看具体的瓶颈点,然后根据瓶颈点的具体数据,进行具体情况具体分析(影响性能的因素很多,这一点,可以根据经验和数据表现来判断分析)。
2、手机设备对系统性能表现的影响分析
由于之前设计了几个不同的测试环境,故可以根据不同测试环境的手机使用状况图进行分析,确定瓶颈是再数据库服务器、应用服务器抑或其他方面,然后针对性的进行优化等操作。
影响系统性能的因素很多,可以从用户能感受到的场景分析,哪里比较慢,哪里速度尚可,这里可以根据2\5\8原则对其进行分析;至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素,具体问题具体分析,这里就不一一表述了。
在性能测试执行过程中,可能会发现某些功能上的不足或存在的缺陷,以及需要优化的地方,这也是执行多次测试的优点。
5、
测试报告
在性能数据收集完毕后,我们这时候手上是有大量的数据的,通过以上的分析之后,得出结论,那么我们需要把这些数据和结论整理出来,以报告的形式来呈现给大家看,这样的测试才会有说服力。相信很多人都会遇到测试与技术的一个这样对话的场景。测试发现了一个bug,但是呢没有截图录制好视频直接告诉程序这里有bug?然后就被程序怼了回来。所以一份清晰明了的性能测试报告也是最关键的环境。也是最能体现到这次测试的意义所在。
总结
在性能测试的业务方向,也是随着项目和时代的发展不断完善和发展的,毕竟游戏不像软件项目一样,有这么多的技术基础支撑,但是对其业务测试时,这个业务能为项目带来什么样的价值才是我们所希望看到的;那么本文也就讨论到这里了,可能描述缺乏专业化,希望大家可以指点出来,共同改进。