于测试用例设计的一点感想(优先级与拆分合并设计)
废话不多说，直奔主题吧
1、用例优先级
大家都知道，用例有优先级之分，但是实际执行过程中如果没有养成良好的思维习惯，又容易把这个给忽略，那么问题来了，怎么破？
解析：以“用户”为主，兼顾程序“依赖”
即以用户为中心，从用户的角度考虑，同时遵循序功能(模块)彼此之间的“依赖”关系展开对用例的设计。
以下为例进行说明。
如上，这是个支付资料进件的需求原型图，站在用户的角度考虑，这个页面的核心功能就是“审核资料”，其它的功能，比如，查询，列表标题旁的下拉筛选，列表排序等都是为了更好的服务这个功能而设置的，所以结论是：“审核”功能--列表的“操作”的用例设计优先于查询，下拉筛选，列表排序等功能的用例设计。
再从用户的角度出发，如果想用户提交的支付资料被“审核”通过，那么必须对这些资料进行查阅，包括列表记录项(商户全称，商户简称，资料商户全称，第一次提交时间，提交来源，资料类型等)和上传附件(可通过“下载”查看)，所以，结论是：需要先对记录数据准确性校验，先对“下载“功能进行用例设计。
问题：这里为何不以“程序依赖”为主呢？按我的理解，打开支付资料审核页面时，默认的也会进行查询，要进行审核就必须先把记录查询出来，如果以“程序依赖”为主，那这里就应该先对查询进行用例设计。但是我没有，因为通常情况下，如果存在列表记录，那么打开类似这种页面应该能自动显示数据的，也就说打开页面(测试的必经之路)已默认解决了这种“依赖”关系，即审核需要查询出数据
2、用例设计拆分
如下图，这是很常见的一种设计，见图1（这里的“终端”可以是某个app，可以是某个web后台、web页面等）
(图1) （图2）
拆分思路：见图2，以数据库为中心，“一刀两段”，分成两部分：终端提交资料到数据库，这里关注资料能否提交成功，数据库存储是否正确；web后台从数据库读取数据并展示，这里关注展示是否正确。
按这种思路来，那么设计提交(新增、修改)资料功能用例时，用例的校验重点是看数据库存储是否正确，如果对该功能对应的数据库、数据库表比较熟的话，可以通过直接查看数据库校验(推荐)，如果没权限或者对数据库、数据库表不熟的话，也可通过本终端相关web页面（比如记录详情页面，修改资料页面等，如果有的话）查看“可见部分”的资料数据是否正确
设计web后台展示数据功能用例时，用例的校验重点是看读取是否正确。这种情况下，可通过直接修改数据库相关字段的值后，查看web后台展示变化，当然这也建立在对数据库、数据表对应关系比较熟悉的情况下，如果不熟悉、对数据库表等没操作权限的情况下咋办？可借助“终端操作”,即通过终端提交(新增、修改)资料来修改数据库对应记录的值，这里不需要对终端是怎么新增，怎么修改的等细节展开细致描述，因为这块在写提交资料的时候已经写了，仅简单的把其当作用例中的一个操作步骤来写，一句话概况。
注：验证展示时需分清
哪些数据会动态改变，且由终端改变的（比如审核拒绝后再次提交审核，会改变审核状态，在验证数据展示时，需要针对这部分，构造对应的数据，否则容易漏测）；
哪些是由web后台自己的操作改变的（比如审核操作，这部分的数据变化比如审核状态，可以放在审核操作的用例步骤预期结果里进行校验）。
注意：因为程序可能使用类似redis，mongodb等缓存功能，所以直接修改数据库可能并不会导致web后台等数据发生变化，因为它可能是从缓存读取的数据，所以如果是在对程序实现不了解的情况下，靠谱起见，还是建议通过借助“终端操作”的方式来实现对数据库的更改（有些程序实现会在执行终端操作时调用刷新缓存命令，使得缓存的数据更新为数据库中最新的值）。
再举个“支付收款”的例子。
我公司做智能pos这块的，涉及支付宝收款，微信收款等，通常这些功能都会涉及到一些关键的配置，要正常收款，必须做正确的参数配置，所以从依赖角度看，设计用例时分两大块，一块是测试配置，看配置保存能否成功，数据库存储是否正确，另一大块呢，查看正确、错误配置下的功能是否正常、是否做了容错处理，查看读取配置是否正确（通过动态执行程序操作，比如执行支付宝收款，执行不同场景的微信收款）
3、用例设计合并
用例合并，没看错吧？对，没看错，就是用例合并。之前提过，一条用例一个点--就验证一个点，出发点是没错的，但是考虑到实际执行效率，我们要做一些取舍，把部分用例合并到一起。
eg:
如上图，左图是收款成功界面，暂且我们称之为“收款成功页”，右图是收款成功后打印的小票，暂且称之为“小票”。关于这两个界面，分别提了一些业务规则，如下：
1）收款成功页：
“不可优惠金额”，“卡券优惠”，“商家活动”，“抹零”，“平台优惠金额”，“交易备注”，这几项如果有则显示，否则不显示,其中抹零金额为0则视为无抹零
“卡券优惠”：如果是会员折扣则显示“会员x折-￥金额”；如果是代金券，且只核销一张，则显示“代金券名称-￥金额”，如是多张则显示“代金券名称*数量-￥金额”；如果是折扣券则显示为“折扣券名称-￥金额”
2）小票：
“不可优惠金额”，“不可优惠金额”，卡券优惠（“会员xx折”\“折扣券名称”\“代金券名称”\“金券名称*xx张”），“商家活动”，“抹零”，“平台优惠金额”，这几项如果有则显示，否则不显示,其中抹零金额为0则视为无抹零
如是门店帐号登录收款，则“交易流水凭证”下方的抬头显示“门店名称”，如果是商户帐号收款则显示为“商户简称”。
3）自动打印：如果后台配置了自动打印且打印小票数不为0，收款成功后自动答应小票
4）打印按钮：点击打印后，再次打印小票，基本同自动打印的小票，但是需要在此基础上增加“重印”二字
按常规思维，有的人就可能会这么设计用例:
Ø 1、按照需求，复制黏贴，数据和逻辑分离，比如，[约束限制]打印小票-“不可优惠金额”有则显示，无则不显示
[约束限制]打印小票-没有“不可优惠金额”；
[约束限制]打印小票-有“不可优惠金额”；
[约束限制]支付宝收款-无不可优惠金额
问题：这样设计有啥不好？
解析：以上用例为例
用例1，看起来似乎很有逻辑性，但是从等价类的角度来看，这里有两种输入，分别对应这两种输出，每种输出走了一条逻辑分支，我们提倡“逻辑”和“数据”分离，但个人认为这里的“逻辑”确切的说应该是逻辑分支，即一条逻辑分支对应n条测试数据，对应到自动化时也是这样，方便处理。所以推荐按用例2的方式编写。
用例2，看起来也没问题，根据等价类划分，可用1条测试数据、1次操作进行覆盖n条正向用例，问题出在执行，这样设计用例，如果动手测试前没规划好，可能会造成这种结果：
收款时，针对“收款结果页”部分字段有则不显示，无则显示的规则把那些字段显示规则都校验一次，然后测试完成，再对小票部分字段有则不显示，无则显示的规则把那些字段显示规则再校验一次，这样会造成重复的投入，如下：
执行支付宝收款->测试收款“结果页”字段信息
执行支付宝收款->测试打印小票字段信息
另外，这里的打印按钮，打印的小票也要遵守这个规则，这样不得不再次做同样的操作（虽然按经验，这里的打印和自动打印调用的应该是同一个接口，但是我们没法保证它真的是那样，因为程序不是我们写的）
那咋整？
按我的理解，这里，支付宝收款，自动打印小票，打印在业务角度看，都是紧密关联的（用例划分要适当，需要考虑执行），执行效率起见，我们可以把用例合并起来，确切的说是串联起来：
支付宝收款->>验证收款结果页面->>验证自动打印的小票信息->>验证重印的小票信息
值得注意的是，这里需要对实际业务逻辑比较深入的理解，结合业务逻辑进行用例的设计（这点很重要，要知道数据怎么走，数据传递时在哪里会发生变化，否则很容易因覆盖不全导致出问题）。
如上图，我们可以看到，如果把判断是否抹零前的计算结果，即应付金额，作为中间结果，那么“是否有可不可优惠金额”和“使用优惠”则是影响应付金额的两个因素，这里考虑使用强一般等价类划分：
是否有可不可优惠金额（有不可优惠金额，无不可优惠金额）
使用优惠（使用会员折扣，使用折扣券，使用代金券，不使用优惠）
得到如下用例：
【功能校验】支付宝收款-有不可优惠金额，不使用优惠
【功能校验】支付宝收款-无不可优惠金额，不使用优惠
【功能校验】使用优惠-有不可优惠金额，折扣券，支付宝收款
【功能校验】使用优惠-有不可优惠金额，多张代金券，支付宝收款
【功能校验】使用优惠-有不可优惠金额，单张代金券，支付宝收款
【功能校验】使用优惠-有不可优惠金额，会员折扣，支付宝收款
【功能校验】使用优惠-无不可优惠金额，折扣券，支付宝收款
【功能校验】使用优惠-无不可优惠金额，多张代金券，支付宝收款
【功能校验】使用优惠-无不可优惠金额，单张代金券，支付宝收款
【功能校验】使用优惠-无不可优惠金额，会员折扣，支付宝收款
搞定这个，接下来的就比较简单了，基本的等价类，
如下:
【功能校验】支付宝收款-不抹零
【功能校验】支付宝收款-有抹零(抹零金额为0)
【功能校验】支付宝收款-有抹零(抹零金额不为0)
【功能校验】支付宝收款-无平台优惠金额
【功能校验】支付宝收款-有平台优惠金额
【功能校验】支付宝收款-有商家活动
【功能校验】支付宝收款-无商家活动
同时，收款结果页，小票的字段有则显示，无则不显示的规则，在上面的用例中未覆盖到的，需要再针对性的设计用例，如下：
【功能校验】支付宝收款-无订单备注
【功能校验】支付宝收款-有订单备注
-----------------------支付抹零用例---------------------------------
【功能校验】支付抹零-四舍五入到角
【功能校验】支付抹零-往下抹零到角
【功能校验】支付抹零-四舍五入到元
【功能校验】支付抹零-往下抹零到元
注：我们的抹零有4中，如上，测试抹零用例时，实际需要再覆盖以上四种情景的用例
附用例步骤：【功能校验】使用优惠-有不可优惠金额，多张代金券，支付宝收款
注：
1、有人会问，这里为何不进行类似如下的组合：
【功能校验】使用优惠-无不可优惠金额，无商家活动，无平台优惠，无备注，无抹零，扫码验证，会员折扣，支付宝收款
【功能校验】使用优惠-有不可优惠金额，无商家活动，有平台优惠，有备注，有抹零，扫码验证，会员折扣，支付宝收款
理由：组合不是不可以，但是这样组合起来后，一眼看去就有点分不清这些“影响因素”之间的关系了，相互制约还是互不影响，这个真不清楚，而且分不清这条用例的测试重点在哪里，整个逻辑显得很乱，影响因素比较少的情况下，可以考虑这样组合下。
2、根据上面说的，你用例预期里也有，类似“如果xxx则xxxx，否则。。。。”这样的描述，这不自相矛盾呢？
理由：是有，但是这里有针对性的，这部分不是用例的核心校验点，但是也可能是用例结果的组成部分，不能丢弃
3、有人又会问，金额啥的还不是重点呀？
解答：是重点，根据测试用例等价类设计思想，我们验证用例时，我们可以稍微组合下，一次收款操作，可以覆盖n条正向用例，这样在验证用例时，可能会把备注2中非重点部分也当作重点部分进行校验（某条用例中不是重点，但是在其它用例中是重点）。
pdf版本下载：关于测试用例设计的一点感想(优先级与拆分合并设计).pdf
