登录与注册背后

一张图认识了解登录与注册方式：

以上是常见的登录注册方式，所以登录注册并不是简单的两个接口，针对不同类型的登录注册方式，有不同类型的接口。

登录注册与安全

安全措施之账号

登录注册也并不是简简单单的任何账号能登录能注册就行，其实账号是涉及安全最多的地方，所以在注册时，就需要把风险前置。
例如针对注册防控，安全检测接入阿里注册风险评估，阿里注册风险评估主要是针对手机号码进行评分，根据分数进行评估，风险系数高的账号是没有办法注册成功的。

同时，也可以根据手机号的注册次数进行黑，白，灰等级区分。这里要介绍两个概念性的东西，可以更好的理解。

什么是黑产？什么是灰产？他们是做什么的？我们常见的app,比如盒马生鲜，美团买菜，每日优鲜，新用户注册总是会赠送一堆新人优惠券，或者一些活动，你在邀请新用户或者分享时，会收到赠送券等。所以这时就有一些产业，专门进行操作，来薅这些公司的羊毛。

什么是黑产？

黑产就是拿一些虚拟账号或者从猫池中拿手机号进行薅羊毛操作，那什么是虚拟账号呢？比如一些流量卡；猫池又是什么？猫池就是运营商未出售，用户未开通的手机号。黑产手段低级，是可以通过阿里注册风险评估阻挡在外，因为可以针对这类账号的注册进行语音验证码，他们是无法接收语音验证码的。

什么是灰产？

灰产的手段要比黑产高明一些，他们是拿一些真实的手机号进行薅羊毛操作。例如，到乡下收集手机号，这时对于这些账号的风险控制，只能是注册成功后，观察他们的业务行为，各个公司根据自己的情况自己制定规则进行风险控制。比如账号黑，白，灰，名单的设定。

账号黑白灰等级

手机号黑白灰等级如何划分？

安全措施之极验

不论你登录或者注册任何app时，有没有在发送验证码的时候出现一个弹框，有时是叫你拼图，有时叫你选汉字等等。这个弹框其实就是极验，那么极验的作用是做什么？极验的作用是防刷，现在市场上的app各式各样，大家都是竞品。不防止有时候会有一些刷接口操作，如果没有这一防护，很可能你的服务会被刷挂，所以极验也是一种安全措施。

安全措施之用户信息

你注册的手机号，设置的密码，设置的地址，以及用户名这些信息都是会存入所使用产品的数据库。这些信息都是你的个人隐私，那是不是这个公司的后端人员只要查数据库就能看到你的全部信息？其实不是，在这个数据值钱的年代，如果数据都是铭文存储的话，那一旦数据泄露都是安全风险和钱。所以符合安全规范的公司，针对你的手机号，密码，地址都会进行加密后，在存储进数据库。
例如：
mobile：156 **** 7853；
address：北京市朝阳区******1单元12号
密码：#@#@#¥##@#@!!@$%^
所以就引入了加密和解密，不同公司使用的加解密算法也不一样，因此加解密也是登录注册测试的一部分。
还有一种安全类措施是敏感词脱敏，就比如你所起的用户名中有一些敏感词，比如一下脏话或者敏感人群的姓名，这类词会进行脱敏操作，你虽然起了，但是也无法生成展示，通常会以***代替。

鉴权

用户一旦登录成功，之后的每一个请求都会带着鉴权所签发的token，用来访问该权限下能访问的路由服务和资源。常见的鉴权有传统session鉴权，JWT鉴权

传统的session鉴权

1.客户端向服务端发送用户名和密码进行登录操作
2.服务端验证通过后，保存当前对话（session）的相关数据，比如用户角色，登录时间等等。
3.服务端返回一个session_id给客户端，客户端得到这个ID存入cookie
4.客户端之后的每一次请求，都会通过cookie，将session_id传回服务端。
5.服务端收到session_id，找到之前保存的数据，由此得知客户端的身份。

