编写测试用例

开头

如果是老粉的话,就知道我一直学的是开发的知识,为什么突然写一篇测试的博客,会不会对测试理解不深,写一坨大的给你们,放心啊,我也学了很长时间的测试了,而且开发,我们懂一点测试的知识,以后我们对自己的项目进行测试的时候是不是也就更加专业,所以学这个还是很有必要的啊,好了,我们进入主题吧。我们也不需要搞什么专业的项目来进行测试(因为大家的知识面是不同的,所以我们就拿一些生活中的小例子来进行举例,这个也是我认为可以让大家更好理解的一种方式)。

我们先来试一试,我们买了一个水杯,我们要试一试这个水杯有没有什么问题,我们需要怎么做呢。水杯的测试不是很简单吗,就装下水,看看会不会漏,再看看喝水怎么样(应该就有小伙伴想,喝水有什么问题啊,来我们看实例)

,是不是这样喝水就有问题了吧(有人可能说感觉有点像强行拉上关系),那我们这样想一个塑料水杯,我们喝热水是不是就可能会对身体有害。所以说这个不算多余,这些都是需要我们测试的,而我们这样想就犯了一个小错误,就是我们想当然,我们之前的经验告诉我们这里不会出错,所以我们忽略了这个问题。但是如果是你写的代码(说句不好听的,可能跑起来,你都很开心了,所以你还指望什么之前的经验啊)。但是如果我们只有这么一点测试用例的话就太少了,因为这样远远覆盖不了,客户在使用过程中会出现的问题,所以我们还需要开拓思维,来发展我们的测试用例。

常规,逆向,发散思维

既然我们要开拓思维,我们就要打破常规,但是打破常规说起来简单,实际做起来就不好说了。毕竟思维定势这个东西,限制还是蛮大的,所以我就给大家提供两个大方向(也是最实用的两个思维),一个是发散思维,一个是逆向思维。

发散思维呢,也很简单就是像思维导图一样,我们对一个方向,我们继续往下细分,这样的实例也就越来越多,我们举一个实例,假如说我要你说出你们家的家电,我一下就想到了,我小时候,小区里面经常有收空调,洗衣机,电风扇的,但是你要我想别的,就有点困难了,但是我们利用发散思维我们先把家里小分下类,就比如分为了卧室,客厅,厨房,厕所,可能有些人有书房,以及办公房,洗澡间,那我们再想,卧室里面有什么,空调,电风扇,冬天时候的电热毯,可能还有什么按摩的一些工具是吧,卧室就想了这么多,我们就下一个客厅,客厅东西就多了啊,洗衣机,烘干机,茶几(有些也是电的了),有些人要健身的跑步机,吊灯,冰箱,这些那些的,是不是,我们才再分类中列举了两个列举的电器就这么多了,别的后面再说。

逆向思维,也就是反其道而行,就像韩信的背水一战,正面打不过,就把士兵逼到绝境,而一个人再绝境中,会肾上腺素飙升,爆发出常人远远达不到的能力,从而极限翻盘(当然这个也是要条件的,后人一直想要模仿,但是大多数就是士兵逼到了绝境就无心再战,军心涣散了,而韩信也知道这点,他就悄悄派人潜入齐军中,把他们的旗帜换汉军的旗帜,导致齐军以为家被偷,齐军军心涣散,汉军的士兵看到了希望,从而爆发了,大破齐军)而在我们的测试用例中,我们的产品实现了我们想要的功能,那我们不想要的功能他是不是也实现了啊(你不可以想当然的认为没有噢)

但是就算我们拥有三个思维的加持,但是你说这个测试用例要多少才算多啊。

根据6方面编写测试用例

