当前进展到哪个阶段？
● 文档
步骤1～3
● 执行
步骤4～7
在传统方式中，可以很简单的将过程分为文档和执行两部分。文档过程很容易被检查，问题主要是在执行过程，这个过程有可能对测试经理是不可见的。
考虑这个问题：如果一次性能测试，没有提起任何问题，是否在性能报告之前的执行过程是不可知的？
如果现有的工作方式确实存在这个问题，该如何解决呢？
这就需要依靠性能测试执行过程规范和检查制度，请继续往后看。
Q3、是否有必要提起性能测试？
● 新项目
目前基本都需要进行性能测试。
● 新版本（哪些变化可能涉及性能）
→ 用户量
用户数的增加，如推广使用、知名度提高。
→ 数据量
数据量的增加，如分布式部属变成集中式部属。
→ 实现改变
架构实现的变化，如音视频点播系统更换了流媒体服务器。
测试负责人的疑问主要是新版本需不需要再做一次性能测试？比如只新增加了一个功能。
抛开上面提到的3个方面，新增功能或模块可能会引起性能测试用户模型的变化。如果经过确认，用户模型无需变化，那自然也没必要重新测试。如果用户模型确实发生了改变，其实我觉得是有必要再次执行测试的，毕竟性能测试也算是一种自动化的测试，就应该能够持续性的运行。
只不过我们现在的问题是，性能测试的复用性太低，基于HTTP请求的脚本很容易失效，测试环境也总需要重新搭建，这些因素导致了性能测试的成本和投入变大，即使只是增加了一个小功能，可能也需要重头来做一次性能测试。如果有办法改变这个状况，那么每次新版本只要补充一下相关的测试代码就可以了。
我的想法是，性能测试要向组件/服务/接口级别靠近（见Q1），越接近底层，可复用性也就越高。另外，企业级虚拟化的建设一定要跟上，这样才不会在测试环境上浪费时间。
