系统测试包含系统功能测试和性能测试，大部分人习惯于把性能测试全部剥离出去，交由性能测试工程师去实施独立的性能测试。实际上性能测试工程师对系统业务特征的了解可能远不如系统功能测试人员，他们在系能指标分析定义、测试覆盖定义、测试数据选取等工作上离不开系统功能测试人员的大力支持。其实我们可以在系统功能测试过程中提前把部分系统性能测试的工作掺杂进去，尽早解决性能问题，这样也能从一定程度上提高系统功能测试的效率，也能减轻性能测试工程师的负担。下面拿以ORACLE为数据库的WEB应用为例，简单说一下我本人的做法。
找出潜在的问题
首先，在没有辅助工具的情况下，我们要对系统的某些比较直观的性能指标（响应时间）有足够的敏感度，就是说在做测试执行的时候要有意识的去关注一下我们在测试的这个功能的处理速度。我们在前端操作时一旦发现系统响应速度可能低于性能需求目标或者低于平时的速度，那么第一时间登录到数据库中查看活动的session，观察是否有wait的session和长时间执行的SQL语句。方法很简单，以PL/SQL为例：进入tools—sessions菜单（中文版是“工具—会话”），根据当前应用的固定中间件用户去寻找其对应的活动session，参见下图。结合前端的响应情况，在不断刷新的过程中如果发现某一个session中的SQL Text始终不发生变化，那么二话不说，把SQL文本复制下来，打开一个执行计划分析窗口对该SQL进行进一步的分析。如果SQL一直在不停的刷新，但是反反复复的始终都是那么几个固定的SQL，那说明程序中使用的是循环体，至于循环体本身是否合理，就需要我们自己去代码走读来判断了。关于SQL性能优化的常见关注点，这里不在赘述，网上有很多达人对此有过阐述。我经常用这种方能够迅速法判断出程序中哪里需要加hint，哪里需要建索引，甚至哪里逻辑冗余或错误，这种方法比起单纯的手动测试和较低覆盖率的并发、压力测试来说更加快速有效。
图一 找到活跃的等待的session
图二 找到session中的SQL
图三 进行SQL效率的进一步分析
我们上面说的这些操作方法都很图形化，当然如果大家对数据字典很熟悉，那么也可以从v$session、v$session_wait、v$sql、dba_tables、dba_objects、dba_source等等这些表或者视图中找到这些相关信息。找到这些疑似问题，无论测试人员有没有断定是否程序异常或者主动优化的能力都无所谓，至少我们还可以寻求开发或者DBA的技术支持。当然，非数据库的性能问题还是要借助一些测试工具来具体定位，经验丰富的开发和测试人员对此 应该很清楚如何去分析、定位。
