web性能测试需求分析(一)

这里仅仅做记录，用于细化测试方法。

web性能测试不光是准备测试脚本、测试场景以及环境准备，在前期也需要很多工作。需要我们在沟通交流中投入很多精力。比如项目确认、需求确认、开发人员沟通、设计人员沟通等。这些东西一般别人不会直接告诉你，这就需要我们自己抓人去问，无论是打电话，发消息，还是跑到对方身边，只要能找到自己想要的即可。

一般需要确认这样几个问题：

项目：项目是新项目还是老项目。

需求文档：有没有需求文档，需求文档中有没有对于数据量、人数等进行描述。有没有特殊的性能需求

历史文档：如果是老项目，那肯定有之前的测试文档了。尤其是有些项目的测试工具比较奇葩，如果有性能测试方案，那测试起来就方便很多。

设计人员：需要找设计人员确认数据库设计表（要过来），使用了什么样的技术（比如ajax），有没有用到缓存技术（一般都用），有没有什么需要注意的地方（比如调用外部接口的程序等 ）。

需求人员：需要找需求人员确认一下实际环境是什么样子的，包括现场环境（操作系统、数据库、中间件，网络带宽，服务器配置），使用人数、在线人数。了解整个系统是要做什么的。性能测试的时候也需要了解业务，才能更好的去分析需求。

根据以上内容，初步的问题确认就完成了。然后性能测试的第一步，该项目是否有可测性就可以开始分析了。

项目可测性：

对于领导分配项目，首先要进行可测性验证。因为设计人员、测试经理不一定能正确评估性能测试。有些项目仅仅是设计人员觉得某个模块存在瓶颈，需要并发压一下，（出于多测比不测强的心理）然后，找到测试经理的时候就是要求进行整体性能测试了。所以在跟设计人员确认问题的时候，设计人员肯定会详细讲述那个模块需要着重测试。

以上是举个例子，下面描述下常见不测项目。

1.使用人数过少的项目（10人以内），这样的项目在功能测试的时候如果有问题就能发现了，不需要再申请做性能测试。

2. 使用人数很多，但是在线用户数很少的（比如论坛），公司论坛可能使用人数是全体职工，公司没有强制要求必须上论坛，那可能就不需要进行性能测试。

3. BI项目：BI项目针对前台页面基本上不需要测试性能，因为性能瓶颈主要在数据库，可以直接优化sql。

4. 统计查询：统计查询功能一般是领导使用。一般一个系统也就1个领导在用，所以也不涉及性能。

5.接口部分：有时候项目会用到一些外部接口，这些接口需要做并发测试，但是页面不需要做。

以上不一定符合实际情况，仅仅做参考。性能测试其实就是并发测试，所以主要关注的是用户在某一段时间的使用数量，所以判断可测性的时候可以用这个作为参考。