针对此条，对于LEADER而言，最大的难处在于时间风险的估算。最好的解决方式是和开发人员开会，共同探讨模块的复杂性和测试时间。一般，开发，测试，修复，再测试的周期中，开发和测试的时间是1：2左右。甚至更多。

　　对于测试用例的设计人员而言，最大的难处并不在于新功能本身，而是如何设计覆盖路径，新旧版本之间的问题将非常严重。怎样设计组合用例，将是测试的重中之重。

　 　活生生的例子： 我们的测试用例中没有设计到横向子模块的兼容性测试，因为旧版本没有该问题，而新版本也仅仅是调用这个模块。结果，在冒烟测试中，就发现，这个被调用的公 用模块，在某一个相对特殊的子模块中，会发生菜单项无效的问题。随后再想到要设计横向模块的兼容性测试，并和旧版本做比较，浪费了很多时间。

　　2、一定要和旧版本一起，做至少一轮的随机测试

　 　尤其是涉及到自定义的数据保存功能的情况下，用新版本的程序读取旧版本保存的数据看看。接口之间的古怪问题，一定会让你颇有成就感。另外，去有规律的做 一些古怪的随机测试，比如，程序中产生报表或者示例图之后，最小化窗口，再还原看看。很有可能，图片和数据就变了，或者消失，或者残缺了。这种怪事就在我 的测试中实际发生了。因此，这一轮的随机测试一定要做，思路越古怪越好。

　　3、不要嫌重复劳动麻烦

　　亲身经历了令人沮丧的事情。在某3天，我不停地测试一个功能，单元测试证 明代码和算法没有错误，我也看过，的确不可能出错。前台依赖这个算法而显示的数据上万。不过还是出于负责而一条一条的检查，一直没有出现问题。最终，想放 弃的时候，发现，这将近2万条数据，最后的10条果然出现了问题。你说妖怪不？早知道就应该从尾巴开始测试。哎。所以，不能放弃，知道不，测试就是要负责 的。

　　4、关于不可重现的BUG

　　唯一能够告诉新手的就是，你每做一个动作，都必须保持脑子清晰。当你发现某些一定是不可重现BUG时（比如内存溢出，花屏等），别着急关闭你的屏幕，直接叫开发过来看，或者打开任务管理器，并截取图片保存。因为这是你的业绩。

　　第一步：画出因果图：

　　第二步：从因果图导出判定表：

　　第三步：从判定表导出测试用例：

　　1、测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。

　　2、测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

