注册
注册：通过手机或邮箱注册，需要校验验证码，并绑定邮箱或手机，验证码放在库表中或 redis 里面
我的思路：
1. 通过linux时间后面截取几位（不同国家的号码位数不一样），作为手机号发起注册申请，不用随机数是因为随机数可能会重复，而注册号码不可以重复
2. 去库表中拿验证码，并发起验证码校验请求
3. 绑定邮箱（通过linux时间后面截取几位@公司名.com）
1. 通过linux时间后面截取几位@公司名.com（实际不存在公司名的邮箱地址），发起注册申请，
由于邮箱不存在，我也不能模拟真实的通过java mail等方法读取邮箱中的指定邮件的方式去拿这个验证码
2. 去库表中拿验证码，并发起验证码校验请求
产生影响：
- 这些数据产生一次后再没别的用处，测试次数越多造成的 “垃圾” 数据也越多，测试环境还好说，但是线上的话。。。，同时目前没有删除帐号的接口
结论：
所以需要 DBA 协助定期删记录
支付
支付：买了商品就要付钱，目前 weekly 环境是走沙箱（不会扣信用卡的钱）的，beta 环境是真付（目前接口测试自动化主测环境）
我的思路：
借鉴回答区的同学们的思路，一分一分的付（需要造些数据）
产生影响：
在 beta 环境需要真付，除了商品本身的钱，还得扣关税，不同国家不一样。。。
其他：
需要配置好主测试区域，后续其他国家再慢慢做
请教
大家是怎么玩转注册自动化和支付自动化这俩场景接口测试的
@Lihuazhang
请教下立华同学，
测试环境的话，注册账号可以定期清理一下，应该影响不大吧，验证码的问题，请教一下开发，给你插个桩，每次都返回指定的就行了，验证码发邮件那块的流程可以单独测试。支付的话就和退款一起做呗，支付一笔再退掉。我现在就这么搞的，反正一次一分钱，也不太心疼。第二天就退回来了
我去催饭
回复
给你插个桩，每次都返回指定的就行了
这个只能测试环境搞吧？
一分一分的付是一个 idea，但是具体的业务逻辑就没有办法覆盖了，比如某商品 10 元，新人打 7 折，老顾客 6 折，这种
我们传值的时候都会把元拆成分这样传，1 元就是 100 分。
@Innocence
嗯，我这儿也是去数据库拿验证码，已经搞定了，接下来搞支付的问题了。
你这插数据是什么意思，支付测试吗？
支付肯定要 mock 掉啊，不能每次去真付钱啊
1.关于注册验证码，从库里直接拿很方便，基于这个操作封装一个通用接口，做成绕过服务，更方便，每次取验证码直接调这个接口即可。适用于短信、图片验证码等等都行。
2.注册本身产生冗余数据，可以再封装一个删除用户的通用接口！！！注册完成，验证完毕，调用删除接口再删掉。关键下次还可以复用这份测试数据！至于怎么生成用户名或者手机号，LZ 说的没毛病。
3.支付的话，方法不一，1 分 1 分最经典。有条件的话，比如支付宝、微信，能拿到他们的测试沙盒是最好的，就想怎么付怎么付，想付多少付多少了。
（后门接口，切勿对外暴露）
微信支付宝有测试账号，详情咨询微信支付宝客服
好像办理流程要 30+ 工作日
杜哲
回复
对于制造测试基础数据（姓名，手机号码，身份证，银行卡）可以自己做出 demo 生成出来，注册前拿到 模拟数据，进行开户，充值，以及提现，可以完成，注册，充值，提现，绑卡一系列的业务场景测试