一、获取测试需求
简单概括下业务逻辑,就是:发起一个消费交易,然后消费交易撤单\冲正\撤单冲中
具体的性能指标是:验证上图4个场景中的接口,在响应时间为3S和5S时,服务器的TPS值(这属于系统性能能力验证的应用领域)。
测试的系统,是代付代扣业务,系统架构相对熟悉,这里不过多介绍。
二、测试计划和方案
所谓的测试计划,无非就是某人用多久时间用什么东西什么方法完成什么事情。
由于这次性能测试需求工作量不大,且时间足够,所以就我一个人完成测试的大部分工作,当然,一部分需要开发协助。
测试方案,就是测试计划的补充和扩展。
比如这次性能测试,我预计用一周时间完成这些测试工作,设计用例、场景建模、准备测试数据、测试脚本开发、环境搭建等各需要多久时间,在哪一天甚至是上午还是下午完成这些工作。
三、执行前的准备工作
环境搭建:测试环境由于之前会员系统也进行过性能测试,测试环境搭建这一步工作量不大,开发很快就配置完成,所以这里不赘述。
场景建模:个人理解,就是考虑哪些场景下可能存在性能瓶颈,相应的设置对应的测试脚本和测试逻辑,以尽可能模拟生产环境(由于对业务蛮熟悉,这里也不赘述,需要提及的一点是:一定要理解、熟悉系统业务,因为需求的产生,就是用户+场景)
测试数据准备:测试数据准备常用的有这两种方式:将生产数据复制一份过来、开发脚本预埋造数据(但无论哪种