最近工作上遇到一些问题，究其原因就是性能惹的祸，特此总结下新的感悟，当然了这个感悟没准1个月以后或者1年以后就会被自己推翻的。

性能

一提到性能就会想什么吞吐量啊、什么磁盘IO、什么CPU使用率啊等等的一堆值，但是仔细回味一下，这么多这么多的参数也只是所运行程序的一个表象。我们需要通过监控这些值，去从侧面验证这个程序的状态是否是最佳状态。不可否认这是一种方法，但是这应该不是唯一的方法。性能测试有的时候也许很简单，比如：让手机开关机100次，能正常启动这也叫性能测试。
最近工作中遇到的性能问题主要集中在以下几个方面：服务端、设备端 （当然了性能还好多，我只是说我现在遇到的）

1.服务端性能

这个就没必要多说了，这篇文章Linux_后台性能测试说的挺清晰的了，但是有一点需要嘱咐以下，这里说了一堆的参数，重点是你要想明白怎么去设计用例，通过什么样的办法，可以探测到被测程序的漏洞，这样我们才能通过表象的参数发现问题。
再说一遍吧：用例很重要，或者高级一点叫做策略。

2.设备端性能

设备端，需要说明一下，公司现在做的业务是跟路由器相关的，是工业级路由器。主要使用场景就是酒店，其中包含独立区域（例如：房间）、公共区域（例如：会议室、大堂、办公室等）
目前摔得比较惨的一个大坑是，我们风风火火的对接了13个型号的设备以后，发现在对接的过程中竟然在设备的性能测试上放松了，导致很严重的后果就是，设备没法应用的实际环境，在实际使用过程中反馈的问题千奇百怪、系统及其不稳定。

感悟

1. 性能测试要紧跟业务

这个是必然的，首先你要明确为什么做性能测试，比如设备端性能，我对他性能测试的目的就是能让设备在实际使用中不出现乱七八糟的故障，这是我的目的。
既然明确了目的，那么我们就需要朝着这个目标去思考问题了。
设备端需要完成的业务： 开关机、待机，用户连接wifi上网弹出认证，认证通过上网，上报用户网安审计信息。
那我们再设计用例的时候，就会主要分为以上5个方面：
1）场景：开关机测试
针对酒店场景设备会经常出现断电、通电的情况，那这样我们就根据业务情况进行用例设计

通电次数	期望	结果
100次	启动正常，网络正常使用
300次	启动正常，网络正常使用
500次	启动正常，网络正常使用
1000次	启动正常，网络正常使用

性能指标判断：

场景	达标	实际	结果
开关机测试	500次启动正常，网络正常使用	1000次启动正常，网络正常使用	优秀
开关机测试	500次启动正常，网络正常使用	500次启动正常，网络正常使用	合格
开关机测试	500次启动正常，网络正常使用	小于500次启动正常，网络正常使用	不合格

2）场景：待机测试
针对酒店使用场景，有些房间是长通电的，也就是设备会一直处于待机状态

待机时长	期望	结果
24h	手机可以正常连接上网且业务不受影响
36h	手机可以正常连接上网且业务不受影响
72h	手机可以正常连接上网且业务不受影响
144h	手机可以正常连接上网且业务不受影响
168h	手机可以正常连接上网且业务不受影响

性能指标判断：

场景	达标	实际	结果
待机测试	168h待机手机可以正常连接上网且业务不受影响	优秀
待机测试	144h待机手机可以正常连接上网且业务不受影响	合格
待机测试	72h待机手机可以正常连接上网且业务不受影响	不合格

。。。等等

小结：
通过以上2个具体的性能测试用例，应该可以看出，
1.这种性能的测试是一个漫长的过程。给人的感觉是很笨重，脑子里不禁会想到，这样做有必要吗？但是实际结果告诉我，你如果没这么做过，你对你工作中提交的产品质量，心里是没底的，也就说你没有给你的产品的质量确定一个量化的概念。
2.性能测试的合格 指标很重要，你在做性能测试的时候如何去确定这个产品达到这个临界点的时候，就能满足市场的需求。

2. 性能测试要搞清楚数据在代码层面的流转关系

比如我们的架构是，厂商romd的服务 + 我们的服务【superd插件+平台服务】
一个路由器就是一个微型的linux系统，一般厂商都会有删减、自定义的情况，所以各个厂商的情况都不一样，从而导致romd情况不一样
综上，搞清楚了架构，差异，那么就能得出性能测试的重点：
1）romd与superd之间通信的性能测试
2）superd与平台服务直接的性能测试
小结：
关于服务性能，这里不展开说了，给我的感觉就是多而杂，你需要监控很多很多的参数。

总结：

性能测试是一个多而杂且漫长的概念，有的时候你需要不断重复这个漫长的过程，寻找其中的差异，然后不断缩小确认引起差异的变量，直到最终找到问题所在。
或者换一个说法性能测试的难易程度，完全取决于你设置的合格标准。不同阶段可能你设置的标准就会不同，这是一个循序渐进的过程。

@阴-2018-05-21 16:47:26