软件测试经验与教训

大概在18年的时候，就看过《软件测试经验与教训》的纸制版，里面的一些观点深刻的影响了我，也影响了后来我对测试的思考。最近又一次快速阅读了电子版，还是收获满满。下面精选出10条，和大家分享。

测试人员是项目的前灯

一个项目就像是一次陆上旅行。有些项目很简单、很平常，就像是大白天开车去商店买东西。但是大多数值得开发的项目更像是夜间在山里开越野卡车，这些项目需要前灯，而测试员要照亮前面的道路，使程序员和经理尽管还在拿着地图争吵，但是至少可以看清他们在哪儿。

注：测试左移、测试持续反馈，这些不正是我们在敏捷测试中讨论的重点么？多么形象的比喻，测试左移能够让测试人员明白需求的价值是什么，如何验证这些价值。持续反馈就是项目的前灯，保障研发活动少走弯路。可参考：测试如何构建快速反馈的能力

当心测试中的不关我事论

测试是如此复杂，与其他项目活动如此密切关联，以至于测试员总想通过采用狭隘的测试使命观进行更好的控制。有些测试员认为，自己的使命就是找出产品和规格说明之间的差别。任何超出这个范围的问题，例如可使用性问题需求问题、数据质量和可支持性问题，都“‍不关我的事”。

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

测试策略要解释测试

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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