大佬教程收集整理的这篇文章主要介绍了浅谈“测试的婆婆妈妈”，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
开发说：你一个接口反反复复确认两三遍，你烦不烦？
你说 ：你文档里面只有字段的正常场景，连长度类型都没标，我怎么写异常案例？
开发说：都跟你说了，不会异常，用户又不会传奇奇怪怪的数据。
你说：你确定吗？
开发说：我保证，线上日志数据我都筛过了，没有异常。
你说：那好。
……
三天过去了，接口上线直接挂掉了，因为用户传了一个乱码的字符。。。。
所以你说，测试的婆婆妈妈重不重要？很重要！如果因为面子上挂不住，经不住开发的不耐烦甚至冷嘲热讽，放弃了刨根问底的追问，极有可能导致重要的异常场景遗漏，而一旦出现场景遗漏，责任全在测试方，因为测试的职责就是这个。
所以你还会发现，测试一天的工作极其繁琐重复。需求文档过来了，你找业务去聊这个具体业务场景。案例写完了，案例评审会上你又要重复一遍实现逻辑，再三确认实现细节的正常和异常案例。站在开发得到角度来说，他会认为，我接口都开发完了，还有啥问题哦。可能你在重复一边他已经开始打瞌睡了，但是没关系，该说的还是要说。
案例评审完了，还要发邮件，将评审的案例和一些待确认的问题只会三方，作为存档。一直到这里，测试的婆婆妈妈才正式告一段落。接下来进入案例执行阶段，因为有了前面的评审和反复确认，所以执行阶段的案例准出标准就是：评审有确认，但是执行阶段未通过的案例，一律视为缺陷。
前期的婆婆妈妈，本质上是在为后期的执行节省时间，因为有时候会面临与开发的争端，比如缺陷不认可等情况。这个时候就可以拿出之前的“婆婆妈妈”的成果，作为一锤定音的铁证。
归根结底，测试的婆婆妈妈是进行质量管控必要的手段，也是为了避免不必要争端的保证。
以上是大佬教程为你收集整理的浅谈“测试的婆婆妈妈”全部内容，希望文章能够帮你解决浅谈“测试的婆婆妈妈”所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。