害,我的回答是韩信点兵,多多益善。所以我们还想要更近一步,我就和你们聊聊,我学到一个特别好的方法,就是他对于一个物品先进行了总结,对于一个产品可以分为6大类,分别是功能测试,性能测试,界面测试,易用性,兼容性,安全测试。这个也是发散思维的一个具体表现。我们就先来解释一下,这些类是代表一些什么吧,功能大家应该都清楚,就是我们对于这个产品最基本的要求,比如水杯就要可以喝水和装水,性能测试就需要对这个功能进一步的要求了,就比如我们这个水杯倒水快不快啊,如果有点勉强就想,我们下东西,有些可能以kb的速度下,这个性能就是不够(不过有些是故意的,就像某些网盘),界面测试呢,在网页这方面是界面,在生活中,也可以叫为好不好看,还是水杯

喜欢吗,易用性测试就是好不好上手,就比如现在的网上店铺都已经做出模板了,差不多都是这些页面,你非要创新,这里改改那里改改,这样对于第一次来的用户就不友好,就比如我看盗版视频的时候,那个页面,搜索都不在醒目的地方,还要我去找,我可能就换一个软件了。兼容性,在专业方面来说就是比如是是不是每一个浏览器都可以使用,但是我就是喜欢不专业的例子,就比如我们看短视频,年轻人可能喜欢看游戏这些的,但是老年人就更不看游戏,他们喜欢看广场舞视频,中年可能就看看孩子的教育,但是有没有什么全年龄端都喜欢的视频呢,也有就比如野生动物的纪录片,像这样全年龄端都喜欢的视频就是兼容性高的视频,安全性就好理解了,就是对于我们有没有什么不好的影响,就像之前那个保温杯爆炸不知道你们还有没有影响。现在我们就开始尝试下一下水杯的测试吧。

使用上述方法编写用例

我们还是对水杯进行编写测试用例,首先把水杯分为6大类,功能,性能,兼容,易用,界面,安全性测试,我们一步一步来。

首先是功能,当然这里最好的方法是画一个思维导图,但是我画了就不好让你们看到我的思路,所以我还是以打字的形式,我想到了以目录的形式,来模拟思维导图,嘻嘻。

水杯

功能测试

我们的功能还可以继续往下划分,我个人感觉要分细一点好,这样覆盖的测试面就更广一点,但是我也知道太细了会造成时间的浪费,所以后面我也会有优化手段。

喝水

喝水我们就可以在装满的时候喝水看看怎么样,我们也可以在一半的时候喝下试试看,没水的时候,我们也要喝下(这些都不是多余,因为对于一个我们没有接触过的东西,我们也没有这样的经验,对于一个知道的东西,你也可能写出bug,多次强调了啊)。

装水

装水也是一样,我们先试试,装满了水,再继续装会怎么样,我装一半的水,怎么样,甚至不装水,而我们要装的一定是水吗,我们试一试装饮料,试试装奶茶,装咖啡,装中药(就拿这个来说,假如药渣我们都可以过滤掉,是不是这个也是我们的一个优点),都试一试。

特色功能

而上面都是一个水杯最基础的功能,而我们现在还要保温杯,我们就看看可不可以保温,有些上面还有盖子可以显示温度,我们也测试一下,还有这个水杯好不好拿,假如说水杯表面很光滑,手都拿不住,是吧各种各样的功能,都是需要我们测试的。

性能测试

性能测试就是对功能的进一步测试,就比如

保温效果测试

在很热的时候,客户烧了一壶水,倒进去了,等了一个下午还是烫嘴,在冬天的时候,客户倒进去了,上个厕所就冷了,这些东西都是需要我们进行测试,

倒水的速率

看看倒水的速率高不高,太高了也不行,一下字就全部出来了,就容易搞一身,太低了,就搞个半天,

会不会漏

我影响很深就是我奶奶家的这个水杯你但凡导慢了,这个水就会沿着杯壁流出来,这个绝对不是人的问题,因为我每次都导出来了。

兼容性测试

这个我想到的就是分人,毕竟还是有特殊人群的。

老人,小孩,孕妇,以及一些残疾人。就比如孕妇,可能他们对一些正常人无所谓的东西会有一定的反应,这个我们也要避免。

