关于测试用例

　　什么时候开始设计测试用例？测试用例该怎么写？什么时候算是完成了测试用例的设计工作?上面几条可以算是网络上测试用例设计方面最热的问题，而且每隔一段时间就会被不同的人重新提起。提问的有刚刚进入测试行业的朋友，也有工作一段时间后重新陷入迷茫的“老手”。这几个问题看似简单，可是要想回答的让大家都感到满意，还真是不容易。这样的高难度，笔者也不敢有太多的奢望，还是把自己的经验写出来，希望对大家有些参考价值吧。 测试用例 是为特定目标开发的测试输入、执行条件和预期结果的集合。这些特定目标可以是：验证一个特定的程序路径或核实是否符合特定需求。——这是 RUP中关于测试用例的定义。而在实际工作中，对于测试用例的设计和选择，是考察一个测试人员工作能力和经验的最好方法。 如果您像笔者前面说的那样，已经在工作中开展了测试需求的整理工作，那么测试用例的设计工作就会变成一件自然而然的事情了。如果您在需求阶段就开始了对测试需求的整理，那么当这部分测试需求整理完后，就可以开始相应测试用例的设计了。而随着开发工作的继续，在测试需求被不断的增补、调整后，也应该添加或修改相应的测试用例，以保证测试用例的有效性。这里笔者要特别强调一点：测试用例的完成并非是一劳永逸的，因为测试用例是来源于测试需求，而测试需求的来源包括了软件需求、系统设计、详细设计，甚至包括了软件发布后，在软件产品生命周期结束前发现的所有软件缺陷。来源的多元化注定了测试需求是非常容易发生变化的。一旦测试需求发生变化，则测试用例必须重新维护。如果您对于软件开发的迭代方法比较熟悉，那么就可以对测试用例的设计采用同样的方法。而最终的结果，是您的团队将逐渐拥有越来越全面细致的测试需求和测试用例库，测试人员越来越多的精力，可以放到对测试过程的考虑和测试用例的选择方面。至少在笔者的实践中，这种方法虽然前期需要相对大量的投入，但随着时间的迁移，在没有使用自动化测试工具的情况下，同样大大提高了每个测试人员单位时间内测试工作的效率。关于设计测试用例的方法，无论是在已经出版的专业测试书籍还是网络上的专业测试论坛中，都已经有了很多非常好的文章来专门讲解，笔者也不打算占用太多篇幅重新引用，大家如果有这方面需要，通过网络都可以很容易的找到这些资料。在这里，笔者只是想简单的评论一下很多初学者对这些方法容易产生的误解。相信对于任何一个测试人员来说，等价类划分法和边界分析法都是最早接触，也是最基本、最容易使用的测试用例设计方法。很多朋友也都知道先使用等价类划分法划分出等价类，然后使用边界分析法确定测试需要的边界值。但是很多朋友也提到，在工作了一段时间后，发现这两中方法所能应用的地方越来越少，难道这两种方法真的只能应用在检查编辑框输入类型和输入长度的时候吗？当然不是。对于一些刚刚接触测试工作的朋友提出的这个问题，笔者认为现在市面上的很多测试书籍都要承担很大的责任。比如很多书中，在讲到测试用例设计时，都不约而同的使用同一个例子—— Windows计算器程序。通常是告诉你对于计算器有一个允许的输入范围（比如允许输入一个大于0小于等于100的整数），然后要求设计相应的包含合法数据和不合法数据的测试用例。当然，仅仅是这样一条简单的描述，我们已经可以设计出很多测试用例和测试数据了，比如对于输入范围的考虑，对于输入数据类型的考虑，对于输入长度的考虑等等。但是在我们的实际工作中，很多时候看到的并不是这样过于简单的软件需求描述，很多时候这些内容都是隐含在一些算法或业务规则中的。 我们现在举个例子来看一下： “双倍余额递减法是在不考虑固定资产残值的情况下，以平均年限法折旧率（不扣残值）的两倍作为折旧率，乘以每期期初固定资产折余价值求得每期折旧额的一种快速折旧的方法。 

              年折旧率=2÷预计使用年限×100%

　　　 月折旧率=年折旧率÷12

　　　 月折旧额=期初固定资产账面净值×月折旧率

