编写测试用例方法之错误推测法

错误推测法是一种补充等价类划分法和边界值分析法的测试用例设计方法,主要依赖于测试人员的经验。通过考虑可能出错的情况,如超长字符串、全角字符、数值0和单引号等,来创建额外的测试用例。这种方法有助于发现程序员可能忽视的错误,例如中文字符限制、空值与0的处理不当以及特殊字符引起的判断错误。通过不断积累经验,可以发掘更多潜在的错误场景,提高软件测试的覆盖率。

今天我们再来介绍另外一个编写测试用例的方法:错误推测法。话不多说,开始整干货,老规矩,首先全图镇楼

错误推测法其实它不同于等价类划分法或者边界值分析法,它是对有效等价类和边界值分析法的一个补充。因为错误推测法从这个里面我们也可以看出,从这句话也可以看出它注重的是一个推测。所谓的推测就是你要有自己的经验,就是在写了很多的测试用例之后,积累了很多的经验。

遇到一个产品之后,就根据自己的经验,在有效等价类和边界值分析法之外,仍能想到一些测试它的方法,这就是错误推测法。这个方法主要还是靠经验,个人经验比较丰富的话,这个方法可以写很多测试用例。

主要还是一个慢慢积累的过程。一般来说,常见的错误推测法都是有一些惯例的,也就是比较容易出错的地方。我们可以从这方面可以入手,比如在输入年龄的时候,有个年龄输入框,输入一个超长的混合字符串,这个是很容易出错的。

 还有输入的是全角字符串,所谓的全角就是中文字符下输入的一些字符串,这时候也是会出现问题的。因为程序员在对这个框进行设置的时候,他通常只对英文状态下的字符串进行限制,并没有对中文进行限制,那很容易漏掉中文的限制。

还有数值0,在判断这个框的时候,如果没有的话,为null或者为空的情况下其实和 0 是一样的效果。因为为null为空为零,它都是一个 false 的结果。但是后台因为使用的是 Java 或者是其他的一些比较严格的语言,它为空的情况下是会报错的。

但是为零的情况下,它就没有很好的控制住这一个异常。还有一个单引号,一般单引号也是很容易出现错误的,因为单引号在输入的时候它并不是一个字符串,它只是一个引号。你在获取这个值的时候,把引号作为一个字符串。它在判断的时候没有想到会有一个引号会过来。

 那很有可能这个引号作为一个数字判断也是容易出错的,所以这都是容易忽略的,忽略的状态下,所以一个单引号也是容易会出现问题的。所以通过错误推测法的话,写测试用例的时候,对于输入条件就可以写比如说年龄输入的话就是 20 到 99 的整数。

我们就可以对它进行分析,在输入框输入超长字符串,也有可能报错。错误推测的取值可以写一个很长的一个字符串,把这个字符串作为一个测试用例,输入到输入框里面,看它是否出错。还有全角,我们把这些全角的字符串也输入进去,作为一个测试用例。

还有 0,还有单引号都一样,都作为测试用例。当然错误推测法不止这几种罗列的可能性,只不过这几种比较常见,还有更多的一些常见的可能性,还需要自己去探索一下。

 

<think>好的,用户想了解错误推测的概念和应用。首先,我需要回忆错误推测的定义,确保准确无误。错误推测是一种基于经验和直觉的测试方法,主要用于识别软件中可能存在的缺陷。接下来,我得结合已有的引用内容,比如引用[1]和[2]提到的测试目的,说明错误推测在发现错误中的作用。 然后,应用部分需要具体说明如何使用这种方法。例如,测试人员可以列出常见的错误类型,如输入验证问题、边界条件等,并设计测试用例来模拟这些情况。需要引用[4]中的案例,当开发人员不认为某些情况是bug时,测试人员如何坚持立场,这可能涉及错误推测的应用场景。 还要注意用户可能想了解实际例子,所以应该举几个典型的错误类型,并说明如何应用推测。例如,测试文件上传功能时,推测用户可能上传超大文件,导致系统崩溃,这就是一个应用实例。 最后,要确保回答结构清晰,分点说明概念、应用步骤、优缺点和实例,并自然地引用相关文献。同时,生成的相关问题要围绕错误推测的扩展,如与其他测试方法的比较、优缺点、具体案例等,帮助用户深入理解。</think>### 错误推测的概念与应用 #### 1. 错误推测的定义 错误推测(Error Guessing)是一种基于测试人员经验、直觉和对系统潜在缺陷认知的软件测试技术。其核心思想是通过推测软件可能存在的错误类型,并针对性设计测试用例来验证这些推测[^1][^2]。例如,针对输入验证不完善的系统,测试人员可能推测“用户输入特殊字符会导致程序崩溃”,并构造包含`$%^&*`等字符的测试数据。 #### 2. 应用方法与步骤 **步骤1:建立错误清单** 基于历史缺陷数据、常见错误模式和领域知识,列举可能出现的错误类型: - 边界值失效(如$n=2^{31}-1$时整数溢出) - 并发操作导致的数据竞争 - 异常处理缺失(如网络中断后未重试机制) **步骤2:构造非常规测试用例** 根据推测设计非常规操作场景,例如: ```python # 测试文件上传功能的异常路径 def test_upload_invalid_file(): uploader = FileUploader() response = uploader.upload("A" * 1024**3) # 构造1GB的超大文件 assert response.code != 500 # 验证系统未崩溃 ``` **步骤3:结合其他测试方法** 与等价类划分、边界值分析形成互补,例如在测试数值输入时: - 等价类:$[-100, 100]$ - 边界值:$-100, 0, 100$ - 错误推测:输入`NaN`, `∞`, `1e308` #### 3. 典型应用场景 - **遗留系统维护**:针对已发现缺陷的相似模块进行定向推测 - **复杂业务逻辑**:推测多条件组合可能产生的逻辑漏洞(如$A>B \cap C<D$时状态异常) - **安全性测试**:推测可能的注入攻击向量(SQL注入、XSS等) #### 4. 方法优缺点分析 $$ \begin{cases} 优点 & \text{• 高效发现“隐藏较深”的缺陷}\\ & \text{• 适用于无明确规格说明的场景}\\ 缺点 & \text{• 依赖测试人员经验水平}\\ & \text{• 难以保证测试覆盖率} \end{cases} $$ [^2] #### 5. 实际应用案例 某电商平台在压力测试中,测试人员推测“秒杀场景下库存可能超卖”,设计以下测试方案: 1. 模拟$10^4$并发请求访问商品详情页 2. 记录初始库存$S_0=100$ 3. 验证最终售出量$S_{sold} \leq S_0$ 通过该测试发现了Redis分布式锁失效导致的超卖问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

编程小猪猪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值