性能测试十问：测试经理篇

　　现状

　　测试经理不知道性能测试人员在做什么

　　不知道性能测试进展如何

　　不知道性能测试是否有效

　　不知道如何协助性能测试人员

　　本文目的

　　了解性能测试的进展，更好的控制整个测试流程

　　了解性能测试的质量

　　十问

　　性能测试何时介入

　　性能测试的过程是怎样的

　　是否有必要提起性能测试

　　性能测试有哪些类型

　　如何分析性能需求

　　如何衡量性能

　　性能测试(不)能做什么

　　如何检验性能测试的质量

　　…

　　Q1、性能测试何时介入

　　开发生命周期中的性能测试

　　单元测试

　　代码层面的测试。写完一块代码，对代码的执行效率、内存使用、资源占用等情况进行测试，由开发人员完成。

　　组件/服务/接口测试

　　此层面的测试，通常是针对一个已完成的公用功能，此功能向外提供服务或者接口。既可以是代码级别的测试，也可以是不涉及代码的调用测试(如webservice接口)，应由测试人员完成。

　　系统测试

　　整个系统已经实现，通过模拟用户的使用对系统进行测试。我们做的性能测试主要就是这个，由测试人员完成。

　　生产环境测试

　　在系统测试通过的基础上，构建出更完整的生产环境。比如一个生产环境，部属多个系统，这些系统共同使用时可能会相互影响，需要考虑到此种情况进行测试。

　　系统测试中，何时介入呢

　　稳定版

　　→ 进入太晚，进度无法保证

　　→ 可能会影响到功能测试

　　这是测试负责人最害怕的，即测试晚期发现性能问题，修改涉及面较大，造成功能测试返工。

　　尽早

　　→ 流程可跑通

　　→ 数据无严重问题

　　等到稳定版再进入是不靠谱的，要尽早。

　　尽早到什么时候，性能测试需要哪些流程和数据呢?关注性能方案中的用户模型。

　　Q2、性能测试的过程是怎样的

　　敏捷方式的最大特点就是不断确认、不断修正、多次迭代。

　　在传统方式的测试过程中，经常出现的问题恰恰是缺少了敏捷思想中的确认过程，导致了测试方向偏离、测试有效性不够

　　当前进展到哪个阶段?

　　文档

　　步骤1～3

　　执行

　　步骤4～7

　　在传统方式中，可以很简单的将过程分为文档和执行两部分。文档过程很容易被检查，问题主要是在执行过程，这个过程有可能对测试经理是不可见的。

　　考虑这个问题：如果一次性能测试，没有提起任何问题，是否在性能报告之前的执行过程是不可知的?

　　如果现有的工作方式确实存在这个问题，该如何解决呢?

　　这就需要依靠性能测试执行过程规范和检查制度，请继续往后看。

　　Q3、是否有必要提起性能测试?

　　新项目

　　目前基本都需要进行性能测试。

　　新版本(哪些变化可能涉及性能)→ 用户量

　　用户数的增加，如推广使用、知名度提高。

　　→ 数据量

　　数据量的增加，如分布式部属变成集中式部属。

　　→ 实现改变

　　架构实现的变化，如音视频点播系统更换了流媒体服务器。

　　测试负责人的疑问主要是新版本需不需要再做一次性能测试?比如只新增加了一个功能。

　　抛开上面提到的3个方面，新增功能或模块可能会引起性能测试用户模型的变化。如果经过确认，用户模型无需变化，那自然也没必要重新测试。如果用户模型确实发生了改变，其实我觉得是有必要再次执行测试的，毕竟性能测试也算是一种自动化的测试，就应该能够持续性的运行。

　　只不过我们现在的问题是，性能测试的复用性太低，基于HTTP请求的脚本很容易失效，测试环境也总需要重新搭建，这些因素导致了性能测试的成本和投入变大，即使只是增加了一个小功能，可能也需要重头来做一次性能测试。如果有办法改变这个状况，那么每次新版本只要补充一下相关的测试代码就可以了。

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