##【前言】
什么是做功能，功能就是客户要一碗蛋炒饭，然后做了给他。
什么是做性能，性能就是把客户要的蛋炒饭，做的很美味给他。

我想谁都明白，一家餐厅能活下去，是因为能把食材料理好，客户喜欢。
我们自然也会明白，一个应用能活下去，也是因为能把功能做到好用，客户喜欢。

更准确的说，一家餐厅能活得下去，要考虑用户需求、食材，然后就是料理水准了。撇开食材和用户需求这些偏市场和产品定位层面的问题，我们今天就聊聊这个料理水准。

评价一碗蛋炒饭有色香味意形养。评价一个 APP 的纬度也有 CPU、内存、耗电、响应、流量、包大小。

你的 APP 可以是上面这一碗，看着就好吃，也可以是下面这一碗，看着就不想吃。

如果说业界优秀的 APP 产品是米其林三星水准的话，平安我们的产品基本上属于大排档水准。是的，大排档。我们有市场有销量，但终归和定级相去甚远。对于大多数的技术人员来说，抱怨老板给食材（资源）不好，抱怨要做的东西（产品）不好，这都是没有卵用的，好好当好自己的厨子，做好了自己的技术活，做好自己的性能。

ok，摊开鸡蛋和大米，我们开始炒个蛋炒饭。

【业内怎么看待的】

确实是给大家说下业内怎么理解的，我一字无讹抄了一些过来。

以下是摘自 Loadrunner 帮助文档的回答：
 

Automated Performance Testing is a discipline that leverages products,people, and processes to reduce the risks of application, upgrade, or patch deployment. At its core, automated performance testing is about applying production workloads to pre-deployment systems while simultaneously measuring system performance and end-user experience. A well-constructed performance test answers questions such as:

➤ Does the application respond quickly enough for the intended users?
    你的应用程序的响应时间足够快吗?
 
➤ Will the application handle the expected user load and beyond?
    你的应用程序能轻松应付那么多的用户负载吗？
 
➤ Will the application handle the number of transactions required by the business?
    你的应用程序能处理那么多业务所需的事务吗？
 
➤ Is the application stable under expected and unexpected user loads?
    在预期的用户压力下，你的应用程序足够稳定吗？在超出预期的用户压力下呢？
 
➤ Are you sure that users will have a positive experience on Go-live day?
    你能确定用户在使用你的应用程序时会得到好的体验吗？
 
By answering these questions, automated performance testing quantifies the impact of a change in business terms. This in turn makes clear the risks of deployment. An effective automated performance testing process helps you to make more informed release decisions, and prevents system downtime and availability problems.

以下是百度百科的观点，

目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

包括以下几个方面:

1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

在百度做个搜索，还真搜不到几条让你满意的答案，百度百科等相关的词条甚至对客户端相关的性能测试开展只字不提。受一些压测工具的影响，现在包括一些从业者也把性能测试和压力测试等同起来。

这也能比较正常的反应出业内对测试和性能测试的一个态度，会认为很重要，但是又缺乏关注。这就好比淘宝双十一活动，第二天在全国各大媒体产品先吹一波 -- 几分钟突破多少亿、累计交易多少亿；然后运营物流在部门媒体吹一波 -- 第一单送达时间 XX 分钟；然后研发在各个技术圈子里再吹一波 -- xxx 高可用架构、并发量 xxx；最后还是测试在内部总结一下。其实在双十一这种技术需求下，也表现得很抗造 -- 如何做容量评估，如何分层评估，如何做压测服务架构设计，怎么分析和设计全链路压测。有兴趣的可以搜一下相关的文章（是的测试技术总结你得搜，产品那一波吹你等推送就可以了）。
可以参考：http://www.sohu.com/a/122339596_354963

说到这个，还是插个嘴，选择了做测试就相当于做了球队的守门员，压力大不大只有你自己懂，没当过守门员的教练和你说拜托了的时候也不代表他就懂你的心态和处境。但是既然选择了做测试，就如同守门员一样选择了寂寞。老想和别的角色一样争出镜率完全没必要，真喜欢曝光自己的，可以考虑彻底放弃 IT，转行做产品研发也一样不适合你。

ok，我们还是要绕回来聊聊我们的看法。首先还是从概念出发，首先我们交付的是一款应用，目标是满足用户的某一个或者某一些需求。所以首先，我们看看质量是如何定义的：

上面的质量定义，我们可以看出几个很关键的词，需求的满足程度。这句话我们先放一下，我们再看下软件质量如何定义的：

软件质量就是 “软件与明确的和隐含的定义的需求相一致的程度” 三类要素（也是三个层次）：

