面试官：做测试工作跟周围同事发生过冲突吗？

文章目录

前言

一、第三方原则

二、测试尽早理念

三、测试同步原则

四、木桶原理

五、解耦原则

六、冒烟优先原则

七、Pareto法则

八、群集效应

九、杀虫剂效应

十、Good-enough原则

十一、安全回归原则

十二、求同理念

总结

---

前言

        面试官：做测试跟周围同事发生过冲突吗？

        答：近期工作中出现了较多次，与周围同事起争论的情况。实际针对的问题并没有谁对谁错，深层次的原因主要就是，大家站的立场不同，考虑问题的角度不同，专业领域也不同，只能理解对方的初级思想，而不能理解对方的高阶思想，如此种种导致产生了较多的分歧。

       

        我总结了一下测试工作的思想理念，希望能够表述的比较清晰易懂。

一、第三方原则

        测试人员应站在设计人员之外的第三方角度上开展测试工作，例如测试工程师设计测试用例时，应从第三方验证和可靠性检验的逆向角度看问题。跳出设计工程师的正向设计思维，往往更容易发现BUG。实际项目中，测试工程师可以利用测试领域的一系列理论方法，以及查找问题的经验来设计出测试用例的大部分内容，然后设计工程师针对测试用例进行走查，并对测试用例进行进一步的补充。

二、测试尽早理念

       测试尽早是指，产品开发的项目早期阶段就应有测试人员参与。一方面是问题发现的越早，优化变更就越容易，项目里边为变更而付出的成本就更低。另一方面是，测试人员可以对产品有更全面和深刻的把握，例如产品的定义、项目的定位、开发的深层逻辑等等这些项目早期的工作，如果测试人员参与项目太晚就会对这些内容的把握有所缺失，使后续一些列的测试工作存在纰漏风险。

三、测试同步原则

        产品的某一功能，设计人员会采用不同的方案来实现，在项目开发的进程中，这样的方案也会出现更迭。当这种情况出现时，相关信息应对测试人员通告，相对应的测试工作也应及时同步，对于已经测试过的内容，应重新测试。

四、木桶原理

        木桶原理，在测试工作中的主要含义是全面要素管理， 例如测试生产力发挥的几个重要条件：测试人员能力高低、测试设备齐备程度、测试项目工时充足程度、测试协作的支持程度等等。这些有一个短板存在就会拉低整体的发挥。

        另外还告诉我们测试时要关注团队中不同模块的人员，例如团队中负责硬件的人员较弱或者负责软件的人，那么相应的模块隐藏的缺陷就会比较多，需要重点进行测试。

五、解耦原则

        解耦原则是测试用例设计环节的一个策略，其含义是指，针对产品不同方面和不同层面的设计内容，测试用例应尽可能解耦开，同时也是针对性更强。

        例如产品的硬件和软件两个方面，硬件软件有不同的工程师设计，应针对各自的对象设计两套测试用例。针对硬件的用例，目标是测试电路、器件和芯片的功能性能好不好，应针对电压、电流和温度这类指标进行覆盖。测试硬件时会用到一些软件，但是软件应该越简单越好，因为软件不是目的，只是辅助的。针对软件的用例，目标是针对每一个函数和代码块的，针对逻辑和控控制流进行覆盖。测试软件时硬件也会用到，但软件只是提供一个程序运行的平台。软件和硬件解耦，一方面是可以两个测试人员分别负责同时进行，针对性更强效率更高。另一方面是查到的问题归属也更加明确，后续的问题跟踪也更顺畅。

        再比如底层驱动软件和上层应用软件这两个层面，一个是通用的一个是定制的，两者开发的时期一般相差较多。底层和上层的软件测试解耦开，就可以根据设计进度的不同，分阶段进行测试。

六、冒烟优先原则

        拿到被测之后，应查找“冒烟”测试项，将其作为重点关注内容优先进行测试。这类测试项往往影响范围较宽，一旦测试Fail就需要对产品做重大变更，那么其他其他测试项就要立即停止，因为就算测试了也就要重新再测。所以这类测试项被形象地称作“冒烟”测试项。

七、Pareto法则

        一般情况下 ，80%的缺陷聚集在 20%的关键核心模块中， 这个法则至少告诉我们在做测试时，应该重点分析和测试 20%的核心模块。

八、群集效应

        群集效应的含义是，在某个测试点发现缺陷后，这个测试点背后比较容易存在一个系统性的薄弱，围绕该测试点一般还会存在其他的缺陷。 群集效应指导我们在找到缺陷的地方要继续找找，举一反三系统性的挖掘BUG。

九、杀虫剂效应

        杀虫剂效应是指，一种测试方法长时间使用后，产品会对这种测试产生“免疫力”。 这个现象告诉我们，测试时应不断尝试新方法，使用新的测试用例，以找出更多产品缺陷。

十、Good-enough原则

        Good-enough 原则告诉我们做测试的时候，既不能测试不充分，也不能做过多的测试。至于多少测试合适， 需要我们不断积累经验才能拿捏准确这个度。 在项目中可以指定最少的测试内容和最低测试通过的标准，然后在具体问题上再具体分析是否提高测试深度。

十一、安全回归原则

        针对产品的优化迭代，每一版本的产品经过一轮完整的测试后，都应对测试数据进行全面的汇总，形成当前版本的测试报告。新版本的设计出来后，要针对变更的内容进行回归分析，筛选出哪些历史测试的结果已经不成立了需要重新测试。对于一些不易区分的模糊部分，回归测试应采用谨慎保守的态度，即安全回归，做到有风险尽。

十二、求同理念

        产品开发的项目进程中，测试和设计两个角色，就像是自始至终存在的一个“矛”和一个“盾”，测试人员极易被当作“挑刺的”、“打小报告的”来对待，然后形成敌对局面，这样一方面不利于产品的开发，另一方面也会使测试和设计的工作都很不顺畅。这时候测试人员应该建立起“求同存异”的思想理念，找出测试和设计的共同目标——开发好产品。然后打开格局，认识到开发好产品需要设计和测试的共同努力，认识到两者自己的工作也都依赖于对方的工作。这样也就摆正了测试的角色定位，再加上实际工作中的一些沟通技巧，基本上就能跳出“矛”和“盾”的怪圈。

总结

        以上就是本人对测试工作思想理念的梳理和总结，有助于对测试本质的深刻理解，可以为实际项目中的一些策略分歧问题带来一些帮助。

        关于这个话题，后期还会不断更新。欢迎评论区留言、点赞、收藏和关注，每一条鼓励都将成为笔者持续分享的动力。

---

        版权声明：原创文章，转载和引用请注明出处与链接，侵权必究！