易用性测试

就像我这个杯子,确实很大,但是我一个手还是拿的起来的重量,就是有点滑手,拿不稳,我就可以测试一下,在装满水的时候,好不好拿,装一半的时候好不好拿。这个就是易用性差了一点,反正不可能是人的问题。

界面测试

看看这个杯子好不好看啊,看看这个高度怎么样,还要圆形杯子的半径怎么样,会不会太大了,一个手抓不下,

安全测试

看看这个杯子能不能 耐高温,能不能耐氧化,能不能耐腐蚀,有没有做到密封,密封的时候里面气压太高了,会不会在打开的时候大量气体喷出,会不会于一些特殊的饮料,奶茶,中药发生一定的化学反应,这个杯子容不容易碎。

对于测试用例的优化手段

这样我们随随便便也可以写出2,3十个测试用例来,但是测试用例就是越多越好吗。那肯定不是,虽然我们测试用例多可以覆盖更多的场景,但是有些场景发生的情况是一样的,我们就可以把这两种情况合并,恭喜你,你掌握了等价类。多说一句,下面的方法我们在工作中不一定会使用,但是我只是想通过这些方法开拓我们的思维,使我们的测试用例更加的高效。

等价类

等价类就是依据需求将输⼊(特殊情况下会考虑输出)划分为若⼲个等价类,从等价类中选出⼀个测试⽤例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以⽤较少的测试⽤例达到尽量多的功能覆盖,解决了不能穷举测试的问题。不过我说白了,就是有些用例可以合并,没有必要再测试一遍。我们最常见的就是输入密码的时候比如我们要输入6到15位就可以了,那么小于6位的情况就是一样的都是无效的,大于15位的情况也是一样的都是无效的,在6到15位中就都是有效的,所以我们就只需要再小于6位中取一个用例就可以代表小于6位的全部情况了,同样的我们也在大于15位中取一个用例就可以代表大于15位的了,在6到15位中取一个代表全部的情况,但是问题又来了,小于6位,我取什么比较好呢,毕竟这么多数字我有选择困难症,不知道怎么选,这时就需要结合我们的边界值法,这个边界值法也特别好理解,就是出问题最经常的地方就是边界,所以我们最好的测试用例就是边界值,不过是一个是有效的,再取一个无效的这样凑一对,在6到15中,就是我们取了6是有效的,离6最近的无效的就是5了,所以 5和6就是一对测试用例,而15是有效的,离15最近的无效的就是16了,所以15和16就是一对测试用例。这两个方法也是在数字的场景下,最方便的,最好想的方法了。

正交法

我们在这种情况下

总不能每一个都按上面的进行测试吧,假如用户名按上面最少的算4个用例,那我们有5个要填的空,这样就有4的5次方个测试用例,是不是太多了,所以我们要进行优化。首先,这么在多元素的情况下,我们也就不需要知道具体是几个数了,我们知道有效无效就好了(就像领导不需要知道底层员工具体要做到事,但是要有一个大方向),那这样我们就把测试用例的数量减为了2的5次方,但是我们还可以优化,我们通过大量的统计(统计学的魅力),发现在某些情况下,出问题的概率要大于别的用例,所以我们进一步的优化就是测试大概率的就好了,别的用例就算了。而这些用例,我们就可以通过正交表来实现

大概像这样,因子就是元素,下面的 1,2,3就是可能发生的情况,不过确实在工作中不使用,我们要掌握这样的思维就好了。

判定表法

我们在生活中有多种操作的时候,组合在一起就可能会产生不一样的效果,就比如我现在玩的情感模拟器一样,我在前面的不同选择,就会导致后面出现不同的结果。而如果我们把每一个前面的每一个选择都提取出来,而后一一列举,我们选择的全部可能性,从而得出全部的结果,这样列一个表,我们就叫为判定表。如图

就像这样,也没有什么想多了,下次见吧

