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

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

---

测试人员任何打造自己的个人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：
知道：偏向需求管理的规范性，需求评审、开发设计评审一定要有，要求每个环节提供必须的物料，并达到要求的门槛；
想到：知道之后，要能够想到一些问题；
做到：比如想到的问题，开发/产品能够接受并实现，在测试的时候要能够测到；
得到：总结方法论或者模型，沉淀并分享，在团队里复制能力；

基于故障注入的测试用例

基于线程安全的测试

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

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

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

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

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