我答“黑盒测试如何保证需求的覆盖度?”

本文探讨了黑盒测试如何确保需求覆盖度的问题,详细解释了用户需求、系统需求及测试需求之间的区别,并介绍了测试需求如何确保系统需求的100%覆盖。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

51testing最新的一个问题,黑盒测试如何保证需求的覆盖度?

http://bbs.51testing.com/thread-106504-1-1.html

 

下面说说我的看法。

黑盒测试如何保证需求的覆盖度?首先我们要明确这里提到的需求到底是什么。在软件开发活动中,涉及到的需求有用户需求、系统需求、测试需求等。

用户需求:描述了用户使用产品必须要完成的任务,在软件开发活动中,属于最基本的需求。

系统需求:描述了软件设计人员、编程人员必须要完成的任务。系统分析员通过分析用户需求,把用户的需求转变成开发设计人员看得懂的系统需求。

测试需求:描述了软件测试人员必须要完成的任务。资深测试工程师通过分析系统需求,产生测试需求,作为测试活动的指导。

        写到这里,我猜想命题人的本意应该指的是上面提到的系统需求,但我的观点认为,黑盒测试应该保证的是测试需求的覆盖度,系统需求的覆盖度应该由测试需求保证。

具体到这个题目来讲,只要涉及到度量,都会要求规范。要度量需求,首先就必须保证需求本身是可度量的,这就要求需求必须明确、规范。

用户需求由最终用户提出,通常比较笼统,例如用户可能会这样描述其需求,

UR1 “能够上网缴电话费”

系统分析员的工作就是分析用户需求,把用户的需求转换成开发设计人员能够理解的系统需求。系统需求从技术层面上对用户需求进行分析,把用户的需求分解成若干个功能点,例如

SR1 登录缴费系统

   要求加密传输,密码不少于6位等

SR2 输入电话号码

   要求验证号码的正确性

SR3 查询特定的电话费

   查询结果中要包含各类明细

SR4 缴费

   连接网上银行页面,要根据不同商业银行的网银,做不同的判断;

   缴费结果一定要明确显示

… …

在测试小组参与后,资深测试工程师要根据系统需求,编写相应的测试需求。测试需求一定要保证对系统需求的100%覆盖,即系统需求的所有功能点在测试需求中必须有所反映。例如

TR1-1 登录成功

TR1-2 登录失败

……

上述的TR1-1到TR1-2都对应于系统需求的SR1(功能点)。

测试工程师要编写测试用例,依据是测试需求,测试用例要保证对测试需求的100%覆盖,即测试需求的所有检查点在测试用例中必须有所提现。例如

TCF1-1-1

输入用户名huior,对应的密码987654,以及验证码

预期结果:用户正确登录缴费系统,进入欢迎界面

TCF1-2-1

输入不存在的用户名huior_error,密码123456,以及验证码

预期结果:提示“用户名不存在”的错误,返回登录界面

TCF1-2-2

输入正确的用户名huior,密码 123456,以及验证码

预期结果:提示“密码错误”,返回登录界面

TCF1-2-3

输入正确的用户名huior,密码 987654,以及错误的验证码

预期结果:提示“验证码错误”,返回登录界面

… …

 测试员在执行测试用例的过程中,会发现BUG,BUG可以和测试用例对应。这样的话,软件开发的各个过程都可以对应起来。

有了这样的对应关系,黑盒测试对于需求的覆盖度就会很容易度量。例如,测试员只执行了用例TCF1-1-1,只覆盖了TR1-1需求,假设系统需求中只定义了2个功能点,则 

测试需求的覆盖度 = 1 / 2 * 100% = 50% 

实现

一般情况下,要成功的实施以上的过程,单单靠手工实现起来很难。目前市场上已经有比较专业的工具来协助实现以上过程。我原来听过一些产品的介绍,要完全实现以上过程,需要几个工具结合起来使用,例如DOORS + TD配合使用,就可以把以上四个过程对应起来。

 

不足

白盒测试的覆盖率本身有一些不足,例如不能发现和数据相关的错误。

int test(int a)

{

       int d = 10 / a;

       return d;

}

一个测试用例(例如输入10)就可以让逻辑覆盖率达到100%,但很明显,该100%并不能说明测试已经很充分。

同样,黑盒测试对于需求的覆盖度量只能作为一种参考。例如,以上的例子中,假如测试员执行了用例TCF1-1-1和TCF1-2-1 ,则覆盖了TR1-1和TR1-2的需求

测试需求的覆盖度 = 2/2 *100% = 100%

很显然,虽然需求已经全部覆盖,但测试还不充分,还远不能结束。

所以我的结论是黑盒测试对于需求的覆盖度量只能作为一种参考,不能以此来衡量测试的优劣。以上文字仅代表个人观点

### 常见的黑盒测试方法列表 黑盒测试是一种基于软件需求和功能描述的测试方法,测试人员不关心程序内部结构,而是关注系统是否能按照规格说明正确运行。以下是几种常见的黑盒测试方法: #### 1. 等价类划分法 将输入域划分为若干个等价类,每个等价类中的数据在测试中被视为等效。通过从每个等价类中选取一个代表值进行测试,可以减少测试用例数量并提高测试效率。例如,在测试年龄输入框时,可将有效年龄范围(如18到60)作为有效等价类,而小于18或大于60的情况作为无效等价类[^5]。 #### 2. 边界值分析法 对输入或输出的边界值进行测试的一种方法,通常作为等价类划分法的补充。该方法强调对等价类的边界点进行测试,确保系统在临界值附近的行为符合预期。例如,如果某个输入字段允许输入1到100之间的数值,则应测试1、100以及其相邻的0和101等值[^2]。 #### 3. 判定表测试法 用于处理多个输入条件组合与相应操作之间关系的测试方法。判定表能够明确表达多个输入变量之间的逻辑关系,并为每种可能的组合生成对应的测试用例。这种方法适用于复杂业务逻辑的测试,是黑盒测试中最严格、最有逻辑性的测试方法之一[^3]。 #### 4. 因果图法 通过因果图将输入条件(原因)与输出结果(结果)之间的因果关系图形化表示,进而转换为判定表以生成测试用例。该方法有助于发现输入条件之间的相互制约关系,适用于逻辑复杂的场景。 #### 5. 正交实验法 利用正交表设计测试用例的方法,特别适用于多因素、多水平的输入组合问题。通过正交实验法可以减少测试用例的数量,同时保持较高的覆盖度。例如,在测试登录功能时,用户名、密码和验证码三个因素各有填与不填两种状态,使用正交实验法可生成少量但具有代表性的测试用例[^4]。 #### 6. 场景法 基于用户使用场景构建测试用例的方法,强调从用户的实际操作流程出发,模拟真实使用情况。这种方法有助于发现流程性错误,尤其适合于测试业务流程相关的系统功能。 #### 7. 错误推测法 依靠测试人员的经验和直觉来猜测哪些地方容易出错,并据此设计测试用例。虽然缺乏系统性,但在某些情况下可以快速发现隐藏较深的问题。 #### 8. 状态迁移测试法 针对具有状态变化特性的系统设计测试用例的方法。通过分析系统在不同状态下对输入事件的响应,验证状态迁移的正确性。该方法常用于测试状态机模型的应用。 --- ```python # 示例:使用边界值分析法生成测试用例 def test_age_input(age): if 18 <= age <= 60: return "Valid" else: return "Invalid" # 测试边界值 test_values = [17, 18, 19, 59, 60, 61] for value in test_values: print(f"Age {value}: {test_age_input(value)}") ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值