这里又抛了一个很关键的词 -- 隐含的。所以做测试之前首先要明白，我们是要对付用户的需求，这个需求可能还是隐含不明确的，然后我们评估这个需求满足的如何？

所以性能测试在接入工具之前，首先要弄明白的问题，我要怎么评估是否开展这个事情，或者用哲学名词说就是，你的明白度 - 量-关节点是什么？

对于任何情况，在决定进行某一种测试前，都应该问自己一些基本问题。这些问题的答案将会决定哪种测试方法是最好的。这些问题包括：

• 结果的可重复性需要有多高？
• 测试需要运行和重新运行几次？
• 您处于开发周期的哪个阶段？
• 您的业务需求是什么？
• 您的用户需求是什么？
• 您希望生产中的系统在维护停机时间中可以持续多久？
• 在一个正常的业务日，预期的用户负载是多少？

上面这几个问题是引用的，因为基本上都归纳到了，这里的最后一句很重要，预期的用户负载是多少，我们很多测试人员只会跳出来问，用户的预期负载是多少。

有些性能测试完全是可以裁剪的，比如常说的压测，如果你的机器性能相比较你的用户需求，高的一塌糊涂，按照经验你的用户也不会暴增，也没人给你做运营。那你确实保证了功能，以及性能层面 -- 响应速度之类的就够了。APP 也是如此，如果你的 APP 是常驻长耗时 APP，比如导航比如音乐比如管家，那你的耗电量是你非常致命的性能需求，如果你这是一个打开看一眼就会关闭的 APP，拜托你就别跟风测什么耗电量了，你只要保证关掉 APP 的时候你没后台搞小动作就好了。

【先把思维方式拧一下】

做性能测试首先要做的第一步是受众分析。这个受众分析请注意，起点不是产品经理，不是研发，不是业务老大，而是你真真实实的用户先，然后 -- 用户看不到的中后台技术指标。而在实际测试执行的时候，我们往往会忽略这一点，先考虑产品怎么想的，会先考虑研发怎么想的，会考虑业务老大怎么想的。确实一些从业者，也会说，作为测试要综合用户 产品 研发 业务线的需求，然后做性能测试。我不能说这个是不对的，但是我个人不是很赞同，作为测试更多的还是用户的代言人，不是团队的意见收集者。

如果过于思考产品要什么，研发要什么，业务要什么，ok，那你注定是在团队里当保姆的，如果你做得好，那也是一个高级保姆而已。是听别人的意见去满足他，还是自己建立自己的体系去影响别人，作为测试人员你自己选，tester 和 QA 终归是有些区别的。

出发点是出发点，其他的意见还是要参考下的，项目组其他角色都会说啥：产品会说『这个地方要给我加载速度到 3 秒以内』『使用中不能发烫』；研发说『请你告诉我那里 CPU 使用异常了，我那里内存飙高了』；业务老大会说『要配合运营活动了，你要看一看』『新版本貌似用户反馈不稳定』。

你和这些角色或者主动，或者被动（最好你是主动去做的，因为测试本来就是一个主动防御体系）的获取了这些信息。这心信息你一定要学会加工。加工的能力，是能体现一个测试工程师的业务测试能力的。

上述例子，我们再拿来举一下：

这个地方加载速度要 3 秒以内

• 混吃等死的假测试理解：听听老大怎么说，他说要测的话我就测一下。怎么测他说了算。如果不会的话，找个做过的人教一下，没人做过的话我也没辙。
• 多数人的理解方式：记录下来，写一条性能测试用例，在点击加载后到内容呈现出来 3 秒钟。
• 技术范儿的理解方式：可以用 xx 自动化测试框架，写一个自动化测试用例，记录点击事件时间，到内容加载的时间。
• 资深技术范儿的理解方式：xx 自动化测试框架解决了测试驱动的问题，内容是否加载完成的普安短存在误差，通过 xxx，yyy，zzz 等技术解决页面识别，提升准确性。
• 业务和技术混合范儿的理解方式：不管自动化还是手工驱动，数据获取不是大问题，要深入看下耗时在什么地方，是前端还是后端问题，前端是否能看下有并行提升速率的，或者渲染时提升效率的，后端看下那些个接口比较慢，响应慢是耗在什么地方，看看后端是否专门再做一些性能专项定位一下如何做优化。
• 我个人希望的理解方式：1. 这个地方要加载到 3 秒，为什么是 3 秒，产品的这个建议从哪里来的？是否合理。如果他没有依据，我是否要有系统的方法评估一下（评估方法 回头我们聊）。评估的结论也许不是 3 秒，是别的一个建议阀值。这个地方要加载到 3 秒，其他是否有类似的用户场景被忽略了。2. 是否有自动化的解决方案，有的话，是否要做这个自动化方案，收益比如何？成本大收益小是否考虑放弃。3. 问题定位一定是要有的，当前的工具有那些可以复用，有那些是没有解决的问题，这些是否值得投入做一次提升？

