2024年软件测试最全软件测试经验与教训(1)，软件测试程序员架构之路该如何继续学习

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

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

需要这份系统化的资料的朋友，可以戳这里获取

04

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

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

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

05

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

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

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

06

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

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

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

07

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

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

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

08

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

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

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

09

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

随着员工对制约产品设计的外部因素、用户如何使用(或将使用)类似的产品、什么样的问题对他们很重要、竞争对手如何解决的这些问题、关于使用这类产品都有哪些文章等了解得更多，他们工作的有效性会显著提高。

注：测试离不开业务，不论是什么测试，加强业务知识的累积，总是有好处的。

10

不要幻想只需两个星期就能够得到黑带柔道段位

要得到黑带柔道段位必须经过长时间的实际训练。第一个里程碑常常是黄带，当教练认为你最终对别人的威胁要比别人对你的威胁大时，就会授予黄带即使得到黄带也要花比两周长得多的时间。

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

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

需要这份系统化的资料的朋友，可以戳这里获取

将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

需要这份系统化的资料的朋友，可以戳这里获取