总结分享：怎么做好一个性能测试？

做好性能测试的要素

做好性能测试 = 了解性能测试底层逻辑 + 过程中使用正确的核心战略

一.了解底层逻辑（流程）

1. 明确问题是什么
2. 尝试将问题复原（首先需要知道一个问题的类型：恢复原状型、追求理想型、防范潜在型；一般的性能问题都是恢复原状型）
3. 分析所有可能导致问题产生的原因并建立课题
4. 列出所有可能能解决问题的解决方案
5. 尝试这些解决方案，可能有的方案无法解决，有的方案能解决，找到真正解决了的就找到了真正导致问题产生的原因
6. 及时和反馈问题的人同步信息
7. 对这次工作进行总结

---

上面介绍的是做性能测试的流程大纲（如果是没有接触过性能测试或者接触很少的同学，可以先一步一步按照大纲来，在测试过程遇到问题了记录总结下来，这样慢慢的做的多了就能融会贯通了~），而接下来要介绍的是日常工作中应该锻炼的一些思维方式和做事方式，先知道怎么样做会带来更好的结果，然后再去学习锻炼把这些思维变成自己的日常思维，这样在执行一个性能测试工作的时候才能做的更快更好！

二.掌握核心战略

1.及时掌握第一手信息

要在开始执行测试之前就要获得测试内容相关的所有有效信息，不然执行过程中发现缺少信息或者根本不具备做性能测试的要求，就白浪费了时间。
比如：

1. 策划提出要测试一个新制作的地图的性能，测试开发什么都没问开始跑测试用例，跑出来发现地图障碍不全，场景资源不全，基础功能还没做完，这种根本就不具备做性能测试的要求，但已经浪费了部署环境执行用例的时间，在开始测试之前如果问清楚这张地图是否制作完毕，可能就能避免这次时间的浪费。
2. 策划提出要测试一下新制作的技能的性能，测试开发询问了选哪个技能作为新技能的对比，策划提供后开始执行测试，测试结果发现两个技能根本没有可比性，因为测试开发不清楚这两个技能的范围作用，不了解范围对性能的影响差别有多大，包括技能的其他特效对性能的影响，这是经验太少的原因，也是没有掌握技能的一手信息导致的，如果测试开发对技能信息非常熟悉，在策划提供对比技能时质疑是否有可比性，就不会浪费这一波测试时间。

2.分享思维

一个性能测试内容很多的话可以找同事一起做，思维方式*2，时间减半，执行的成功率也增加。
比如：

1. 测试开发是一个团体，在接到版本任务急内容又多的测试时，应该优先进行这些测试，就可以和同组同学一起分配，在上一步获取信息时也能有更多的发散思维，分享自己的思维给对方可以获取到更多的测试内容相关的信息。在测试过程中遇到问题时，双方可以思考出更多的解决方案，执行的时间可以减半，如果大家都是熟悉测试底层逻辑的人，还能把效率提到最高。

3.终极思维

给我一个支点，我可以撬动整个地球；获得对问题思考的原点，再用合理的方法可以更轻松的解决问题。要点是要捕获到问题的本质，比如得到玩家反馈游戏卡顿，卡顿的本质是什么呢，是玩家玩游戏时没有得到及时的反馈，那我们就要从这点出发，从现象研究到本质。

4.结果导向思维

以结果为导向出发，思考要做成什么样，其实就是思考提出需求的甲方想要什么。
比如：

1. 策划提出想要测试一个新资源的性能如何；从测试开发的角度来说可能就是我们要提供一份新资源相关的性能数据给策划，但是策划想知道的其实是这个新资源对客户端的影响是好是坏，如果影响是好的，使用新资源可能就是一种客户端性能优化，如果影响是坏的，则不能使用新资源，需要对新资源进行优化直到测试通过，这时候他们也想知道什么地方需要优化；
2. 根据上面分析的甲方想要的结果来看，我们就可以知道我们要做什么了，不仅仅是提供一份数据，还要整理出结论：新资源的性能数据，旧资源的性能数据，对比两者得出新资源的性能消耗结论，如果新资源性能不达标但是策划想要上这个新资源，可能会进行后续的优化，我们要用合适的方法去分析性能热点在哪里，提供有效的优化意见，然后回测，直到测试通过。
3. 当然中间有很多是我们为了达到最终测试通过这个结果需要做的一些其他思维的事情，但是这些思维也是为了这个结果来服务，所以目标一定要明确，不然也是白白浪费时间。

5.焦点思维

研究问题要透彻，这样才是有效解决问题，有效积累经验学识。
比如：