新版本貌似稳定性不好

• 混吃等死的假测试理解：我发这个 app 听老大的做了 monkey 测试啊，monkey 指标和以前差不多，我也不知道上线为啥 crash 率变高了。
• 多数人的理解方式：monkey 测试的随机性太强了，有些页面还依赖于登录，跳不进去。
• 技术范儿的理解方式：monkey 是需要做一些改造的，通过 instrument 可以运行一些自动化 case 做登录，解决部分页面无法被遍历的状况，增加一些深度遍历的工具和算法，提升遍历能力。
• 资深技术范儿的理解方式：这次问题的暴露是个很好的场景，可以挖掘一下 monkey 智能化和遍历工具的产出，可以推广别的产品线，是个扬名立万的机会。
• 业务和技术混合范儿的理解方式：需要分析一下 crash 类型和机型分布，看下是什么类型的原因引入的，是否能通过 monkey 的改造解决，稳定性的问题不能等到上线被用户反馈回来，小流量灰度测试是否能帮忙，需要评估一下；要结合业务场景优先一些核心场景的覆盖，如果工具一时半会无法产出，要有其他临时手段解决。
• 我个人希望的理解方式：1. 用户反馈的稳定性，是否只是 crash 的问题，是否有其他原因 2. 问题分析要先聚类看下，是否当前稳定性测试手段可以改善的，是否和前后端结合的部分有影响；3.即便是 monkey 这种问题的发现效率是不是比较低，当前产品线对发布周期又有强烈要求，是否能满足

总之：你的起点是先提用户想，用户报的问题一定是问题，只是他们通常报的不准；然后再去结合各方的反馈，一定留心对你瞎 J8 指挥的老大（如果你觉得我说得不对，你按你的理解来，不用和我争），你得弄清楚他说的对不对。然后才是如何提升效率，是否可以输出工具，输出的工具是否有普适性可以推广。

【如何做产品性能测试需求分析】

测试是一定要讲测试经济学的，一定要考量投入、产出、介入时间、投放时间、退出时间，不然你做到死也都是跟着老大混，也自然活该被老大坑。做性能测试自然也是一样，要不要做，为什么做，怎么做，做完能解决什么问题，是否有普及前景都是要思考的。

• 产品分析 先得明白你的产品是什么样的一款产品，市场定位几何。不然在你想做什么包冗余分析的时候，老板和你说没必要的时候，你别连为什么都不知道。同样，作为一个测试，你一定要做主动防御体系，应该是你做完产品分析，告诉老板该在什么阶段引入什么样的测试，包括性能评测和优化的逐步开展。
• 受众分析 你要先看下你的用户都是什么样的一群人。受众分析而不是用户分析，是我这里偷换一个概念。用户还是真实的用户才算，受众这里我把内部项目参与者也算进来。总归你还是要了解你的用户，即便同样的产品，你的用户不同也有可能导致细微的差异。
• 技术分析 这里提一句，90% 的测试开发，都喜欢开始前先搜一下，看别人怎么做的，有什么现成的方案可以借用，开发到一半然后发现有很多技术问题解决不了。或者放弃，或者推翻了重来。技术分析一定要考虑好工具选型，参考什么选： >1. 先明白你的产品要解决的问题是什么，这个对应的问题大概有那些个工具可以借鉴，亦或者从 0 开始做一个。 >2. 然后弄清楚各个工具或者方案的优缺点是什么，那些个工具和你需求最吻合。 >3. 选型的工具可二次开发的空间有多大，应对当前的需求需要做那些开发，对将来的潜在需>求是否能做好技术上的储备。或者说方案将来被推翻的概率要小。
• 收益分析 也是从经济学的角度出发，不是什么都要工具化，不是什么都要做自主研发的，解决问题是王道。当有人笑你们自动化率低的时候，你完全不必要理会这样的傻逼。同样是工具化的过程中，也要分析先做什么收益大，做什么收益小。比如做响应时间分析，如果你当前的 APP 某功能加载时间 5 秒以上，人眼误差 0.2-0.3 秒，误差 5% 作用，然后页面又变化比较大，维护成本高。那你做 UI 层的驱动自动化精力，不如做性能数据的采集、分析、以及报表的自动整理生成。

今天的先写到这里了，下周我们再继续