测试人员如何打造自己的核心影响力

本文为在霍格沃兹测试开发学社中学习到的一些技术，写出来分享给大家，希望有志同道合的小伙伴可以一起交流技术，一起进步~

---

测试人员任何打造自己的个人IP，如何提高和打造自己的核心影响力？ 那就要进行全流程的测试，要打破常规，不仅仅局限于测试环节，而要进行测试左移和把控测试右移。

一、全流程测试

测试人员需要改变一下自己的身份定位，不再是简简单单的测试，而应该是质量工程师；保证整条业务线的质量保障工作。不要在盯着自己面前的一亩三分地，不再做井底之蛙，否则就会被淘汰。
如何能够保证整条业务线的软件质量呢？需要进行全流程的测试；我们都知道常规的研发流程是：需求设计>需求评审>编程和编写测试用例>测试环节>发版>线上环境监控 。那什么是测试左移和右移呢？ 就是以测试环节为中心，向左或向右去辐射发力，在需求环节：能够发现需求根源的问题，能够纠正或者避免需求在传递过程中出现的误差。在代码环节：能够发现代码架构设计不合理；在发版环节，能够发现运维人员存在不规范的操作等等，质量问题可能会产生于任何一个环节，每一个环节都需要我们测试人员有应对的策略。

二、 需求评审

需求评审是一场良性的思维博弈，是产品、研发、测试 三个角色之间的博弈，各自站在自己的阵营，拿着自己的矛和盾去刺探对方，最终大家都一团“和气”（达成一致），携手并进搞事业。
测试人员如何在需求评审环节提高自己的影响力呢？那就是多问问题，多问高质量的问题，把产品问哭，让开发再也不能小看你，自然而然，你就能够博得自己的一席之地。那么测试人员如何才能提高质量的问题呢？ 可以在工作中多归纳总结自己的方法论，形成自己的套路，如下图所示：

如上图所示，可能时提供的是一个比较基础的模版 ,重点不是末端罗列出来的问题，而是和大家分享发现问题的思维模式，大家要在不断的复盘和踩坑中逐渐的总结出自己的工作方法，不断的去补充和升级内容。都可以在自己的垂直领域加上特有的问题点，比如说电商领域中，产品的秒杀、优惠的计算等等 。日积月累，久而久之，你一定可以凭实力赢得各位同学的“尊重”。

三、 开发设计评审

在开发设计的评审环节，也有找问题的方法论：

数据层面

• 表字段不能存在二义性；比如 定义了一个字段，当用户填写手机号就存手机号，当填写邮箱时，就存邮箱。不合理，应该调整为两个字段，每个字段只负责存储一种数据。
• 表字段的单一原则：定义一个字段即标识是否为部门负责人，又标识为是否有踢出权限，则该字段违背了单一职责原理，当想扩展为某些普通员工也能拥有踢人权限时，则无法扩展。不合理 ，应该单独增加一个管理员的标识。

逻辑层面

• 数据特性兼容： 有些企业，一个员工兼顾几个部门，但是接口校验一个员工只能属于一个部门，不合理。
• 功能的通用性： 某某企业，希望部门的职务信息带“部长”后缀的自动识别为部门负责人。不合理 ，不适配其他企业的情况，产品设计要通用，应该单独给定参数指定负责人 。其实这个问题应该在需求评审环节就能够发现出来。开发设计评审和需求评审两个环节是相互契合的，前者是后者的延续，都是为了让需求更加明朗。

特定技术栈

• Redis 技术栈检查套路 ： Redis 是否考虑数据的主动刷新、数据穿透、击穿、雪崩、容灾、数据恢复等问题；需要在设计初期就对这些情况进行规划。

数据穿透：

缓存穿透：缓存和数据库中都没有的数据，而用户（黑客）不断发起请求。
例子
我们数据库的 id 都是从 1 自增的，如果发起 id=-1 的数据或者 id 特别大不存在的数据，这样的不断攻击导致数据库压力很大，严重会击垮数据库。
解决

1. 增加校验。比如用户鉴权，参数做校验，不合法的校验直接 return，比如 id 做基础校验，id<=0 直接拦截；
2. 布隆过滤器，判断出一个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return。

数据击穿：

缓存击穿是指一个 Key 非常热点，在不停地扛着大量的请求，大并发集中对这一个点进行访问，当这个 Key 在失效的瞬间，持续的大并发直接落到了数据库上，就在这个 Key 的点上击穿了缓存。

解决

1. 设置热点数据永不过期；
2. 或者加上互斥锁就搞定了

雪崩

Redis缓存中大面积key失效，从而导致大量请求直接访问了数据库，大面积的缓存失效，打崩了 DB。

举例：
大量key同时过期，大面积失效，请求直接打到数据库。如果挂的是一个用户服务的库，那其他依赖他的库所有接口几乎都会报错。如果没做熔断等策略基本上就是瞬间挂一片的节奏。

解决：
对症下药，避免缓存中出现大量key同时失效的情况。

1. 设置失效时间。批量往 Redis 存数据的时候，把每个 Key 的失效时间都加个随机值就好了，这样可以保证数据不会再同一时间大面积失效；setRedis（key, value, time+Math.random()*10000）;
2. 热点数据均匀分布。如果 Redis 是集群部署，将热点数据均匀分布在不同的 Redis 库中也能避免全部失效。
3. 取消设置热点数据有一个失效时间，用更新缓存代替。或者设置热点数据永不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就好了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

参照资料：【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数据丢失场景	启动数据恢复策略，规定时间段内数据恢复，并产出恢复结果
接口服务异常	接口服务重启	开发配合制造部分实例重启场景	集群负载策略自动踢出重启实例，所有请求无异常
	集群崩溃	开发配合制造集群崩溃场景	外部接口返回对应的错误信息，内部服务需要有重试机制

基于线程安全的测试

线程安全性问题出现的三个必要条件：

1. 多线程环境
2. 多个线程共享同一个资源
3. 对资源进行非原子性操作

需求：创建部门，部门的名称不能重复；支持对部门的增删改查；

解析为何存在线程安全性问题，如下所示，三个条件都满足：

标题	事项	子项目	前置条件	预期结果
创建部门接口	并发测试	并发相同parentID、name	相同parentID、name	只有一条数据插入成功，其他请求失败
创建部门接口	分布式测试	并发相同parentID、name	分布式环境，相同parentID、name	只有一条数据插入成功，其他请求失败
修改部门接口	并发测试	并发修改部门为相同parentID、name	相同parentID、name	只有一条数据修改成功，其他请求失败
修改部门接口	分布式测试	并发修改部门为相同parentID、name	分布式环境，相同parentID、name	只有一条数据修改成功，其他请求失败
修改部门接口	数据库线程安全测试	同时并发 更新与插入操作		更新与插入操作都能够正常执行，互不影响
删除部门接口	数据库线程安全测试	同时并发 删除与插入操作		删除与插入操作都能够正常执行，互不影响

文末说明
推荐博文：接口测试经典面试题：Session、cookie、token有什么区别？_霍格沃兹测试开发学社的博客-CSDN博客