划分性能测试的一个通俗例子
假设一个人很轻松就能背一袋米，背两袋米很吃力，最多就能背三袋米，那么★ 一般性能测试－－－我就让他背一袋米；
★ 稳定性测试－－－我让他背一袋米，但让他背着跑，看他多久累倒；
★ 负载测试－－－我让他背两袋米去跑，看他多久累倒；
★ 压力测试－－－我让他背一袋米，两袋米，三袋米，四袋米......看他背到多少袋就背不动。
:em17: :em17: :em17: :em17: 这样分，ms做得比较多的是“稳定性测试”以及“压力测试”:em17:
性能测试的几个阶段【ZT】
对于互联网应用软件，性能是其质量的一个非常重要的组成部分。作为解决软件性能问题的重要手段，软件性能测试已经广为人们所熟悉，并受到很高的关注。一般而言，性能测试都是在项目的后期才开展，被测试的对象通常是已经具备一定稳定性的产品。而实际上，性能测试应贯穿于整个软件生命周期中，和功能测试一样，性能测试也分为几个阶段。软件生命周期与性能测试
不论哪种软件生命周期模型，需求分析、设计、编码、测试和运行维护这几个阶段都是其中的基本要素，只是在不同的软件生命周期模型中可能迭代、合并、拆分或重组这几个阶段，在此不做过多的描述。与其他几个阶段相对应，测试从软件开发过程按阶段可以划分为：单元测试、集成测试、系统测试，在其他的书上可能还能见到诸如确认测试、验收测试等名词，但是前3种测试确实是最基本的测试活动，而其他的测试活动只是在某些软件开发过程中会发生。
值得注意的是，通常在谈论单元测试、集成测试和系统测试时，其实仅仅谈论的是不同阶段的功能测试；而当讨论性能测试时，绝大多数的情况是，一个已经开发完毕或基本开发完毕的软件，测试人员用一种或几种性能测试工具，以尽量模拟真实用户行为的方式对该软件进行并发操作，收集并比较不同场景的结果，然后对软件的性能进行分析，这个活动通常发生在系统测试阶段，甚至更往后的阶段，如运行维护阶段。
一直以来，性能测试跟单元测试、集成测试似乎都是绝缘的。可是它们真的应该是绝缘的吗？没有任何理由可以说明性能测试跟单元测试、集成测试无关，除非你认为“这太难了，我不会做”（这正好是本章主要想说的）或者“做这个没什么意义，浪费时间”（那么请接着往下看）。
众所周知，把测试划分为单元测试、集成测试和系统测试，而不仅仅是在最后关头做一个系统测试，其主要原因有两点：
1．同样的缺陷在不同阶段被发现，其修复成本差异极大，而越早发现缺陷，修复成本越小；
2．某些缺陷几乎只能在某个阶段被发现，即在其他阶段需要投入巨大的人力才能发现这些缺陷或根本不可能发现这些缺陷。
简而言之，对于不同阶段的测试活动，总有一些缺陷是最适合被发现和修复的。对于功能性缺陷这点早已达成共识，而对于性能性缺陷，由于性能测试本身起步较晚、性能问题比较难以暴露、早期用户对性能问题容忍度比较高、商业性能测试工具价格昂贵等原因，很多时候可能根本不会进行性能测试，或仅进行比较简单的性能测试，因此虽然性能性缺陷同样有这个特性，但却被人们遗忘了。简单地列举几个在不同阶段进行性能测试的好处。
1．在单元性能测试中运行一遍后就能发现的内存泄漏问题，如果这个问题遗留到系统测试阶段，可能需要花费几天的时间才能找到问题的所在，尤其是当Dump 内存信息后发现大量对象是到处都在使用的基本对象时，欲哭无泪可能是性能优化人员此时的真实写照，这点笔者曾有幸体验过；而实际上运行一遍单元测试的时间可能也就几分钟，此时发现问题极易解决。
2．异构系统之间的接口，通常是先完成接口，而调用接口的系统可能过很久才会完成。当然，可以等完成调用接口的系统后直接对该系统进行测试，接口的性能自然被测试到了，但是万一很不幸——性能测试结果不佳，再花费一番力气后终于确定是接口性能不佳，那可能就得大费周折地重新写接口了。更倒霉的是别的系统已经在用新的接口了，而不巧的是新老接口又不兼容（比如差一个参数什么的），那代价可就大了；如果进行过接口性能测试，问题早就发现并解决了，这时候真是想想都会笑了。
3．越早开始性能调优，调优工作就会越容易。当组件小规模的集成后即可运行并调优时，由于系统复杂度低，自然而然地性能调优的难度会比较低。很显然，性能调优是以性能测试为基础的，那么较早阶段的性能测试就很有必要了。
4．在运行维护阶段，系统已经在稳定地为用户提供服务了，这时候还需要进行性能测试吗？需要。因为生产系统可能会表现出疑似性能问题的症状，这时候性能测试是查找问题的有效手段，有助于为用户提供更好的服务；性能再好的系统也会有极限，当用户数不断增长的时候，通过性能测试来评估系统的容量，以确定系统应如何进行扩容或者需要更换新的架构，通常这称之为容量评估。
很明显，性能测试和功能测试一样贯穿于多个阶段。基本上，各阶段的性能测试包括以下几种：单元性能测试、集成性能测试、系统性能测试、多系统性能测试、容量评估、接口性能测试。接下来看看这些不同阶段的性能测试活动到底做些什么。 性能调优的难度会比较低 原帖由 daolangzhi 于 2008-7-20 18:25 发表 http://bbs.chinaunix.net/images/common/back.gif
性能调优的难度会比较低
为什么呢？能说说你的理由？:)
俺不敢苟同:em17: 如何还确定这个人的能力？
最多能背几袋米？ 原帖由 starxing 于 2008-7-22 09:56 发表 http://bbs.chinaunix.net/images/common/back.gif
如何还确定这个人的能力？
最多能背几袋米？
★ 压力测试－－－我让他背一袋米，两袋米，三袋米，四袋米......看他背到多少袋就背不动。
猩猩你居然跑来这里混:em10: 原帖由 knighter 于 2008-7-22 10:08 发表 http://bbs.chinaunix.net/images/common/back.gif
★ 压力测试－－－我让他背一袋米，两袋米，三袋米，四袋米......看他背到多少袋就背不动。
猩猩你居然跑来这里混:em10:
那么负载的参数那里来的，难道用压力测试的最大值还进行负载测试吗？ 原帖由 starxing 于 2008-7-22 10:13 发表 http://bbs.chinaunix.net/images/common/back.gif
那么负载的参数那里来的，难道用压力测试的最大值还进行负载测试吗？
性能瓶颈，是要经过测试得出的，如果负载和预期不一致，就必须对性能调优:P
负载测试不是压力测试，那几袋米例子能看出来:mrgreen:
系统瓶颈分析举例
经验举例1交易的响应时间如果很长，远远超过系统性能需求，表示耗费CPU的数据库操作，例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立的是否合理；尽量使用简单的表联接；水平分割大表格等方法来降低该值。
经验举例2
分段排除错误。测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器，这样，就可以在Web端测出的响应时间减去以上各个分段测出的时间就可以知道瓶颈在哪并着手调优。
经验举例3
UNIX资源监控（NT操作系统同理）中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。
经验举例4
UNIX资源监控（NT操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU.可以考虑增加一个处理器或换一个更快的处理器 .合理使用的范围在60%至70%.
经验举例5
UNIX资源监控（NT操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等，另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
经验举例6
Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
经验举例7
SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值