1. 在查一个问题的时候，先分析这个问题是CPU类的还是GPU类的还是内存类的。比如是GPU类的，策划想要测试技能的性能，数据出来后测试不通过，美术同学把特效削了又削，性能还是很差，我们就要针对这个技能的特效去分析他的性能热点到底在哪里，也可以使用工具来帮助分析，比如GPA，而使用GPA需要知道这个工具使用方式，要知道工具采集到的数值代表的是什么意思，而gpa工具其实展示的就是GPU渲染管线流程中的每个阶段的数值，这个时候就要去了解GPU渲染管线是什么，每个阶段代表了什么，把这个流程学会了就相当于知道了GPU相关的性能问题要怎么查了，也就把这一块内容研究透了。

6.节约时间

其他任何与测试无关的事情都不要做。
比如：

1. 版本一周后就要上线了，然后来了一个版本相关的测试，为了这个测试尽快完成我们可能要停下其他的测试空出足够多的测试机器，调用足够多的测试人员，停止优先级低的其他任务进度，必要时可能还要加班。毕竟把性能测试做好，不仅表现在测试本身的结果，测试人员的时效性也非常重要。

7.全局思维

多看讲解底层逻辑的书，数学之类的，可以锻炼逻辑思维；减少无效社交。

1. 这里说的就是日常生活工作的一种好习惯。测试开发也是开发呀，也需要严谨的逻辑思维，我们还需要查问题，对问题的分析和结论的整理要更严谨，因为自己的一句话可能会影响到项目，还需要积累很多的经验。锻炼逻辑思维可以日常看看底层逻辑相关的书，在做事情的时候，不管是生活中的事情还是工作中的事情，都尽可能的用上自己的逻辑思维，这样才能有效的锻炼到。另外和能力强的同事多相处，可以在平时生活工作中体会到别人做事的逻辑，并且积累到一些你还没有过的经验，这对自己也是很有帮助的~

8.风险控制思维

我们接手的测试或者代码功能都要考虑到在项目中他的风险程度如何
比如：

1. 测试性能。如果这个性能不达标，是否考虑不发布，如果发布了可能会对项目造成什么影响，会不会有大批玩家卡掉线之类的。
2. 代码发布。如果制作一个插件想要跟着发到外网，但是最近刚好有一个比较大的版本要出，如果和版本一起出可能会造成更多的问题，导致版本不够稳定，风险太大，是不是可以考虑避开这个版本延后再出，在出外网前测试好这个插件有没有功能和性能问题，将可能对项目造成的影响和风险降到最低。

9.以变应万变

要用变通的思维去思考，如果“变”能得到更多的利益，那肯定要选择更好的方式，而不是死板的钻牛角尖。
比如：

1. 测试开发的日常监控数据中发现内存突然上涨较多，而和以往的差别就是游戏中过图后开启了某个任务指引，然后开启了世界地图，查了很久觉得还是地图相关资源太大和加载逻辑的问题，但是这一部分目前没有办法优化，而我们还要解决这个问题，那就只能找到他为什么会打开世界地图的原因了，只要修复了这个问题，内存上涨问题也能得到解决，后来查到是策划的脚本问题，修改后问题解决。
2. 可能看到这里会有点奇怪，前面不是说了要用终极思维去找问题的根本吗，道理是这样没有错，但是不是每一个问题都能从根本上解决，在这个例子里优化地图相关的资源或代码逻辑当然是最好的，但是相关人员有更重要的事情要做，优化这个过程要耗费的时间精力人力都是巨大的，如果要解决需要项目组专门设立课题，专攻才可以，而我们要解决这个问题，最快的方法就是把客户端还原回原来不会打开世界地图的状态，这样整个项目组得到的利益比花费精力去优化资源和逻辑更大。这也是这项战略的意义所在。

10.资源的配置

自己解决不了的，可以通过其他方式解决，曲线救国也能救，记住我们的目标始终是：解决问题。（万物为人所用而不为人所有）
比如：

1. 前面有个例子里有个查GPU问题时使用了GPA工具，虽然我们自己组内也有相关的测试工具，但是不能查出问题，这种时候再去开发当然是不合理的，我们可以有效使用市面上已经有的成熟的工具去查问题，作为测试开发当然是工具会使用的越多越好。
2. 我们有很多测试机每天要去跑用例，我们自己每天也有很多优先级高的工作要完成，这个时候是不是可以把这种日常的维护自动化测试的相关工作交给实习生去做呢，这样实习生一开始不会觉得工作很难无法完成，另一方面也可以熟悉将来的工作，更重要的是我们自己也有更多时间去完成优先级更高的工作，创造更多的价值。

