1.步骤和数据的分离：
好的测试用例，在执行的步骤(Step)的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：
1. 密码正确的登录
2. 密码错误的登录
3. 密码输入三次错误，卡被锁定
4. 取少于余额的款项
5. 尝试取大于余额的款项
6. 尝试取等于余额的款项(考虑手续费)
6. 取款额度大于当次的限制
7. 取款额度大于当天的限制
7. 取款次数大于限制次数
等等
不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下(此处只列出了操作的步骤，略去了系统的交互中的反馈结果)：
(1) 插入卡->A：输入密码->B：按“确定”键->重复A-B
(2) A：选择取款功能->B：填写取款金额->C：点击“确定取款”的按钮->D：取现金->重复A-D
因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢?
2. 单独的测试基础数据准备工作
第一个例子中的输入数据比较简单，但我们同样需要考虑的一个问题是：在测试中究竟我们输入什么样的具体数据呢?什么是“正确的密码”?什么又是“大于余额的款项”呢?
对于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至也有其他外部系统导入、传输或计算出的数据。 一个比较好的做法是，将这些测试数据提前准备好，在每个阶段性测试前导入到系统中。一个比较典型的例子，假设要求你单独去测试几张复杂的财务报表，用其他的模块和外部系统，自己逐一的去创造数据，那会非常耗时耗力。这时，基础数据的准备就显得尤为重要，以此才能保证测试工作是高效的、测试结果是精确的。
如果有可能，复杂的测试基础数据最好是提前准备好的，类似这里例子中简单的 一个帐号为1234567890，密码为66666的有效银行卡，里面有人民币1000元正，等等。将这些内容预先准备好(可以用自动化工具来准备，或导出已有的数据为一个SQL的脚本)，写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。
文章来源于领测软件测试网 https://www.ltesting.net/
