作者：lyscser
系统测试包含系统功能测试和性能测试，大部分人习惯于把性能测试全部剥离出去，交由性能测试工程师去实施独立的性能测试。实际上性能测试工程师对系统业务特征的了解可能远不如系统功能测试人员，他们在系能指标分析定义、测试覆盖定义、测试数据选取等工作上离不开系统功能测试人员的大力支持。其实我们可以在系统功能测试过程中提前把部分系统性能测试的工作掺杂进去，尽早解决性能问题，这样也能从一定程度上提高系统功能测试的效率，也能减轻性能测试工程师的负担。下面拿以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的技术支持。当然，非数据库的性能问题还是要借助一些测试工具来具体定位，经验丰富的开发和测试人员对此 应该很清楚如何去分析、定位。
大家在使用性能测试工具做测试的时候都比较看重监控分析这块，因为如果测试过程中的表现如果不被完整记录，我们的结果判断很可能产生一定偏差。除了性能测试工具本身自带的监控模块之外，还有一种工具叫做APM（Application Performance Management），应用性能管理，也可以称作应用性能管理解决方案，一般这些工具都能够搜集数据库的历史表现，定时更新报表，并且图形化性能趋势。这种工具不但是运营监控的好帮手，也是系统性能测试中一个比较好的支持工具。曾几何时我们用过赛门铁克的I3，可惜这种工具很早之前就被赛门铁克卖给其他公司了，后来我们就没有再继续得到这个工具的售后服务，所以性能测试监控和分析都转为使用其他工具了。后来公司在用HP Performance Manager，我发现这些工具的原理大同小异，都是不断地采集主机本身的性能参数和主机上所部署的应用的各个性能参数，搜集整理，有必要的话再图形化，这与LR的监控模块功能如出一辙。
有这些好用的监控工具，我们所需要做的就是打开监控，选择合适的数据量去进行手动功能的全面回归测试，记录操作的时间点。回归测试结束之后我们参照监控结果去分析，能够清晰的看到哪段时间物理读写频繁、哪段时间CPU飚高、哪段时间网络繁忙或者哪段时间内存吃紧。再结合我们功能测试的时间点记录，可以很快的找到一些平常被我们忽略了的问题，操作起来非常简单，只是我们都忘记了该好好利用一下我们的监控工具了。可能有人说我们买不起这些昂贵的服务，那不要紧，LR还是能用得起的，你懂的……LR的Controller中有监控模块，打开它，指定好我们需要测试执行的应用所在的物理机和应用的instance，监控一样可用，这与其他监控工具没什么差别，只是在分析时需要人工去判断一些指标数据而已。一般来说，先开监控去做全面的测试，然后再找到某一时间段的功能去有针对性的测试比较好。
建立性能基线
大家很容易理解为什么系统性能前日尚好，今天便如此之慢，因为数据量临界变化、数据库表结构变更或者程序的不合理书写等等方面都有可能带来性能问题。不过理解之外，要去有针对性地找到这些隐藏的性能问题就不那么容易了，因为系统响应的变化可能只是1、2秒的差异，或者“本来就比较慢，现在的慢与以前的慢或许没啥差别”……明显出现“上周1秒响应、本周30秒响应”的情况毕竟是少数。这些不明显的差异如果到了生产环境，在高并发的情况下很可能产生一些不可预知的故障，所以忽略这1、2秒的差异也不是什么明智的选择。
有人想到一个办法：建立性能基线，也就是依据SLA（Service Level Agreement，或称服务等级协议）去定义一组性能基线指标，定期去进行性能的回归测试。这个方法在我们部门，有些同事做得还是非常不错的，不过具体操作细节我也不是非常了解。我个人理解，要在一两个版本的周期内去实施全面的性能测试回归所需要投入的资源是相当大的，性能测试执行的频率的确值得商榷。不过有一点可以肯定，这些基线指标数据可以被看做数据字典，可以用于一个系统所有功能点的性能参照指标。我们不需要集中去进行一次大规模的性能测试，却可以在常规的系统手动测试中进行简单的所有功能点的性能分析覆盖。从道理上说，经过这种测试之后，后续的并发、压力测试所发现的缺陷数将大幅降低。
性能基线不仅可以定义在各个功能的响应指标上，也能够定义在某次的监控数据上，甚至可以使用图形化的监控结果来产生。定义好明确的性能基线指标，使用监控工具去采集分析当前的结果数据和基线数据之间的差异是比较简单可行的。
能够早点解决明显的性能问题，就能尽早发现并规避性能隐患，也能让我们的技术得到进步，所以何乐而不为呢。