如果你选择了转发本篇内容、建议留下对本文章的意见和需要改进的地方;
如果你选择了收藏本篇内容、建议添加关注不迷路!
(本人是公司在职人员,空闲时间整理测试理论更新,所以内容更新比较慢。请理解!)
引言(1):如何保证测试用例的质量?
1、测试用例的覆盖率,必须保证需求点的100%覆盖
2、测试用例的可执行,得保证测试用例能够执行 ,或者便于操作的步骤
3、测试用例的可读性,能做到让一个不懂测试的人员,也可以根据测试用例,执行用例即可达到标准
4、测试用例的评审,往往一个人的思维具有局限性,但多人进行讨论就会迸发出不一样的维度或者见解,增加测试用例的健壮性,也可以去除重复的测试用例。
5、及时的维护测试用例,也许一个功能的变更,或者场景的添加,就需要考虑更多的情况,保证测试用例的完整性
6、确保测试用例足够多的异常场景来进行异常测试
7、收集用户在使用产品过程中反馈的问题进行用例设计
用例设计的基本思路在实际工作中,稍微大型一点的软件系统一般都包括用户注册、登录、搜索以及附件上传等常见模块。本节就以这些模块为例,结合已介绍过的用例设计方法来分别讲解这些模块的设计思路。
引言(2):编写测试用例的步骤?
- 序号
- 测试模块
- 标题
- 前置条件
- 测试环境
- 测试步骤与数据
- 期望结果
- 实际结果
- 是否通过
- 备注
- 以上就是我在编写测试用例过程中的一般步骤。
QQ邮箱注册模块
由于QQ邮箱大家都比较熟悉,其用户体验也做得很好,接下来就以QQ邮箱注册模块(简化版)为例来分析一下它的测试思路。
一. 此注册模块的需求文档
邮箱名:由3~18个英文字符、数字、点、减号、下划线组成。昵称:中英文字符,不能为空。密码:长度为6~18位,不能为空,至少包括英文、数字、符号中的2种。
二. 基本功能的测试点分析
从图中可以看到QQ邮箱的注册页面为3个字符输入框。上文介绍过对于多个输入框的测试可以采用正交表法。基于正交表的设计思想,可以设计出以下组合的测试点
针对每一个输入框,还需要利用等价类划分法、边界值分析法以及错误推测法设计正确和错误的测试数据分别对邮箱名、昵称、密码输入框进行测试。
实际工作中,可以将输入框测试的测试数据合理地设计到上表中,即在利用正交表测试输入框组合时,同时进行输入框测试。
例如,对于表中的第二行组合,需要输入正确的邮箱名、错误的昵称、错误的密码。那么这个正确邮箱名的测试数据,可以从邮箱名的有效等价类中选一个(如test_123-a@qq.com);错误昵称的测试数据,可以从昵称的无效等价类中选一个(如@@@);同理,错误密码的测试数据,可以从密码的无效等价类,或者从边界值中不符合需求的测试数据中选取(如取五位密码12345),那么第二行组合的用例可以设计为如下表,这样在进行组合测试时,就已经对每个输入框的某些测试点进行了测试。
在本例中,QQ邮箱注册模块的功能测试用例其实就是将邮箱名的用例、昵称的用例、密码的用例合理地组合起来,通过如表的组合设计,覆盖所有的测试点。本测试用例的设计主要考察测试人员对常用用例设计方法的运用能力。
QQ邮箱登录模块
一 登录模块的需求文档
账号:由3~18个英文字符、数字、点、减号、下划线组成。密码:6~18位,不能为空,至少包括英文、数字、符号中的2种。
二 基本功能的测试点分析
下图可以看到QQ邮箱的登录页面主要由用户名和密码这两个输入框组成,同样可以利用正交表分析法来设计。表中列出了用户名和密码输入框的各种测试组合。
1)测试输入正确用户名和正确密码的组合:可以在用户名的有效等价类中选择一个正确的用户名作为测试数据,在密码输入框中输入与用户名对应的一个正确密码。
(2)测试输入正确用户名和错误密码的组合:可以在用户名的有效等价类中选择一个正确的用户名作为测试数据,同理从密码的无效等价类、边界值分析法和错误推测法中选择不符合需求文档或错误的密码作为测试数据。
(3)测试输入错误用户名和正确密码的组合:可以在密码的有效等价类中选择一个正确的密码作为测试数据,然后从用户名的无效等价类、边界值分析法和错误推测法中分别选择不符合需求的用户名或与密码不匹配的错误用户名作为测试数据。
(4)测试输入错误用户名和错误密码的组合:可以从用户名、密码的无效等价类,边界值分析法和错误推测法中分别选择不符合需求的用户名和密码作为测试数据。
在本例中,QQ邮箱登录模块的功能测试用例就是将用户名的用例、密码的用例合理地组合起来,通过上表的组合设计,覆盖所有的测试点。本例的用例设计主要考察测试人员对常用用例设计方法的运用能力。
QQ邮箱邮件搜索模块
搜索功能也是QQ邮箱比较常用的功能,对搜索模块来说,测试人员又该如何测试呢?接下来就以QQ邮箱的搜索模块(简化版)为例来分析一下搜索模块的基本测试思路,如图
一 关键字搜索的需求文档
(1)支持模糊匹配和完全匹配、支持搜索框记忆功能、支持全角搜索、不支持同音字或错别字搜索、不区分字母大小写、支持特殊符号的搜索、支持常用快捷键、支持含有空格的搜索、支持中英文数字的混合搜索、不输入任何字符搜索时则显示全部内容、支持超长字符串搜索。
(2)没有限定关键字的长度。
(3)搜索的位置:全部内容,包括邮件地址、邮件标题、正文、附件名、草稿箱、发件箱等。
二 基本功能的测试点分析
本例需求的细节项较多,那么测试人员就需要针对这些细小的需求项进行用例设计;其次搜索框毕竟还是一个输入框,所以对各种字符的处理能力也是测试的一个关键。对搜索输入框设计测试用例的思路,可以借鉴前面学习过的字符输入框对字符的处理过程。接下来,本书列举了搜索框常见的测试点,以下的测试点都是初级软件测试人员能理解的。
第一,正常情况下的搜索。
(1)把邮件地址的部分内容或全部内容(模糊匹配和完全匹配)作为关键字进行搜索,可搜索出内容。
(2)把邮件主题的部分内容或全部内容(模糊匹配和完全匹配)作为关键字进行搜索,可搜索出内容。
(3)把邮件正文的部分内容和全部内容(模糊匹配和完全匹配)作为关键字进行搜索,可搜索出内容。
(4)把附件名称的部分内容和全部内容(模糊匹配和完全匹配)作为关键字进行搜索,可搜索出内容。
(5)输入不存在的内容进行搜索,搜索结果为空。
(6)搜索结果为空时应给出相应提示。
(7)输入曾搜索过的关键字进行搜索时,搜索框应该给出记忆的功能。
第二,各种异常情况下的搜索。
(1)不输入任何字符进行搜索,显示为全部内容。
(2)搜索的关键字中包含全半角混合字符,可以搜索出内容。
(3)搜索的关键字中包含有同音字或错别字,不能搜索出内容。
(4)搜索的关键字中包含各类特殊符号,可以搜索出内容。
(5)搜索的关键字中包含大小写字母,可以搜索出内容。
(6)搜索的关键为中文英文数字混合并且每个字符的前后都加了空格,可以搜索出内容。
7)输入关键字为“0”进行搜索,可以搜索出内容。
(8)关键字中带有单引号进行搜索,可以搜索出内容。
(9)输入超长字符串进行搜索,可以搜索出内容。
第三,测试搜索框对快捷键的支持。
(1)在输入结束后,按“Enter”键后系统应该可以进行搜索处理。
(2)支持使用“Tab”键。
(3)支持“Ctrl+C”“Ctrl+V”组合键。
第四,可以尝试一下随意性的、无规则的测试(也叫探索性测试)
因为无规则的测试也可能会发现软件中的一些Bug。在本例中,QQ邮箱搜索模块的功能测试用例就可以依据以上四部分用例的测试思想进行设计。
对于一个初级软件测试人员,由于受经验和技术所限,刚开始可能无法设计出那么多的用例,这个很正常,最重要的一点是找准搜索框的需求文档并尽可能地去挖掘更多的需求细节(或向产品经理去求证更多的需求细节),然后再针对这些需求细节才能设计出更为完整的用例来,所以挖掘需求细节是一个初级软件测试人员能设计好测试用例的一个重要因素。
那么本例的测试用例设计主要考察测试人员发散思维能力和挖掘需求的能力。
QQ邮箱附件上传功能
附件上传也是QQ邮箱比较常用的功能,那么测试人员该如何对附件上传进行测试呢?接下来还是以QQ邮箱的附件上传模块(简化版)为例分析一下其基本的测试思路(只测附件上传功能),如图
一 附件上传的需求文档
(1)用户上传的文件可包含图片格式的文件、常见的文档、压缩文件这3类,见表
2)用户一次最多可上传10个附件,单个附件的容量不能超过1GB,多个附件的容量不能超过5GB。
二 基本功能的测试点分析
对于本需求,可以按有效等价类划分法、无效等价类划分法、边界值分析法、错误推测法这4种方法来设计测试用例,以下给出附件上传的常见测试点。
第一,有效等价类划分法的测试点有以下几个。
(1)分别单个上传所有格式的文件,且附件容量都是在1GB以内时,可上传成功。
(2)上传多个不同格式的附件(10个以内)并且附件总容量在5GB以内时,可上传成功。
(3)可以删除上传成功的文件。
(4)文件上传失败后,需给出正确合理的提示信息。
第二,无效等价类划分法的测试点有以下几个。
上传需求文档规定以外的格式文件(如.html、.tif、.mp3、.avi、.iso等)时,均不可上传成功。
第三,边界值分析法的测试点有以下几个。
(1)可以上传0KB的附件。
(2)可以上传一个1GB以内的附件。
(3)可以上传9个不同格式的5GB以内的附件。
(4)可以上传10个不同格式的5GB以内的附件。
(5)不可以上传11个不同格式的5GB以内的附件。
(6)可以上传一个0.99GB的附件
(7)可以上传一个1GB的附件。
(8)不可以上传一个1.01GB的附件
(9)可以上传多个不同格式的(10个以内)4.99GB的附件。
(10)可以上传多个不同格式的(10个以内)5GB的附件。
(11)不可以上传多个不同格式的(10个以内)5.01GB的附件。
备注:第一部分和第三部分测试点中如有重复的测试点需要在后期设计用例的时候进行合并。
第四,错误推测法的测试点有以下几个。
(1)不可以一次上传大批量文件(超过10个)。
(2)上传木马文件是否可检测(需要视需求而定)。
(3)上传可执行的文件(以.exe结尾的文件)是否可检测(需要视需求而定)。
(4)不可以上传超大容量文件(超过10GB)。
(5)如果存在已上传的同名文件,再次上传,检查文件能否正常上传(需要视需求而定)。
(6)是否可上传超长文件名的文件(需要视需求而定)。
(7)是否可上传一个正在打开的文件(需要视需求而定)。
(8)上传过程中网络中断后又恢复,是否可以接着之前的继续上传(需要视需求而定)。
(9)是否可以上传文件名包括特殊字符的文件(需要视需求而定)。
(10)是否可以上传文件名中包括中英混合字符的文件(需要视需求而定)。
(11)上传多个文件的过程中,一部分文件被删除或被重命名,是否会影响正在上传的文件(需要视需求而定)。
(12)上传文件的路径是否可手动进行输入(需要视需求而定)。
(13)检查文件上传的响应时间是否正常(是否符合需求规定)。
第五,最后测试人员一样可以尝试一下随意性的无规则测试。
这些测试点写出来之后,相信初学者都能看得懂,大体也知道如何利用以上的测试点去设计用例。对于第四部分中出现了几个视需求而定的测试点,这是因为在本例的需求文档中并没有对这些测试点给出明确的规格说明。在实际工作中,经常也会遇到需求文档对需求项的细节描述不是很详细的情况,很多隐含的需求在需求文档中并没有体现出来。在这种情况下,一方面要求测试人员在评审需求文档的时候更仔细一点,另一方面在设计测试用例或测试软件的过程当中要随时同产品经理或自己的领导沟通,找出这些隐含的需求标准,这样才能保证自己设计出来的用例覆盖面会更全面一些。初级软件测试人员由于相关的测试经验较少,如何去找这些隐含的需求呢?
建议初学者可以从以下方面入手。
(1)要紧扣需求文档,挖掘需求细节,并针对这些需求细节进行用例设计。
(2)除了应用所学习过的用例设计方法外,测试人员还应充分利用自己的发散能力和逻辑推理能力来设计,因为人的思维是开放的。
(3)想要更快地获取更多的测试思想,比较直接的办法就是通过互联网来获取相应的资料(因为常见功能点的测试网上几乎都有而且很全面),以此来充实自己的基础测试能力,并扩充视野。
(4)多与测试人员、开发人员、产品人员交流,多看测试人员之前写过的测试用例和相关文档。
如若转载,请注明出处:https://www.hanjifoods.com/16171.html