🔥 交流讨论：欢迎加入我们一起学习！
🔥 资源分享：耗时200+小时精选的「软件测试」资料包
🔥 教程推荐：火遍全网的《软件测试》教程
📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
作为一个合格的测试工程师，必须掌握测试的日常工作流程。
那么在一个产品周期里面，测试工程师是什么时候介入工作的呢？具体承担了哪些工作呢？这两问题，也是在日常面试中经常遇到的，这里我用一张思维导图进行简单的概括（如下图）
今天我们就来说说“测试用例设计”和“测试用例评审”。
01
测试用例设计
常见的测试用例方法大家都在网上和日常测试过程中都有用到过。这里给大家讲解一些特殊的测试点该如何进行用例设计。
1. 详情页字段校验
方法：场景组合设计用例
实现：同一个详情页不同字段，通过场景组合用例设计，可实现在“同一条测试数据”的基础上，校验“不同字段，不同枚举值”，节约测试工作量。
通过上面这个场景，实现在“同一条测试数据”的基础上，校验“不同字段，不同枚举值”。
原本需要8条测试用例，经过“场景用例设计”后，只需要3条测试用例即可校验。
2. 查询条件校验
方法：全局到细化
实现：
2.1全局校验查询条件字段是否齐全或正确
2.2具体查询条件功能校验
02
测试用例评审
由于设计测试用例的标准：一条用例尽可能只验证一个点。
所以测试人员设计的测试用例对开发来说简直是“又臭又长”。在测试用例评审时，大部分开发估计都在神游...评审会议时间长达一两个小时，但是对开发来说有效的吸收不到百分之一。
那么如何有效的进行用例评审呢？
1. 用例标注重点
需求疑问：在经过产品确认后，输出具体测试用例
设计交互：UI未提供交互，需求文档未描述的功能的实际交互细节
......
以上在设计测试用例过程中，【未在需求文档中明确描述&在设计测试用例过程中已同产品确认】，需要在用例评审中着重提醒开发，保持信息同步。
2. 逻辑概述+核心评审
业务流程较为繁长的测试用例条数较多，少则上百，多则上千，逐一讲解，不论是对开发或产品，甚至测试本身，都会出现前后文衔接不上。此时可以使用“全局流程+局部细”的方式来评审测试用例。
全局流程-逻辑概述
借助“Xmind”思维导图，进行简要的逻辑概述，阐述用例描述的基础流程。该阶段描述后，经产品和开发确认无疑问，则进行用例评审时，可略过该部分的基础测试用例。
局部细节-突出核心细节用例
除了基础业务流程外的，一些特殊场景细节的测试用例，可能影响业务流程或对公司造成损失，使用加粗/颜色标注，在用例评审时着重提醒开发。
特殊场景包括：
前后端数据同步交互、多人同时操作数据等，以下为逻辑校验的核心测试用例（仅供参考）
03
总结
不论是在测试用例设计或者是在用例评审时，使用“先概述，后细节”的方式，不论是对开发或者测试本身都有益处。
针对测试：
✅ 保持清晰的评审逻辑，避免评审时出现混乱
✅ 提高用例评审的效率，节约团队时间成本
✅ 提高开发对测试用例的重视
针对开发：
✅ 节约精力，提高对核心用例的重视和吸收
✅ 及时改善代码设计缺陷，提高开发质量
最后我邀请你进入我们的【软件测试学习交流群：785128166】， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路
作为一个软件测试的过来人，我想尽自己最大的努力，帮助每一个伙伴都能顺利找到工作。所以我整理了下面这份资源，现在免费分享给大家，有需要的小伙伴可以关注【公众号：程序员二黑】自提！
192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
