测试用例的设计思考与盲区

背景：本以为编写测试用例是一项复杂度较低的工作，覆盖到全部功能，没有遗漏场景就行。后来看到了组内大佬写的测试用例，发现了可以提升的地方。

对测试用例的设计深度能体现出对当前版本的理解程度。

以下是设计思路及盲区分析

 一、如何设计测试用例保证功能的全面覆盖？

关于设计测试用例，经常提到的那几种设计方法在实际工作中只能启到一定作用。按照这种设计模式编写的测试用例偏向属于黑盒测试，偏业务。

如何才能覆盖得更全面？最好的方法是看代码。看不懂代码去看概要设计，先大概了解代码的实现思路，根据时序图了解数据走向。

（测试用例的设计方法：等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法等。）

 

二、事例说明

测试用例设计实例分析。以常见的下单为例（流程：浏览产品页面->下单->支付成功->提交订单->退货）：

1浏览产品页面：项目普遍是分布式或者微服务，可考虑修改相关服务的配置项后的界面展示，此处可以考虑修改产品配置。

2下单界面：UI展示与输入信息检查，此处为常用的测试用例设计方法。

3支付：正常场景&异常场景&支付信息检查。支付的正常&异常场景：1-手动操作；2-定时任务批处理（涉及第三方支付接口，批处理后得到处理结论，此处需考虑正常&异常时的DB事务一致性，目的是验证事务后的数据一致性。这里最好是看代码理解具体实现，或者看概要设计&流程图理解，走到每个分支）

4提交订单：根据项目情况是否调用第三方验证订单：正常&异常(eg.:超时)&失败(eg.:验证失败)

 支付异常场景事例：1-第三方支付数据更新失败；2-支付回调超时；3-支付时人为终止；4-支付金额设置(eg.:小数)；5-DB事务一致性：交易订单表与商品订单表的支付状态

5退货：1-业务层面：UI展示与功能；2-退保批处理与DB事务一致性：相关表的数据一致性。

 

三、测试用例设计反思

对分布式的理解不够深入、不熟悉/没有正确理解项目的业务数据流。测试用例规范：一个用例一个点，复杂用例分成多个确认点确认，测试用例的粒度不要太粗。

 

四、测试用例总结

除了基本的功能测试用例（UI展示、界面操作、数据库的正确保存、服务端的接口测试与接口自动化等），也要结合代码的具体实现，了解服务端的处理逻辑，尽可能的走到每一个分支。