测试人员如何打造自己的核心影响力
本文为在霍格沃兹测试开发学社中学习到的一些技术，写出来分享给大家，希望有志同道合的小伙伴可以一起交流技术，一起进步~
测试人员任何打造自己的个人IP，如何提高和打造自己的核心影响力？ 那就要进行全流程的测试，要打破常规，不仅仅局限于测试环节，而要进行测试左移和把控测试右移。
测试人员如何打造自己的核心影响力
- 一、全流程测试
- 二、 需求评审
- 三、 开发设计评审
- 四、 测试用例编写
一、全流程测试
测试人员需要改变一下自己的身份定位，不再是简简单单的测试，而应该是质量工程师；保证整条业务线的质量保障工作。不要在盯着自己面前的一亩三分地，不再做井底之蛙，否则就会被淘汰。
如何能够保证整条业务线的软件质量呢？需要进行全流程的测试；我们都知道常规的研发流程是：需求设计>需求评审>编程和编写测试用例>测试环节>发版>线上环境监控 。那什么是测试左移和右移呢？ 就是以测试环节为中心，向左或向右去辐射发力，在需求环节：能够发现需求根源的问题，能够纠正或者避免需求在传递过程中出现的误差。在代码环节：能够发现代码架构设计不合理；在发版环节，能够发现运维人员存在不规范的操作等等，质量问题可能会产生于任何一个环节，每一个环节都需要我们测试人员有应对的策略。
二、 需求评审
需求评审是一场良性的思维博弈，是产品、研发、测试 三个角色之间的博弈，各自站在自己的阵营，拿着自己的矛和盾去刺探对方，最终大家都一团“和气”（达成一致），携手并进搞事业。
测试人员如何在需求评审环节提高自己的影响力呢？那就是多问问题，多问高质量的问题，把产品问哭，让开发再也不能小看你，自然而然，你就能够博得自己的一席之地。那么测试人员如何才能提高质量的问题呢？ 可以在工作中多归纳总结自己的方法论，形成自己的套路，如下图所示：
如上图所示，可能时提供的是一个比较基础的模版 ,重点不是末端罗列出来的问题，而是和大家分享发现问题的思维模式，大家要在不断的复盘和踩坑中逐渐的总结出自己的工作方法，不断的去补充和升级内容。都可以在自己的垂直领域加上特有的问题点，比如说电商领域中，产品的秒杀、优惠的计算等等 。日积月累，久而久之，你一定可以凭实力赢得各位同学的“尊重”。
三、 开发设计评审
在开发设计的评审环节，也有找问题的方法论：
数据层面
- 表字段不能存在二义性；比如 定义了一个字段，当用户填写手机号就存手机号，当填写邮箱时，就存邮箱。不合理，应该调整为两个字段，每个字段只负责存储一种数据。
- 表字段的单一原则：定义一个字段即标识是否为部门负责人，又标识为是否有踢出权限，则该字段违背了单一职责原理，当想扩展为某些普通员工也能拥有踢人权限时，则无法扩展。不合理 ，应该单独增加一个管理员的标识。
逻辑层面
- 数据特性兼容： 有些企业，一个员工兼顾几个部门，但是接口校验一个员工只能属于一个部门，不合理。
- 功能的通用性： 某某企业，希望部门的职务信息带“部长”后缀的自动识别为部门负责人。不合理 ，不适配其他企业的情况，产品设计要通用，应该单独给定参数指定负责人 。其实这个问题应该在需求评审环节就能够发现出来。开发设计评审和需求评审两个环节是相互契合的，前者是后者的延续，都是为了让需求更加明朗。
特定技术栈
- Redis 技术栈检查套路 ： Redis 是否考虑数据的主动刷新、数据穿透、击穿、雪崩、容灾、数据恢复等问题；需要在设计初期就对这些情况进行规划。
数据穿透：
缓存穿透：缓存和数据库中都没有的数据，而用户（黑客）不断发起请求。
例子
我们数据库的 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博客
测试人员如何打造自己的核心影响力相关推荐
- 为什么互联网公司需要测试人员？
偶然在知乎上看到一篇帖子:为什么互联网公司不开除测试,转而让大众来测,找到一个bug给100元?几年测试经验下来,看到大家的讨论,深感心有戚戚焉,于是也想浅谈测试人员对于公司的重要性. 知乎原帖:ht ...
- 测试人员想做游戏测试，你一定要知道这几点！
如果你想转行游戏测试,如果你对游戏测试不太了解,如果你想知道游戏测试具体工作内容是什么,到底适合什么样的人,今天的分享会帮助你做全面了解. 01游戏测试的工作内容 我们先来说一下游戏测试的到底是什么? ...
- 开发中有没有遇到过特别难以交流的测试人员?
转自知乎:https://www.zhihu.com/question/30192685?sort=created&page=1 各位码农有没有遇到过这样的测试人员? 提了bug给你, 你看了 ...
- 为什么互联网公司需要测试人员
目录 引言 身边项目的例子 对测试大致会有以下几个方面的误解 重要的测试方法论 为什么互联网公司需要测试人员 测试人员地位为什么在团队中没有足够的被重视? bug悬赏 对测试人员考核的一些思考 总结 ...
- 随心测试_软测基础_005 测试人员工作内容
接上篇:清楚了_测试人员的工作职责范围,那每项测试活动的具体工作内容有哪些呢? Q1:如何理解测试工程师的工作内容? A1:SX的观点:综合一体化 现如今互联网行业高速发展,每一项IT职业的工作职责与 ...
- 【转】测试思考——测试人员需要具备哪些素质？
之前写的文章,今天分享出来 测试人员需要具备哪些素质? 测试人员需要具备哪些技能? 软件测试知识:测试计划.测试方案.编写用例.提交bug.跟踪bug,编写测试报告 测试工具的使用 操作系统 编写代码 ...
- 【转】测试人员的思想理念和工作方法
测试人员的思想理念和工作方法 软件测试的前提假设 测试人员进行软件测试的基本假设是"有罪推断" ,即认为被测程序一定是有bug的,而且每个功能点的实现都存在bug,而且一定存在严重 ...
- 测试人员未来的3条出路
大家好,我是Z哥. 前两天有个做测试的小伙伴加我微信问我测试相关的一些事情. 她自己是从学习毕业就开始进入到互联网行业做测试的,到现在三年工作经验.她现在都不太敢跳槽,因为觉得自己没有什么核心竞争力, ...
- 测试人员要了解的知识
写代码 测试需要学会编程吗? 我比较建议学,不用学太深,因为测试的对象就是软件,那么它们是如何构成的还是需要做一些基本的了解.有了程序员的思维,在与开发的沟通过程中也能更好的相互理解. 学哪门语言? ...
最新文章
- 秒懂Mycat和MySQL的区别【转自百度知道】
- java责任链模式做优惠_Java设计模式菜鸟系列(十八)责任链模式建模与实现
- Django之ORM(多对多)
- 【LightOJ - 1027】A Dangerous Maze（概率dp，数学期望）
- python安装百度aip_Python3.6安装aip
- 基础编程题之最大连续bit数（位运算）
- 用Python的smtp模块发邮件的示例
- 2020年Q3笔记本电脑出货量：惠普反超联想居首位 苹果第四
- mdt服务器实现自动加域,Windows自动化部署（三）MDT环境准备
- Python之爬取安居客网二手房小区详情页数据
- 51单片机小车（附源码）
- 请设计输出实数的格式，包括：⑴一行输出一个实数；⑵一行内输出两个实数；⑶一行内输出三个实数。实数用“6.2f“格式输出。
- Linux性能分析命令
- 证明：模n加法满足结合律
- fix-下拉出现白条问题
- 图形验证码 java
- 原始套接（ARP协议的使用）
- Building Worlds In Unreal 学习笔记——07-11 岩石树落木灌木绘制/溪水着色器/潮湿与焦散贴花/后处理
- 【心电监测】理论1-相关医学知识
- 《那一夜》———孙溟㠭书画