谈实际项目性能测试流程

  做现在这个项目，也有一段时间了。从开始到现在，从我的leader身上学到了很多东西，也对之前的知识有了更深一层的理解。今天，在这里总结下，我所参与的实际项目的性能测试流程。

  做测试最重要的武器是什么？无可厚非，就是我们设计的case。那么，在设计case之前，测试人员需要干什么呢？没错，需要理解需求，熟悉系统，作为性能测试人员依然如此。在项目的初期，我们需要熟悉自己的系统，对系统进行分析，通过分析掌握以下几点：

1、系统的哪些功能点需要做性能测试

2、系统的业务流程当前是否稳定？哪些地方可能存在后期脚本优化的难点？难点是什么？

3、对于需要做性能测试的功能特性，相关的性能测试的数据是怎么样的？例如：多少系统用户数?多少在线用户数？多长时间段的多少用户同时或什么样的方式加载？等

在前期对系统熟悉，分析之后，就需要动手进行case的设计了，那么，标准的或者说规范的性能测试的case需要包括功能测试用例所要包含的步骤以外，我们还需要加入，多少用户？做什么样的行为？预期的性能指标是什么样子的？实际的性能指标是什么样子的？至于性能指标的分类，你可以分的很细也可以做在一张表，只要能表达出相关的意思就可以了。

 在我们完成了对系统的熟悉，业务流程的单用户单循环脚本的录制，replay-verify，case的设计（也可以说是我们后期创建，实现场景的指导）之后，我们就可以实现我们的case，也就是实现我们的场景了。在这个过程中，我们可能需要对我们的脚本做transaction的添加，做rendezvous的设定，做参数化，做自定义的函数的开发，调用等等等等，也就是--性能测试当中的脚本的调优。在这一部分完成之后，我们就可以进入我们的场景的运行和监控了。

  在监控的过程中，我认为比较难把握的就是：到底需要监控哪些监视器。有时候，我们习惯性的一堆往上面堆，但是却不知道添加这个的目的是什么？这个是不可取的，我个人认为，你添加一个计算器去监控，就应该知道这个计算器的阀值，达到了多少，出现了什么状况就可能是什么问题。比如：监控数据库服务器，发现lock wait/sec的值一直在爬高，那可能就死锁了，这个时候就需要查看数据库，看当前的锁等待和锁竞争，事务执行的状况等。

  当然，性能测试工程师，在我看来一直是，如果能做到问题的定位和调优，就是很优秀了，呵呵。。。。。。很多情况下，我们还是需要专业的DBA和开发，架构师一起，才能更好的定位和调优问题。只是，我们应该努力的pursue。只有这样，我们做了初步的定位和优化建议，才能使得我们最后的一步，性能测试总结和报告的发布更加的锦上添花。

在这一块，我自己也还做的不好，on the way~~~~but,i believe if you can dream it you can do it.

share this sentence to my every friends.Thanks~~~~