以上就是底层逻辑和十个战略思维的全部总结了，里面放了一些我亲身经历过的坑，都是自己的宝贵经验，可能看文章的你也经历过，会感同身受，或者你有更深刻的经验，欢迎分享；可能看文章的你还没经历过这些，看了也觉得没有想法，那我建议你先按照测试的底层流程去做性能测试，在这过程中你肯定会踩到很多坑~这个时候你再回过头来看看这些战略思维，就会有更深刻的感受了ヽ(✿ﾟ▽ﾟ)ノ

这里详细总结一个解决bug分析问题的过程，会标注出具体哪些地方用到了什么底层逻辑和战略思维，这次测试里面也踩了很多坑，每一个点是我后续反思的时候觉的应该做到的补充：

1. 问题现象：多个玩家反馈游戏更新后开始卡顿
2. 解决方案：玩家更新或重装驱动
3. 分析过程和遇到的问题：得知玩家有卡顿的现象（底层逻辑：1.明确问题是什么），其他组同学先进行实验尝试发现关闭插件后卡顿修复，认为是插件的问题；测试开发接手查这个问题，首先部署一个游戏更新前的环境，测试确认卡顿存在（战略：3.终极思维）（底层逻辑：2.尝试将问题复原），随后顺着上面那个同学的思路实验是插件什么模块造成的，本机对比测试有无插件发现插件对卡顿的影响不大，该同学受到插件影响可能是个例，而此时测试开发并没有玩家的准确信息，耗费一些时间后要到玩家qq，联系得知玩家机器配置，客户端环境画质，要到客户端log（战略：1.掌握一手信息），分析玩家log，本机尝试采集数据，发现有些玩家的卡顿可能和插件有关，而关掉插件能缓解但并不能完全还原回原本的情况，利用wpa工具采集数据（战略：10.资源的配置）查看堆栈发现卡顿可能还和资源相关的逻辑有关（底层逻辑：3.分析所有可能导致问题产生的原因并建立课题），于是和上面那个同学分工合作，他负责查插件相关的，我来查资源相关的（战略：2.分享思维）；随后就逻辑问题询问了相关程序，认为这块逻辑没有改动并且也无法优化，而逻辑的另一块无法深入探知的就是显卡的dll，可能和显卡驱动有关，或许可以通过更新显卡驱动解决（战略：9.以变应万变）（底层逻辑：4.列出所有可能的解决方案），而玩家又表示驱动已经是最新的了，但还是卡顿（底层逻辑：5.尝试这些解决方案），而在看了玩家给的卡顿时的CPU截图时，发现CPU利用率很高，但是降频了，说明CPU有东西要处理，但是没有办法处理，怀疑是玩家内存出了问题（战略：5.焦点思维；这里可以借此次机会将CPU和内存的工作流程研究透彻）；而后来发现GEFORCE GAME READY（测试版）的版本比玩家的版本超前，建议玩家安装后反馈不卡了，这也是歪打正着，因为玩家本身安装的确实是NVIDIA STUDIO稳定版驱动的最新版本，只是可能玩家安装的这个驱动有问题，卸载重装或者更新到测试版本的最新都可以解决问题；至此解决了该玩家因为资源导致卡顿的问题，和客服以及上级同步信息（底层逻辑：6.同步信息），然后（底层逻辑：7.总结）。
4. 问题：
   1.在完成这次测试中，测试开发在分析问题没有太大进展的时候抽空完成了其他开发需求，没有贯彻节约时间（战略：6.节约时间）
   2.在测试开始之前没有思考需要的结果是怎么样的，这样在测试流程和分析问题的时候就很容易卡住（战略：4.结果导向思维）
   3.测试开始之前测试开发没有掌握一手信息，要解决的是玩家的问题，就应该去还原玩家的情况，不应该顺着别人的思路进行。

其实本篇里面总结的“怎么做好一个性能测试”相关的流程也好，思维也好，也同样是可以应用在生活的方方面面的，这不是性能测试专有的，如果能培养好这种思维方式，我相信不管在生活中还是工作中，你都会明白“怎么做好xxxxx”这个问题的答案~

最后的最后，也是最重要的一点，要总结，踩坑不可怕，可怕的是一直踩坑，把经历总结下来，这能帮你看到自己的不足，总结本身就是一次审视自己的机会，只有多审视自己才能知道自己什么地方好，什么地方不好；总结也是一次锻炼战略思维的机会，写下来的时候你会清楚的看到自己欠缺哪些思维，没有人一开始就能把一切都做的井井有条，都是长期锻炼的结果，一起加油吧！(๑•̀ㅂ•́)و✧