软件性能测试发展方向

1、“这个网站怎么今天打开这么慢”，“这个破电脑怎么反应这么慢”，这样的话几乎所有依赖电脑工作的人都抱怨过，尤其是当你还有工作亟需处理的时候，心急如焚的心情会使你恨不得把机器给砸了。其实这些都是性能问题的典型体现。刚才说的那些小例子其实还是危害比较低的情况，由于性能问题而导致的重大问题也屡见不鲜，中国银联业务曾经因性能问题中断6个小时，导致数百万笔跨行交易无法进行，损失超过10亿。大家都知道任何一个系统或者软件的运行速度，取决于硬件配置和软件运行速度两个方面，那么我们现在遇上的性能问题是否能够随着硬件的发展而消失呢？1965年戈顿·摩尔提出了大名鼎鼎的摩尔定律，即“集成电路上可容纳的晶体

2、管数目，约每隔18个月便会增加一倍，性能也将提升一倍，同时保持价格不变。” 1971年intel 公司发明了第一款面向商用的微处理器4004，这款划时代的产品意味着人类拉开了个人电脑时代的帷幕。当时这款处理器的最高频率只有740kHz 。时光流转到2010年，现在CPU 的主频已经提升至3G 赫兹以上，摩尔定律作为一只看不见的手，依然发挥着作用。回首这30年的硬件发展，我们看见计算机的硬件运算能力在不断提升，而我们软件性能问题却始终存在。因此我们可以得出结论，性能问题不能只依靠硬件的运行速度提升来解决，更多部分需要依靠软件本身的设计和实现来解决问题。 由于性能问题的重要性，因此在软件测试行业中

3、出现了专门的性能测试，性能测试的发展历史基本和软件测试同步。以往的性能测试主要是由开发工程师来完成，主要是因为之前的性能测试只能由手工编程实现，测试人员一般缺乏性能测试的技术能力。目前随着商业化的自动化性能测试软件的出现，性能测试开始逐步由测试工程师来完成，现在通用的性能测试软件目前已经发展了至少三代产品。1、 第一代的自动化性能测试软件大概在二十年前开始，主要依靠通过特殊的硬件设备来录制键盘输入，以及回放脚本方式工作，这一代产品缺少检查点的功能，而且测试脚本很难维护。2、 第二代自动化性能测试软件出现在大约十五年前，此时录制脚本功能已经由特殊硬件设备转为软件来实现，并且增加了检查点的功能，可

4、以对软件做验证，测试的范围也比硬件方式的自动化方式大了许多。同时测试脚本语言的可读性大大增强，可维护性也比第一代产品有了极大提高。3、 在2001年开始出现第三代自动化性能测试软件，主要标志为测试框架的出现。测试框架主要改进为将测试脚本抽象化和对象化，提高了测试脚本的复用性和可维护性，同时也让非技术人员可以更方便的参与到性能测试过程中。软件性能测试主要关注于系统的三方面特性：响应性、伸缩性和可靠性，这三个方面相互制约，缺一不可。 系统的响应性是目前软件性能测试领域中被大家最熟知的特性。甚至在现在，很多性能测试工程师对于性能测试的理解只体现在响应性方面。简单来说，系统响应性主要考虑的是在一定的负

5、载情况下，系统能够在多少时间内做出适当的反应。这个特性也是一般用户在使用系统时能够获取的最直观印象，也是用户使用体验非常关键的一项特性，我们通常说系统反应太慢，其实指的就是系统响应性问题。例如大家都使用的淘宝网站，我们在使用淘宝内的订单查询功能时，就会发现在不同模块其实有着不同的响应时间。在“订单查询”模块中，我们查询三个月之内的订单信息一般都能在3秒以内出现结果，这个响应时间非常良好，而在“历史订单查询”模块中，我们查询订单一般都需要10秒以上的时间才能得到结果。这一点表明“历史订单查询”的用户体验不如“订单查询”模块。通常我们在做性能测试之前，需要对客户的性能要求做需求调研和分析，对于用户

