很棒的原创哦！mark 一下

very good

学习了~~~

不错，如果有实例说明就更好了

比如业务流和操作流这两者有点混淆，大神能否用实例区分一下呢？
还有就是设计方法，等价类和边界值是比较容易用到的，其他的方法感觉在实际使用时总有些困难。比如正交分解法，这个实际写用例的时候真的有人用吗，有没有实际测试的例子呢？希望大大能帮忙解惑，感激不尽

图中 “用例分层” 和 “用例设计共性步骤” 再好好看看。

先把需要被测试设计的 “测试对象” 找明白喽。

啥是狭义的 “业务流” 就好比 A 注册 B 登录 C 搜商品 D 下订单 E 支付 A B C D E 就是业务流 不同的组合序列就是业务流了。 他的逻辑对象 就是 你们平台的 各种大类 “功能” 他的物理承载对象 就是 各种 功能页面 比如 注册页面 下订单页面 支付页面等。

啥是狭义的 “操作流” 就是 站在用户角度 去做交互体验测试 就是在某个具体的 功能性页面 做页面操作的序列 比如 注册页面
用户要操作 各种 输入行控件 和 各种展示型控件 他们之间有逻辑 和 业务规则制约关系 和交互效果要求 这些都是逻辑对象关系 所以 把一个页面中的输入型提取出来 比如测试 注册输入控件 就是 账号 密码 确认密码 邮箱 手机 这些就是 物理操作对象 找到了他们 才可以用 因果 判定表法 去设计组合序列。

啥事狭义的数据流 就是 具体的输入型控件或数据 他们找到了 比如 注册 就要根据业务规则 和各种逻辑限制关系 去用 等价和边界值了

所以 图中的概念 是具体分层到某一个层内 一个概念内 是狭义的 但广义上来看 这些方法 是可以在其他层通用的 所以不要玩死这些设计方法。

所以 共性的步骤 都是 找测试对象 和 设计组合序列 然后等价边界设计取值策略 你先要看的请 你的测试目标是啥 你目前处在哪个层在测试 然后分别用好测试用例设计方法。

以上都是 站在 比较通用的 黑盒设计策略 从功能来展开 属于比较常用的业务测试方法

实际 还要站在 系统技术实现层 来继续优化深入用例 比如 要站在 三层结果 前端 服务 和 数据 从系统大的这些层 去再优化用例。
弄清 服务处理流 和 数据流 做到 全生命周期性的系统测试设计。

其实是不是可以理解为：点线面 ，点：可见的控件的限制逻辑与显示逻辑，线：由一个或者多个页面组成流程，面：和上述线有联系的流程的组合。
用未登录购买来理解
点就有：购买按钮、账号密码输入页中的控件、购买页面控价，这里有账号密码输入框的输入限制条件、逻辑条件，购买页面方案选择框的限制逻辑等
线就有：登录流程中账号与密码、登录按钮的逻辑和制约关系、购买流程中方案选择制约关系、付费方式逻辑关系等，付款流程中账号密码的输入与确定还有支付流程的逻辑关系
面就有：登录流程 + 购买流程 + 付款流程的组合 （与线相关的环境、流程、系统等都可以组成面）
2、有个不是特别明白的点，怎么设计用最少的用例测试最多的范围（较少组合），又保证用例质量和尽可能的发现更多的 bug
3、什么样的用例才能叫做好用例？从哪几个角度去考虑：用例覆盖范围、用例可操作性、用例可维护性等？

1 点 线 面 的理解还算可以吧。 就是让你分的清 当前的测试对象 当前的测试层次 当前自己在测什么 可以测出什么问题。
测试对象的属性 决定了测试的类型 决定了可以测出的缺陷类型。 好比我举例的 由上往下 业务场景层（对象是页面）

操作交互层（对象是页面控件 各种元素） 数据出入层（对象是 具备输入性质的各种数据 可以是页面的 可以是接口的 也可以是数据库的）

场景层 有场景层的 业务组合问题 页面控制流转问题

操作交互层 有控件 和元素 之间的各种前端 JS 脚本控制业务逻辑 交互逻辑 业务规则的限制问题
数据出入层 有具体的问题 但要看数据是哪一层的数据 产生了什么交互 比如前端的 JS 校验 规则控制问题 这些都是纯前端的 js 问题。 到接口了 提交前端表单了 有接口的输入限制问题 和服务校验返回控制问题 到数据库了 有数据落地的正确啊 位数啊等等问题。

就是让你建立起 分类 分层 有层次 有系统性理解 测试。 当前我是测业务组合 还是测前端交互 还是测接口 还是测落地数据。
要分的清，拎得清。 不要混为一谈，要对这个数据的整个处理流转的细节梳理清楚，前端干啥了 服务接口干啥了 落地数据干啥了，分层次 分流程 分门别类的 去检查各自的 ” 输出” 输出就是检查上一个节点输入正确的 “预期结果” 分层的测完一整套 每一层的输入 输出 很明确。 用例写的也会有层次感 ，好摘的开，以后也好维护。 比如 你判断准确了 就是前端 Js 没做输入规则业务规则控制，那么在用例的 前端输入 这一块 你只需要改这一块就行了，如果发现是，构造绕过接口了，接口的输出 落地数据产生了非法数据，那么就是接口层没对前端提交的数据做出一些校验，这个问题在用例维护里只需要改 接口输入 这一块 就够了。

