软件测试的两个关键问题,针对B/S客户端进行性能测试的几个关键问题

在针对B/S客户端进行性能测试的时候，会遇到很多技术难点，往往成为性能测试的礁石。有些难题，虽然看起来是个小问题，但是如果没有科学的解决办法，往往会影响整个测试项目的进度，带来很大的损失。

基于以往性能测试项目的经验，本文总结了针对B/S客户端进行性能测试时遇到的多个关键技术问题，愿与业内同行进行深入探讨，共同提升测试能力。

1、性能测试脚本录制最重要的地方

性能测试脚本录制最重要的地方，个人认为有以下三个方面：

第一，在性能测试之前要先做程序的功能验证。这是最开始要做的事情，要确保厂商程序的被测功能点都是正确的。功能验证都不通过，性能测试所做的一切都没有意义了，同时，功能验证的过程也是熟悉业务的过程，对于测试工程师非常重要；

第二，参数化分析。虽然参数化本身非常重要，但是更重要的是参数化的分析，要分析哪些值需要做参数化，这才是关键；

第三，做关联。做关联可能是最难了，因为需要分析服务器返回的数据，要对程序的流程有个彻底的了解。做关联的难点还是对程序流程的理解，并不是关联本身。

2、测试脚本的第一次录制

对B/S客户端进行第一次脚本录制，测试工程师需要注意以下几个方面：

1)在测试脚本录制之前，测试工程师应该已经对测试规范进行熟悉了，第一次脚本录制的目的之一就是要按照测试规范实际进行一步步的操作，看看是否会遇到一些报错的问题；

2)通过第一次脚本录制，测试工程师需要了解被测程序的各个功能是否已经实现以及实现的方式是怎么样的。虽然是性能测试，但是对于功能的理解，流程的把握是相当重要的；

3)B/S性能测试脚本里面，核心的问题就是要把参数化做好。所以第一次录制脚本，测试工程师要仔细的观察程序变化，要看一看哪些地方是需要做参数化的，以及做参数化的难易程度问题。

3、在测试脚本里找不到需要参数化的那个值

问题描述：按照测试规范的要求，需要对一个数值进行参数化，但是在脚本中没有发现这个值，参数化无法进行。

解决方法：这是属于厂商实现机制的问题，测试工程师需要和厂商进行沟通，让厂商修改程序，使被参数化的值能够在脚本中显露出来，这样，性能测试才可能顺利进行。

4、参数文件里不能有空行

问题描述：在实际测试中，我们配置了11个参数文件，跑10个循环没有错误，很正常，但是跑100个就报错了。

解决方法：把报错的链接从IE中打开，发现有几个值是空的，因此而报错。打开脚本，看参数文件，界面里显示的确实是11个值，没有更多的值了，但是从记事本里把参数文件打开，按Ctrl+A，发现在后面几行里有空行，就是因为这个空行才报的错。所以发现，参数文件里不能有空行，对于空行，系统也是识别的。

5、极限测试中测试终止条件必须定义明确

问题描述：起初，性能测试终止条件定义的是CPU的最高值以及事物通过率的最低值，后来发现这些条件其实都是很难达到的。尤其在极限测试的时候，终止条件显得尤其重要，没有终止条件就没有办法达到极限了。

解决方法：需要定义更细的终止条件，而且在一定的时间内能够达到，要不然无法进行极限测试。

6、用LoadRunner监控Linux及Unix资源不稳定

问题描述：用LR监控Linux及Unix资源，有时监控会断掉，就无法监控资源了

解决方法：有时候确实会出现这个问题，所以在实际测试中首先要用LR对服务器进行监控，同时使用服务器自身的NMON函数来收集数据，把应用服务器和数据库服务器的CPU、内存、硬盘IO等的值都收集下来。

7、使用NMON函数要注意的事项

第一，NMON函数是在服务器端本地启动的，所以每次使用都需要登陆到服务器把NMON打开。查看NMON是否打开的命令是：ps –ef|grep nmon。

第二，NMON函数的原理是把每次收集的数据都放到了一个文件里，所以每次开始新一轮的测试，都需要关闭上一次开启的NMON，然后打开一个新的NMON，以便容易区分数据。

第三，要把时间校准好。作为控制台的那台测试机的时间、应用服务器的时间、数据库服务器的时间，这三个时间要校准，没有必要去确认哪个时间准确，需要做的是把这三个时间的差别算出来，要以做控制台的测试机的时间为基准。