Web测试需求分析，具体应该怎么做？

lsekfe

这里仅仅做记录，用于细化测试方法。
　　web性能测试不光是准备测试脚本、测试场景以及环境准备，在前期也需要很多工作。需要我们在沟通交流中投入很多精力。比如项目确认、需求确认、开发人员沟通、设计人员沟通等。这些东西一般别人不会直接告诉你，这就需要我们自己抓人去问，无论是打电话，发消息，还是跑到对方身边，只要能找到自己想要的即可。
　　一般需要确认这样几个问题：
　　项目：项目是新项目还是老项目。
　　需求文档：有没有需求文档，需求文档中有没有对于数据量、人数等进行描述。有没有特殊的性能需求。
　　历史文档：如果是老项目，那肯定有之前的测试文档了。尤其是有些项目的测试工具比较奇葩，如果有性能测试方案，那测试起来就方便很多。
　　设计人员：需要找设计人员确认数据库设计表（要过来），使用了什么样的技术（比如ajax），有没有用到缓存技术（一般都用），有没有什么需要注意的地方（比如调用外部接口的程序等）。
　　需求人员：需要找需求人员确认一下实际环境是什么样子的，包括现场环境（操作系统、数据库、中间件，网络带宽，服务器配置），使用人数、在线人数。了解整个系统是要做什么的。性能测试的时候也需要了解业务，才能更好的去分析需求。
　　根据以上内容，初步的问题确认就完成了。然后性能测试的第一步，该项目是否有可测性就可以开始分析了。
　　项目可测性
　　对于领导分配项目，首先要进行可测性验证。因为设计人员、测试经理不一定能正确评估性能测试。有些项目仅仅是设计人员觉得某个模块存在瓶颈，需要并发压一下，（出于多测比不测强的心理）然后，找到测试经理的时候就是要求进行整体性能测试了。所以在跟设计人员确认问题的时候，设计人员肯定会详细讲述那个模块需要着重测试。
　　以上是举个例子，下面描述下常见不测项目。
　　1.使用人数过少的项目（10人以内），这样的项目在功能测试的时候如果有问题就能发现了，不需要再申请做性能测试。
　　2.使用人数很多，但是在线用户数很少的（比如论坛），公司论坛可能使用人数是全体职工，公司没有强制要求必须上论坛，那可能就不需要进行性能测试。
　　3.BI项目：BI项目针对前台页面基本上不需要测试性能，因为性能瓶颈主要在数据库，可以直接优化sql。
　　4.统计查询：统计查询功能一般是领导使用。一般一个系统也就1个领导在用，所以也不涉及性能。
　　5.接口部分：有时候项目会用到一些外部接口，这些接口需要做并发测试，但是页面不需要做。
　　以上不一定符合实际情况，仅仅做参考。性能测试其实就是并发测试，所以主要关注的是用户在某一段时间的使用数量，所以判断可测性的时候可以用这个作为参考。
　　分析完项目的可测性后，确定这个项目确实有值得测试的地方，下一步就要针对项目内容进行深入测试。
　　数据量分析
　　如果是老项目，那很好办了，看看主表放了多少条数据，用了多少年，每年都有多少条数据，一个漂亮的分析就产生了。诸如第一年50000条数据每年依次递升10%，共计500000条数据等。那往后在推3年、5年，约需要制作xxxx条数据。
　　如果是新项目，那就惨了，因为没有参考，那咋整呢？我是这么考虑的，第一参考依据来自于需求人员，问问他大概多少数据量。因为现在的电子商务，一般来说都是将纸质转化成电子，如果有可能，需求人员是可以跟业务人员确认数据量的。还有一种方式就是可劲加数据，加到撑为止。什么叫撑呢，页面打开慢了，查询速度慢了就成了。然后开始优化sql，至少保证sql本身没有什么优化的余地了，那数据量分析也就到这了。（前提：这个是有前提的，时间得富裕，没时间的话都是扯淡）
　　用户数分析
　　这部分我觉得挺坑的，啥用户数量分析啊？确认了使用人数后就能分析了吗？一点参考价值都没有。（牢骚）在单位看了各种高级员工很漂亮的用户分析ppt，其实一点参考价值都没有。为啥？不管怎么分析，我觉得都是不对的，跟实际场景能对应上吗？。还不如啥都不管直接200绝对并发开始压，压到死为止呢。至少能发现在强压力破坏性测试下，那些模块不稳定了。
　　牢骚过后，开始分析
　　用户数分析是建立在良好的监控条件下的，在保证整体框架设计良好，数据库设计完善的前提下，直接上线。通过监控获取用户的使用情况、在线情况以及页面访问数量后，分析起来才有依据，这样的分析才能令人信服。这里主要是为测试人员的场景设计服务的，如果有了令人信服的数据，然后直接作用于场景，才是有效的测试。
　　监控内容需要包含
　　1.使用人数监控（共计多少人登录系统）
　　2.在某时间段内在线人数监控（时间可以调整）
　　3.页面访问次数，以及在某段时间内的访问次数
　　4.服务器参数、数据库参数变化，JVM参数变化（单位都用java）