软件测试用例设计理论及技巧（偏黑盒）

最新推荐文章于 2024-09-11 15:38:09 发布

weixin_33775582

最新推荐文章于 2024-09-11 15:38:09 发布

阅读量101

点赞数

原文链接：https://my.oschina.net/dpp/blog/137343

版权

为什么80%的码农都做不了架构师？>>>

因为前几天在面试中被问及测试用例的纯理论的知识，一时错愕回答的很乱，所以今天搜集整理总结一下关于测试用例设计的相关理论知识。

1. 测试用例的作用和意义

软件测试中永远不可能做到穷举测试，又要使得测试工作的效率达到最高，那么该如何兼顾二者，往往成为测试工作中的瓶颈问题所在。如何测试，用什么方法测试，在什么环境和什么样的条件下进行测试，测量的工作量和如何避免重复的测试，等等各种应该考虑的因素在测试工作中如何协调和同步，在测试用例中应该充分描述这些问题。

因此，软件测试工作中处于重中之重的测试用例的设计要求也随之上升到更高的层次。测试用例不但构成了设计和制定测试过程的基础，而且测试的深度与测试用例的数量原则上是成正比的。

2. 测试用例定义

Robert V.Binder是这样描述的：“测试实例：输入、执行条件，及为一个特殊目标所开发的预期结果的集合。一个定义IUT（被测实现，即被测代码）及其环境、测试输入或条件，及预期结果的测试前状态的表示或实现。

3. 包含要素及需要注意的点

首先是测试用例所包含的元素，这个每个公司甚至不同的项目组可能都会有细微的差别，这里以我比较认可的一个版本：

ID
Title or Description or Summary
Precondition
Steps
Expected result
Actual result
Test environment: SW configuration(e.g. version info), HW config, specific configuration, etc.
Author
Date
History
Feature or Feature group

然后说到测试用例中需要注意的问题，这个引述一段文章中的论述：

    每个测试用例清楚地阐述了正在进行评估的用例、用例场景、测试目标或条件的有关说明。
    每个测试用例都描述了预期结果和评估该结果的方法。
    对于每个测试需求，在测试用例中需要考虑在正面测试和负面测试的条件下的测试，或者通过确定两个测试用例来实现，一个测试用例代表预期的条件，它可用于核实行为是否正确或符合预期（正面测试）。另一个测试用例代表不可接受的、异常的或意外的条件，它可用于核实测试需求是否未以非预期方式执行（负面测试）。
    在一般情况下，对于测试的每个需求来说，至少要有一个正面测试用例和为数较多的负面测试用例，以此来检查在异常情况下系统能否正常处理，或者用户进行了错误的操作时的友好提示等等。
    测试用例已被确定用来执行测试目标中所有的产品需求行为，包括（视情况而定）：功能、数据确认、业务规则实施、测试目标工作流程或控制、数据流、对象状态、性能（包括工作量、配置和强度）、安全性/可访问性、兼容性。
    每个测试用例都说明或者/代表一个唯一的输入集或事件顺序，它能够产生唯一的测试目标行为，复审那些产生相同行为的测试用例并判定它们是否等同，即它们是否都执行测试目标中的路径。每个测试用例（或每组相关的测试用例）确定初始的测试目标状态和测试数据状态。测试用例名称和/或 ID，与测试工件命名约定一致。

4. 测试用例设计方法

关于这个设计方法，首先得分黑盒测试和白盒测试：

白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖、程序变异。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。

具体可参考： http://baike.baidu.com/view/51297.htm

http://www.cnblogs.com/Jackc/archive/2009/09/16/1567203.html

黑盒测试中的几种主要方法是：

等价类划分
边界值
错误推测法
因果图
判定表驱动法
正交法
功能图法
场景法

关于其中每一种方法的详细介绍，可参考：http://blog.csdn.net/vincetest/article/details/1475499

5. 测试用例的评审及维护

关于测试用例的评审，结合自己的项目经历，第一的话当然是自己的评审，需要去看一看用例是否完整？是否每一个需求都有其对应的测试用例来验证？是否每一个设计元素都有其对应的用例来验证？时间顺序，能否产生唯一的测试目标行为？是否每个测试用例都阐述了预期结果？是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？是否包含了所有的单一边界？是否包含了所有的业务数据流？是否所有的测试用例名称、ID都与测试工作命名约定一致？

第二的话，因为参与评审的人员包含PM，系统分析员，对应模块开发者，测试组Leader（或许还有一些QA之间的交叉评审），我在项目中的做法是在写case前对用例进行一个简化的break-down list，就是只把测试点列成表格，方便自己思路更清晰，而且只是将这些list交予其他人员review的时候也节约很多时间。

随着项目的不断深入，用例库难免要进行更新维护，比如说在之前的Smoke auto-case中一旦API名称变化，某些函数功能的变化，都需要不断的与开发沟通并及时更新脚本的case。用例库的维护主要包括的就是不合适用例的修改、冗余用例的删除、测试用例的增加，以及一些其他方面可能会涉及的改动。

转载于:https://my.oschina.net/dpp/blog/137343