关键词：
一
除了纯后台测试或者纯接口测试外，我想大部分人都会接触业务测试，至少我们目前的客户端产品测试就是这样。
之前和我们组客户端测试同学沟通，总是会发现大家用例的关注点大部分都集中在业务逻辑的覆盖上，对具体逻辑的实现，以及底层实现原理的关注偏少。
这样做其实并没有错，用例不就是覆盖需求的么？而需求就是我们说的业务逻辑呀。
但是仔细想一下双 V 模型就会发现，我们缺少了概要设计（集成测试）和详细设计（单元测试）的阶段，直接进入了系统测试，而要求大家在系统测试阶段考虑单元测试和集成测试的点，确实不是每个人都能做到的，事实证明也确实如此。
前段时间看的《软件测试的艺术》刚好有提到三层应用系统的分层：表示层、业务逻辑层和数据访问层，我觉得可以利用这个分层理论，让我们也可以在系统测试阶段考虑到逻辑实现和底层原理的验证。
下面我根据我们当前项目的情况，以我的角度来按这个分层分别进行举例说明。
二
先说说表示层。
我把表示层对应到我们目前的系统测试阶段的需求覆盖上，所有的显性需求的覆盖，都属于表示层，部分基于需求本身的补充和完善的隐性需求也是属于表示层。
设计表示层的用例比较简单，直接和需求说明进行一一对应就行，保证用例覆盖的集合是需求说明集合的超集，那么对显性需求的覆盖率肯定是百分百了。
举个例子。
有个需求中有这么一个描述「该功能的入口是否展示，需要参考注册表 HKCUSoftware est[testvalue] 的值，值为 0 时不展示，值为非 0 时展示。」
针对显性需求的用例覆盖：
验证注册表 HKCUSoftware est[testvalue] 的值为 0 时，功能入口不展示；
验证注册表 HKCUSoftware est[testvalue] 的值为 1 时，功能入口会展示；
验证注册表 HKCUSoftware est[testvalue] 的值为 2 时，功能入口会展示；
验证注册表 HKCUSoftware est[testvalue] 的值为 4294967296 时，功能入口会展示；
针对隐性需求的用例覆盖：
验证注册表 HKCUSoftware est[testvalue] 不存在时，功能入口不展示；
看，我们用例已经覆盖了需求显式说明的所有情况，同时也对部分隐性需求进行了覆盖，如果从表示层角度看，这个覆盖率已经很完全了。
那是否还有可以补充的用例呢？我们继续往下看。
三
再说说业务逻辑层。
所谓的业务逻辑，可以理解为集成测试或者接口测试阶段的测试对象，比如前面那个例子是调用的哪个接口实现的，如果没有调用接口，自己又是如何实现的？
比如经过和开发沟通，我们得到的实现逻辑是这样的「我们内部没有现成的接口，我直接使用的系统提供的 RegGetValue API 来读取的注册表值进行判断的。」
别看就这么一句话，如果从程序实现的角度看，这里面涵盖的信息量可不少。
我们首先想到的，当然去 MSDN 查询 API 使用说明，地址在这里：https://docs.microsoft.com/en-us/windows/desktop/api/winreg/nf-winreg-reggetvaluew
通过文档可以发现，这个 API 的第四个参数 dwFlags 可以指定我们要获取的注册表值的类型，如果类型不匹配，API 直接返回失败，那么这就可以新增一条用例了：
验证注册表 HKCUSoftware est[testvalue] 为 REG_SZ 类型，并且值为 1 时，功能入口会展示；
接着往下看，会发现这个 API 最低支持平台是 Windows Vista，那么新的用例又来了：
验证在 Windows XP 系统上，注册表 HKCUSoftware est[testvalue] 值为 1 时，功能入口会展示；
我们现在回过头来看这两条新增的用例，它们不是显性需求的描述，也不是我们把显性需求进行等价类或边界值进行划分能够补充到的用例，他必须是对具体实现逻辑有了解，才会考虑到的用例。
当然，也有人会说，我不这么分析，我也能想到这些用例，那恭喜你，对实现逻辑的挖掘已经深入你的骨髓，你养成了一个好习惯，千万不要给丢掉了。
四
最后再说说数据访问层。
这里说的数据是广义的，包含数据库存储的数据、注册表里面的数据、具体的文件变化等等，都可以算，概况起来就是，如果需求有涉及到非程序本身的数据变化时，一定要对数据本身进行确认和验证。
这个如果要和标准流程对应的话，部分涉及到单元测试的范畴了，所以如果有开发代码权限的可以多加关注。
如果继续使用前面这个例子来说明的话，那就是相关注册表值的位置、值的类型、值的内容等，这个例子里面这部分内容显性需求里面其实有说明，所以我们换个例子。
比如我们有个流程管理系统，每个流程阶段都需要经过对应角色确认，才能让这个流程继续下去，当初我们定的角色名称有开发、产品和测试，实现的时候，有人就直接把开发、产品和测试这样的字符串写入到数据库了，并把这些字段放到了逻辑判断的语句里面，仅从黑盒测试的角度看，没有任何问题，所有用例都可以通过，但是，如果有一天我们需要把产品改名为产品经理，就会发现要改的地方特别多，测试也几乎需要把所有相关逻辑重跑一遍，并且还避免不了部分日志记录中根本无法分离出这部分数据。
碰到这种情况，我们建议的方式是把一些变化的内容使用不变的代号来表示，比如开发用代号 DEV，那么不管你叫开发、开发经理、开发工程师还是其他的，DEV 的代号是唯一且不变的，那么对逻辑的影响就是微乎其微的了。
同样的，涉及数据库的时候，还需要关注哪些是主键，是否需要建立索引等等（业务测试人员也需要关注这些内容？看你心情了）。
再比如我们有些逻辑涉及到注册表的更新操作，某个操作只需要更新某一个注册表值就行，但是通过过滤规则发现，实现时竟然是把所有相关注册表值都进行了一次重写，如果不去关注数据的变化，仅仅从功能上看是发现不了问题的。
文件操作也是类似，有时候我们仅需要读取部分内容即可，但是实现时是全部读取，甚至是频繁的进行全部读取的操作，造成不必要的 IO 浪费。
五
说了这么多，有没有对前面说的分层有更好的理解呢？有没有可能借助这个理论让我们的用例更深入也更有针对性？
再总结一下：
表示层，就是要关注显性需求以及和显性需求相关联的隐性需求，并设计对应的用例；
逻辑层，就是要关注具体的代码实现逻辑，根据实现补充一些针对性的测试用例；
数据层，就是所有和广义上的数据相关的操作，都要关注实现的合理性和正确性。
以上，希望对你有所帮助，有任何问题欢迎留言沟通。
本文首发于公众号「sylan215」，十年测试老司机的原创干货，关注我，一起涨姿势！
测试用例设计方法：判定表
...些输入做出的响应的一种工具;遇到复杂业务逻辑是可以利用该表理清业务关系;重要概念条件l 条件桩:需求规格说明书定义的被测对象的所有输入l 条件项:针对条件桩,所有可能的输入数据动作l 动作桩:针对条件用户可... 查看详情
（转）接口测试用例设计（详细干货）
随着测试分析和分层测试的深化，“接口测试”出现在我们视野的频次越来越高。那么接口测的用例设计常用哪些方法呢？本文将详细描述。1 接口测试 1.1 接口测试接口：主要是子模块或者子系统间交互并... 查看详情
软件测试：针对具体物品的测试用例设计
...正常；报警装置是否可用，报警电话是否可用；通风状况如何.突然停电时的情况；是否有手机信号；比如说上升途中的响应。电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先... 查看详情
测试设计如何提升测试用例设计水平？(代码片段)
原文链接：http://www.51testing.com/html/22/n-3724422.html定义测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。首先，测试需要保证以下两点：程... 查看详情
测试用例-判定表
...行不同操作的情况的工具 在遇到复杂业务逻辑时可以利用该表理清业务逻辑关系 关联概念条件条件桩需求规格说明书定义的被测对象的所有输入条件项针对条件桩所有可能输入数据的真假值动作动作桩针对条件被测对象... 查看详情
软件单元测试及测试用例设计
...明了用例设计的过程。 1.软件测试 软件测试是指利用相关测试工具，按照一定的测试方案和流程对软件系统的功能和性能进行测试，对可能出现的问题进行分析、评估，发现开发错误并跟踪，以确保所开发的软件满足用... 查看详情
如何做好测试进度管理
作为测试经理，测试进度管理是测试管理的重要组成部分，贯穿产品需求到产品发布整个测试活动。测试活动按阶段拆分为：测试需求分析、编写测试策略和测试计划，测试方案和测试用例设计，测试用例执行，测试发... 查看详情
如何提升测试用例设计水平？
...整覆盖测试需求，而不应针对单个Case去评判好坏。二、如何设计测试用例1、对被测版本足够了解由粗略详细步骤来解读产品需求文档，如交互、功能流 查看详情
ui自动化在robotframework中采用的分层设计
RF测试数据 RF测试数据由4种表数据组成。这些测试数据由表的第一个单元格标识，名称和用法如下：表名用法别名设置表导入测试库，资源文件和变量文件。为测试套件和测试用例定义元数据Settingsettingsmetadata变量表定义可... 查看详情
黑盒测试用例设计——错误猜测法
...经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。-测试用例不是基于需求文档设计，而是针对猜测可能出现的缺陷进行设计。-错误猜测法有时候可以更好的完善需求文档 例如，测试一... 查看详情
分层自动化测试模型深入研究
分层自动化测试模型的发展分层自动化测试模型最早是由MikeCohn在2009年出版的《SucceedingwithAgile》书中的第十六章进行阐述的，他说“测试金字塔是分层测试的一种最佳实践“。金字塔自动化测试模型如上图A所示，从下往上分为... 查看详情
分层自动化测试模型深入研究
分层自动化测试模型的发展分层自动化测试模型最早是由MikeCohn在2009年出版的《SucceedingwithAgile》书中的第十六章进行阐述的，他说“测试金字塔是分层测试的一种最佳实践“。金字塔自动化测试模型如上图A所示，从下往上分为... 查看详情
功能测试用例的书写
...以是开发人员的一个解释）4）已经基本成型的UI（可以有针对性的补充一些用例） 简而言之，所有你能得到的项目文档，都尽量拿到。从所得道德资料中分解出若干小的“功能 查看详情
黑盒测试用例设计-测试类型和环境因素
四、测试类型1.设计方法对测试类型的覆盖 其中，第二章设计方法主要针对程序本身功能、逻辑的测试，可以基本覆盖的测试类型有：基本功能测试、边界测试、等价类测试、等价边界测试、容错性（... 查看详情
如何做好接口测试？
参考技术Asgbtmy：基于selenium的自动化框架开发，我主要是想问一下，你的框架除了前台的自动化，后台的数据的测试是否集成在你的测试框架中？小刀：你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知... 查看详情
(转)腾讯tmq接口测试用例设计
...面来说，这个文章写得无可挑剔的！ 随着测试分析和分层测试的深化，“接口测试”出现在我们视野的 查看详情
软件测试——用例设计3（其他）
...经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。2. 错误推测方法的基本思想：列举出程序中所有可能有的错 查看详情
接口自动化测试怎么做的
...确保每个用例执行前都是一个清洁的环境参考技术A可以利用工具postman，直接构建触发请求，同时也可以加入tests，增加测试通过的判断条件；也可以利用单元测试框架，比如python语言的话，应用pytest，构建接口测试用例，完成... 查看详情