　　3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是  `相同的。

　　二、测试用例设计方法原则（只对常用的两种举例）

　　比如：对边界值设计测试用例，应遵循以下几条原则：

　　1、如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

　　2、如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。

　　3、根据规格说明的每个输出条件，使用前面的原则1。

　　4、根据规格说明的每个输出条件，应用前面的原则2。

　　5、如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

　　6、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

　　比如：等价类设计测试用例的原则

　　1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

　　2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。

　　3、在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

　　4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

　　5、在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

　　6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

　　三、测试用例必要元素描述

　　测试用例编号：用来唯一标识测试用例的编号，由测试组根据具体情况统一管理。

　　测试用例级别：用来衡量测试用例的重要性，测试组根据具体情况制定统一标准。

　　测试需求或者测试需求编号（其实就是测试名称 尽量简单易懂）：描述测试的目的是什么。

　　前置条件：运行测试用例必须的条件

　　测试用列的输入：简单的讲就是用来测试的数据

　　操作：就是在输入数据之后用户的操作，将会影响到测试的输出

　　输出：相应的期望结果。

　　用于黑盒的测试用例

　　说明：根据情况可以将输入正确的用户名字和密码；输入错误的用户名字和密码进行具体的拆分；输入字母数字为组合的用户名，字母符号为组合的密码或者直接给出具体的值。一般写到上面的程度就可以了，能够给测试起到很好的指导作用。

　　用于白盒的测试用例

　　说明：一般要求函数有返回数值，如果没有就要根据设计说明书来判断是否实现设计说明书上提出的功能。

　　总结：目前我们用到的测试用例只有这两种，如果其中某一项没有就不必写出，原则上都要写出测试用例再做测试，而且要评审测试用例是否完整，否则所测试的需求很有可能是得不到充分测试的。用户可以根据实际情况选择测试用例模板。

　　一、用正交表设计测试用例的步骤

　　（1） 有哪些因素（变量）

　　（2） 每个因素有哪几个水平（变量的取值）

　　（3） 选择一个合适的正交表

　　（4） 把变量的值映射到表中

　　（5） 把每一行的各因素水平的组合做为一个测试用例

　　（6） 加上你认为可疑且没有在表中出现的组合

　　二、如何选择正交表

　　● 考虑因素（变量）的个数

　　● 考虑因素水平（变量的取值）的个数

　　● 考虑正交表的行数

　　● 取行数最少的一个

　　三、设计测试用例时的三种情况

　　（1）因素数（变量）、水平数（变量值）相符

　　（2）因素数不相同

　　（3）水平数不相同

　　四、我们来看看第一种情况：

　　（1）因素数与水平数刚好符合正交表

　　我们举个例子：

　　这是个人信息查询系统中的一个窗口。我们可以看到要测试的控件有3个：姓名、身份证号码、手机号码，也就是要考虑的因素有三个；而每个因素里的状态有两个：填与不填。

　　选择正交表时分析一下：

　　1、表中的因素数>=3；

　　2、表中至少有3个因素数的水平数>=2；

　　3、行数取最少的一个。

　　从正交表公式中开始查找，结果为：

　　L4(23)

　　变量映射：

这个可以直接查正交表，会发现L25(5^6)这个正交表，它表示有25次试验数即测试用例个数，5表示水平数，6表示因数。如下，有3个因数，它们都有5个水平数。 A:a1,a2,a3,a4,a5 B:b1,b2,b3,b4,b5 C:c1,c2,c3,c4,c5 它们对应的正交表为： 000000 012341 024132 031423 043214 104324 111110 123401 130242 142033 203143 210434 映射成测试用例为： A   B   C    a1 b1 c1  a1 b2 c3  a1 b3 c5  a1 b4 c2  a1 b5 c4  a2 b1 c5  a2 b2 c2  a2 b3 c4  a2 b4 c1  a2 b5 c3  a3 b1 c4  a3 b2 c1  a3 b3 c3  a3 b4 c5  a3 b5 c2  a4 b1 c3  a4 b2 c5  a4 b3 c2  a4 b4 c4  a4 b5 c1  a5 b1 c2  a5 b2 c4  a5 b3 c1  a5 b4 c3  a5 b5 c5  你可以再往上下一些工具，有助你生产测试用例。 

　　新入职公司，感觉测试部各位同事抒写的用例都不太标准。也许是出来久的缘故，很少去总结用例之间的关系。比如边界值分析法、等价类分析法、因果图分析法等等，这些本该对我们测试用例做指导工作的 方法。在实际测试中往往没有那么多时间进行归纳与分析。由此，本人借51这个黄金时间对之前在公司实习一个星期后，对表单测试用例、上传组建测试用例等在 Web系统测试中比较集中的用例进行了深入的分析和总结，由此拿出分析结果与各位分享一下。如有什么错误或不足之处希望各位能回复指出，非常感谢您的参 与！

　　使用FreeMind8.0总结了以下的内容，希望能结合实际项目使用各种覆盖方法对项目中的测试用例进行一次完全的归纳分析。

　　表单测试用例篇

　　（1）输入系统支持的数据格式测试用例分析

　　（2）输入非系统支持的数据格式测试用例分析

　　（3）路径覆盖测试分析

　　以下一个TextArea域为例子，使用Excell计算路径覆盖测试点，最终产生完全覆盖表单用例。

　　这里需要首先区分一下，是手动测试用例还是自动测试用例？

　　一、对于自动测试用例，首先就是要改变脚本的开发方法，如：

　　1.数据驱动脚本：将测试数据从脚本中分立，保存在外部文件中，当数据发生变化时，就不再需要更改代码，脚本的维护成本也比较低

　　2.关键字驱动脚本：把脚本中的检查点和执行操作的控制都维护在外部文件中，同样的，数据也会与代码分离开，可以说是结合了数据驱动的脚本开发方法，提高了测试脚本的共享和复用，缺点就是脚本开发需要更多的编程经验和设计能力

　　二、对于手动测试用例，那么我们就需要解决如下问题：

　　1.测试用例管理工具：之前看到很多讨论，都没有提到这个，但我想说的是，工欲善其事，必先利其器，良好的测试用例管理工具，绝对会为测试用例的复用带来简单、方便和快捷，也比office文档更适用于测试用例库的建设和维护

　 　2.测试用例的设计策略：测试策略无非有两种，基于功能和基于风险，之前也在论坛里提到过，还有筒子回贴说，测试策略就是基于功能的，这点我不敢苟同， 基于风险的测试用例，往往才是最能被复用的，对于任何同类型产品来说，无论如何进行功能升级，其失效模式也一定大同小异，比如：汽车的失效模式之一——刹 车失灵，这个不论是小汽车、三轮车、还是大卡车，都会存在同样的问题，但是功能和性能上，三者之间的差异就比较大了，所以我才会提到我们需要在测试开始前 考虑这样一种基于风险的测试策略

　　3.业务抽象：对于测试来说，同样需要跟研发的系统分析师有相当水平的测试设计师存在，他们的工作职责 是分析系统需求、抽象业务用例、设计测试方案来指导测试用例的进行，测试用例的复用也应该在这一环节被考虑，因为一条一条的去查找和审阅相同和相似的测试 用例，对于庞大的系统来说，由于海量测试用例的存在，无疑为大海捞针，但是从更高层次的业务用例中去寻找相似性，一定是更快捷的方法，但这也同时需要清晰 合理的、能够与分解后业务用例对应的、可跟踪可追溯的测试用例库结构，基于此，我才把管理工具放在了第一位

　　以上是我对于“如何提高测试用例复用性”的问题答案，其中不考虑“如何正确编写测试用例？”“如何进行测试用例设计”等问题。

　 　组织和编写良好的测试用例具有很强的可复用性。因此，在重复使用的过程中，需要对测试用例进行维护或者更新，测试用例不是一成不变的。在一个阶段的测试 过程结束后，或多或少会发现一些测试用例编写得不够合理或缺少测试用例覆盖一些应用场景。而且，当下一个版本在测试中使用前一个版本的测试用例时，其中部 分功能可能发生了改变，这时候也需要去修改那些受功能变化影响的测试用例，使之具有良好的延续性。通常情况下，测试用例需要更新，可能有以下几种原因：

　　1、先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究，对某些功能、特性、逻辑等的理解越来越清楚、深刻。

　　2、所发现的严重的软件缺陷没有被目前的测试用例所覆盖。

　　3、新的版本中有新功能的需求或者原有功能的增强而需要发生改动。

　　4、编写的测试用例不规范或者语句错误。

　　5、旧的测试用例已经不再适用，需要删除。

　 　开发一个软件产品，会发布多个版本，伴随着测试用例的不断维护，测试用例也需要不断完善并与产品功能、特性的变化保持一致，从而使测试用例和产品版本相 关联。在线软件服务中，用于不同的客户有不同的需求及定制，而且有些客户激进，有些客户保守，所以软件产品的多个版本常常共存，为不同的客户提供服务，这 时测试用例多个版本并存。所以在新建、修改、删除测试用例时要十分小心，确定对正确的版本进行修改，不要错该其他版本的测试用例。无论是对软件产品还是软件服务，多个版本并存的可能性很大，而且可能为不同的主要版本发布不同的补丁包或小版本，这样早期的一些版本所拥有的测试用例还是有效的。

　　根据产品特性和一致性准则，测试用例的维护可以按下面几种情况分别处理：

　　1、产品特性没变，只是根据漏掉的缺陷来完善测试用例。这时候，增加和修改测试用例均可，因为当前被修改的测试用例对相应的版本都有效，不会影响某个特定版本所拥有的测试用例。

　　2、原有产品特性发生了变化，不是新功能特性的问题，而是功能增强，这时候原有的测试用例只对先前版本（如 1.0、2.0）有效，而对当前新的版本（如 3.0）无效。这时，决不能修改测试用例，只能增加新的测试用例，不能影响原有的测试用例。

　　3、原有功能取消了，这时只要将与该功能对应的测试用例在新版本上置为空标志或“无效”状态，但不能删除这些测试用例，因为它们对先前某个版本还是有效的。

　　4、完全新增加的特性则很清楚，增加新的测试用例。

　　每个测试用例记录，针对一个有效版本都有对应的标志位，通过这个标志位，很容易实现上述维护需求。这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几倍、几十倍的增加，可以真正保证测试用例的完整性和有效性。

相关链接：

　　测试用例的设计在很大程度上是由简单到详细且逐步完善的一个过程。其依据需求文档、概要设计、详细设计等参考资料。假如在测试过程中没有测试用例或仅有简单的功能描述，那么测试过程难以控制或测试结果将毫无可靠性而言。网上对测试用例的具体设计的文章也数不胜数了，笔者在这也不重复阐述。

　　因此，笔者对测试用例的总结为：

　　简单的测试用例可靠性低、重用性差，且可能导致不同人员理解不同。

　　详细的测试用例可靠性高，而且便于估计执行所需时间，易于控制。

　　我们在设计测试用例时应当考虑以下几点：

　　第一、时间要求。［是否在测试过程中，测试用例的执行易于控制］

　　第二、执行者。［应当考虑不同的测试用例执行者对系统的了解程度］

　　第三、理解程度。［当把测试用例交付给他人执行时应不需要过多的解释］

　　所以，测试用例的设计重要性显而易见。

　　登录功能，是一个大家熟悉得不能再熟悉的功能了。但是往往这类看似简单但却不简单的功能，在设计测试用例时却漏洞百出。下面，我们通过Google邮箱的登录窗口实例进一步了解测试用例的设计。

　　☆ 简单的测试用例

　　☆ 一般的测试用例

　　☆ 详细的测试用例

　　通过以上三个测试用例，我们可以很直观的了解到测试用例具体实现价值。但是，我们达到第三种测试用例设计技巧时还是不能体现其“详细”的概念化。

　 　到这，可能很多读者会问为什么？其实，答案很简单。虽然我们在设计用例时把过程体现了，但并没有把测试数据容入当中。那为什么又要写入相应的测试数据 呢？我们可以分三点看待这个问题。第一、没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试员理解，导致难以控制和执行；第二、通过将 用例参数化，可以简化用例，使测试用例逻辑清晰，数据与逻辑的关系明了，易于理解；第三、有利于提高测试用例的复用性。所以，在加入输入（数据或操作 等）、输出（结果数据或预期结果等）的测试用例可以很好的重复使用。

　　☆ 详细的测试用例（含测试数据）

　　结束语：测试用例的设计是否详细，直接关系着测试生命周期的正常表现。

　　这个例子的设计并不是我首先想出的，我参考了原文，然后经过整理，融汇了我的Excel技巧，把它整理了出来，分析了表的生成过程，比原来的设计有一定的易学易用性。现在让大家来进行分析与学习。

　　需求规格：

　　1、如果落点在棋盘外，则不移动棋子；

　　2、如果落点与起点不构成日字型，则不移动棋子；

　　3、如果落点处有自己方棋子，则不移动棋子；

　　4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；

　　5、如果不属于1-4条，且落点处无棋子，则移动棋子；

　　6、如果不属于1-4条，且落点处为对方棋子（非老将），则移动棋子并除去对方棋子；

　　7、如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。

　　一、原因条件：

　　1、落点在棋盘上；

　　2、落点与起点构成日字；

　　3、落点处不为自己方棋子；

　　4、落点方向的邻近交叉点有棋子（绊马腿）；

　　5、落点处无棋子；

　　6、落点处为对方棋子（非老将）；

　　7、落点处为对方老将。

　　二、结果动作：

　　21、不移动棋子

　　22、移动棋子（不吃子）

　　23、移动棋子并除去对方棋子

　　24、移动棋子除去对方老将，胜利。

　　添加一个中间节点11，这样能够简化设计。然后画出因果图：

　 　通常的设计方法就是一个表的方法，我称为一表法。但是七个因子，表格就会非常的长，让人望而却步！2^7=128，那么长的表是一般人不能做到的，在 Excel里面都感觉版面不够，要是拿来考试怎么办？所以这里提供两表法。1、2、3、4只与11及21有关，可以使用一个表先处理。然后11、5、6、 7有可以作为一个表。