测试用例该怎么写？什么时候开始设计测试用例？什么时候完成了测试用例的设计?上面几条可以算是软件测试用例设计方面热的问题，而且每隔一段时间会被不同的人重新提起。提问的有刚刚进入测试行业的朋友，也有工作一段时间后重新陷入迷茫的“老手”。这几个问题看似简单，可是要想回答的让大家都感到满意，还真是不容易。这样的高难度，笔者也不敢有太多的奢望，还是把自己的经验写出来，希望对大家有些参考价值吧。

测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合。这些特定目标可以是：验证一个特定的程序路径或核实是否符合特定需求。??这是RUP中关于测试用例的定义。而在实际工作中，对于测试用例的设计和选择，是考察一个测试人员工作能力和经验的好方法。如果您像笔者前面说的那样，已经在工作中开展了测试需求的整理工作，那么测试用例的设计工作会变成一件自然而然的事情了。如果您在需求阶段开始了对测试需求的整理，那么当这部分测试需求整理完后，可以开始相应测试用例的设计了。而随着开发工作的继续，在测试需求被不断的增补、调整后，也应该添加或修改相应的测试用例，以保证测试用例的有效性。

这里要特别强调一点：测试用例的完成并非是一劳永逸的，因为测试用例是来源于测试需求，而测试需求的来源包括了软件需求、系统设计、详细设计，甚至包括了软件发布后，在软件产品生命周期结束前发现的所有软件缺陷。来源的多元化注定了测试需求是非常容易发生变化的。一旦测试需求发生变化，则测试用例必须重新维护。如果您对于软件开发的迭代方法比较熟悉，那么可以对测试用例的设计采用同样的方法。而终的结果，是您的团队将逐渐拥有越来越全面细致的测试需求和测试用例库，测试人员越来越多的精力，可以放到对测试过程的考虑和测试用例的选择方面。至少在笔者的实践中，这种方法虽然前期需要相对大量的投入，但随着时间的迁移，在没有使用自动化测试工具的情况下，同样大大提高了每个测试人员单位时间内测试工作的效率。关于设计测试用例的方法，无论是在已经出版的专业测试书籍还是网络上的专业测试论坛中，都已经有了很多非常好的文章来专门讲解，笔者也不打算占用太多篇幅重新引用，大家如果有这方面需要，通过网络都可以很容易的找到这些资料。在这里，笔者只是想简单的评论一下很多初学者对这些方法容易产生的误解。相信对于任何一个测试人员来说，等价类划分法和边界分析法都是早接触，也是基本、容易使用的测试用例设计方法。很多朋友也都知道先使用等价类划分法划分出等价类，然后使用边界分析法确定测试需要的边界值。但是很多朋友也提到，在工作了一段时间后，发现这两中方法所能应用的地方越来越少，难道这两种方法真的只能应用在检查编辑框输入类型和输入长度的时候吗？当然不是。对于一些刚刚接触测试工作的朋友提出的这个问题，笔者认为现在市面上的很多测试书籍都要承担很大的责任。比如很多书中，在讲到测试用例设计时，都不约而同的使用同一个例子??Windows计算器程序。通常是告诉你对于计算器有一个允许的输入范围（比如允许输入一个大于0小于等于100的整数），然后要求设计相应的包含合法数据和不合法数据的测试用例。当然，仅仅是这样一条简单的描述，我们已经可以设计出很多测试用例和测试数据了，比如对于输入范围的考虑，对于输入数据类型的考虑，对于输入长度的考虑等等。但是在我们的实际工作中，很多时候看到的并不是这样过于简单的软件需求描述，很多时候这些内容都是隐含在一些算法或业务规则中的。我们现在举个例子来看一下：“双倍余额递减法是在不考虑固定资产残值的情况下，以平均年限法折旧率（不扣残值）的两倍作为折旧率，乘以每期期初固定资产折余价值求得每期折旧额的一种快速折旧的方法。
　　　年折旧率=2÷预计使用年限×
　　　 月折旧率=年折旧率÷12
　　　 月折旧额=期初固定资产账面净值×月折旧率
　　 为了保证固定资产使用年限终了时账面净值与预计净残值相等，在该固定资产折旧年限到期的前两年，将固定资产净值扣除预计净残值后的余额平均摊销。”上面的内容是我国现行财务制度中关于固定资产折旧的一种方法??双倍余额递减法??的具体算法，大家可以在任何一本会计书中找到这部分内容以及一些相应的例子，不过我们这里并不关心固定资产的折旧到底是怎么一回事。笔者想知道的是大家在看完上面的描述后是否已经发现，我们在设计测试用例时，对于准备进行折旧的固定资产，至少应该包括预计折旧年限小于两年、等于两年和大于两年三种不同的类型。这也应该算是一个等价类划分法和边界分析法的应用吧。实际上，制约我们更好的使用这些测试方法来进行测试用例设计的，并不是方法的应用范围不够宽广，而是因为如果我们不能对这些同实际业务相关的具体算法或业务规则进行深入的分析，不可能挖掘出深层的测试需求，那么这两种方法的应用也很有限了。这也是笔者在前面一再强调加深对软件需求了解的原因。对于网络上也有讨论的另外两种方法??错误推测法和因果图法，则分别因为可靠性较差和操作相对复杂而并没有得到广泛的应用。