测试用例的设计在很大程度上是由简单到详细且逐步完善的一个过程。其依据需求文档、概要设计、详细设计等参考资料。假如在测试过程中没有测试用例或仅有简单的功能描述，那么测试过程难以控制或测试结果将毫无可靠性而言。网上对测试用例的具体设计的文章也数不胜数了，笔者在这也不重复阐述。
因此，笔者对测试用例的总结为：
简单的测试用例可靠性低、重用性差，且可能导致不同人员理解不同。
详细的测试用例可靠性高，而且便于估计执行所需时间，易于控制。
我们在设计测试用例时应当考虑以下几点：
第一、时间要求。［是否在测试过程中，测试用例的执行易于控制］
第二、执行者。［应当考虑不同的测试用例执行者对系统的了解程度］
第三、理解程度。［当把测试用例交付给他人执行时应不需要过多的解释］
所以，测试用例的设计重要性显而易见。
登录功能，是一个大家熟悉得不能再熟悉的功能了。但是往往这类看似简单但却不简单的功能，在设计测试用例时却漏洞百出。下面，我们通过Google邮箱的登录窗口实例进一步了解测试用例的设计。
☆ 简单的测试用例
用例编号 | 功能点 | 操作过程 | 预期结果 | 备注 |
01 | 登录 | 能够正确处理用户登录 | 正确处理登录操作 | 无 |
☆ 一般的测试用例
用例编号 | 功能点 | 操作过程 | 预期结果 | 备注 |
01 | 登录 | 输入正确的用户名和口令可以进入系统 | 登录成功 | 无 |
输入用户名或口令错误无法进入系统 | 登录失败 | 无 |
☆ 详细的测试用例
用例编号 | 功能点 | 操作过程 | 预期结果 | 备注 |
01 | 登录 | 输入正确的用户名和口令（均为6位），点击[登录]按钮 | 进入系统 | 无 |
输入正确的用户名和口令（均为10位），点击[登录]按钮 | 进入系统 | 无 | ||
输入正确的用户名和口令（均为6至8位之间），点击[登录]按钮 | 进入系统 | 无 | ||
用户名为空，点击[登录]按钮 | 提示输入用户名 不能进入系统 | 无 | ||
用户名为空格，点击[登录]按钮 | 提示无效用户名 不能进入系统 | 无 | ||
用户名小于6位，点击[登录]按钮 | 提示用户名太短 不能进入系统 | 无 |
通过以上三个测试用例，我们可以很直观的了解到测试用例具体实现价值。但是，我们达到第三种测试用例设计技巧时还是不能体现其“详细”的概念化。
到这，可能很多读者会问为什么？其实，答案很简单。虽然我们在设计用例时把过程体现了，但并没有把测试数据容入当中。那为什么又要写入相应的测试数据呢？我们可以分三点看待这个问题。第一、没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试员理解，导致难以控制和执行；第二、通过将用例参数化，可以简化用例，使测试用例逻辑清晰，数据与逻辑的关系明了，易于理解；第三、有利于提高测试用例的复用性。所以，在加入输入（数据或操作等）、输出（结果数据或预期结果等）的测试用例可以很好的重复使用。
☆ 详细的测试用例（含测试数据）
结束语：测试用例的设计是否详细，直接关系着测试生命周期的正常表现。