缺点：扩展性不好，单机容易实现，如果是集群或者是跨域的读物架构，需要session数据共享。一旦session持久层宕机，会出现单点失败问题。

JWT鉴权

JWT：JSON Token Web 是一个开发标准，它定义了一种紧凑独立的基于JSON对象在各个之间安全地传输信息的方式。这些信息可以被验证和新人，因为它是数字签名。JWTs可以使用一个密钥（ HMAC算法），或使用RSA的公钥/私钥密钥对对信息进行签名。由于其体积小，JWTs可以通过URL/POST参数或者HTTP请求头部参数进行传递，体积小也意味着其传输速度相当快；有效负载包含了所需要的关于用户的所有信息，避免了多次查询数据库的需要。
用户一旦登录，之后的每一个请求都会带上这个JWT，用来访问该token权限下的路由，服务和资源。由于JWT开销小，能解决跨域问题等特点，被广泛应用于SSO.

1.客户端收到服务端返回的JWT，可以存储在cookie里面，也可以存储在localstorage。
2.客户端之后每次与服务端通信都要带上这个JWT，但是若放在cookie中，不能跨域，最好是放在 Bearer 模式下的 HTTP 请求的头信息 Authorization 字段里。
Authorization: Bearer token
或者是跨域的时候，放在post请求的数据体里。

优点：
1.因为json数据格式的通用性，所以JWT是可以是跨语言的，主流语言都可以支持
2.payload的部分可以存储其他业务逻辑必要的非敏感信息（此处一定是非敏感信息，因为可以解密）
3.构成简单，字节占用小，便于传输
4.不需要在服务端保存会话信息，易于应用的扩展和安全等。
缺点：
JWT一旦签发，到期就会始终失效，所以使用需要考虑续约问题。

中台登录注册

不同的公司登录注册业务逻辑是不一样的，这边只记录一些中台测试思想。

数据交互服务

作为服务端测试在测试之前一定要搞清楚当前要测服务主要是做什么的，规范的项目一般是有专门与数据库交互的服务，所有的CRUD操作基本是都是在这个服务。所以如果是测这个服务的需求，在需求逻辑正确的情况下，重心应该是数据的入参，入库数据，每个字段，每种数据类型，数据库唯一索引，都要正确保证。
测试中过程中，注意请求日志以及入库数据是否该加密的数据都按要求加密。

业务逻辑服务

业务逻辑服务，更多偏向的就是业务逻辑。
例如：
1.密码登录密码错误次数过多
2.验证码错误次数超过几次失效
3.验证码使用后，是否失效
4.密码修改成功后登录态，原token是否失效
5.验证码在规定时间内未使用，之后使用是否失效。
6.有登录注册，就有注销，账号的注销，是否是把所有的用户的关联信息都物理注销干净。
7.多设备登录等
登录注册的case网上详细的一大堆，这边不一一列举。

作为中台，有多业务方接入，作为中台QA如何保证质量？
首先，是要对自己底层业务非常了解，case覆盖全面，尽量做到代码全部覆盖。其次，要深入了解各个上游业务线影响他们主流程中的字段，也就是对他们最有用的数据，不同的业务其实需要和看中的字段是不一样的。当你对这些有所把控的时候，底层在怎么改，所有的风险控制你是可以把控的。最后，在与上游业务方联调的时候，记录总结各个业务线的特性，要帮他们多关注数据的入库，很多业务测的同学他们是不关心数据的落库。还有一个宗旨就是，不论怎么改，登录与注册主体功能，不能影响用户使用

在底层做修改时，上线前，问题前置，通知上游各个业务方的QA,进行主流程回归。也可通过上下游自动化联动，有问题的自动化case联系对应的QA 一起排查问题。

影响面较大需求，需要提前拉群，邮件通知，确定风险点，检查改动接口的流量，上线可以灰度上线，观察日志流量，这样如果有问题影响面也会较小。