高效设计测试用例的技巧

1.什么是好的测试用例？

测试用例英文为Test Case，缩写为TC。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

好用例含有如下三点：

作为测试实施依据的测试用例，必须要能完整覆盖测试需求，测试用例的覆盖率最大化是一套测试用例的最重要评价标准。

一套软件产品的测试用例的分类，是否有归类，如同类的用例是否集中在一起测试，对应的用例是否集中到相应用例目录包下面，如接口的测试用例是否全部集中在接口测试用例用例库下。

测试用例是“一组输入、执行条件、预期结果”，包括清晰的输入数据和预期输出，测试用例中对测试结果的显式的要有可验证手段，比如：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

2. 常见的测试用例设计方法

• 等价类划分：首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类。从无穷多的测试数据中，挑选少量代表数据进行测试，是提高测试效率最有效的方法。
  

• 边界值分析：使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。

• 错误推测法：可以使用错误推测法追加一些测试用例，这需要依靠测试人员的智慧和经验。

• 提高逻辑覆盖：对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。

• 因果图法：如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。

• 用例场景法：对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。

• 软件产品中备选流用例占比：各软件产口中的备选流用例个数至少占总用例数50%。

3：如何高效的设计测试用例

那些显现的功能点容易编写相应的测试用例去覆盖，但对一些“隐含的测试点”，如大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对软件产品本身的了解，另一方面要靠测试人员的经验，来一一挖掘这些隐藏点的测试验证，才能真正地保证我们的测试覆盖度。这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

 其他测试类型的测试如性能测试、安全测试、可靠性等，这些测试通常都有其特定的测试方法，如性能测试准备大量的测试数据来进行大批量测试或是采取性能测试工具辅助验证测试。

如后台定时处理的备份文件功能的操作，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中有可能没有写出来，需要测试人员提升对被测软件产品的了解再去挖掘的测试点。

将业务流串接起来，关注的是业务流向的处理，这类用例也往往容易被忽略。识别出被测软件产品中常用的业务或是业务敏感度高的完整业务流的验证，需要测试人员对被测软件产品的行业知识的积累及被测软件产品的软件架构了解，才能进行深度挖屈其完整业务流程的测试点。

与被测试软件产品实际业务有关，如通讯行业计费系统的套餐功能的收费，需要在套餐生效的某一天或是月初或是月末，对所有相关功能中的日期处理进行测试；又如某项软件产品对IE浏览器能兼容，在IE8/IE9/IE10下都可正常运行，相同页面展示一致。

系统间的接口测试，有些接口与业务逻辑关联密切，不能单独从接口角度测试，要设计业务逻辑相关的用例。

4：如何让用例高效的使用

建立并维护一套完整的测试用例库，保证测试用例的完整性和有效性，提高测试用例的共享和复用率。保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。并要在测试过程中随着对软件的深入了解，不断进行调整补充。

测试用例库分软件产品系统测试用例库、公共测试用例库。

测试用例结构可以参考下列规划：