本文为在霍格沃兹测试开发学社中学习到的一些技术，写出来分享给大家，希望有志同道合的小伙伴可以一起交流技术，一起进步~
测试人员任何打造自己的个人IP，如何提高和打造自己的核心影响力？ 那就要进行全流程的测试，要打破常规，不仅仅局限于测试环节，而要进行测试左移和把控测试右移。
一、全流程测试
测试人员需要改变一下自己的身份定位，不再是简简单单的测试，而应该是质量工程师；保证整条业务线的质量保障工作。不要在盯着自己面前的一亩三分地，不再做井底之蛙，否则就会被淘汰。
如何能够保证整条业务线的软件质量呢？需要进行全流程的测试；我们都知道常规的研发流程是：需求设计>需求评审>编程和编写测试用例>测试环节>发版>线上环境监控 。那什么是测试左移和右移呢？ 就是以测试环节为中心，向左或向右去辐射发力，在需求环节：能够发现需求根源的问题，能够纠正或者避免需求在传递过程中出现的误差。在代码环节：能够发现代码架构设计不合理；在发版环节，能够发现运维人员存在不规范的操作等等，质量问题可能会产生于任何一个环节，每一个环节都需要我们测试人员有应对的策略。
二、 需求评审
需求评审是一场良性的思维博弈，是产品、研发、测试 三个角色之间的博弈，各自站在自己的阵营，拿着自己的矛和盾去刺探对方，最终大家都一团“和气”（达成一致），携手并进搞事业。
测试人员如何在需求评审环节提高自己的影响力呢？那就是多问问题，多问高质量的问题，把产品问哭，让开发再也不能小看你，自然而然，你就能够博得自己的一席之地。那么测试人员如何才能提高质量的问题呢？ 可以在工作中多归纳总结自己的方法论，形成自己的套路，如下图所示：
如上图所示，可能时提供的是一个比较基础的模版 ,重点不是末端罗列出来的问题，而是和大家分享发现问题的思维模式，大家要在不断的复盘和踩坑中逐渐的总结出自己的工作方法，不断的去补充和升级内容。都可以在自己的垂直领域加上特有的问题点，比如说电商领域中，产品的秒杀、优惠的计算等等 。日积月累，久而久之，你一定可以凭实力赢得各位同学的“尊重”。
三、 开发设计评审
在开发设计的评审环节，也有找问题的方法论：
数据层面
- 表字段不能存在二义性；比如 定义了一个字段，当用户填写手机号就存手机号，当填写邮箱时，就存邮箱。不合理，应该调整为两个字段，每个字段只负责存储一种数据。
- 表字段的单一原则：定义一个字段即标识是否为部门负责人，又标识为是否有踢出权限，则该字段违背了单一职责原理，当想扩展为某些普通员工也能拥有踢人权限时，则无法扩展。不合理 ，应该单独增加一个管理员的标识。
逻辑层面
- 数据特性兼容： 有些企业，一个员工兼顾几个部门，但是接口校验一个员工只能属于一个部门，不合理。
- 功能的通用性： 某某企业，希望部门的职务信息带“部长”后缀的自动识别为部门负责人。不合理 ，不适配其他企业的情况，产品设计要通用，应该单独给定参数指定负责人 。其实这个问题应该在需求评审环节就能够发现出来。开发设计评审和需求评审两个环节是相互契合的，前者是后者的延续，都是为了让需求更加明朗。
特定技术栈
- Redis 技术栈检查套路 ： Redis 是否考虑数据的主动刷新、数据穿透、击穿、雪崩、容灾、数据恢复等问题；需要在设计初期就对这些情况进行规划。
数据穿透：
扫描二维码关注公众号，回复： 14624427 查看本文章
缓存穿透：缓存和数据库中都没有的数据，而用户（黑客）不断发起请求。
例子
我们数据库的 id 都是从 1 自增的，如果发起 id=-1 的数据或者 id 特别大不存在的数据，这样的不断攻击导致数据库压力很大，严重会击垮数据库。
解决
- 增加校验。比如用户鉴权，参数做校验，不合法的校验直接 return，比如 id 做基础校验，id<=0 直接拦截；
- 布隆过滤器，判断出一个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。
数据击穿：
缓存击穿是指一个 Key 非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个 Key 在失效的瞬间，持续的大并发直接落到了数据库上，就在这个 Key 的点上击穿了缓存。
解决
- 设置热点数据永不过期；
- 或者加上互斥锁就搞定了
雪崩
Redis缓存中大面积key失效，从而导致大量请求直接访问了数据库，大面积的缓存失效，打崩了 DB。
举例：
大量key同时过期，大面积失效，请求直接打到数据库。如果挂的是一个用户服务的库，那其他依赖他的库所有接口几乎都会报错。如果没做熔断等策略基本上就是瞬间挂一片的节奏。
解决：
对症下药，避免缓存中出现大量key同时失效的情况。
- 设置失效时间。批量往 Redis 存数据的时候，把每个 Key 的失效时间都加个随机值就好了，这样可以保证数据不会再同一时间大面积失效；setRedis（key, value, time+Math.random()*10000）;
- 热点数据均匀分布。如果 Redis 是集群部署，将热点数据均匀分布在不同的 Redis 库中也能避免全部失效。
- 取消设置热点数据有一个失效时间，用更新缓存代替。或者设置热点数据永不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就好了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。
参照资料：【Redis】数据击穿、穿透和雪崩
- MQ技术栈检查套路：MQ丢消息、时序性等问题。循环推送和成功状态回写、接收消息回调获取最新消息。
- Task技术栈检查套路：任务防重措施、防漏措施、处理结果幂等性。首先要确定任务处理幂等性，调整合适的偏移量和执行频率。
- DB技术栈检查套路：是否存在锁表问题、数据线程安全。当前读条件是否添加索引，共享数据争抢的逻辑是否加线程锁和分布锁。
四、 测试用例编写
一个优秀的合格的测试人员要做到以下的四Dao：
知道：偏向需求管理的规范性，需求评审、开发设计评审一定要有，要求每个环节提供必须的物料，并达到要求的门槛；
想到：知道之后，要能够想到一些问题；
做到：比如想到的问题，开发/产品能够接受并实现，在测试的时候要能够测到；
得到：总结方法论或者模型，沉淀并分享，在团队里复制能力；
基于故障注入的测试用例
| 事项 | 子项目 | 前置条件 | 预期结果 |
|---|---|---|---|
| Redis 故障 | TokenRedis 数据丢失 | 开发配合清空Redis数据 | 获取Token请求，击穿Redis从DB中获取到正常的数据，并回写Redis |
| 开发启动Redis数据恢复功能 | 获取Token请求，可以从Redis中获取正确的Token数据 | ||
| TokenRedis 奔溃 | 开发配合制造Redis 奔溃场景 | 获取Token请求，降级从DB中获取到正常的数据 | |
| MQ故障 | MQ消息积压 | 开发配合制造MQ消息积压场景 | 创建部门消息可以正常接收，故障恢复后，积压消息正常处理，数据无丢失，速率正常，无时序性问题 |
| MQ 崩溃 | MQ 崩溃 | 开发配合制造MQ崩溃场景 | 新请求应该有对应的返回信息，已经进入的数据应有还原策略 |
| DB | DB崩溃 | 开发配合制造DB崩溃场景 | DB多活策略启动，功能正常无影响 |
| DB数据丢失 | 开发配合制造DB数据丢失场景 | 启动数据恢复策略，规定时间段内数据恢复，并产出恢复结果 | |
| 接口服务异常 | 接口服务重启 | 开发配合制造部分实例重启场景 | 集群负载策略自动踢出重启实例，所有请求无异常 |
| 集群崩溃 | 开发配合制造集群崩溃场景 | 外部接口返回对应的错误信息，内部服务需要有重试机制 |
基于线程安全的测试
线程安全性问题出现的三个必要条件：
- 多线程环境
- 多个线程共享同一个资源
- 对资源进行非原子性操作
需求：创建部门，部门的名称不能重复；支持对部门的增删改查；
解析为何存在线程安全性问题，如下所示，三个条件都满足：
| 标题 | 事项 | 子项目 | 前置条件 | 预期结果 |
|---|---|---|---|---|
| 创建部门接口 | 并发测试 | 并发相同parentID、name | 相同parentID、name | 只有一条数据插入成功，其他请求失败 |
| 创建部门接口 | 分布式测试 | 并发相同parentID、name | 分布式环境，相同parentID、name | 只有一条数据插入成功，其他请求失败 |
| 修改部门接口 | 并发测试 | 并发修改部门为相同parentID、name | 相同parentID、name | 只有一条数据修改成功，其他请求失败 |
| 修改部门接口 | 分布式测试 | 并发修改部门为相同parentID、name | 分布式环境，相同parentID、name | 只有一条数据修改成功，其他请求失败 |
| 修改部门接口 | 数据库线程安全测试 | 同时并发 更新与插入操作 | 更新与插入操作都能够正常执行，互不影响 | |
| 删除部门接口 | 数据库线程安全测试 | 同时并发 删除与插入操作 | 删除与插入操作都能够正常执行，互不影响 |
文末说明
推荐博文：接口测试经典面试题：Session、cookie、token有什么区别？_霍格沃兹测试开发学社的博客-CSDN博客