性能测试十问：测试经理篇(2)

　　我的想法是，性能测试要向组件/服务/接口级别靠近(见Q1)，越接近底层，可复用性也就越高。另外，企业级虚拟化的建设一定要跟上，这样才不会在测试环境上浪费时间。

　　Q4、性能测试有哪些类型

　　基准测试

　　比如单用户的测试或者在无数据条件下的测试，目的是提供一个标准供后续测试比对。

　　负载测试

　　向系统施加一定的压力，一般最大压力的20%或者日常使用压力即可，确保系统可正常运转。

　　压力测试

　　向系统施加预期最大压力，测试系统在繁忙状态下的性能表现。

　　容量测试

　　不断的增大对系统的压力，直至出现瓶颈。用于探测系统的瓶颈，为系统的发展提供重要信息。

　　稳定性测试

　　长时间运行的稳定情况。

　　还有很多其他类型的测试，这里只是列出了几种最常用到的，术语的定义可能也和其他资料有些差别，比如负载和压力，不过无关紧要。

　　这里需要注意的一点，在负载、压力和容量测试中，测试的依据都是用户模型，只有用户模型准确，测试的结果才会有意义。

　　提起性能测试，需要做那种测试呢?

　　一般来说，除了容量测试，其他几种都是要做的，这是得到有效测试结果的必备过程。容量测试，属于获取“额外信息”的测试，不过这种测试其实是非常有价值的，很多资料都把它列为了必做之一。

　　稳定性测试需要运行多长时间?

　　之所以会有这个疑问，其实是因为测试人员提供的结果数据没有说服力，不是证明了系统可以长期稳定运行，而只是下了个系统稳定的结论。

　　我也总和性能测试人员强调，测试的结果是要用数据来证明的，不是说测完了下一个通过的结论就可以了，这样自然要被测试经理、开发经理怀疑(尤其是你是一个新人)。

　　如果能够提供各种详尽的数据，比如测试运行12小时内，操作系统的资源利用情况、应用中间件内部的资源利用情况、甚至是程序内部的一些性能指标等等，如果这些指标足够代表系统的性能，且它们的表现是非常平稳的，那么完全可以从这个趋势推断出，即使系统运行更长的时间也将是稳定的。

　　反之，如果不提供数据，而只是描述测试运行了3天，那么自然会有“3天够不够长”的疑问，只有通过“足够长”的运行时间才能减少人们的顾虑。

　　Q5、如何分析性能需求

　　性能相关需求一般由需求人员提供，测试负责人是这些需求的第一个把关人。针对这些需求，测试负责人可以分析哪些内容呢?

　　是否全面

　　用户角度

　　→ 能不能

　　→ 快不快

　　业务角度

　　→ 吞吐量、TPS、每小时完成工作量

　　→ 处理压力的方式

　　如12306购票，当压力太大的时候，是让所有人都能得到非常慢的服务，还是保证一部分人可以正常使用、另外的人停止服务?

　　技术角度

　　→ 是否使用了某些有潜在风险的技术

　　→ 系统内部的一些资源

　　其他角度

　　→ 比如系统拥有者，要求服务器资源利用率60%左右，想想为什么?

　　是否有效

　　可行性

　　要求发送短信后能即时到达。这就是不可行的需求，因为涉及到运营商的网络。

　　可量化

　　邮件发出后，较短的时间内到达。

　　是否灵活

　　需求vs.期望

　　→ 需求是必须要达到的。比如发送即时消息，必须保证没有丢失，这时可能就要有一个到达率的指标，如果达不到100%，那就是不合格。

　　→ 期望是灵活的，比如页面响应时间3s以内，这就是一个期望，不会因为最后是3.2s而影响结论或者导致延期发布。

　　Q6、如何衡量性能

　　性能的评价标准

　　用户感受

　　用户实际的感受是最权威的评价标准。

　　明确的性能指标

　　但大多数情况无法用实际感受来进行衡量，所以我们需要能够有效代替“感受”的数据，也就是各种性能指标。

　　性能指标一般有哪些

　　响应时间

　　业务类web系统一般主要耗时在服务端，所以通常获取请求的响应时间即可，这是不涉及到客户端展现的。

原文转自：http://www.uml.org.cn/Test/201304085.asp