蓝田网站建设,龙华app网站制作,货源一件代发从哪里找,大连 网站前言
上一篇博客讲述的是一次基本的测试过程。 在我们开始做了一段时间基础测试#xff0c;熟悉了业务之后#xff0c;往往会分配来写测试用例#xff0c;并且在日常测试中#xff0c;有时也需要补充测试用例到现有的案例库中。
在这里我们将回答以下问题
1、测试用例的…前言
上一篇博客讲述的是一次基本的测试过程。 在我们开始做了一段时间基础测试熟悉了业务之后往往会分配来写测试用例并且在日常测试中有时也需要补充测试用例到现有的案例库中。
在这里我们将回答以下问题
1、测试用例的基本要素2、测试用例的设计方法3、测试用例的有效性4、测试用例的粒度和评价
简单来说这篇博客就开始教大家怎么去写一个测试案例 测试用例的基本要素
其实测试用例的基本要素就是 测试用例的 定义/概念
测试用例Test Case是为了实施测试而向被测试的系统提供的一组集合这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。 好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试评价测试用例的标准对比好坏用例的评价标准
用例表达清楚无二义性。。 用例可操作性强。 用例的输入与输出明确。一条用例只有一个预期结果。 用例的可维护性好。 用例对需求的覆盖率高。 测试用例的设计方法
基于需求设计测试用例
我们在讲需求的时候说过需求是测试人员进行测试的依据。
当我们测试人员拿到需求之后需要分析需求验证需求的合理性与正确性。 随后从需求中提取出测试项再去根据测试项进行进一步的细份提取出测试点编写测试用例
虽然我们书写测试用例的时候是从软件功能上入手的但是当我们进行测试的时候最先引入眼帘的是 程序界面。因此我们测试一般是从软件界面开始进行测试。 也就是观察界面是否符合 UIUser Interface - 用户界面的设计稿。 这个设计稿你可以理解为是软件的静态页面也说是前端程序员的 页面模板。 前端程序员就是按照 UI 的 设计稿 进行 页面设计的。 软件页面测试完成之后就是验证软件的功能。 我们可以把业务相关的功能串起来进行测试。 比如 假设我们是阿里的员工比如: 淘宝APP的 购物场景搜索商品 加入购物车 结算 付钱[大致流程]它的购物场景是由一个个功能组成的。其实这就是把 业务中相关的功能 串起来进行测试 紧接着就是针对一个功能的不同输入 与 其相应的输出 进行测试。
比如:我们在淘宝的搜索栏中输入一件商品的名字页面就会输出响应的商品数据这个就是验证前端的“动态页面”的效果。 举一个例子: QQ登录测试用例对于登录操作就属于 针对同一个功能进行不同的输入以及对应的输出(效果) 1、输入正确的用户名和密码登录成功(输出)。 2、输入的用户名和密码有一个甚至两个都是错误的情况登录失败(输出) 3、输入的用户名和密码有一个甚至两个为空(没填入数据) 的情况提示某某为空!(输出) 随后就是 功能之间的交互性 与 异常功能的测试 功能的交互性:同一个系统中不同角色 (功能) 之间的交互。比如: 功能角色: 1、注册 和 登录[你没有注册怎么可能登录成功? ] 2、购物车 和 收藏夹[购物车满了。。多的放在收藏夹里面] 用户角色; 网购过的朋友都知道购买物品之后在待收货的界面中商品是有一个联系 客服的功能此时这个功能就相当于 让 买家 和 卖家 之间进行交互。 相同的例子还有很多! ! 上面这两个只是简单的交互操作。 复杂的:买家这边一下单卖家就会收到订单请求。卖家就根买家的订单信息进行发货同时会给买家更新货物状态。这也是 不同角色之间的交互动作。 这些功能不管你是那个角色都要进行测试! 尤其是和上面这种关于利益之间交互尤为重要!需要我们仔细对待! 异常功能的测试: 就拿我们前面看到 qg登录测试用例来举例! 1、用户名和密码有 一个/两个 为空有没有提示信息? 2、用户名和密码 一个/两个 输入错误有没有提示信息? 这里的错误提示信息就是异常功能[换句话来说:就是对异常情况的处理] 还有一些比较难的测试项 比如实现功能所用到的算法也是需要进行验证的。 关于算法的验证你是结合代码的 而且需要开发人员辅助告诉这个算法它的作用与规则是什么? 然后我们就进行针对性的去设计一些专门和特殊的数据 来 测试该功能的算法 然后就是从易用性兼容性性能等几个方面去考虑 易用性: 软件的功能使用起来简不简单上手度怎么样? 兼容性:软件安装在各种系统上会不会出现“排斥”[设备的操作系统不支持运行这款软件] ? 总结
当我们进行设计 测试用例 的时候我们应该从以下这几个点入手 1、界面测试 2、验证软件的功能把业务相关的功能串起来进行测试【每个功能都需要测试】 3、一个功能的不同输入 与其 相对应的不同的输出。 4、功能之间的交互性 5、异常功能的测试 6、功能所用到的算法也需要进行验证 7、从易用性兼容性性能等几个方面去考虑简单来说设计一个合格的测试用例就是从一个软件的外在到内在的进一步分析分析出一个个测试项。再通过这些测试项细化出一个个测试点而测试点又可以分情况处理【即对测试点进一步细分】。 一至六都是针对 功能性 进行测试。 唯有 第七条 是针对非功能性测试。 有的人可能觉得有点糊你确定是在讲 “基于需求设计测试用例”嘛
学习测试需要探索性思维。你也可以理解为是一种发散思维从不同的角度将内容给联系起来。你们之所以感觉有点糊不是你们没有看懂而是你没有捅破“那一层膜”膜就是你们要主动思考 两样东西的关联之处。下面我就来给你们“开个光”那 界面 来说界面的功能和排版都需要符合大众的需求。比如支付宝我们在打开支付宝的时候通常都是为了出示支付嘛或者是收款码进行首付款。因此我们希望已进入支付宝我们就能看到 这两个功能。如果两个功能可以合并在一起那最好。支付宝也是这么去做的当我们打开支付宝的时候马上就能发现收付款的功能图案
点击它我们首先进入是付款码因为花钱 比 收钱的日子要多。而且工资什么的都是直接进行银行卡转账的。因此默认显示 付款码是很合理的而且你想要收款的时候就在付款码的下面是有一个收款码的选项的。以上这一些都是根据用户的需求习惯衍生出来的。 而我们需要测试的地方也就是这里。 我们点击这个收付款首先进入的是不是付款码的界面 这就是一个测试点啊 为什么要测为了符合用户的需求啊 其它的6个点其实你们仔细想想。 结合前面讲解的例子就都能发现它们都是符合用户需求习惯的。 实战案例 - 日历系统 上面都是一些功能性的测试还有一些非功能性测试这里我们这是书写一下。
易用性兼容性性能安全性可移植性可维护性。非功能性测试 就是测试在软件本身有的功能之上做的一些限制。 比如 QQ用户登录测试用例中的关于登录操作的测试。 即使 用户登录操作是可以进行登录的。 而非功能测试就比如拿性能来说 其实这句话 “非功能性测试 就是测试在软件本身有的功能之上做的一些限制。”
还可以这么去理解这里的限制你可以理解为是一种 要求 / 指标。这么说吧“非功能性测试”就是为了提升用户的体验对软件的执行没有影响。
需要注意的是上面提到这些非功能性的测试易用性兼容性性能安全性可移植性可维护性不是所有的都要测试
不同的应用软件 对于 以上 非功能性的要求 是 不一样的比如1、面向客户端的软件【画图板officeWordxmind】
这种软件对 性能安全性要求不高。 但是对于 兼容性可移植性稳定性要求较高。 理由很简单因为是面向客户端的也就是 1v1 的服务。 面向一个客户的服务软件。 这么说吧在你的电脑上是访问不到我电脑的的画图板的。 不存在用户之间的交互1 v 1 服务。 既然是 1 v 1 服务软件只需要满足你一个人的需求即可因此对性能的要求肯定不高。 其次不存在客户端与服务器之间的交互也就不存在中间人攻击的说法。 因此对于 安全性 的要求也不高 另外这都是办公必备软件因此必须在不同类型的系统上都能安装运行。 因此对于 兼容性 的要求比较高。 还有就是我发送给你的 Wordoffice 之类的文件只要对方也安装了相应的文件也能打开使用。因此对于可移植性的要求也是比较高的。 既然这些软件都是公办必备软件肯定是会被频繁使用的。 因此对于软件的 稳定性 要求就比较高你这软件不能用着用着就崩了别人的数据怎么办 2、面向企业内部的软件 比如飞Q飞书字节跳动。。。。这种用于企业内部员工使用的交流软件。
因为这种类型的软件只是针对自己公司的内部人员使用。 公司可以统一电脑的操作系统因此对于 系统的兼容性要求不高 公司内部的人员其实不是很多。 别看着几千人其实对于计算机来说也就那样。 因此对于 性能的要求 也不是很高。 但是对于功能性可靠性的要求高。 因为是公司内部人员使用那么肯定是用来 互传文件互相沟通之类。 至少需要满足 员工 的一些日常操作。 因此对于功能性的要求高。 对于传文件肯定是要求不能发生 传输残缺/丢包 的情况 文件里都是代码缺胳膊少腿谁知道是哪里少了点什么 因此对于 可靠性的要求 是比较高的 3、大型的商用软件 比如微信QQ
别边看它们是免费使用的。。。你想想会员和各种钻还有超级版本的更贵的。 另外用户基数多说明流量多广告商就会投资让 QQ/微信 投放 他们的广告.这是要给腾讯钱的也就是说我们都在直接或间接的 为腾讯赚钱 奈何自己不花钱的是真的香广告商的钱又不是我们的钱。。。 这种大型商用软件对 非功能性 的 各个方面要求都很高。 你这么想用户多对软件的性能的要求就高。不然请求一多服务器根本处理不过来。 另外对于这种大型商用软件尤其用户基数特别大的软件。 它不可能说要求必须是某某系统才能安装吧这不是在 “作死”嘛 摆明就是想损失用户。 因此想这种大型商用软件 对于 兼容性的要求就很高。 巴不得什么设备都能装它们的软件这些都是钱啊 接着像QQ 和 微信 这种交流软件对于 可靠性的要求也很高。 总不能我给 A 发消息结果B收到了。 万一聊天内容特别劲爆发错人就很尴尬 另外聊着聊着就丢包数据无法进行传输也是不好的。 同时对 可移植性 和 安全性 的要求同样也很高。 可移植性 体现在 我们在换手机之后进行软件搬家的时候把软件从一个系统到另一个系统的难易程度。 对于安全性这是最好理解。 每个人的聊天信息都属于个人隐私没有人愿意说给一个外人看。 另外现在的 QQ号/微信 多数都是和游戏账号绑定的。 如果QQ号被盗那么这些绑定的“财产”也就没了。 具体的设计测试用例的方法
等价类
根据输入特殊情况下才考虑输出把输入划分成若干个等价类从每一个等价类当中选择测试用例进行测试。 如果这个测试用例测试通过了。
我们就说这个测试用例代表的等价类测试通过。 我来举个例子帮助你们来了解 等价类。等价类就是把同一个事物进行划分。比如这里有 3只狗哈士奇阿拉斯加萨摩耶它们都是犬类动物也就是狗吧此时我们就可以将它们划分到 狗这一类里面。那么问题就来了狗这一类难道只有这3种品种吗 答案肯定不是种类还有很多 虽然种类繁多但是狗的习性基本是一致的。 我们可以通过对 几只共性很强的狗 进行试验而得出的结果基本上是可以代表绝大部分的犬类 这也是 等价类 目的通过将相同类型的事物划分成一个类等价类。从中提出几个典型的案例进行测试其测试的结果就能代表 这个等价类中 的 绝大部分情况的测试结果。简单来说等价类能够帮助我们解决测试用例 无法进行穷举的情况 下面我们再来举个例子了解一下 等价类的应用场景。 边界值
不知道大家还记不记得在 冒泡排序选择排序中有两层for循环。
里面循环变量是从0开始自增但小于 length - 1的。 其实这里 array.length -1 就是边界值为了防止数组越界导致代码崩溃 而我们测试中的边界值是 输入 和 输出 的边界。 我们要针对 输入 和 输出 的 边界 进行 测试用例的设计。 tips (建议)等价类 和 边界值 结合在一起进行测试用例的设计。 因为 等价类 的 测试用例中就包含着 边界值 测试用例。 只不过在等价类中是分离开的有效等价类 和 无效等价类。 错误 猜测法
注意不是瞎猜 而是根据 测试人员的经验 和 知识 的 积累来猜测某一块功能有问题。 随后有针对性的进行测试用例的编写。 说白了就是程序员的经验之谈。 有的朋友可能就会有疑问你觉得我像是有经验的佬嘛。。。 其实我们是有经验的 因为我们一直在使用各种 APP打游戏听音乐看小说等等。。。。 我们具有使用经验也就是用户体验软件的经验。 我们很容易就能 get 到 用户的需求有哪些因为我们也是用户。 也就是说我们至少拥有用户的经验。而我们缺少的是站在测试的角度去看待需求的经验。 错误 猜测法有点类似于 探索性测试。 针对性比较强比较依赖测试人员个人的水平。 比如1、搜索查询框 - 空格 在某个 软件/网页 中搜索关键字的时候而且这个关键字在服务器的数据库中是有对应的数据的。 只要我们在关键字的左右两侧敲一个空格关键字 “空格 奥特曼 空格”就搜索不到。因为这两个空格导致原本可以搜索到的数据现在搜索不到了。 在Java中String类型有一个方法 trim()可以去除 字符串 前后的 空格。由这个问题引申出另外一个问题字符串中间的空格是否要去掉 答案不能 中间的空格一般是用户刻意敲的可能具有实际的意义。 而两侧的空格可能是用户误敲的没有实际的意义。 2、搜索查询出的信息500条每一页展示 100 条共展示5页。 但是发现不同的页面上有相同的数据数据ID也是一样的。一般查询到的结果是需要经过排序的。 排序的条件暂且忽略。反正就是根据某种唯一的参数进行排序。 比如数据ID 下面我们来分析一下 案例 - 水杯测试 - 培养的思维
这是一个在美团面试中被提到的面试题。 PS由于题目没有给出 到底是那种水杯牵扯的范围很广。 因此我们这个案例不是 全面覆盖性不强。 场景设计法
很多软件不同的场景 都是基于不同事件的触发。不同事件的触发会导致场景走向不同的 时间流 / 场景。
前面讲的 错误猜测法等价类 和 边界值都是针对某一个孤立的功能去进行设计。而场景设计法 就是把不同的功能点 给串起来了形成一个场景。需要注意的是不同的功能点有不同的输出不同的输出就会导致不同的测试场景。下面我们来通过一个例子来加深对场景设计法的理解。 场景分析法还可以认为是将一个功能集成模块 给 拆分成一个个单独功能模块进行设计测试用例。 因果图法
面试会问但是在实际工作中用的很少。 即便是在工作中用到了你可能都没有意识到自己使用了因果图法。
因果图法与其说是 一种指导思想 不如说是在我们经过大量测试之后具有了一定的测试经验总结出来的 测试方法。 和前面 错误猜测法 是类似的都是经验之谈。
首先因果图 是 一种逻辑图它具有 恒等与或非 逻辑。 用因果图来设计测试用例就叫做因果图法。
因果图法的使用场景 当我们有很多不同的输入的时候不同的输入/不同的输入组合 就会产生不同的输出。 这个时候我们可以用因果图法来进行测试用例的设计. 总的来说:就是因为它的输入和输出实在是太多了!这个时候如果不用 某种方法/某种工具 来进行分析的话那我们很可能会遗漏掉一些 测试用例 和 测试点因果图法就是起着这样的一个分析效果其作用就是降低 遗漏 测试点/测试用例 的 概率。 下面我们再来分析因果图中所包含的那些逻辑。 下面我们来看一下因果图法 设计测试用例 的 步骤 1、分析出所有的输入和输出 ‘2、找出输入和输出之间的组合关系 3、根据关系画出因果图 4、根据因果图画出判定表 5、根据判定表写出测试用例 ‘ 下面我们来通过一个例子来加深对这五个步骤的印象 正交排列 - 了解即可
顾名思义就是根据正交性来设计测试用例的。 它是从大量的实验测试数据中根据正交原则 取出最优的数据的组合。 然后根据最优数据组合 实验的结果 来分析整个测试的结果。 详细来说全称正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法它是根据正交性由试验因素的全部水平组合中挑选出部分有代表性的点进行试验通过对这部分试验结果的分析了解全面试验的情况找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验 因素Factor在一项试验(测试)中凡欲考察的变量称为因素变量 水平位级Level在试验测试范围内因素被考察的值称为水平变量的取值 正交排列的运用场景 因果法设计用例太多怎么办正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。 正交表的构成 行数(Runs)正交表中的行的个数即试验的次数,用N代表。 因素数(Factors)正交表中列的个数用C代表。 水平数(Levels)任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”用T代表。正交表的表示形式 L行数(水平数*因素数) LN(TC) 正交表的两条性质 每一列中各数字出现的次数都一样多。 任何两列中的各有序数对出现的次数都一样多。 正交法设计测试用例的步骤 1、有哪些因素变量 2、每个因素有哪几个水平变量的取值 3、选择一个合适的正交表 4、把变量的值映射到表中 5、把每一行的各因素水平的组合作为一个测试用例 6、加上你认为可疑且没有在表中出现的用例组合 案例: 继续以注册为例类似工具可以使用微软的PICT工具 1、因素姓名、邮箱、密码、确认密码、验证码 2、水平填写、不填写 3、表中的因素数5 表中至每个因素数的水平数2 行数取最少的一个即试验次数最少的一个 LN(TC)(2-1)*516(25) NCx(T-1)1 L6(25) N试验次数 T水平数 C因素数 选择正交表这里选择了L6_2_5。正交表不是随便选择的而是设计好的 4、生成测试用例 思路因素取值为填写时正交按取值个数5-3-2-15已全了321任意排列进行排列实验次数不够用取值为填写个数为2或3任意组合但要满足正交的二条性质。 5、增补测试用例 姓名、邮箱、密码、确认密码、验证码都不填写 3、测试用例的有效性 1、测试用例对应的功能已删除不可操作了。 这个测试用例没有用了没有意义了。 微信刚出来时与QQ可互发消息下一个版本后就不可以发消息。 2、执行一条测试用例未发现BUG实际该处有BUG 苹果7手机微信添加了mobile单车小程序扫码不能开锁只能使用mobile APP开锁测试用例未涉及到苹果7微信小程序扫码开锁测试遗漏 / 测试用例覆盖率不高 换句话来说就是测试用例的有效的范围没有包含到该情况。 4、执行一条测试用例发现了BUG 苹果7手机微信添加了mobile单车小程序用例已写到了苹果7微信添加mobile小程序扫码开锁问题被发现。测用用例的有效性的范围包含了这个点。 5、执行一条测试用例未发现BUG实际该处BUG已修改 苹果7手机微信添加了mobile单车小程序扫码开锁可以正常开锁。测用用例的有效性的范围包含了这个点并且实际效果达到了预期的效果。 4、测试用例的粒度和评价 - 了解
测试用例的粒度
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试 粒度指测试用例编写的详细程度. 测试用例可以写得很简单也可以写得很复杂。最简单的测试用例是测试的纲要仅仅指出要测试的内容如探索性测试中的测试设计仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。 而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样会指定输入的每项数据期待的结果及检验的方法 具体到界面元素的操作步骤指定测试的方法和工具等。
(1)测试用例写得过于复杂或详细会带来两个问题一个是效率问题另一个是维护成本问题。另外测试用例设计得过于详细留给测试执行人员的思考空间就比较少容易限制测试人员的思维。
(2)测试用例写得过于简单则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”只是把需要测试的功能模块记录下来而已它的作用仅仅是在测试过程中作为一个简单的测试计划提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求检验需求并把对软件系统的测试方法的思路记录下来以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容 产品的质量要求 项目对用例的要求 测试时间和资源是否充分 但是不管用例怎么简化都不应该省略. 测试用例的评价 测试用例设计出来了如何提高测试用例设计的质量就像软件产品需要通过各种手段来保证质量一样测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。 同行评审 用户检查 项目组评审 1测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审尤其是临时的同行评审应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”要强调测试用例设计者之间的思想碰撞通过讨论、协作来完成测试用例的设计原因很简单测试用例的目的是尽可能全面地覆盖需求而测试人员总会存在某方面的思维缺陷一个人的思维总是存在局限性。因此需要一起设计测试用例。 2除了同行评审还应该尽量引入用户参与到测试用例的设计中来让用户参与评审从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛关键在于如何定义测试如果测试是对产品的批判则顾客应该指最终用户或顾客代表在内部可以是市场人员或领域专家如果测试是被定义为对开发提供帮助和支持那么顾客显然就是程序员了。 (3) 由测试负责人组织协调开展会议用例编写人对用例进行讲解参会人员有异议的当场提出。 实战测试用例百度云盘的测试用例 - 自己可以参考这个写一个。
百度云盘功能需求分析 - 粗略版 注意在文件传输模块中对于下载测试项中的 不同文件格式我们并没有说清楚很模糊。 下面我们再来看一下对它的补充、 非功能性测试
