相信现在很多公司都有专职的性能测试工程师，但是数量不会很多.。对于项目来说是几乎都会有性能测试的，而在日常中,性能测试并不是每个都需要的。当然有人说宁可错杀一千，也不放过一个：），这个是可以，不过需要多少的时间和资源啊，对于日常这种发布期暴紧、数量暴多的任务，显然不能这样，因此就需要制定一个明确的流程来保证它，保证需要性能测试的日常能高效率的做好，而不需要做的可以放过，以免浪费时间和资源。那么怎么的流程才能做到这一点呢？我来简单的说一下，抛砖引玉。
第一阶段：我们性能测试介入点是在系统分析师（简称系分）在根据PRD编写系统设计时介入的，我们提供性能回归点及性能基准数据，由系分来识别新的性能点。然后根绝这些性能点，设定出性能目标。
第二阶段：在日常需求评审时，可以向开发人员了解开发的具体情况、实现方法，进一步识别是否需要变更性能点。
第三阶段：开发完毕合并后，功能测试人员开始测试，我们就可以进行性能测试服务器的配置，更新分支，准备测试数据。并在性能点的功能无bug后开始性能点的测试（性能回归点的脚本是统一的复用，新性能点的脚本需要制作，测试完毕后需要上传cvs脚本库中，以便以后复用）。运行时间根据有多少个日常需要测试等实际情况来定，但每个脚本运行时间不得低于20分钟。
最后了，将测试结果分析后写成日常性能测试报告发给开发与系分，并同时将测试结果数据更新入性能基准数据库中。同时需要将分支编号、系统变更情况写入。
看上去似乎很多步骤，其实时间一共只有1-2天时间而已，所以日常性能回归是比较繁忙的，但同时也是意义重大的，因为有了这样的回归，才能最大限度的保证日常发布的性能。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1758320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
