该文原创为新潮质量保障技术团队中的 “上进的中年软件测试从业者”，用于技术交流分享
首先，不要怀疑，我们是专业做软件测试的，本篇内容与接口自动化相关。
又到了吃小龙虾的季节，虽然过段时间虾尾更肥美、虾黄更多，但是并不阻止各位饕客们的蠢蠢欲动，我大概去年夏天开始尝试自己做小龙虾。每家都有自己的独门秘籍来烧制美味的小龙虾，尤其是身在美食之都，说家家都有一个川菜厨子可能有点夸张，但是也足以说明成都人会吃也会做。说了这么多，还是奉上我烧麻小的步骤：
- 小龙虾三斤，青椒红椒黄瓜洋葱适量，八角花椒香叶桂皮干辣椒少许，姜蒜少许。
- 龙虾去虾线，刷干净晾干。（这里有小技巧，加少许醋浸泡龙虾 3-5 分钟反复两次，刷的时候就容易多了）
- 宽油烧冒少许青烟下龙虾中火炸五分钟捞出控油。喜欢嚼钳子的可以大火复炸 30 秒。
- 留底油下豆瓣 + 火锅底料小火炒香炒化，后下葱姜蒜香料小火炒香，下龙虾大火炒三分钟，小火放入适量料酒、老抽、生抽、盐、糖，大火炒均匀。
- 放入大瓶啤酒一瓶半（坚决不加水），大火烧开后，中火烧十五分钟，放入青红椒黄瓜洋葱焖两分钟出锅，撒上葱花即可。
昨天我做的蒜香味步骤也基本差不多。蒜一定要多，一半炒料的时候炒蒜蓉，另外一半最后一步和配菜一起焖两分钟即可。**
小龙虾对我来说和鸭脑壳、酱牛肉、猪头肉这些并没有什么特别的之处，只是不同时节的深夜，给啤酒换个搭档罢了。
言归正传，近些年架构师成为了炙手可热的职业，我接触过的架构师基本上开发做了一定的年限后：
- 集编程思想、系统架构、主流业务框架层次、各类高可用技术选型于一身。
- 并经历过系统由最初的虚拟机->微服务->容器化部署，数据库有最初的企业级 Oracle->灵活便利的 mysql->文档型 mongoDB->内存级的 Redis->便于检索的 ES->以及用于大数据的 Hbase/HadoopDB。
- 数据定时处理也由最初较为单一的数据库存储过程->spring 定时任务->开源 xxl-job。
说白了，架构师就是经历丰富，有足够经验告诉你如果采用了当前技术选型，会遇到我之前就遇到过的某某问题，导致了什么样的后果。
那么对于以上我们列举出来的各种工具和技术，对于一个公司来说，可排列组合出来的技术架构就会五花八门，尤其是面向 B 端的业务，一般情况下并没有性能方面的压力，如果没有强硬的架构师组织，在系统后续的维护、扩展和业务支撑方面，对于技术部门都将是毁灭性的。
至此，我们引入今天的主题，前端登录的那些伎俩。
做接口自动化必不可少的就是通过登录鉴权拿到登录认证信息，用于后续的接口请求。随着技术和黑客的不断升级，最原始的用户名 + 密码的表单式提交基本上已经退出了历史舞台，随之而来的就是各种登录前的骚操作。
对于普通的测试人员来说，如果我只关注我项目的测试工作，一般找找开发了解一下登录过程，基本上也能把自己项目的接口自动化做好。但是对于整个测试部门的接口自动化的实现来说，我们需要屏蔽不同的登录方式对外统一提供项目初始化过程，让项目的测试人员把更多的经历放在接口自动化的冒烟 + 业务逻辑实现（功能）上面，可以参照上一篇测试平台之自动化框架选型来获取更多介绍。
这种方式基本上是因为前端采用的表单提交的方式
<form role="form" action="/login" method="post" class="login-form">
<div class="form-group">
<label class="sr-only" for="form-username">Username</label>
<input type="text" name="form-username" placeholder="Username..." class="form-username form-control" id="form-username">
</div>
<div class="form-group">
<label class="sr-only" for="form-password">Password</label>
<input type="password" name="form-password" placeholder="Password..." class="form-password form-control" id="form-password">
</div>
<button type="submit" class="btn">Sign in!</button>
</form>
这种情况一般是前端对表单数据进行了序列化处理，然后发送给后端，可能是为了兼顾后端吧。想了解更多的请参照https://www.cnblogs.com/makexu/articles/6377617.html
从数据传输过程和密码的安全性方面来说，登录请求又会有以下三种：
这种协议方式是相对 http 的，数据在传输过程中报文自动加密。这种就不过多的介绍了。（其实我也不知道更多的细节）
很多时候我们看到密码是一串不规则的字符，并且在 html 里面可以看到了 MD5 加密的过程。
表象与 MD5 相似，但是密码更长，并且基本上以等号结尾，一般都是 RSA 加密，细心的同学应该也会发现 RSA 的公钥是 MIG 开头、AB 来结尾，感兴趣的同学可以去研究下。
那么在对密码的加密处理上面，那种方式更好呢？
在安全性方面，如果我能知道是 MD5 加密，那很容易就可以解密；反而如果采用了 RSA 加密，那么即便我告诉你是 RSA 加密，并且给你公钥，在你无法知道和公钥一对的秘钥的情况下，你是无法解密的。如果 RSA 还采用了一次性使用的情况下，那安全性将更上一个台阶。
同样在成本上面，可以参照安全性方面，实现的越复杂，那么接入的成本就会越高，比如一次性的 RSA 加密，客户端拿到公钥本身就是一次消耗。
## 实现过程&思考
对于以上所讲的各种登录验证方式，很不幸的是我都遇到了。本着平台化的原则，我们的接口自动化登录部分，针对以上的几种登录方式根据传入的不同标识，自适应去选择对应的登录并返回认证信息，做好了屏蔽登录差异。尤其是 RSA 加密，我们有自己封装好的工具可以使用，感兴趣同学可以私聊。
这只是登录的入口部分，已经五花八门了。然后对于权限维护、各业务系统在认证系统的存在形式、认证过程更是多种多样。如果这里再掺杂着图片验证码、手机验证码、三方认证等更多的认证方式。以及可能在网关层面做接口层面的限制、数据层面的处理、业务层面的分析，让本该就不富裕的技术部门更是雪上加霜。
## 结语
以上仅代表个人观点，不代表公司和部门。有不对的地方，欢迎各位来指正！可能受疫情的影响小龙虾滞销了，与往年相比至少便宜了 4-5 元，不妨参照我烧制小龙虾的步骤尝试一下。
五一假期过半，技术不能丢，期待与更多的测试小伙伴相互学习，下期见！
