论软件自动化测试中 QR_Code 的登录的逻辑

   在日常生活中，二维码出现在很多场景，例如付款、系统登录、应用下载、乘车码等等。二维码登录本质上也是一种登录认证方式，简单地说，这认证过程主要有两个， “告诉系统我是谁” 和 “向系统证明我是谁”。例如 账号密码登录，账号就是告诉系统我是谁， 密码就是向系统证明我是谁; 手机验证码登录，手机号就是告诉系统我是谁，验证码就是向系统证明我是谁; 手机端应用扫PC端二维码，手机端确认后，账号就在PC端登录成功了。

   二维码其实与条形码类似，只不过它存储的不一定是数字，还可以是任何的字符串，你可以认为，它就是字符串的另外一种表现形式，后台有一套基于token的认证机制。这个token其实就是一串有着特殊意义的字符串，它的意义就在于，通过它可以找到对应的账号与设备信息，客户端得到这个token后，需要进行一个本地保存，每次访问系统API都携带上token与设备信息。服务端就可以通过token找到与它绑定的账号与设备信息，然后把绑定的设备信息与客户端每次传来的设备信息进行比较， 如果相同，那么校验通过，返回AP接口响应数据， 如果不同，那就是校验不通过拒绝访问。从前面这个流程，我们可以看到，客户端不会也没必要保存你的密码，相反，它是保存了token。

   为了及时知道二维码的状态，客户端在展现二维码后，PC端不断的轮询服务端，比如每隔一秒就轮询一次，请求服务端告诉当前二维码的状态及相关信息。用户用手机去扫描PC端的二维码，通过二维码内容取到其中的二维码ID，再调用服务端API将移动端的身份信息与二维码ID一起发送给服务端。服务端接收到后，它可以将身份信息与二维码ID进行绑定，生成临时token。然后返回给手机端。因为PC端一直在轮询二维码状态，所以这时候二维码状态发生了改变，它就可以在界面上把二维码状态更新为已扫描。那么为什么需要返回给手机端一个临时token呢？临时token与token一样，它也是一种身份凭证，不同的地方在于它只能用一次，用过就失效。

   手机端在接收到临时token后会弹出确认登录界面，用户点击确认时，手机端携带临时token用来调用服务端的接口，告诉服务端，我已经确认。服务端收到确认后，根据二维码ID绑定的设备信息与账号信息，生成用户PC端登录的token。这时候PC端的轮询接口，它就可以得知二维码的状态已经变成了"已确认"。并且从服务端可以获取到用户登录的token。到这里，登录就成功了，后端PC端就可以用token去访问服务端的资源了。

   以下通过尝试登录 JD 官网的例子，作具体说明。

   打开 JD 登录界面，可见 QR_Code 带有 2个 Cookies，和主 API 接口。其中在接口最后显示的 t=1657781923616表示对应的 Unix时间戳 (格兰威治秒数)。

   根据多次观察 t 后面的秒数变化，都是固定13位，在代码中可以用 round(time.time()*1000) 的方法取整 13位数。然后直接打印 cookies, 就得到 上面所提到的2个 cookies 的 key_value对的 dict 。

   把QR_Code 下载到 Local，并编码转换成 b64，结果为 b’iVBORxxxxxxx

   把多出的 " b’ " 去掉，主要方法可以用 split() 方法去 list [1] 的值，或者如果对正则熟练的，直接用 findall 去匹配。

   开始的时候介绍了 QR_Code 的 原理，后台会大概每隔一秒自动更新状态和 API 接口，从下图可见，JQuery 后面的7位数字是随机产生的，没有一个规律。因此要破解这个登录几乎不可能。

   尝试手动用手机 app 去扫描登录后，可获取相对应的 token。

   因此，要实现 QR_Code 登录，只能手动在 App 扫描后获取 token, 然后就可以在后台进行各种操作； 或者通过 Selenium 和 Appium 相结合，实现全自动扫描登录操作。关于 Appium 在自动化测试中的应用，可以看我博客相关的文章，这里不再重复演示。