这里仅仅做记录,用于细化测试方法。
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)
软件测试学习资料获取关注公众号:程序员雷叔