【转】性能测试十问：测试经理篇
现状[*]测试经理不知道性能测试人员在做什么
[*]不知道性能测试进展如何
[*]不知道性能测试是否有效
[*]不知道如何协助性能测试人员
本文目的
[*]了解性能测试的进展，更好的控制整个测试流程
[*]了解性能测试的质量
十问
[*]性能测试何时介入
[*]性能测试的过程是怎样的
[*]是否有必要提起性能测试
[*]性能测试有哪些类型
[*]如何分析性能需求
[*]如何衡量性能
[*]性能测试（不）能做什么
[*]如何检验性能测试的质量
[*]…
Q1、性能测试何时介入开发生命周期中的性能测试
[*]单元测试
代码层面的测试。写完一块代码，对代码的执行效率、内存使用、资源占用等情况进行测试，由开发人员完成。
[*]组件/服务/接口测试
此层面的测试，通常是针对一个已完成的公用功能，此功能向外提供服务或者接口。既可以是代码级别的测试，也可以是不涉及代码的调用测试（如webservice接口），应由测试人员完成。
[*]系统测试
整个系统已经实现，通过模拟用户的使用对系统进行测试。我们做的性能测试主要就是这个，由测试人员完成。
[*]生产环境测试
在系统测试通过的基础上，构建出更完整的生产环境。比如一个生产环境，部属多个系统，这些系统共同使用时可能会相互影响，需要考虑到此种情况进行测试。系统测试中，何时介入呢
[*]稳定版
→ 进入太晚，进度无法保证→ 可能会影响到功能测试这是测试负责人最害怕的，即测试晚期发现性能问题，修改涉及面较大，造成功能测试返工。
[*]尽早
→ 流程可跑通→ 数据无严重问题等到稳定版再进入是不靠谱的，要尽早。尽早到什么时候，性能测试需要哪些流程和数据呢？关注性能方案中的用户模型。Q2、性能测试的过程是怎样的敏捷方式的最大特点就是不断确认、不断修正、多次迭代。http://www.uml.org.cn/Test/images/2013040851.jpg在传统方式的测试过程中，经常出现的问题恰恰是缺少了敏捷思想中的确认过程，导致了测试方向偏离、测试有效性不够当前进展到哪个阶段？
[*]文档
步骤1～3
[*]执行
步骤4～7在传统方式中，可以很简单的将过程分为文档和执行两部分。文档过程很容易被检查，问题主要是在执行过程，这个过程有可能对测试经理是不可见的。考虑这个问题：如果一次性能测试，没有提起任何问题，是否在性能报告之前的执行过程是不可知的？http://www.uml.org.cn/Test/images/2013040852.jpg如果现有的工作方式确实存在这个问题，该如何解决呢？这就需要依靠性能测试执行过程规范和检查制度，请继续往后看。Q3、是否有必要提起性能测试？
[*]新项目
目前基本都需要进行性能测试。
[*]新版本（哪些变化可能涉及性能）→ 用户量
用户数的增加，如推广使用、知名度提高。→ 数据量数据量的增加，如分布式部属变成集中式部属。→ 实现改变架构实现的变化，如音视频点播系统更换了流媒体服务器。测试负责人的疑问主要是新版本需不需要再做一次性能测试？比如只新增加了一个功能。抛开上面提到的3个方面，新增功能或模块可能会引起性能测试用户模型的变化。如果经过确认，用户模型无需变化，那自然也没必要重新测试。如果用户模型确实发生了改变，其实我觉得是有必要再次执行测试的，毕竟性能测试也算是一种自动化的测试，就应该能够持续性的运行。只不过我们现在的问题是，性能测试的复用性太低，基于HTTP请求的脚本很容易失效，测试环境也总需要重新搭建，这些因素导致了性能测试的成本和投入变大，即使只是增加了一个小功能，可能也需要重头来做一次性能测试。如果有办法改变这个状况，那么每次新版本只要补充一下相关的测试代码就可以了。我的想法是，性能测试要向组件/服务/接口级别靠近（见Q1），越接近底层，可复用性也就越高。另外，企业级虚拟化的建设一定要跟上，这样才不会在测试环境上浪费时间。Q4、性能测试有哪些类型
[*]基准测试
比如单用户的测试或者在无数据条件下的测试，目的是提供一个标准供后续测试比对。
[*]负载测试
向系统施加一定的压力，一般最大压力的20％或者日常使用压力即可，确保系统可正常运转。
[*]压力测试
向系统施加预期最大压力，测试系统在繁忙状态下的性能表现。
[*]容量测试
不断的增大对系统的压力，直至出现瓶颈。用于探测系统的瓶颈，为系统的发展提供重要信息。
[*]稳定性测试
长时间运行的稳定情况。还有很多其他类型的测试，这里只是列出了几种最常用到的，术语的定义可能也和其他资料有些差别，比如负载和压力，不过无关紧要。这里需要注意的一点，在负载、压力和容量测试中，测试的依据都是用户模型，只有用户模型准确，测试的结果才会有意义。提起性能测试，需要做那种测试呢？一般来说，除了容量测试，其他几种都是要做的，这是得到有效测试结果的必备过程。容量测试，属于获取“额外信息”的测试，不过这种测试其实是非常有价值的，很多资料都把它列为了必做之一。稳定性测试需要运行多长时间？之所以会有这个疑问，其实是因为测试人员提供的结果数据没有说服力，不是证明了系统可以长期稳定运行，而只是下了个系统稳定的结论。我也总和性能测试人员强调，测试的结果是要用数据来证明的，不是说测完了下一个通过的结论就可以了，这样自然要被测试经理、开发经理怀疑（尤其是你是一个新人）。如果能够提供各种详尽的数据，比如测试运行12小时内，操作系统的资源利用情况、应用中间件内部的资源利用情况、甚至是程序内部的一些性能指标等等，如果这些指标足够代表系统的性能，且它们的表现是非常平稳的，那么完全可以从这个趋势推断出，即使系统运行更长的时间也将是稳定的。反之，如果不提供数据，而只是描述测试运行了3天，那么自然会有“3天够不够长”的疑问，只有通过“足够长”的运行时间才能减少人们的顾虑。Q5、如何分析性能需求性能相关需求一般由需求人员提供，测试负责人是这些需求的第一个把关人。针对这些需求，测试负责人可以分析哪些内容呢？是否全面
[*]用户角度
→ 能不能→ 快不快
[*]业务角度
→ 吞吐量、TPS、每小时完成工作量→ 处理压力的方式如12306购票，当压力太大的时候，是让所有人都能得到非常慢的服务，还是保证一部分人可以正常使用、另外的人停止服务？
[*]技术角度
→ 是否使用了某些有潜在风险的技术→ 系统内部的一些资源
[*]其他角度
→ 比如系统拥有者，要求服务器资源利用率60％左右，想想为什么？是否有效
[*]可行性
要求发送短信后能即时到达。这就是不可行的需求，因为涉及到运营商的网络。
[*]可量化
邮件发出后，较短的时间内到达。是否灵活
[*]需求vs.期望
→ 需求是必须要达到的。比如发送即时消息，必须保证没有丢失，这时可能就要有一个到达率的指标，如果达不到100％，那就是不合格。→ 期望是灵活的，比如页面响应时间3s以内，这就是一个期望，不会因为最后是3.2s而影响结论或者导致延期发布。Q6、如何衡量性能性能的评价标准
[*]用户感受
用户实际的感受是最权威的评价标准。
[*]明确的性能指标
但大多数情况无法用实际感受来进行衡量，所以我们需要能够有效代替“感受”的数据，也就是各种性能指标。性能指标一般有哪些
[*]响应时间
业务类web系统一般主要耗时在服务端，所以通常获取请求的响应时间即可，这是不涉及到客户端展现的。
[*]页面展现时间
互联网网站通常最关注展现时间，一般有更具体的指标如首屏展现时间。大家用一用淘宝或者京东就能理解了。
[*]吞吐量
[*]TPS
业务上的需求，比如百度一定会有每秒钟处理多少万次搜索请求这类的指标。
[*]特定需求的评估标准
如上面举的例子，消息到达率。这些对性能的评价标准，应该在测试设计时就明确下来，测试负责人可对此进行检查。有一点需要注意的是，性能指标是否可检测。通用的指标如页面响应时间很容易获取，所有的测试工具都可以做到。但一些特殊的指标，尤其是涉及到客户端的，可能会存在技术上的问题。比如即时通讯软件的测试中，要求最大压力时，发送信息能够在1s内到达。那么这个到达时间如何获取呢？如果没有提前做好准备，在测试执行时很可能会遇到问题，而测试人员遇到这个问题，很有可能会选择忽视它，只顾把压力加上去就算测完了。Q7、性能测试（不）能做什么web系统性能测试最常见的目的是模拟用户的实际行为，获取用户的感受。如何模拟用户的实际行为建立用户模型。即用户做什么操作、操作路径是什么、操作频率……如何建立用户模型
[*]常用业务
[*]性能敏感业务
[*]关键业务
[*]特殊关注
这里只是用户模型覆盖度的问题，实际使用的用户模型还需要很多其他信息才能建立起来。测试负责人需要重点关注和确认用户模型的建立。性能测试的覆盖率由上可知，性能测试只能覆盖系统的一部分功能。不要指望所有和性能相关的问题都由性能测试来发现。性能测试最最想发现的是瓶颈，而不是缺陷。我比较害怕听到这样的话，“生产环境的一个操作很慢，去做下性能测试吧”。Q8、如何检验性能测试的质量执行过程
[*]建立执行规范
明确定义执行过程各检查点需要的输出物
[*]指派检查人员
根据执行规范进行检查
[*]输出执行记录
测试人员都知道，设计的用例和实际的执行总是不一样的。性能测试更是如此，调整参数重新运行脚本也是一次执行，这些信息必须有清晰的记录。
[*]持续交互确认
性能报告
[*]让数据证明结论，而不是下结论
页:
[1]
