软件测试经验与教训(1)，2024年最新薪资翻倍-CSDN博客

本文链接：https://blog.csdn.net/2401_84264468/article/details/137825260

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

注：在职场中，职责是清晰的，边界是模糊的，当我们能多走一步，多思考一点的时候，还是需要多做一些，即促进了价值的流转，也提升了自己解决问题的能力。想要团队变的更好，首先需要自己变的更好。

测试策略要解释测试

在心中形成一种清晰的测试策略，并且在按照该测试策略执行测试之后，可以向任何关心这个问题的人快速、令人信服地解释自己的测试过程。这会赢得测试小组其他人对该测试过程的支持。如果自己不清楚自己的测试策略，那么对测试策略的解释也就更可能是模糊的，缺乏说服力的。

注：告诉别人为什么要这么做，可以在争取资源的时候更有说服力，也能展示测试的专业性。而不是盲目、简单的根据边界值、等价类来无脑的进行测试。

永远都要报告不可重现的错误，这样的错误可能是时间炸弹

不可重现的错误会是公司能够交付的最昂贵的缺陷。有时程序的表现没有办法重现。看到程序错误一次，但不知道如何使其再次出现。如果产品交付客户后还出现这种情况，会影响客户对产品的信心。如果技术支持人员需要很长时间评估客户的数据或环境，客户就会更加厌烦。

注：测试可观测的重要性最近也被反复的提起，原来我们对于偶发BUG是需要记录在案，然后观察几个迭代，但是现在我们更多的是需要记录用户的操作过程，做好链路跟踪，做好测试的可观测性，减少对用户的干扰。

使自己的错误报告成为一种有效的销售工具

不管测试员是否这样想，他们的错误报告都是–种推销工具，它劝导人们付出宝贵的资源来换取测试员所建议的好处。对于程序错误，资源就是时间和资金，好处就是通过改正这个具体错误而带来的质量改进。

注：编写好的缺陷报告，即是专业的体现，也是个人的名片。更可以让团队快速识别风险，评估修复成本。

避免在测试脚本中使用复杂逻辑

测试脚本中的条件逻辑会使测试更难理解，也更容易出错。更成问题的是包含发出和获取错误信号的代码。可能需要逻辑控制来处理测试的设置、响应经过检查的输出，或处理定制控件。把这些逻辑放在单独的功能中。可以单独测试该功能(这样做很好)，也使测试更容易评审。

注：接口测试脚本中，不需要做过够的逻辑判断，不需要过多的分支选择，因为这些完全可以拆解成独立的用例。他们的理由往往是这样可以减少重复用例的编写，但这样的结果是，你可能自己都不知道哪些分支被执行了哪些没有被执行，就像白盒测试中分支覆盖测试。

建设一种服务文化，而不是控制文化

测试员为整个项目团队提供服务。典型的服务就是发现并报告程序错误。其他服务取决于测试小组的使命。贯穿测试文献和测试亚文化的基本问题之一是，测试员的角色究竟是服务还是控制？

注：其实上我们应该更期望的是提供服务，在项目不满足上线条件时，提供风险预防和解决方案，和团队共同识别和承担对应风险，共同为交付价值负责。

不要指望别人能够高效处理多个项目

如果测试项日比测试员多，测试经理往往想为每位测试员指派多个项目。有些入会接受多项任务，但是在特定的一周(或一个月)内，他们只能承担这些工作中的一项，而其他任务会被抛在一边。积极地承担所有被分配的任务的测试员会把时间分得很碎，要在管理方面花很多时间。最终，测试经理使某个测试员参与多个项目，参加很多会议花大量时间了解各个项目(重新阅读笔记，核对数据库中的新程序错误阅读新功能报告，阅读大量电子邮件，等等 )，而对任何一个项目所做的实际测试都很少

注：专注，是敏捷测试中非常重要的价值观，团队管理者应该让成员专注于工作，排除不必要的干扰。

积累自己员工的专业领域知识