6、使用频率非常高的功能，我们需要严格保证系统响应时间不能过长，按照现在用户通常的习惯，这些常用功能响应时间一般不能超过5秒钟（5秒钟是良好的用户体验时间的上限）。但是系统中确实可能存在非常消耗时间的功能，这些功能可能使用频率不高，但是需要做复杂的计算和处理，在现有的软硬件条件下，无论如何调优都不可能达到5秒以内的响应时间，例如比较庞大和复杂的报表等等，这些特殊功能我们最好能够在需求调研阶段把它识别出来，并且和客户确认这部分的响应时间要求，避免在性能验收的时候出现意外问题。性能测试的伸缩性和可靠性指标是我们做架构评估和容量规划等工作的重要依据。系统的伸缩性比较难以下严格定义，从最简单的情况来看，可

7、伸缩性就是系统可以做更多的事情，而更多的事情可以是响应更多的用户请求，执行更多的工作，或处理更多的数据。通常我们做性能测试需求分析时，除了需要了解系统当前最多需要处理的用户数或者事务数，还需要考虑系统未来需要处理的用户数或事务数。我们还是用淘宝系统来作例子，淘宝在2003年开发上线，系统上线前2个月，只有会员1.7万，上网商品6.2万件，日平均网页浏览量达到30万，日平均访问人次有2.5万。短短几年间，淘宝业务不断发展壮大，目前已经达到在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的规模。 在这这样的业务压力下，淘宝的系统架构就需要有良好的伸缩性，在当初的系统设计时就需要

8、考虑软件架构能够支持更多的并发用户在线使用。伸缩性要求意味着我们在做性能测试需求分析时不能只考虑目前业务的最大压力情况，同时需要考虑业务未来发展时，系统可能面临的增加压力状态。因此软件的伸缩性可以被定义为在不从根本上改变系统设计或架构的情况下，通过逐步增加系统资源的方法，让系统支持更多工作负载的能力。理想情况下，随着系统资源的增加，系统处理工作负载的能力也应等比例增加，但是从实际情况来看，实现近乎线性的伸缩性通常来说非常困难，这是由于部署在在各个系统中不同组件之间存在着必不可少的管理、协调和沟通，而这些工作同样会带来大量开销。另外在很多情况，系统架构的优劣决定了对于硬件性能是否能够充分发挥，好

9、的系统架构应该比较好的发挥出硬件性能，而不好的系统架构会由于自身设计问题，导致无法发挥硬件性能。软件可靠性是近年来越来越被业界所关注的性能测试领域。1983年美国IEEE 计算机学会对“软件可靠性”作出了明确定义，此后该定义被美国标准化研究所接受为国家标准，1989年我国也接受该定义为国家标准。该定义包括两方面的含义：（1）在规定的条件下，在规定的时间内，软件不引起系统失效的概率；（2）在规定的时间周期内，在所述条件下程序执行所要求的功能的能力；在我们在关注系统的伸缩性时，一定要同时关注可靠性。我们依旧用淘宝系统来做说明。淘宝在运行之初，用于用户数并没有特别高，因此系统压力不大，软件运行良好，

10、比较少出现系统无法使用或者失效的情况。但是当用户数不断增加时，即系统的伸缩性开始接受考验时，系统提交单据超时的错误开始频繁出现，意味着可靠性也同时出现下降。可靠性和伸缩性都是考虑在压力增加的情况下的系统反应情况，但是两者存在区别。具有良好可靠性的系统是应该是在不出现故障的情况下对不断增加的工作负载进行妥善处理的系统。此外，可靠系统不应该随着工作负载的增加而出现崩溃的情况，只允许出现系统性能的缓慢下降，即在系统伸缩性出现增加时，系统可以变慢，但不应该出现崩溃。但是当系统压力足够大时，任何系统都可能会出现崩溃。可靠性高的系统在此时需要能够迅速恢复服务，并且保存崩溃之前的数据状态，不应该出现脏数据问题。完整系统的可靠性还可以体现在不同模块中。例如淘宝系统中，商品查询模块的可靠性相对就比较低，因为大家对于查询结果出现错误的容忍度相对较高，出现错误时再做一次查询即可。但是使用订单支付等模块，特别是和费用相关的模块时，客户对于可靠性要求就非常高，这些模块一旦出现可靠性问题时，客户就会大大降低对于整个淘宝系统的信任度。因此淘宝系统架构在设计时，就必须特别关注这些模块的可靠性问题。 软件性能测试的这三个性能特性是相互制约的，响应性是系统的直观外在表现，但是没有伸缩性和可靠性保证的响应