小记“性能瓶颈定位”测试沙龙

 

开展性能测试的目的：

1.为了写产品说明书需要一些系统的性能参数，这种性能测试是没有预期结果的，测出来什么样的数据就往说明书上写什么数据

2.验证系统的性能需求是否达标

3.已知系统存在性能瓶颈，通过性能测试找出瓶颈所在

用段念老师划分的性能测试应用领域概念，可以将上面三类归为能力规划、能力验证与性能调优。

 

性能瓶颈分类：

1.系统类：无论在什么情况下，系统都存在性能问题

2.事件类：只有在特殊的事件发生时才出现性能问题

3.路径类：按某条路径执行时会出现性能问题

陈文广老师就事件类性能瓶颈举了一个具体的例子。我简单的描述一下：一个系统自上线以来一直运行良好，突然周五的一天，软件开发公司接到用户的投诉，说系统太慢无法忍受。软件公司的技术人员怀疑是因为系统运行的时间太长，就通知用户重启系统。可是过了一段时间用户又投诉相同的问题，还是在周五。软件公司就派资深测试工程师到用户那里了解情况，情况确实和用户描述的一样。但技术人员无法定位问题出在哪里。后来软件公司给用户出了一个DEBUG版本放在用户的SERVER上跑没有问题。两个版本没有太大的区别，这可把软件公司的技术人员给难住了。没办法他们就去向另一个测试工程师请教，这个测试工程师技术不是很好。这个技术不是很好的测试工程师就问了几个简单的问题：

1.问题是什么时间发生的，是从系统上线开始一直都有还是某个时间开始？

2.问题是在什么样的环境下发生的？

原来并不是一开始就有的，而是在某个周五才发生的。技术人员就开始查在这个周五用户都做了哪些操作，用户说没有什么变化，就和平常一样使用的系统。不过是一个台湾过来的科长用的。原来这个系统在内部处理的时候需要把人名转换为汉语拼音，而这个台湾科长的名字比较特殊，当转换的时候会出错，导致主进程挂掉了。这就是一个典型的事件类性能瓶颈。

 

性能表现形式：

1.响应时间

2.资源占用

 

性能瓶颈定位的目的：（不能过度的追求高性能，鱼与熊掌不可兼得）

1.改善用户体验

2.降低成本

 

影响性能的因素：

1.硬件

2.带宽

3.程序

4.DBMS

.

.

.

不过归根结底性能瓶颈都能从程序代码中找到答案，因为使用的语言特性、编写方式就在一定程度上决定了系统的行为。

性能瓶颈定位的流程：

1.分析

2.设计用例

3.执行用例

4.分析性能数据

5.调试

6.比较

性能测试的流程一个两头大中间小的模型。在第一步分析阶段涉及的人员会很多，包括用户、开发人员、测试人员、设计人员。陈老师用三多来描述性能瓶颈定位的流程，基中有一个就是人员多，那两多想不起来了。我个人认为在分析阶段涉及这么多人，无非是为了获得更多、更全面的信息。如果在第一阶段得到的就是错误的或者是片面的信息，那么后续的测试必然是错误的。

 

设计用例：

采用白盒测试的覆盖率分析法，设计的用例要覆盖认为可能出现性能问题的代码

常用的性能分析指标：

FCC函数调用次数

FAT函数平均执行时间

FTT

PEC页面失效次数

 

性能瓶颈定位对环境的要求：

1.应用程序必需单独安装在一个空白的分区

2.系统一定是干净的系统，不能安装杀毒软件

3.测试之前需要重启操作系统，等待系统稳定后（CPU、内存、磁盘I/O）再开始测试

4.有些主板会根据温度自动调节CPU的频率，测试时要稳定CPU的频率

 

接下来就是嘉宾回答问题了，在这个过程中金蝶的测试经理分享了一个金蝶的测试方法。金蝶ERP软件的功能点比较多，大概有两万多个，这时候如何进行性能测试呢？

他们的做法是采用log将各个功能点信息记录，然后将所有的log导入DB.虽然有几万个功能点但最重要的性能指标也就集中在少数的功能点中，通过在log DB中检索最重要的性能指标来确定系统是否达标。同洲电子的测试总监针对嵌入式产品的特点引入了可测试性的概念，强调在产品设计初期就考虑测试的需求，加入相应的测试接口模块。