如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。
　　当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉

　　性能测试，并非网络应用专属
　　软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：
　　1.当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时间进行处理？
　　2.当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？
　　3.杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？
　　4.是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？
　　如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。
　　获取有效的性能需求
　　一个实际的例子
　　为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。
　　这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的^_^
　　系统总容量达到日委托6000万笔，成交9000万笔
　　系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
　　实际股东帐号数3000万
　　这个例子中已经包括几个明确的需求：
　　佳并发用户数需求：每秒7300笔
　　大并发用户数需求：峰值处理能力达到每秒10000笔
　　基础数据容量：实际股东帐号数3000万
　　业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型
　　什么是“有效的”性能需求？
　　要想获得有效的性能需求，要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。
　　1.明确的数字，而不是模糊的语句。
　　结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。关于这方面的内容，在下面两篇文章中的留言内容中有精彩的讨论：
　　2.有凭有据，合理，有实际意义。
　　通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。
　　3.相关人员达成一致。
　　这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那把这个责任交给你的直属领导；如果你是领导了，那这领导也白当了
　　如何获得有效的性能需求
　　上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：
　　1.客户方提出
　　这是理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
　　2.根据历史数据来分析
　　根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了，还有周一到周五的一早一晚上下班时间。
　　3.参考历史项目的数据
　　如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。
　　4.参考其他同行类似项目的数据
　　如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。
　　5.参考其他类似行业应用的数据
　　如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。
　　6.参考新闻或其他资料中的数据
　　后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。