一、动态测试用例编写

1.分析因素

支付金额需要是数字，那如果输入非数字例如字母a，会怎样？这里有了名列前茅个因素（或维度），即是否是数字；数字有正有负，是否支持0和负数？这是第二个因素，即数字类型（考虑有理数）；支持小数，就有了整数和小数之分，于是第三个因素是小数点位数。

需要说明的是，划分并不是少数的。譬如第三个因素，可以从“是否是整数”的角度来划分，也可以从“小数点位数”来划分，是等价的。

2.划分等价类

首先，分析完因素设计用例时，要保证每一个层级只考虑一个少数的因素，也是为了保证MECE。例如，上图中的“正数”包含在“数字”中，而不能和它并列。

要保证每一个层级只考虑一个少数的因素

接下来对“整数”和“小数”进行等价类划分。每个分支都根据MECE分析法划分有效等价类和无效等价类，例如针对“小数”的划分，支持小数点后2位有效数字，即1位和2位都可以，那输入3位系统会如何提示？都要设计出来。

3.注意描述

失败：是怎样失败？无效类有三种情况，所以具体是“无法输入”，是“可以输入但无法确认”，还是“可以输入并确认但提示报错”以及报什么错，都要明确写出来。因为有些面向最终用户的关键系统，用户体验很重要，不明确写出来在测试时很难注意到细节。

同样，成功了会怎样？扣款是否正确，收款方能否收到，这些都是关键的验证点。

当然，写好一个完整项目的测试用例，离不开深入的需求分析。本节内容是在需求分析的基础上，教你如何写出覆盖全面、逻辑清晰、可读性好的用例，这也是复用和维护测试用例的基础。如何衡量你的用例是否符合这些特征，这里提供三个tips：

延伸阅读：

二、测试用例如何管理

在说测试用例管理之前，首先要明确背景，即为什么要管理测试用例，我们在第二小节已经提到了，这里再详细总结一下：

首先，一个测试用例可能既用于冒烟测试，又用于回归测试，以及不同级别的回归，需要一个方便的方法将其筛选出来；

业务系统会越来越复杂，有已经管理好的用例做参考，可以直观了解到某个模块涉及到的业务逻辑，有效避免漏测；

迭代开发时，要了解之前的逻辑。复用已有的测试用例，便于理解之前的业务逻辑，也避免了重复造轮子；

系统的重构，利用现有的用例，可以大大提升工作效率和质量。