这两天看了培训视频，做一下简单的总结内容
1、一般情况的服务访问用户 —> 端（H5/native/web） —> 网关 ---- >(负载均衡) —> 微服务集群（依赖服务集群、大数据计算架构、数据库等存储）
正常的肯定比这个复杂，此处简单介绍几个点：
网关、负载均衡
- 网关 ：
- 功能
① 基础的负载均衡
② 映射
前端映射到网关地址1，网关地址2 映射到后台访问的服务，从而实现前端后台之间的访问关联
也避免了前端修改内容，后台需要变更，后台更改内容，前端需要变更的情况，前端多对一，后台一对多，从而更好地实现前后端隔离
③ 部分网关具有加密SDK
由于协议都会走网关，例如密码等内容，通过抓包是可以获取到的，或者需要制定一个加密规则进行加密，而部分网关具有加密功能，可以使用网关自带的加密SDK，在内容发送出来之前，就已经加密
- 功能
- 负载均衡
- 功能
均衡负载
例如，每台服务器，最大支持5W请求，现有50W请求量，我们可以增加设备，并根据不同的服务器性能设置负载量，从而使每台服务器的性能都在合理范围内
- 功能
这个图，感觉挺不错的，直接拿来用了
在这里，学到两个词：测试左移，测试右移
左移：偏研发
右移：偏交付
也就是说，测试的技能，不单单是只和测试相关，还可以扩展到开发、交付层级，同时也说明，测试的技能面可能会更广，上升空间更大，对测试人员本身的要求也就更高
这里就涉及到几个常见的测试流程了：
敏捷开发
持续集成
持续交付
DevOps
其实最终目的都是希望开发交付上线时更快速
-
敏捷开发
原则：
①：递增。将大的目标分解为小的目标，通过持续完成小的任务，最终实现完整的需求
②避免不必要的开销。认为面对面沟通比书面沟通更加快捷有效，减少不必要的书面文档内容，将更多的时间投入到产品的研发中
③：协作。 -
DevOps
首次将运维加入到研发过程中
运维的中心思想是保证稳定性，但是项目的持续发布，就会导致不稳定，与运维的思想相矛盾，此时出现了DevOps -
持续集成、持续交付、持续部署
其中
实现持续集成的重要工具是：Jenkins
实现持续交付、持续部署重要工具是：docker
目前，由于追求的交付更快，会给测试带来更多的测试压力，交付快，意味着测试时间的压缩。
持续交付的三大支柱：
持续集成、自动化测试、自动部署
压力也带来提升，基本可以看到，测试现在不仅限与基础的功能测试，大家招聘的要求也越来越高，反向逼迫测试人员技术能力的提升
这里我也不懂，我只能拿别人的来直接展示
APP客户端发布
- 内部测试交付
Jenkins自动打包，打包完成后，会有自动通知，在Jenkins上可以拿到最新的下载包，测试团队可以进行对应的手工测试 - 灰度交付
内部测试完成后，会减小用户量，回复发布，方式很多，如test flight、灰度比设置，并且可以通过bugly等工具，对发布后产生的问题进行追踪 - 正式发布（全量）
Android：上传渠道包
iOS：上传到AppStore
后台发布
这里不太懂，直接给PPT截图吧
由于最近在新公司，功能测试，每天加班迭代，正好看到这个，觉得有点道理，就贴出来了，可以看看，求同存异
其中，新功能测试，目前来说，还是需要人工手动点点点来验证，但是回归测试，小版本、大版本测试，是不是可以通过自动化，来实现用例分层，从而减少测试人员手动点点点的时间，从而达到更快的交付呢？？？
❖策略改进⽅案
- 使⽤分层测试策略，控制UI⾃动化测试规模
- 少数核⼼⽤例交给⾃动化测试
- ⼤部分的基础回归测试交给⾃动遍历
- 新功能测试交给⼈⼯测试
❖技术改进⽅案
- 良好的维护模型：PageObject或者其他更简单的封装
- 更好的框架⽀持：增加Watch，智能等待，失败重试等机制
- 流程自动化
- 打包自动化（Jenkins）
- 环境自动化（Docker）
- 测试自动化
- UI自动化（selenium、appium……）
- 接口自动化（restassured、soapUI、requests……）
- 专项自动化（LeakCanary、BlockCanary……）
很多测试人员在学习的时候，包括我自己，可能学习的时候，更多的侧重于测试自动化中的UI自动化以及接口自动化。对于流程自动化其实考虑的会比较少，这个地方是一个遗漏点。
其次就是专项自动化。特别是在移动端测试时，很多人会考虑电量的测试，兼容的测试等等，但是大多数都没有往自动化这方面想，这也是一个欠缺的地方。
包括UI自动化、接口自动化，很多人用selenium、appium、requests，其实只是因为这个比较主流，但是没有自己真正去调研一下为什么这些工具用起来更好更方便。
以上，是值得让我自己反思的地方
