4.4.2　测试执行过程中的工作

·在这个阶段，您的工具在干活，您所需要的就是周期性地检查一下负载生成器的性能，确保负载生成器没有过载。测试执行前的准备工作过程中提供的信息足可以证明你的负载生成器的能力，不过，最好不要想当然。

·确保对于每次的测试执行都形成了文档，这些文档至少应该包含以下信息：

—性能测试执行文件的名称，测试执行的日期和时间。

—对测试组成部分进行一个简要描述。（假如你所使用的性能测试工具允许，可以让它自动添加这个描述）

—当前执行的测试对应的测试结果文件名称。

—与性能测试以及相关事务对应的所有输入数据文件名称

—对测试过程中所发生的任何问题的简要记录。

执行测试的次数以及相应的性能情况很不容易跟踪。假如性能测试工具允许在测试配置中添加注释，请使用这个功能并通过添加注释信息的方法来区分这些测试。同时确保对测试结果文件与之相关联的每次测试执行都进行了记录。一些性能测试工具分别保存测试结果和其他测试设置，最后当你在准备测试报告的时候，只需要找出你需要的数据信息即可。（以上这些都是我的测试经验的总结）

最后，假如性能测试工具允许您将测试保存为一个项目，那么组织和访问测试结果的过程将非常容易。

·测试执行过程中注意如下事项。

突发错误

这经常意味着应用程序架构某些地方已经达到了它的极限。假如你的测试是由数据驱动的，它也可能意味着你的数据已经不够使用了。错误是否与特定数量的活动用户相关，这值得去考察。一些性能测试工具允许对出现问题的事务手动减少活动用户的数量。你可能会发现在51位用户的时候有错误发生，但退回到50位用户时错误却消失了。

注意

突发错误也可能意味着某个操作系统默认设置问题。我记得有一个项目，该项目的应用中间件是部署在运行Sun Solaris的UNIX操作系统的一组刀片服务器上。该性能测试在活动用户达到一定数量后开始持续不断地失败，但是从我们配置的服务器KPI监控器上看不出处理能力不足。通过查看系统日志文件发现是操作系统对于单个用户会话打开多个文件句柄的数量限制而导致了上述问题的产生。当我们把250的限制提高到500后，上述问题就消失了。

事务吞吐量突然下降

这是一个出现问题的典型标志，特别是Web应用程序，该应用程序上用户在等待Web服务器的响应。如果问题比较严重，用户的等待队列将最终超时，并导致测试退出。不要立即断定是Web服务的问题，这也可能是一个简单的应用服务器或者数据库服务器的问题。也许你会发现当一定数量的用户退出之后问题解决了，此时可以确认应用层处理容量限制。假如你的应用程序链接了外部系统，请检查并确认这些链接是否会带来问题。

系统可用内存泄漏问题

我们知道当越来越多的用户被激活的时候可用内存会越来越少，但是如果所有用户都被激活后可用内存仍在持续减少，这说明系统存在内存泄露的问题。私有内存很快就能暴露出应用程序的问题，但是仅当进行渗透测试才能揭示释放内存时更多微妙的问题。这是一个应用服务器的特殊问题，它的价值在于确定系统组件和方法级别的分析。

来自网管的紧急电话

糟糕！在我进行性能测试的过程中，生产系统却意外地崩溃了。这种现象在Web应用中最为常见，因为在Web应用中指向一个错误的URL链接是常有的事。