这种 业务思维 加 技术实现分层思维 不断的找类 找层次 找输入输出的思维 你要不断加强 强化 然后就会越做越顺，看问题就越会有努力的方向，问题类型缺陷类型就会越定位越准确，直接找到解决的开发角色。提高缺陷解决效率。 这个前提就是用例设计的好坏来决定的。

2 减少组合 具体思维 你可以参考 判定表因果图法 相关的理论讲解里的 如何去掉重复的 列 的方法，有具体业务规则 可以去掉，
具体的逻辑规则限制，可以去掉，和其他许多 技术限制 比如数据类型 大小限制 导致一些数据根本不可能产生。 就这样去掉。
或者 你看 图例 用例设计参考文件里的 业务需求 和技术实现 里有什么 可以去重的条件拿来去掉重复。

3 好的用例 就是 我图里 列的 “满足特性” 你写的用例 具备了这些特性 就基本上 合格了、

楼主好厉害！学到了，能否问一下楼主，业务流、操作流、数据流，分析好之后，如何在用例中体现，如果说要做到低耦合好维护，那是不是意味着三个层的测试用例要分开写呢。

大体上 只要是 符合 或者你能分为三层架构的系统 前端 服务 数据 都可以分层写。
针对不同测试层 比如 前端 我图上也列了 你的前端的测试对象 如果是重点测试业务流转组合 那实体物理对象 就是 页面 各个功能性页面 或弹窗 都可以 比如 注册页 登录页 支付页 或 登录弹窗 他们会形成业务流组合 你就把 这些物理页面对象 设计个流程组合即可。比如 今天还没有登录弹窗 后天加两个登录弹窗 只需要在 业务流测试层 加个登录弹窗的组合流程 覆盖到相关业务流组合。

具体的操作交互层，就写到单独一层，这一层主要是放，或模拟客户前端操作行为对页面控件带来的组合，主要是测前端 Js 实现的问题。 比如 注册页面 那么多输入项 和 输出项的组合操作逻辑 就用因果判断 进行组合就可以了，具体的物理对象 是各个页面控件 但不涉及具体控件的输入内容，具体的输入内容 是放在 数据层的。 这一层主要是放 操作模拟组合。 比如操作序列，什么都不填，直接提交表单，看页面 js 和服务接口是如何控制的。

最后 就是 等价边界 注册页面的具体输入内容。 这一层就是放 我们测试最熟悉的 等价边界值 那些个东西。

这样就拆开和低耦合了啊，每一层的 测试内容不同 测试对象属性不同 就决定了这一层是可以单独设计和维护的了呗。

想问下广义的数据流有哪些呢？数据库 接口参数？或者其他的？可以举例说明吗

感谢楼主的分享，看完后其实跟上面那位有一样的问题，三个层面的用例分别设计吗？然后比如一个报名功能，报名后状态变更、按钮样式改变、页面信息改变，这种情况下是统一走业务层还是说关于样式的再拆分到前端的处理，数据落库的一个变化拆分到数据层

分层 分类写。聚焦点要原子性。
一 业务维度 就是经典的我图里的三层 纯按黑盒用例设计方法的一种分层思路。
二 技术实现维度 就是任何业务系统，实际都是三层，前端 服务 数据库

这种可以拿 testlink 或支持分类树写的都可以写成。 但不必拘泥于此。
实际建议 tesklink 的写清整理好，各层的业务规则，技术处理规则就好，实际按上面写，挺复杂的，如果思路分不清 摘不清 放不明白地方的话，你也写不好，这是时间淬炼下的功力，体验领会精髓，再慢慢写，慢慢改进吧，最终才会锻炼出很清晰的分层原则的。

实际，建议拿 xmind 脑图写，也能达到分层 分类 还能体现业务时序 或 服务处理时序 数据流时序 上的，而且比较直观 各层 title 命名好，每小节 也能很清晰的体现该层的测试目的，业务技术规则 时序 各层的要求。

分层看数据流。夹板思路看数据流。
前端 提交表单 是一种对 server 的输入 展示查询页面是对前端的一种输出。角度不同，输入输出是会互换的。

接口层面 就是提交的入参 是输入，它的输出，最近的输出就是接口的返回，较远的输出可以是落地的数据。这种就是广义的输出数据流。狭义一点的，就是 DB 里的一些不面向业务处理的字段 或接口里不面向业务处理的参数，这些是非业务处理的，一般我们较多关注业务处理的参数或 DB 字段，那么狭义的就是 哪些隐性参数 或 落地字段 是面向技术处理的判断字段。

另一种，就是 接口承载的 server 对象的，服务处理 log ,可以认为是接口的一种输出，因为它体现接口服务的内部处理逻辑，和技术处理异常。 可以当做接口的输出来做检查。

所以，不同夹板线下，的输入 输出 是可大 可小 可远 可近的，看你具体测试点 是关注前端交互 还是接口 还是服务处理逻辑 还是落地数据。 当然 全部大夹板的话，一个提交表单的输入 就是你提交的表单内容，输出可以是接口的返回，输出可以是 server 的 log ，可以是落地的 DB。按从前端 server DB 把处理串联起来来看的话，就是这些。