我给很多的系统和项目做过测试，那就给大家分享一些我做测试的心得体会以及测试工具推荐，希望对大家的测试工作有帮助。太基础的测试内容大家可以看看书本就可以获取，这里就不重复了。
因为测过的项目比较多，所以也就多多少给运维同学添过不少麻烦。每次惹麻烦的时候，我的运维同事们就会毫不留情的来问候我，为了减少被问候，我只能努力提升我的测试技能。
之前的项目体量不是特别大，所以生产发布也不会存在啥特大风险。而且，之前的项目一直处于试水的状态，所以测试方面也做了很多裁剪，比如先上线再做压测，这个风格到了特殊的项目后，发现不适用了。所以就最近的工作经验跟大家分享一下。
快速梳理出需求的关键案例
1
当项目越做越复杂的时候，参与测试工作的同事也就越来越多。案例编写以及执行都会由不同的同事负责，毕竟案例执行和编写也是特别耗时的一件事情，这里还包含了问题的追踪和处理。
一个人没有办法做到对每条案例都去检查执行结果。所以要形成自己专用需求案例点，这些点主要是一些关键的逻辑检查，比如超时、重复请求、金额、越权等等场景，一起参与的同事也会做这些场景测试，但是为了防止出现漏测或者理解偏差，特殊场景（重复、多发等等）我通常会自己做验收，避免出现系统故障以及损失。
随时调整你的测试策略
2
我们项目涉及的部门很多，链路特别长，遇上下游交付延迟的情况就更艰难了。我们遇到的20200806版本和20201208版本都再度刷新了我们加班的新记录，1208版本曾经从转测到上线，每天都是10点下班，周末还要连轴转，加班不是因为案例复杂，而是下游各种异常，不是功能异常就是环境异常，每天就是追着人查BUG处理问题。
传统测试来看，会觉得没有达标就可以拒绝测试，等到可以转测的时候才转测，但是在我们这里，不适用。项目要上线才能吸引更多用户，有数据才能持续运转，所以，我们不能按照传统测试标准来运转。
在下游同事响应不及时的时候，只能是夺命连环call，不要在意下游人到底怎样想，优先解决阻碍。否则，一个阻碍一天也解决不了。
没有压测环境也没有关系，做不了端对端的压测，就做自己系统短闭环的测试。把下游mock掉做压测验收。保证新增接口没有性能问题，有逻辑变更的接口性能测试也要达标。这里也给大家推荐一个比较简洁的mock工具，不依赖于发布模板修改，随时可以使用的mock工具。
WEMQ-Mocker：
更真实的模拟生产数据
3
测试环境跟生产环境相比，差别很大。至少表数据量就在一个量级。我们接入了慢查询监控，但是如果数据量太少的话，一样无法被监控到。
我们平时做压测，一张数据表存量100W条也就差不多了，但是，上了生产后，数据表就直接翻了5-6倍，特殊条件下SQL语句在MYSQL数据库下执行起来就不一定按照你的预期顺序执行了，测试环境不会出现的慢查询上了生产出现了。除了总表数据量，还要考虑单个用户的数据条数。这个同样对测试结果有巨大影响。
我们之前遇到的一个验证阶段的慢查询问题，就是一个有10W条好友记录的用户在邀请表500W+的情况下，10S没有返回，但是只有几十好友的用户就很快返回。经DBA定位是因为在数量很大时候，mysql的执行顺序会不按照我们理所当然的预期执行。
所以，测试环境尽可能的模拟生产的数据量级，这样才有可能发现更多的问题。
SQL性能分析平台：
保持敬畏心态
4
做测试，最怕的就是理所当然的以为都测好了，然后一上线，发现各种小问题漏测，前端测试，容易产生视觉疲劳。
项目做了1年半多，每个版本都有前端修改，可想而知，我们的案例有多庞大。我们做了一个回归案例库，每个迭代测试完成，我们都会拉关键测试案例到回归案例库，时间久了，案例库就非常庞大，而且一些老旧的案例随着视觉交互的需求变更也会不合适。前段时间，我们测试同学为了给测试案例库瘦身，就新建了一个案例库，当然这里的案例都是依据现有的功能编写，所以，出现了很多过度裁剪导致那个版本出现了2个小的前端BUG，虽然影响不大，但是也从侧面暴漏了我们这种减负的方式是有问题的。所以，又用回原来的案例库，在原来的案例库的基础上进行调整，保证细节功能不遗漏。
我们计划21年做小程序录制回放的自动化，减少人工的自动化成本，做到对基本功能的验收，作为对人工测试的一个补充，减少漏测。
开发也是优秀的测试
5
目前迭代周期短，不是每个需求都有开发设计图可以参考，经常会存在测试考虑不到的地方，也就比较容易造成漏测。但是开发同学对自己的逻辑又特别的熟悉，所以我们要充分利用好我们项目组的资源，让开发同学也能自测，给项目质量提供双重保证。
前端测试
目前我们的周版本特别多，虽然是叫周版本，但是我们国庆节后也几乎达成了每日发布的频率。周版本基本上都是前端小程序逻辑的变更，后台不发布。但是小程序交互也超级多，每次发布也多少需要测试人力投入。在变更比较少，不涉及管理台发布的时候，我们前端基本上通过代码review就可以保证发布质量，这离不开前端老司机们的高水平搬砖技能。
后台测试
对于我们种后台逻辑比较重的业务，后台系统一定要严格测试过的才能上线的。否则，出现问题就会影响很大。所以，后台测试粒度也需要特别细。
在接入mumblesdk门户网站的覆盖率测试之前，每次转测后我就能听到李婷不停的追杀，“举哥，我的功能测了没？！”，做接入之后，李婷的问候语就变成：“举哥，我的功能怎么还没有覆盖到？！”。为了早点看到自己的代码测试情况，我们开发现在都是自己做测试，或自己写脚本或者用我们测试提供的流程脚本。
在回归测试环节我们从release版本还会采集一次覆盖率数据，对于新增的基本上是要满足100%覆盖，不允许有未覆盖的或者未评估过的代码上生产。当然，单靠测试同学怎么完成6-7个系统的测试覆盖，当然需要我们开发的支持。开发同学会梳理未被覆盖的逻辑，我们再补充测试场景完成测试覆盖。对于实在无法覆盖的，开发同学也会人工确认是否有影响。
基于DIFF的覆盖率数据：
尽可能多的自动化
6
当你测试一个功能，需要来回切2个以上的系统DB做数据预埋或者清理，然后需要发一个请求，然后再去检查个结果，出现浪费时间的情况的时候，你就需要考虑要把这些浪费时间的步骤程序化了。把时间花在你的案例设计以及细节确认上，减少对操作步骤的时间投入，让测试工作更有意义。自动化的工具很多，就不给大家再啰嗦了。你喜欢用啥都可以，只要你用的顺手，并且方便管理。
当然，还是要给大家推荐一款工具：RMB-MSG。这个工具的推出，帮大家节省了很多时间定位问题，特别是我们这个上下游关联很多系统的项目。在这个工具出来之前，一个流水要每个系统查一遍，才知道谁导致的，通常查完要半个小时+，现在可快多了。
运维技能也有助于测试
7
虽说条条大路通罗马，但是熟路的人会更快到达。
我初学压测的那会儿，就起个线程慢慢跑存量数据，后来李全栈发现我效率太低，让我把数据写xx.sql文件，然后连接数据库后直接source。再后来，运维同事刚子需要做运维演练，让我造数据，检查了我的文件后告诉我去掉表头后source数据效率更高。
最近也是因为要模拟网络超时，平常用mock做，有时候mock也不生效又定位不到问题，特别浪费时间，后来就用前段时间运维同事分享的容灾演练平台做（iptables）。一样可以满足测试需求。我们运维同事提的一些运维需求对系统健壮性也特别有帮助，所以多与运维同事保持高效沟通。
感悟
8
做这个项目遇到很多优秀的同事，有的合作了很久：独挡一面的涛哥和幽默的表哥，以及那个每次都能无情的问候我测了吗的沙特王子，也有因为这个项目才组合到一起的同事剩凯、果汁、刘航、蓝天、海湾、银川、S，李婷、亚军、显斌和全康，还有刚入职的姐姐和淑敏，当然还有做了不久就被借调走的给力小徒弟文静，每个人都很包容并且有担当。
未来还有很多需求要一起完成，虽然我懂得不是足够多，但是我也一直在努力学习满足项目的测试需求。
最后，愿2021年系统稳定，项目数据越来越好。
