目录一.测试用例1.介绍2.测试用例的一般设计思路1:设计测试的万能公式2:弱⽹测试3:下载安装测试3.设计测试⽤例的方法1:基于需求的设计⽅法2:等价类3:边界值4:错误猜测法5:正交法(重)6:判定表法(重)7:正交法与判断表法小总结8:场景法二:总结前言:对于测试来说,测试方法是很重要的,接下的博客内容在实际测试中,并不一定非得按照我的先这样在这样,具体场景具体分析一.测试用例1.介绍测试用例是专门为被测程序提供的一组集合,包含测试环境、操作步骤、测试数据、预期结果等要素为什么一定需要测试用例??当产品上线出现问题的第一责任人,就是测试的问题,他为什么没有测试到该错误,测试就扣工资了2.测试用例的一般设计思路1:设计测试的万能公式对于测试来说,用例一定是尽可能包含所有情况,保证生产品正确,那么好的测试用例必不可少一般思路:功能测试 界⾯测试 性能测试 兼容性测试 易⽤性测试 安全测试因为需要测试的都是新的,为了方便理解,举例水杯,大家就当不知道这个东西2:弱⽹测试测试在延迟差的网络环境下,数据的请求响应时间是否可以接受、超时文案的设计是否合理、是否有超时重连等在fidder里面设置弱网环境接下来访问搜狗网址3:下载安装测试检查下载是否正确,卸载是否正确,及卸载后再下载数据有没有清除干净4:小总结针对一切未知、没有需求文档等情况的产品时,设计测试用例一般从: 功能测试 界⾯测试 性能测试 兼容性测试 易⽤性测试 安全测试 弱网测试 下载安装测试3.设计测试⽤例的方法上面的可以保证我们在面对未知产品可以设计有效的方法,但真实的生产环境下很少用它,都是按照需求文档设计,因为很少会对所有项目都 “无差别、全维度” 地铺开测试,按需取选取即可1:基于需求的设计⽅法a.对需求进⾏分析和验证b.分析细化需求c.从细化的 需求中找出测试点d.根据测试点再去设计测试⽤例假设需求是:用户登录时输入正确账号密码应成功登录a.确定需求是否描述清楚,确保对需求的理解是准确的b.宏观的需求拆解为更具体子需求或需求点,比如:账号格式符合要求、密码格式符合要求c.从账号格式符合要求找出测试点,比如:“账号长度为 5-10 位”“账号仅包含字母和数字d.编写测试用例,比如:账号长度是小于5或大于10位能登陆成功等注:我们面对测试用例有时会出现无法穷举的情况,此时就需要如何减少数量且设计高效的测试用例的方法,接下来的讲的都是该方法2:等价类用于解决穷举法无法实现的情况,依据需求将输⼊划分为若⼲个等价类从等价类中选出⼀个测试⽤例如果这个测试⽤例测试通过则认为所代表的等价类测试通过解决了不能穷举测试的问题等价类分类•有效等价类有效的数据构成的集合利⽤有效等价类验证程序是否实现了规格说明中所规定的功能和性能•⽆效等价类无效的数据构成的集合,根据需求说明书不满⾜需求的集合。比如上面的账号密码正确格式是5-10位,不正确的太多位数,不好测试,可以用等价类表示3:边界值在有效等价类存在边界值,但等价类着重处理的是范围内数据是否合法,而边界值着重处理边界条件,是对等价类的补充分为:所以此时测试只需要: 5、10、4、11,即可全部测试完成3.1分类以及解释边界值分析里最常看的是三个“点”上点刚好等于边界的值。比如要求长度是 5-10 位那么 5 和 10 就是上点。离点紧挨着边界但不属于合法范围的值。比如 4 和 11。内点边界范围内的任意一个有效值。比如 7。按照“测多想全”的程度又可以分为三种弱边界值只测边界本身例如 5、10用例最少先确认边界可用。强边界值在边界基础上覆盖紧贴边界的有效值例如 5、6、9、10验证边界切换是否正常。健壮边界值再增加刚好越界的无效值例如 4、5、10、11验证系统能否正确拒绝非法输入。一般取 min-1 和 max1更极端的容错测试、特定的容错 / 极限测试场景才可能继续取 min-2、max2但已不属于健壮边界值。举例注册账号长度要求 5-10 位则边界为 5 和 10。弱边界值测 5、10强边界值测 5、6、9、10健壮边界值测 4、5、10、11其中 4min-111max1。因此对 5-10 来说就是 4 和 11而不是固定取 min-2、max2。4:错误猜测法基于测试人员的经验、直觉和对系统的理解推测程序中可能存在错误的地方从而设计测试用例的方法。关键在猜比如:谈到登录系统,就想到测试账号密码等5:正交法(重)等价类与边界值解决 “单一变量” 的 “范围覆盖” 和 “边界风险”,但面对多变量无法准确覆盖典型用例,此时就需要正交法进行解决(1).了解概念:正交试验设计是根据正交性由试验的全部组合中挑选出部分有代表性的点进⾏实验以及结果分析,从而找出最优的⽔平组合的设计方法核心:通过正交表减少⽤例数⽬,⽤尽量少的⽤例覆盖输⼊不同变量的组合。简记为:针对多个输入变量每个变量都有若干个固定取值水平,此时用正交表筛选出有代表性的组合覆盖测试用例(2).正交表正交表一般由表 实验次数(行) 因素数(列) 水平(填写的元素)组成性质一:每⼀列中不同的数字出现的次数相等这个大家看图,每一列的 1 与 2 的次数相同性质二:任意两列中数字的排列⽅式⻬全⽽且唯一当满足这两条性质,在数学上才是一个标准正交表(3).如何用正交表设计测试用例假设给定因素姓名、年龄、密码、确认密码、邮箱,每个的水平都是填与不填,按步骤设计正交表第一步:下载allpairs测试工具,给定因素与水平,自动设计正交表第二步:在excel表格填写水平与因素第三步:在pairs.exe文件下创建空文本,并把该表格内容复制到记事本并保存第四步:打开cmd输入命令创建正交表第五步:打开result文件,查看result表第六步:可以根据数据写出测试用例场景所有信息均填写姓名、年龄、密码、确认密码、邮箱全为 “填写”场景姓名填写年龄不填写密码不填写确认密码不填写邮箱不填写场景姓名不填写年龄填写密码不填写确认密码填写邮箱不填写场景姓名不填写年龄不填写密码填写确认密码不填写邮箱填写场景姓名填写年龄填写密码填写确认密码不填写邮箱不填写场景姓名填写年龄不填写密码不填写确认密码填写邮箱填写第七步:补充重要用例7.场景所有信息均不填写姓名、年龄、密码、确认密码、邮箱全为 “不填写”第八步:把生成的测试用例带入对应产品进行测试(4).使用场景适用于输入因素多、组合数量极大的场景如超过 20 种组合6:判定表法(重)(1) 了解概念判定表专门解决「多个输入条件按业务规则组合后产生不同输出动作」的场景核心是规则匹配而不是变量取值变化主要由条件桩、条件项、动作桩、动作项组成。组成条件桩列出所有输入条件比如“账号包含 admin”“通过内部链接”“点击注册”。条件项每个输入条件的具体取值通常用“是/否”“真/假”表示。动作桩可能出现的输出结果比如“管理员”“非管理员”。动作项在特定条件项组合下对应产生的动作结果。(2) 使用场景适用于输入条件少、组合逻辑复杂的场景尤其是输入之间存在“与、或、非”等逻辑关系且不同组合对应不同结果的场景。例如公交一卡通充值系统投币金额与充值金额的组合对应不同的充值结果订单优惠规则订单金额大于 500 元或使用红包则有优惠。(3) 如何用判定表设计测试用例假设案例注册账号时若账号包含 admin 信息或通过内部链接注册并且点击了注册按钮则会获得管理员权限。请设计测试用例。第一步明确规则管理员权限 账号包含 admin或通过内部链接且点击注册。即必须点击注册同时“账号包含 admin”和“通过内部链接”至少满足一个。第二步确定输入条件和输出条件输入条件A 账号包含 adminB 通过内部链接C 点击注册。输出条件管理员Y非管理员N。第三步列出全部组合并推导结果三个条件共 2×2×28 种组合只有“点击注册且账号条件满足”时才输出管理员权限规则12345678A 账号包含 admin否否否否是是是是B 通过内部链接否否是是否否是是C 点击注册否是否是否是否是结果非管理员非管理员非管理员管理员非管理员管理员非管理员管理员第四步画判定表第五步根据判定表编写测试用例结果为“管理员”的用例账号不包含 admin通过内部链接点击注册按钮 → 管理员账号包含 admin不通过内部链接点击注册按钮 → 管理员账号包含 admin通过内部链接点击注册按钮 → 管理员结果为“非管理员”的用例账号不包含 admin不通过内部链接不点击注册按钮账号不包含 admin不通过内部链接点击注册按钮账号不包含 admin通过内部链接不点击注册按钮账号包含 admin不通过内部链接不点击注册按钮账号包含 admin通过内部链接不点击注册按钮第六步把生成的测试用例带入对应产品进行测试7:正交法与判断表法小总结简单来说:若需在大量组合中高效覆盖核心场景选正交表若需理清复杂逻辑的全量组合关系选判定表法8:场景法(1).了解场景法就是⼀个常规的流程中某些阶段可能会出现⼀些意想不到的情况其中常规流程是基本流从阶段中分析出来的不同情况被称之为备选流还是不懂???看图:紫色的流程是基本流,除此之外的称为备选流(异常分支流)(2).根据场景法设计测试⽤例的步骤第一步:确定基本流第二步:确定备选流第三步:根据备选流补充测试⽤例第四步:编写测试⽤例1.和女朋友见面,家长叫我回家,拜拜~2.和女朋友见面,她想逛街,结果困了会酒店睡觉3.和女朋友见面,她想逛街,吃晚饭~~..........................(3).使用场景通过模拟用户使用软件的实际业务流程场景来设计测试用例以验证软件在不同场景下的功能是否正常、流程是否通顺二:总结1.当面对不熟悉的产品,直接按照一般设计思路来写2.在实际的生产环境下,都是有需求文档的,此时就需要按照需求文档设计测试用例,但因为有的需求测试无法穷举,此时就需要如何减少数量且设计高效的测试用例的方法,再根据测试的属性的变量数量、覆盖范围等确定方法3.方法的总结平时我们设计测试用例感觉不到使用正交表与判定表,是因为我们已经下意识的使用了,比如登录场景,我们随时可以说出许多个,要是细致分析如下:a.单变量填什么数据→ 等价类、边界值先给每个输入项定出具体的测试取值比如账号分「正确、错误、空」密码分「正确、错误、空」。b.多变量怎么组合着测→ 正交表解决 “3 个变量各 3 个值不用全测 27 组挑 9 组有代表性的” 这个问题它只管组合的抽样结构保证每个值都均匀出现不关心业务逻辑对不对。c.组合合不合法、填什么数值、对应什么结果→ 判定表按业务规则过滤无效组合、合并同类规则比如 “账号错误时密码和验证码无论是什么都只提示账号错误”把多组条件合并成一条规则