学生选课类接口,学生在学期开始后进行选课,同一门课只允许学生选择一次,学生可以选择多门课。
单接口场景测试下,如果我想 100 并发数循环执行 5 分钟,那么是不要准备(5*60)*100 = 3000 个用户账号来进行登录,每次请求都需要进行登录,以满足实际的学生选课场景? 按上面来算如果做稳定性能场景下 持续运行 2-3h 难道要准备(3*60*60)*100 = 1080000 个用户来满足??
大胆一点,100 个用户循环登录即可,你创造 100 万个用户,其实跟 100 个用户,有什么区别?
区别就在于用户数据是不可循环使用的,一个 session 只能选一次课,重复选就会提示已选课,不走后面的落库操作
不做单接口,登陆查询剩余课程选课一起测试,这才符合真实场景
大胆一点,创建 3000 个用户和创造 100 万个用户,其实跟 3000 个用户,有什么区别?
如果有 session 限制,要么让后端再提供个接口,清除,保证这 10 个用户可循环使用。 如果在不改后端的情况下处理,那么,就只能走注册流程。。。先把 100 万个用户注册完,再一起并发循环执行。
要测试的场景不清晰。用户要不要重复选课,一共有多少门课。前置的条件要清晰
让开发把选课去重判断的代码注了,测完再加回来