论测试用例的规范化

试用例是对一项特定的软件产品进行测试任务的描述而编制的一组测试输入、执行条件以及预期结果， 以便测试或核实某个程序路径是否满足某个特定需求， 体现针对此软件进行测试的方案、 方法、 技术和策略。 测试用例是测试项的细化， 是测试工程师在现场进行测试的实际依据， 因此测试用例的编写是软件测试活动中最重要的。 测试用例是测试工作的指导，是软件测试的必须遵守的准则， 更是软件测试质量稳定的根本保障。

测试用例内容应该包括测试目标、 测试环境、 输入数据、 测试步骤、 预期结果、 测试脚本等， 并形成文档。 每个具体测试用例都应包括下列详细信息： 用例编号、 用例名称、 测试级别、 入口准则、 测试步骤、 期望结果、 判断标准、 出口准则、 注释等。

1 编写测试用例的基本方法

早期的软件测试是按功能编写测试用例， 这种方法比较简捷， 按用例规约遍历每一功能即可以完成软件测试的目的。 但是随着软件行业的发展， 对于复杂操作的程序模块， 其各能的实施是相互影响和紧密相关的， 可以演变出数量繁多的变化， 在这种情况下， 如果没有严密的逻辑分析， 产生遗漏是在所难免。 路径分析是一个很好的方法， 其最大的优点是在于可以避免漏测试。 但路径分析法也有局限性。 在一个非常简单字典维护模块就存在十余条路径。 一个复杂的模块会有几十到上百条路径。 若一个子系统有十余个或更多的模块， 这些模块相互有关联， 再采用路径分析法， 其路径数量会呈现几何级增长， 在实际中就无法使用路径分析法来编写测试用例，那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。 因而目前软件测试都是按功能、 路径混合模式来编写测试用例。

2 针对于白盒测试的用例编写规范

白盒测试是有关代码的结构测试， 所以被测对象基本上是源程序， 以程序的内部逻辑为基础编写测试用例。 程序内部的逻辑覆盖程度， 当程序中有循环时， 覆盖每条路径是不可能的， 要编写使覆盖程度较高的或覆盖最有代表性的路径的测试用例。 在实际的逻辑覆盖测试中， 一般以条件组合覆盖为主编写测试用例， 然后再补充部分用例， 以达到路径覆盖测试标准。 其具体手段有语句覆盖、 判定覆盖、 条件覆盖、 判定/条件测试、 条件组合覆盖、 路径覆盖等。

3 针对于黑盒测试的用例编写规范

1.等价类划分。

2.边界值分析： 使用边界值分析方法编写测试用例时一般与等价类划分结合起来。 但它不是从一个等价类中任选一个例子作为代表， 而是将测试边界情况作为重点目标， 选取正好等于、 刚刚大于或刚刚小于边界值的测试数据。

3.错误推测： 在测试程序时， 人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例， 这就是错误推测法。

4.因果图： 等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能， 而没有考虑多个输入数据的组合引起的错误。

5.备选和异常： 测试用例可以分为基本事件、 备选事件和异常事件。 编写基本事件的用例， 应该参照用例规约（或编写规格说明书） ， 根据关联的功能、 操作按路径分析法编写测试用例。 而对孤立的功能则直接按功能编写测试用例。 基本事件的测试用例应包含所有需要实现的需求功能， 覆盖率达100%。 编写备选事件和异常事件的用例， 则要复杂和困难得多。

例如， 字典的代码是唯一的， 不允许重复。 测试需要验证： 字典新增程序中已存在有关字典代码的约束， 若出现代码重复必须报错， 并且报错文字正确。 往往在编写编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。 而测试本身则要求验证全部非基本事件， 并同时尽量发现其中的软件缺陷。

4 在编写用例时还要注意的两条原则

单个用例覆盖最小化： 如果一个要测试的功能有三个子功能点， 则应该用三个单独的用例分别来覆盖三个子功能， 这样测试用例的覆盖边界定义更清晰， 测试结果对产品问题的指向性更强， 测试用例间的耦合度最低， 彼此之间的干扰也最低。使测试结果分析最简单化： 在测试用例执行时， 要重点考虑如何使得测试结果分析和测试执行更为简单， 因为测试用例的执行属于多次投入， 测试人员要经常地去分析测试结果、执行测试用例， 在这部分活动上的投入是相当可观的。 成本永远是任何项目进行决策时所要考虑的首要因素， 项目中的测试也是如此， 对成本的考虑也应该客观和全面的体现在测试的设计、 执行和维护的整个阶段中。

微信+17031115530，拉测试微信群交流