作为一名点工，说到提效，可能都会想到各种自动化技术、测试平台，特别现在暴热的 AI 赋能等，但是对于刚入行的同学，带着复用的思维去思考和做事，也许会更容易直观感受到提效成果。

复用思维

我认为复用思维可以简单归结为一个问题，下次再遇到同样的问题怎么办？，带着这个问题，测试过程中的资产：测试数据、操作手册、常用 sql、脚本、测试用例等都是优化的对象。

每次测试完成后，把测试资产中可复用的核心部分整理归档，下次遇到相同或类似问题的时候拎出来，或作为参考，或直接复用，或多或少都可以避免总是重复地解决同样的问题，以及遇到同样的问题还要走一遍相同的老路这种低效的做事方式。

复盘思维

复盘这个概念太多人提到了，即使在工作中，大家也都会参与到项目复盘、每日站会、日报跟踪、周报提交等各种各样的复盘方式或工具。其实仔细观察一下就很容易总结出来，不管是技术大牛还是业务大佬，复盘一定是提升路上最好的利器，复盘的目标是复利。

记得我刚毕业的时候，公司没有人带，自己每天南辕北辙，看见感兴趣的领域、技术、工具就像捞摸两把，摸完就跑，从不总结，最终导致提到什么好像都知道点，稍微深入讨论一下又半天憋不出头绪，结果就是猴子下山，丢了西瓜，落了芝麻，一地鸡毛。

测试工作可以复盘的内容很多，比如测试用例的设计思路、系统架构、业务模型、缺陷复盘、故障分析......

站在整个项目的角度，一个必要而且重要的复盘内容就是故障分析，很多公司应该都有专门的分享会来做这件事情。典型的案例是公司非常重要的财产，因为很多时候故障不仅仅是一个代码错误的问题，反映出来的可能是整个项目质量管控中的薄弱一环，复盘不是定责分锅，而是为以后铺路。

其次，测试执行过程中，一些典型的 bug 也是值得记录的对象。缺陷的分布有一个有趣的现象——缺陷集群。

类比二八原则：即 80% 的 bug 集中在 20% 的模块中‌。一个开发犯下的错误，在另一个开发身上也可能重复发生，在开发自己身上也可能重复发生。通过对 bug 复盘分析，总结出一些开发常犯的错误以及一些隐藏在业务中或技术设计中的偏门小坑，这样就可以一定程度反哺开发，提高代码的提测质量，也可以降低缺陷 reopen 的频次，同样可以提高自己的 “bug 嗅觉”。

以上就是自己工作中认为相对比较重要的新手要早日培养起来的测试思维了。