如图 是俩个接口,一个测试登陆失败,一个测试登陆成功~ 点击上方的新增/新增登陆态按钮 可以新增空白接口 或 接口库中设置的登陆态接口 滑动页 右上角显示这个用例的id 每个接口左侧都有俩个小按钮, 这样的好处是 可以快速一目了然的知道该接口 有过什么特殊设置: 5。同样可以使用公共header,但是位置有变化: 更多人性化设置 就不一一介绍了。当然还在不断的更新优化中。
3) 设计分析 通常,设计接口测试用例需要考虑以下几个方面: 1、是否满足前提条件 有些接口需要满足前置条件,才可成功获取数据。 ; 3、业务规则、功能需求 这里根据实际情况,结合接口参数说明,可能需要设计n条正向用例和逆向用例 5、参数是否必填 逆向用例: 针对每个必填参数,都设计1条参数值为空的逆向用例 4、参数之间是否存在关联 有些参数彼此之间存在相互制约的关系 逆向用例: 根据实际情况,可能需要设计0~n条用例 5、参数数据类型限制 逆向用例: 针对每个参数都设计1条参数值类型不符的逆向用例 6、参数数据类型自身的数据范围值限制 假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例 以上几个方面考虑全的话,基本可以做到如下几个方面的覆盖: 主流程测试用例:正常的主流程功能校验; 分支流测试用例:正常的分支流功能校验 异常流测试用例:异常容错校验 4) 编写描述 尽量逻辑化,这样方便后续的维护 5) 实践操作 接口样例 获取订单列表接口(多条件) 获取店铺指定期间的所有订单列表(多种条件组合),默认根据日期倒序排序
测试用例设计之正交法 by:授客 QQ:1033553122 什么是n阶拉丁方? 正交试验设计方法 与一般的试验设计类似 ,用正交试验设计方法设计测试用例时主要包括以下步骤: (1) 确定因素 这里的因素是指对软件运行结果有影响的软件 (2) 确定因素的取值范围或集合( 1=12, 即L12(35*21) (5) 测试结果分析 加上你认为可疑且没有在表中出现的组合。 增补测试用例 5:不填姓名、不填身份证号、不填手机号 测试用例可以看出:如果按每个因素两个水平数来考虑的话,需要8个测试用例,而通过正交实验法进行的测试用例只有5个,大大减少了测试用例数。 编写测试用例 ? ? dpf版下载地址: 测试用例设计之正交法.pdf
公共用例设计实践 by:授客 QQ:1033553122 背景介绍(大致如下): 图一:我的-个人资料-动态 图二:发现 ? ? ? ? 图三:动态转发 图四:动态评论 ? ? ? 用过新浪微博之类的应该懂的,没用过的话去用用就懂了~~ 问题: 从上图可看到,转发,评论,赞都有多个入口: 发现页面-列表、我的-个人资料-动态页面-列表、动态详情(正文)界面 转发,评论对话框都有多种情况,怎么设计用例 且动态详情页面的信息和列表页面的信息(转发数,评论数,赞数等是保持一致的) 到此:我们可以划分出两个公用模块:动态列表+动态详情 接下来,对公用模块进行用例设计分析 第二:分析操作流程 动态列表页 >返回动态列表>>评论按钮旁的评论数加1 情形2:评论按钮(评论数不为0的)>>动态详情页(显示转发标签页或评论标签页)>>评论标签页的评论数加1 仔细分析情形1,情形2,我们可以很好的划分出两个测试点 评论不转发 还有个特别 @ 功能 注:其中@功能比较特殊,单独出来 2.转发对话框 评论加转发 评论不转发 也有个特别 @ 功能 注:其中@功能比较特殊,单独出来 第四:用例设计
如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。 5. 采用因果图法设计测试用例的步骤 1)分析软件规格说明描述中, 哪些是原因(即输入条件或输入条件的等价类), 哪些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。 5)把判定表的每一列拿出来作为依据,设计测试用例。 4)用例设计 针对每一条规则(C,D列除外)设计一条用例 2.有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。 5)用例设计 pdf版下载: 测试用例设计之因果图方法.pdf 参考文章: 测试用例设计白皮书_张元礼
恰好,最近我正在帮助客户设计和实施测试策略。 我便有了想法重新写一篇文章,体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客,正好缺失这样的一篇文章。 测试策略设计 在进行测试策略设计之前,我们确立好基本思想:每个人为质量负责。不是 QA,也不止是 QA 和 开发,而是所有人。 测试策略不是一成不变的,而是不断演进的 在我们继续设计之前,我们还需要: 收集、分析现有的缺陷类型、修复时间等 寻找适合项目的测试类型、方式 确认方案所需要的度量体系 定义『测什么?』 于是,在与我的同事于晓南讨论之后,大致有了一个总体方案设计和实施的过程: 明确总体目标。即我们做这件事的价值是什么? 可测试性调研。评估自动化测试的可行性;定位 设计测试策略。 通用的应用级测试策略模板;设计环境管理、数据管理、用例管理方案; 对齐标准的测试环境。打通自动化测试环境; 进行测试数据管理。 持续优化。
对如果进行有效测试设计, 分为以下几点作说明: 测试设计概述 测试场景分析 测试对象分析 测试类型分析 交互分析与规程设计 自动化设计与环境分析 1. 测试设计概述 #1.1 定义: 测试设计技术是从特定的测试依据中得到测试用例用来实现特定测试覆盖的标准化方法. ? #1.2 测试设计能够解决的问题 ? 测试设计能够解决的问题 有效减少测试用例的数目 避免测试用例之间的冗余 满足测试覆盖率的要求 ...... #1.3 测试分析设计技术全景图 ? 对开发和测试工作的开展起到指导和约束的作用 从系统内部处理过程着手进行分析, 找出需要测试和观察的内容,筛除不需要测试和观察的内容,减少用例数量 #2.3 场景分析原则 - 5W1H1E ? 在5W1H1E原则基础上, 需要增加和客户交流与确认的环节, 客户需求是产品之源 场景分析是个功能方法, 它可以在需求分析、设计、编码各个阶段进行 场景分析与测试类型无关, 大部分测试类型都可以采用场景分析工程方法
接着上一篇继续分享 经过上面几篇的了解,现在的yaml文件肯定是不符合测试参数化,主要存在以下问题: 没有相对于的预期结果数据 只支持一种headers,肯定是不够的 没有设计相关值的提取和替换 因此我们需要改进下我们的测试数据的格式 validate: - equal_to: $.code: 0 - equal_to: $.code: 0 上面是我设计的测试数据结构 ,不是很完善,但是大部分该有的都有了吧,各种字段的介绍: -testCase 是一个测试用例的开头,是列表里面的一项 description 是测试用例的描述 name 测试接口的描述 method 测试用例的断言 根据上面的数据格式,我们暂时需要做以下事情 1.重新改写request封装的函数 2.需要设计提取值的规则和提取值的函数 3.需要设计如何使用提取的值的规则和编写提取值之后的数据处理的函数 testData:存放yaml文件测试数据 今天的分享就到这里,后续的文章会从以下的存在的问题进行分享 1.重新改写request封装的函数 2.需要设计提取值的规则和提取值的函数 3.需要设计如何使用提取的值的规则和编写提取值之后的数据处理的函数
5.设计测试用例 在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例: 1)为每一个等价类规定一个唯一的编号 用例设计 覆盖有效等价类的测试用例: a b c 覆盖等价类号码 3 4 5 (1)--(4) 4 4 5 (1)--(3),(5) 5 4 5 (1)--(3),(6) 5 4 4 (1)--(3),(7) 4 4 4 (1)--(3),(8) 覆盖无效等价类的测试用例: ? 现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。 .pdf 参考文章: 测试用例设计白皮书_张元礼
测试用例设计之边界值分析方法 1.定义 对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。 使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。 例如一程序属于情报检索系统,要求每次"最少显示1条、最多显示4条情报摘要",这时我们应考虑的测试用例包括1和4,还应包括0和5等。 5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。 6)分析规格说明,找出其它可能的边界条件。 pdf版下载: 测试用例设计之边界值分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼
输入编号,点击“优惠券”,“会员卡”图标,可对输入的卡券(会员主卡,代金券,折扣券)编号验证,另外,如果输入是手机号,则对手机号关联会员的会员主卡进行验证 如果不考虑逆向用例,考虑正向用例,你会咋样设计用例 用例数比较多,进而花费的测试时间也跟着变长,如果再加上一些条件(本例子中还有个条件:是否携带“不可优惠金额”,验证结果会受到其影响),那就更多了,咋办呢? 综上,我们在测试用例不能仅停留在用例设计原理上,很多时候还应该从实现角度来进行设计分析,减少不必要的时间投入,特别是逻辑复杂的情况,通常我们可以做如下事情: 1、分析调用的接口请求 查看不同(相似) 1和条件2之间的关系是不一样的,对应的,用例设计也就不一样了。 3、查看调用的实现相关的sql语句 有时候,我们也可以通过日志获取开发代码调用的sql语句,作为用例设计中结果校验的手段。通过sql语句来分析界面数据是怎么展示出来的,数据取值是否正确。
5.例子,“阅读指南”判定表 ? 6.规则及规则合并举例 如下图左端,两规则动作项一样,条件项类似,在条件1、2分别取Y、N时,无论条件3取何值,都执行同一操作,即要执行的动作与条件3无关。 5)简化判定表。 pdf版下载 测试用例设计之判定表驱动分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼
借鉴软件设计的思想,引进“按场景设计用例”的思想 ? 基本流用黑色表示,是经过用例的最简单的路径。 分院负责人仅可见其管理院系的学生提交的申请表 3.学工处和资领小组审批可见所有审批拒绝通过的申请表 4.职位较低的审批人拒绝通过,不影响较高职位的人(学工处及资助领导处)对申请进行审批、删除(如果审批人有权限的话 5. 用例设计 通常情况下,可以把每个场景当作一条用例。这里需要注意的是,这里的事件流侧重事件触发逻辑顺序,设计用例时,还要注意测试数据(按我的观点,测试逻辑和测试数据一般是要分开的)。 适用范围: 通常,按场景设计用例,比较适合流程性比较强的测试,比如业务测试。 当然,这种思想,也可以应用用在局部功能的测试上,具体参见文章“测试用例设计实践总结”描述中,其核心思想和这个场景测试是差不多的。 pdf版下载: 授客细说场景测试用例设计与实践.pdf
,对系统业务功能影响不大的模块或功能的测试用例 p2、P3:重要程度介于P0和P4之间 其他要素: 用例的设计者,用例设计日期,对应的开发人员,测试结果(pass,fail,block),测试类型( 功能,性能,压力等) 4、测试用例的设计原则 (1)明确性:测试人员要尽量避免测试用例存在含糊的因素,在测试过程中,测试用例的测试结果是唯一的 (2)代表性:尽量将具有相似功能的测试用例抽象合并,功能相似的用例要合并 5、设计方法:等价类划分法 案例:QQ登录 1、明确需求:6~10位自然数,不能以0开头 2、划分等价类: 参数 说明 有效等价类 有效数据 无效等价类 无效数据 qq号 长度 6~8位 1234567 约束条件: 8、设计方法:判定表法 判定表示例: 9、设计方法:正交表法 案例: 使用正交设计助手工具: 选择正交表,填写水平因素: 生成的正交表: 每一项实验就是一条测试用例 10、设计方法:场景法 11、设计方法:错误推断法 12、总结 版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。
by:授客 QQ:1033553122 大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率。再细想想,这种核心作用的本质也就是一种“提醒”作用。 话说,写用例、设计用例是需要时间的,而在追求速度的时代,似乎连这点时间都给不起。 按我的经历来看,这种类型用例,在测试的时候,用例编写人自己都懒得看用例,完全是按自己的当前时间的想法来测试,而非用例编写人呢? 5. 针对一些步骤比较复杂的用例,步骤和预期结果都要写出来。 复杂情况下,一个用例包含多个操作步骤,这些操作步骤中,每个步骤可能都对应一个子测试点(预期结果)。 所谓的通用用例,本质上看,也就是设计方法的体现,与其去“记忆”这些会变化的“通用”,还不如多想想你的用例设计里面,哪里体现了、到了这些设计方法。
用例设计: ? 说明: ? 注意: 1、模块的层级不能太多,有必要的话可通过“2级模块1-3级模块1”的形式,减少模块的层级 2、模块下,分“字段校验”和“功能校验”,划分依据呢? 3、这样划分的好处是,比较能突出重点,特别是时间来不及的情况下,可能只执行“功能校验”的用例,当然也视情况而定,有些字段校验也很重要,属于重点测试内容。 4、有啥好想法,欢迎交流,别只做伸手党~~
测试设计 ---- 1. 什么是测试设计 测试设计的过程是根据测试对象信息,不断建立模型的过程。 测试设计流程 设计流程 由测试对象的必要效能输出最高优先级测试点, 即冒烟测试用例 根据测试对象的实现逻辑进行设计, 如逻辑上需要判断/遍历/数据类型转换/序列化/循环等使用对应的测试设计方法输出测试用例 /可行性/方法效率 设计方法 根据边界值设计 根据容量设计 根据正反状态设计 根据等价类设计 根据输入多样性设计 测试合并方法 UI/功能/性能容量合并 正反合并 包含合并 过程合并 重难效测试点合并 测试分析设计总结 ---- 1. /可达到测试目的 通过测试设计可降低不同人员执行时的差异
黑盒测试用例设计方法包括: 1、等价类划分法、 2、边界值分析法、 3、错误推测法、 4、因果图法、 5、判定表驱动法、 6、正交试验设计法、 7、功能图法、 8、场景法等。 4 5 (1)—(7),(8) 4 5 5 (1)—(7),(9) 5 4 5 表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。 Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。 这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。
第1章 测试用例设计方法 测试用例设计方法包括黑盒测试用例设计方法和白盒测试用例设计方法,下面 分别进行介绍。 1.1 黑盒测试用例设计方法 黑盒测试用例设计方法包括等价类划分法、边界值分析法、判定表法、因果图法、正交试验法、状态迁移图法、流程分析法、输入域测试法、输出域分析法、异常分析法和错误猜测法等,下面进行详细介绍 例如,在1<x<5中,一个有效等价类为1<x<5,两个无效等价类为x≥5和x≤1。 ② 在输入条件规定了输入值的集合或者规定了必须如何操作的情况下,可以确立一个有效等价类和一个无效等价类。 这里n=5,可以确定5个有效等价类和一个无效等价类。5个有效等价类就是楷体、黑体、宋体、隶书和微软雅黑;一个无效等价类就是不属于这5类中的其他字体。 现用等价类划分法设计测试用例,用来测试程序的“日期检查功能”。
这个值不应该超过5。 ØPage Faults。 处理器页面错误计数。这个值大说明操作系统向内存读取错误数据过多。 •Physical disk。 Ø%Disk Time。 表3-3 磁盘的I/O数的计算方法 RAID类型计算方法RAID0(Reads+Writes)/Number of DisksRAID1(Reads+2×Writes)/2RAID5(Reads+4× 如果这个值持续增长或者性能测试终止后这个值仍旧不降,说明发生了内存泄露。 5.网络 •Network interface。 Ø Bytestotal/sec。