性能测试总结

从这一段时间性能测试的情况来看，急需计划和梳理的是如下方面的事情。

 

第一，性能基线测试。

   性能基线测试是在正常预置的容量环境和正常背景下进行的测试。之所以说正常，就是我们尽量不要到有一些可靠性问题，资源泄漏问题导致环境整体操作慢的环境中去测试。因为性能基线测试主要就是测试出性能基线文档中所描述的每个比较有代表性，常用的功能项的单点操作耗时的问题。在当前性能基线要求的时间下，暴露出单点功能在性能环境下是否存在设计不合理和需要优化的地方。如果当前环境比较恶劣，或者其他上述的可靠性问题，资源泄漏问题演变成了耗时中的主要部分，则第一个是性能基线项的耗时就存在不准确的地方，可能觉大部分的性能基线项都不满足性能要求。其次开发人员定位时也抓不出主要的矛盾在哪，因为他们肯定会去定位耗时最久的在什么地方。所以综上分析，性能基线测试时需要在性能环境开启背景2~3个小时之后进行测试，不宜在性能环境放置太短，或者放置太长后进行测试。如果性能环境的背景刚启动起来就开始进行性能基线的测试，也是不太恰当的，这个时候的性能背景可能都还没有对性能环境达到正常的负荷。

  性能基线测试离不开三个条件。第一，正常的，完备背景的性能环境，基于一线场景抽取和提炼；第二，精简的有代表性，常用功能的性能基线指标。基于工作量和覆盖率的考虑，性能基线需要分优先级。对于较难区分测试耗时边界的指标，应该明确说明测试耗时计算起始和结束点。第三，尽可能在单点数据量多（当然这个多不能超过实际的预期），真实的环境下进行性能指标的测试。这一点是常被忽略的，因为数据量多的环境需要耗时间构造，而如果又是真实的设备环境，这个就更难找了。

 

第二，负载测试。

 

  开始还比较犹豫，不知道把这个想象的叫做可靠性测试好些，还是叫其他的更好些。后面想到负载两个字，再对照公司的可靠性测试的内容，觉得这个名字还比较恰当。公司中的可靠性测试，主要是看进程是否持续运行正常，资源是否会耗尽等。而在这里要讲到的负载测试，是如下模样的。

 负载测试是什么？按照我的理解，负载测试就是在常态背景的性能环境中，持续的进行一些常用操作，查看进程和系统是否存在资源泄漏和使用不恰当的问题，关键性能指标是否存在比较明显劣化的问题，较高优先级业务处理是否存在错误或丢弃的问题。

  持续的进行一些常用操作，最好是能尽量的模拟一线场景，使用比较真实的用户，进行常用的操作。如实际过程中，可能100个用户中60%都在浏览告警，20%都在激活去激活端口，10%的用户正在通过GUI下发业务，2%的用户正在通过TL1部署业务等等。可以参考大容量性能环境场景中相关的胶片，只不过那个设计更加复杂，其实是没必要这么复杂的。当然持续的操作，除了多客户端工具帮忙分担一些简单的操作外（现在我们这块确实存在工具瓶颈的问题），最好的就是跑自动化了，建议跑初验用例，覆盖面广，还可以检查一些资源泄漏的问题。

   通过做上面这些操作，一个是查看进程的资源泄漏情况，包括物理资源的超过预期的使用如进程内存泄露，CPU过高，IO持续过高，内存页面交换过于频繁等。逻辑资源则如同步的调度队列，北向的连接数，数据库句柄等等，这部分主要是观察获取资源不释放，导致后续请求一直等到的情况。这一部分是我们测试的薄弱点，其中逻辑资源部分，可以说基本上没有测试这些，后续肯定是要关注到的。这部分目前的手段就是通过脚本监控系统资源，监控进程资源，监控数据库资源，监控内存泄漏。手段还有待大的提高。在测试过程中，偶发性的碰到CPU过高，IO过高这种问题，我们一定要警惕，这种问题很难定位，影响也非常大。出现时一定要立即找开发人员定位，并备份所有可能的日志和相关信息。

  较长时间运行的情况下，其次需要关注关键性能指标是否存在比较明显劣化。如果持续运行一段时间，鼠标都点不动了，也就不用玩了。在负载测试过程中，可以抽测两到三次关键的性能指标，看看性能指标是否有明显的变慢。抽测时间点建议为中期，中后期和结束点。这个与跑初验用例不同，这是需要测试关键性能指标，关键性能指标不宜到，100个以内，2到3个小时就能搞定。当然能实现自动化更好，这个是我们后续努力的方向。在前面的测试过程中，遇到过同步时有这种情况的，一个模块的同步可能耗时近半个小时。

  在负载测试中，还要关注的一个是成功率的问题，即较高优先级业务处理是否存在错误或丢弃的问题。举些简单的例子，在测试过程中，高优先级trap被丢弃，手工同步超时，业务发放成功率低下，设备自动轮询成功率低...  这个成功率或者说处理出错的问题，与指标劣化分开出来讲，是因为这些操作可能不慢，指标没有明显劣化，但就是处理不了太多的业务了。深层次的原因，跟开发人员讨论得出的一个结论就是我们设计的系统就只能处理当前这么多容量的业务，时间一长，这些资源都耗在处理前面还滞留的业务上去了。打个比方，你800m还能跑到终点，但是4000m的赛跑，你终点都跑不到了，因为你的体力(资源)都耗在了前面3000m的跑道上。业务处理也是这么个逻辑，持续的业务处理，没有缓口气的时间，后面的处理就超时或者丢弃了。(这里的业务不仅仅指业务发放中的业务，这个范围更大)。在当前新支撑的大容量环境中，这个问题应该还是有不少的。

   在负载测试过程中，最好能给出关键性能指标的性能曲线，系统和关键进程的性能曲线，较高优先级业务处理成功率的一个曲线，方便后续评估被测试的环境。

 

 

第三，压力测试

 

压倒骆驼的最后一根稻草。压力测试就是要找出待测系统的性能拐点和性能拐点时的背景数据，另外一个就是以比实际多出2~5倍的背景测试系统，看看待测系统是否会死，操作是否会失败。找出性能拐点不是一件太容易的事，需要从小的压力加到大的压力，一直加到预期的压力为止，当然也有可能这个拐点不会出现，那是最好的。压力测试不需要放置多长时间，但是环境可能稍微有些难得准备。比如多出预期2~5倍的设备节点，这个是很难得做到的，一线也极少极少出现这种情况，这个就没有必要了。一般，应该是在告警，trap，TL1和多客户端同操作某个功能来进行压力测试。另外个人觉得，网络延迟，报文丢失的恶劣环境背景，也可以在这个测试过程中体现。压力测试要求的就是可以慢，但不可以死。

 

 

性能测试过程中，其实有很多是扯在一起分不清的。但是我们在意识上知道我们在干啥，为什么这么干。这样才知道后续的计划怎么做，下一步怎么走。

 

就暂时先写这么多吧，后面再补充。。。