📋 个人简介

•  作者简介：大家好，我是凝小飞，软件测试领域作者
• 支持我：点赞👍+收藏⭐️+留言📝

整个文章来源于我的xmind梳理和总结，接下来为各位一步步拆解。

一、测试流程遵守和推进

在日常测试过程中，因为是团队协作，涉及到不同的工种不同的时间节点做不同的事情，有主次之分，有先后顺序之分，有上下依赖之分，故没有规矩不能成方圆，必须有红绿灯一样的规则的，大家默认遵守，红灯的时候停，绿灯的时候行。这样有利于整个团队业务的研发效率，不至于因为没有人指挥出现瘫痪状态。在研发领域，这个就是流程规范。

对于测试人员而言，更加需要这个流程规范，因为测试同学在整个流程偏后一点的时间重点介入，前面环节产出质量的好坏，决定了测试人员把关的质量和效率，也决定这个项目的质量健康度。

对于初级测试同学，团队中制定的流程规范，我们严格遵守，主要是在执行过程中去思考，为何要制定这样的流程，对整个团队研发效率有怎么样的好处。这个思考有利于在下个阶段，成为一个提出流程改进的发起者，倡导者。

对于中高级测试同学，需要在日常的每次迭代中总结和复盘，针对性地提出自己的想法，推动流程的改进，让每个想法能够落地，能够产生效果。这就是一个创造性的产出，能够提升效益的。这样的产出是正向的，有价值的。

二、测试分析和测试策略执行

同样一个业务，同样的测试内容，不同测试同学发现bug的效率，质量，深度都可以是不一样的。这个基本功就体现在测试分析上，从多个角度去观察发现，从而制定相应的测试策略。我相信这个测试分析和测试策略制定和执行过程，考察了一个测试的业务测试能力，是面试官一般从各种项目经验里面最想深挖出来的东西。而这些经验就在于每次测试任务的分析和执行过程中得到实操和沉淀。

可以在以下几个方面去思考：

1. 影响到的业务单元

影响到哪些业务，决定了测试的范围。例如支付业务的测试，是否需要考虑不同的商品类型，依赖于支付的类型来决定价格，此时测试支付的时候，要把有相互影响和依赖的商品类型考虑进来，加入到测试用例当中。
 

2. 影响到的历史业务

是否影响到历史业务，很多时候我们总是认为，不影响到原来的业务，但是上线之后发现影响到了。一方面是可能没有仔细去思考，是否影响到。一方面是经验不够，对历史业务不够了解。无论如何，线上问题可能影响资损。反推到测试过程中，要重视和解决没有考虑到，经验不够这些障碍，尽量去客服。因为这块，是不会写在需求文档中的，需要有经验有责任感的人员去挖掘。

3. 影响到的app版本

我们总是去测最新版本，没有考虑到在用户角度，我可以不安装新的版本，那么对于服务端来说，是否只支持了新版本的情况，没有考虑旧版本也会使用，在新旧版本上对于字段的使用，对于业务的处理方式可能不同，需要兼容。这块，测试同学可能不能从代码层面去确定，但是可以在测试分析评估的时候去考虑这点，必要情况下，在新服务端旧版本app去回归这个问题，保证这里的场景是没有问题的。

4. 回归的最小路径，最全测试范围

我相信，测试同学经常会听到一句话，某开发说，我也不知道会影响到哪里，最好全部回归一下。我一听到全回归，就非常的反感。但是测试同学就是要最大能力保证质量呀，不是吗？那么我们就需要凭借自己的经验，测试能力去评估用最小的路径回归最全的范围。例如，其实某个业务场景，对应的开发就是一块if else的判断逻辑，我们去知道具体的判断逻辑，就可以一方面去从业务角度判断，开发的判断逻辑是否有遗漏，是否有多余或者冲突。另一方面也可以评估我们测试哪些点，其实就可以覆盖这个逻辑。而不需要测很多实质上是同一回事的地方。

也可以分侧重点回归，也就是考虑ROI。如果我们需要在最短的时间来做全面的回归，怎么做呢？当然是先分重点，高频核心的场景优先回归保证没有问题，次重点场景，还可以通过涉及场景，串起来，在一个场景中都覆盖到。再者，可以搬出自动化，通过快速写一些脚本帮助快速回归，等等。

5. 造数据的难度

测试场景上某些测试数据方面造数据很难，场景不好测，如何模拟出这种场景？现实情况下，可能有些同学会选择不测这个场景，让开发逻辑保证。但是在线上用户真正踩到这个场景，肯那个还是会有问题。是否真正的覆盖到这个点，是考验测试同学对于质量保障的决心。通过各种办法去到达验证和保障的目的，才能够真正做到对质量的敬畏。

6.可能的风险

测试做久了，是有一种焦虑体质。相信大家都知道墨菲定律，越不可能发生的时候往往发生了。我听到的最多的，开发说代码角度不可能走到这里的，但是实际情况就是走到了，所以测试同学有时候会做一些极限测试，“疯狂”的测试，往往被开发人员鄙视，但是我认为从最终用户是否会遇到为评判，这个点还是需要保障的。要考虑所有可能的风险，并一一验证。

三、测试文档沉淀

我相信，在经历过一个迭代各种大大小小的坑之后，测试人员往往心里想，总算是把一个版本送上线了，可以躺一下了。其实这个时候，如果花一点时间回想，总结，往往是对自我职业发展最有价值的地方了。所谓好记性不如烂笔头。我作为一枚业务测试同学的时候，最喜欢去总结，并记录到公司内网上，有时候再去回想很多都记不全了，但是有文档为证，反复实习之，又如复得。

可以沉淀和深挖的点有如下：

上下游之间的关系和入口
客户端开发用到技术，框架和平台组件
如何造数据和测试数据的积累
业务的逻辑和分类，重点和难点
测试流程的规范和约定
历史业务的总结和线上问题的记录
  -线上问题的记录，有利于知道历史原因和总结容易遗漏的点
历史改动的记录和查询
  -能快速的查到，哪个业务是哪个版本的改动
保持业务文档的实时更新