TD管理模式下的用例书写方法之层进法

先说一些在软件测试过程中的一些现象：用例风格的多样和用例设计人员不同的思维习惯，都导致了用例评审、执行、维护一直处于比较困扰的境地。所以一直想总结出一些规范和方法来起到一定的约束作用以降低用例评审、执行和维护的成本。

古语有云：熟能生巧。什么事情做多了总能产生一些“巧”，这些“巧”往往都是体现在一些方法上，好的方法才能产生好的结果。我们公司使用TD来管理软件的开发。下面总结一下我在TD的管理模式下书写用例的一个方法--层进式的书写方法（先这么叫着吧测试老鸟不要笑我），当然这个方法在其他管理模式下可能也有一定的适用性，写出来供大家参考和借鉴。

一.根据设计文档列出测试点。TD中有专门提取测点的部分，刚开始设计用例的时候我就是先把测试点列出到TD的需求提取模块中。先写一遍测试点再书写用例模块去设计用例。对于新人练手来说这样有助于思维的逐步养成，但是当测试人员有了一些设计用例的经验后这种做法的效率就有些低了。当然，先列测试点再设计用例的思路是没有问题的。为了提高设计效率我现在设计用例的时候都是直接到用例设计模块去写测试点。因为TD的用例设计模块是树形的显示结构，这给我们设计用例带来很大的便利。将测试点直接写到用例的题目中，形如：XX系统_XX功能_XX测试点。也就是设计用例时先设计用例题目，用例的题目就是测试点。这样我们一边对照设计文档一边写测试点，测试点写完了用例的整体结构也就出来了。不过要注意，这样写出的用例容易受设计文档的干扰而导致测试用例的不完整，所以之前对文档进行评审。

二.对测试点进行层层挖掘。按照上述方法写出的用例题目数并不能代表用例的最终题目数。以上只是描绘出了用例的主干，还需要对测试点进行层层挖掘。将测试点进一步细化而形成覆盖率更高的用例集合。如：XX系统_XX功能_XX测试点1;XX系统_XX功能_XX测试点2....,有时这样细化的程度还够那就需要继续细化，如：XX系统_XX功能_XX测试点1.1；XX系统_XX功能_XX测试点1.2...这样以每个测试点和子测试点为节点层层展开就形成了一个逻辑性集中、可读性好、便于维护的用例集合了。还要说一下用例的细化程度，这里只提供一个经验值，每个用例题目下的用例数一般维持在3~5个左右为宜（除特殊情况）。这个主要是出于执行和理解的层面来考虑的，具体的数量大家可在日常工作中根据自己的实际情况来考虑。