　　为了保证固定资产使用年限终了时账面净值与预计净残值相等，在该固定资产折旧年限到期的前两年，将固定资产净值扣除预计净残值后的余额平均摊销。” 上面的内容是我国现行财务制度中关于固定资产折旧的一种方法——双倍余额递减法——的具体算法，大家可以在任何一本会计书中找到这部分内容以及一些相应的例子，不过我们这里并不关心固定资产的折旧到底是怎么一回事。笔者想知道的是大家在看完上面的描述后是否已经发现，我们在设计测试用例时，对于准备进行折旧的固定资产，至少应该包括预计折旧年限小于两年、等于两年和大于两年三种不同的类型。这也应该算是一个等价类划分法和边界分析法的应用吧。实际上，制约我们更好的使用这些测试方法来进行测试用例设计的，并不是方法的应用范围不够宽广，而是因为如果我们不能对这些同实际业务相关的具体算法或业务规则进行深入的分析，就不可能挖掘出深层的测试需求，那么这两种方法的应用也就很有限了。这也是笔者在前面一再强调加深对软件需求了解的原因。对于网络上也有讨论的另外两种方法——错误推测法和因果图法，则分别因为可靠性较差和操作相对复杂而并没有得到广泛的应用。

　　如何划分测试用例的粒度？

　　我们是不太可能在一个测试用例包含所有测试需求的，因为众多的功能以及不同的路径组合将使这样一个测试用例像巨无霸一般，完全不具有可操作性。——除非您的软件所包含的功能真的又少又简单，不过如果真的有这么一个软件，恐怕也没有测试和发布的必要了。

　　当然，这也并不是要您走向另一个极端，为需求中定义的每个特性或功能都提供一个甚至多个测试用例。这里的关键，是要寻找一个合适的度。 笔者推荐的方法是：关注有效功能。

　　有效功能：就是指在被测应用所涉及的实际业务中，当用户在手工状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。这个功能的特征是当我们把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就失去了意义。而该业务完成后，可以为其他用户或业务提供所需要的信息。

　　这里区分“有效功能”的关键有如下两个：

　　1.　这个功能是可以还原到用户原始的手工业务流程中去的。我们的计算机和软件，都是为了帮助用户解决手工业务中一些烦琐和低效的问题，而提出的一些忠实于原始工作方法或略有变通的解决方案，并不是要改变用户全部的业务流程。所以，应该从用户实际业务的角度来判断功能是否有效。

　　2.　这个功能是否可以标志着用户实际业务的一个阶段性结束？并且这项业务完成之后，被完成的业务实体是否可以交付给其他用户或业务以供完成下面的工作？ 为了方便理解，我们可以先看一下下面的例子。拿我们常见的财务软件来说，当添加一张会计凭证时，通常是需要填写会计科目，在使用计算机完成工作时，我们可以利用软件的功能，从很多备选科目中选择一个自己需要的科目，或者通过科目代码来输入科目。这项功能很有可能会作为一个特性要求出现在软件需求规格说明书中，那么这个科目的选择或输入是不是一个有效功能呢？让我们试着用上面规则来衡量一下。首先，这个功能在用户手工业务处理过程中是存在的，不同的是这项功能是在用户填写凭证时，在自己的大脑中完成的——用户会根据需要，在自己记忆的科目中选择合适的填写上去，这项功能节省了用户在记忆大量会计科目时付出的额外劳动。我们可以认为这个功能是为用户原来的工作提供了一种简便的、变通的方法。那么这项功能的完成对于用户来说意味着什么呢？我们从上面的描述中可以看到，用户希望软件提供的是可以添加一张完整的凭证这样的功能，而不仅仅是方便填写会计科目。填写会计科目只是用户在添加凭证时的一个步骤，单独把这个功能提取出来对用户来说没有任何实际意义。对于业务流程下游的用户，需要的也不仅仅只是一个会计科目的信息，而是一张包含了会计科目以及其他会计信息的完整的会计凭证，否则就无法进行下面的工作。这样看来，这个功能并不是一个有效的功能，我们可以把它最为需要测试的特性在测试需求中进行描述，却不应该作为一个单独的测试用例出现在我们的测试用例集中。而我们在测试用例中真正关注的，应该是添加会计凭证这个具有实际意义的功能。另外，我们还需要关注如何将多个相互之间存在依赖关系的功能区分为单个的有效功能。例如，现在有 A、B、C三个功能，其中B功能的开始必须依赖于A功能的完成，而且A功能如果出现不同的完成状态，B功能也会做出不同的反应；C功能对B功能的依赖也是如此。那么这时候，我们是否应当将三个相互依赖的功能包含在一个测试用例中呢？这样的做法也不是不可以，但是我们也可以先判断一下，这三个功能是否都是有效功能（您可以使用前面提到的方法来试着评判一下）？如果A、B、C都是独立的有效功能，那么我们可以从上面的描述中发现，它们之间存在的依赖性，可以理解为是一种状态或者说数据的依赖性。后一个功能关心的，是前一个功能最终提供给它的是什么样的“输入”，而不是前一个功能到底作了些什么。这样看来，我们完全可以将它们分别包含在几个独立的测试用例中，而在每个测试用例的开始，把不同的输入作为不同前置条件来描述。