<think> 首先,用户的问题是:“我想了解编写测试用例的思路 请问编写测试用例的思路”。这基于几个参考引用:[^1], [^2], [^3], [^4]。 我需要回顾这些引用: - 引用[1]:描述了测试用例的基本定义、内容和作用。包括测试用例是对软件产品的描述,指定输入、预期结果等;内容有测试目标、测试环境、输入数据等;作用包括检验需求、体现工作量、展现设计思路。 - 引用[2]:提供了测试用例设计思路的具体例子,如查找替换操作在Word中的测试。包括通过测试(正常情况)和失败测试(边界值、特殊字符);还讨论了编辑窗口的功能测试,如控件交互、热键使用。 - 引用[3]:似乎是推广信息,提到功能测试用例设计思路,但内容不具体,主要是一个群组邀请。 - 引用[4]:讨论了设计测试用例的万能思路和六种方法,包括使用正交表等工具。提到了如何生成测试用例的具体步骤。 用户的问题集中在“编写测试用例的思路”,所以我需要综合这些信息,提供一个清晰、结构化的回答。 系统级指令要求: - 所有行内数学表达式用$...$,但没有数学内容,所以忽略。 - 独立公式用$$...$$,但主题不涉及数学,所以可能不需要。 - LaTeX语法正确:确保回答中如果有数学,但这里不需要。 - 使用中文回答:整个回答用中文。 - 生成相关问题:在末尾添加相关问题。 - 引用末尾添加引用标识:任何引用内容结束时自然地添加[^n]。 回答结构: 1. 介绍测试用例的基本概念。 2. 描述编写测试用例的整体思路。 3. 分解具体思路和方法。 4. 引用相关部分,并在结束时添加引用标识。 5. 结尾生成相关问题。 关键点从引用中提取: - 从[^1]:测试用例的作用和内容。引用:测试用例是测试工作的核心,指定输入、预期结果;内容有测试目标、环境等。 - 从[^2]:设计思路示例,如查找替换操作,区分通过测试和失败测试;控件交互。 - 从[^4]:万能思路和六种设计方法,如使用正交表。 用户提到“思路”,所以我应该聚焦在方法论上。 结构化回答: - **引言**:简述测试用例的重要性。 - **核心思路**: - 理解需求:基于用户需求设计测试用例。[源自[^1]] - 分类测试类型:如功能测试、性能测试等。 - 设计方法:使用边界值分析、等价类划分、错误猜测等。[源自[^4],提到六种方法] - 具体步骤:定义测试场景、输入数据、预期结果。[源自[^2]] - 考虑失败测试:包括边界值、特殊字符。[源自[^2]] - **工具和技术**:如使用正交表生成测试用例。[源自[^4]] - **总结**:强调测试用例的系统性。 生成相关问题: - 基于主题,如测试用例设计方法、工具、常见错误等。 完整回答框架: 1. 介绍测试用例的定义和作用。 2. 详细说明编写测试用例的思路: - 需求分析 - 测试分类 - 设计方法(列出关键方法) - 具体编写步骤 - 验证和优化 3. 引用相关引用。 4. 添加相关问题。 确保回答真实可靠,引用信息。 </think> ### 编写测试用例的思路 编写测试用例是软件测试的核心环节,它确保测试的系统性、覆盖性和有效性。测试用例描述了针对特定功能或场景的输入、操作步骤和预期输出,用于验证软件是否满足需求。以下是编写测试用例的核心思路,基于测试理论和实践总结而成。思路主要包括理解需求、设计测试场景、选择设计方法、编写具体内容以及优化验证等步骤。我将逐步解释这些思路,并结合参考引用中的关键点进行说明。 #### 1. **理解需求和定义测试目标** 编写测试用例的第一步是彻底理解软件需求,包括功能需求、用户故事或规格说明书。测试用例必须与需求对齐,确保每个用例都有明确的测试目标。例如: - **关键点**:分析需求文档,识别被测功能的输入、输出和边界条件。测试用例应覆盖正常流程(通过测试)和异常流程(失败测试)。 - **示例**:如引用[^2]所述,在测试Word的“查找替换”功能时,需明确“查找”操作的正常输入(如直接查找字符串)和异常输入(如过长或特殊字符)。 - **作用**:这确保测试用例能检验软件是否满足客户需求,并作为测试工作的基准[^1]。 #### 2. **设计测试场景和分类测试类型** 基于需求,将测试分解为多个场景,每个场景代表一个独立的测试路径。测试场景应覆盖: - **分类方式**: - **功能测试**:验证核心功能,如查找替换操作(引用[^2])。 - **边界测试**:针对输入数据的边界值(如最小值、最大值、空值),引用[^2]提到测试字符串长度(0,1,255)。 - **错误测试**:模拟失败情况,如输入无效数据或特殊字符。 - **交互测试**:检查控件间的逻辑关系,例如当搜索框为空时,相关按钮应为禁用状态(引用[^2])。 - **思路**:先识别主要用户流程,再扩展边缘情况。这有助于展现测试设计思路的全面性,避免遗漏关键场景[^1]。 #### 3. **选择测试用例设计方法** 采用结构化方法提高用例效率和覆盖度。常用设计方法包括: - **等价类划分**:将输入数据划分为有效类(正常输入)和无效类(错误输入),减少冗余用例。例如,对数字输入,有效类为1-100,无效类为负数或大于100。 - **边界值分析**:针对边界点设计用例,如引用[^2]中对字符串长度测试(1,255,256)。 - **错误猜测法**:基于经验预测潜在错误点,如测试特殊字符(如Word中的^g代表图片)。 - **正交表法**:对于多参数组合,使用工具生成用例(如Allpairs工具生成正交表),提高覆盖率(引用[^4])。 - **场景法**:基于用户故事设计端到端场景。 - **思路**:这些方法可单独或组合使用,形成“万能思路”,引用[^4]强调使用工具辅助设计,以提升效率。 #### 4. **编写具体测试用例内容** 测试用例应结构化编写,确保清晰可执行。内容包括(基于引用[^1]和[^2]): - **必备元素**: - **用例编号和名称**:唯一标识符,如"TC001_Word查找功能_正常输入"。 - **测试前置条件**:执行用例前的环境设置,如打开Word文档。 - **测试数据**:具体的输入值,例如查找字符串="测试用例"。 - **测试步骤**:详细的操作序列,如“1. 打开替换对话框;2. 输入查找内容;3. 点击查找按钮”。 - **预期结果**:明确的输出,如“文档中高亮显示匹配项”。 - **实际结果和备注**:记录测试执行情况。 - **思路**:用例应独立、可重复,并优先覆盖高优先级场景。引用[^2]演示了如何通过控件交互(热键、Tab键)设计用例,展现细节。 #### 5. **验证和优化测试用例** 编写后需验证用例的完整性和有效性: - **评审**:与团队评审用例,确保覆盖所有需求和风险点。 - **优化**:删除冗余用例,补充遗漏场景(如失败测试),并使用工具(如正交表)优化组合用例(引用[^4])。 - **迭代**:根据测试结果更新用例,体现测试方案和策略的动态调整[^1]。 #### 总结 编写测试用例的思路是一个系统过程:从需求分析出发,通过场景设计和结构化方法生成覆盖全面的用例,最终验证优化。思路的核心是确保测试用例能有效暴露缺陷,并作为测试工作的量化和指导工具[^1]。实际应用中,结合工具(如Allpairs)可大幅提升效率(引用[^4])。测试用例不仅是文档,更是测试人员思考过程的体现,帮助团队高效交付高质量软件。 相关问题: 1. 如何选择最适合的测试用例设计方法(如等价类 vs 边界值)? 2. 测试用例评审有哪些最佳实践? 3. 在敏捷开发中,如何高效编写和维护测试用例
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值