开发说：你一个接口反反复复确认两三遍，你烦不烦？
你说 ：你文档里面只有字段的正常场景，连长度类型都没标，我怎么写异常案例？
开发说：都跟你说了，不会异常，用户又不会传奇奇怪怪的数据。
你说：你确定吗？
开发说：我保证，线上日志数据我都筛过了，没有异常。
你说：那好。
……
三天过去了，接口上线直接挂掉了，因为用户传了一个乱码的字符。。。。
所以你说，测试的婆婆妈妈重不重要？很重要！如果因为面子上挂不住，经不住开发的不耐烦甚至冷嘲热讽，放弃了刨根问底的追问，极有可能导致重要的异常场景遗漏，而一旦出现场景遗漏，责任全在测试方，因为测试的职责就是这个。
所以你还会发现，测试一天的工作极其繁琐重复。需求文档过来了，你找业务去聊这个具体业务场景。案例写完了，案例评审会上你又要重复一遍实现逻辑，再三确认实现细节的正常和异常案例。站在开发得到角度来说，他会认为，我接口都开发完了，还有啥问题哦。可能你在重复一边他已经开始打瞌睡了，但是没关系，该说的还是要说。
案例评审完了，还要发邮件，将评审的案例和一些待确认的问题只会三方，作为存档。一直到这里，测试的婆婆妈妈才正式告一段落。接下来进入案例执行阶段，因为有了前面的评审和反复确认，所以执行阶段的案例准出标准就是：评审有确认，但是执行阶段未通过的案例，一律视为缺陷。
前期的婆婆妈妈，本质上是在为后期的执行节省时间，因为有时候会面临与开发的争端，比如缺陷不认可等情况。这个时候就可以拿出之前的“婆婆妈妈”的成果，作为一锤定音的铁证。
归根结底，测试的婆婆妈妈是进行质量管控必要的手段，也是为了避免不必要争端的保证。
标签：浅谈,确认,评审,婆婆妈妈,案例,开发,测试 来源： https://www.cnblogs.com/xiaoxiami1995/p/15615419.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。