首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏测试开发干货

    接口测试平台设计思路-3:成品总览

    我们今天来看异常健壮性测试。 其实就是简单的统计出url和body的所有参数。然后用预置的各种类型数据进行排列组合般的替换。来自动每次进行请求。 虽然说前端一般会控制好接口的传入字段,但是接口测试的主要思想就是要绕过前端测试接口本身。 首先来看我们接口的正常调试参数: 它url中有俩个参数,body里有1个参数 返回值是一段text文本: 然后我们点击保存后,点击这个接口的健壮测试按钮 页面就变成了这样 所以最终会有大概3个参数*13门徒 = 39次请求。 那么点击执行按钮吧。

    39920编辑于 2022-05-18
  • 来自专栏授客的专栏

    测试思想-测试设计 接口测试用例设计实践总结

    设计思路 1) 优先级--针对所有接口 1、暴露在外面的接口,因为通常该接口会给第三方调用; 2、供系统内部调用的核心功能接口; 3、供系统内部调用非核心功能接口; 2) 优先级--针对单个接口 3) 设计分析 通常,设计接口测试用例需要考虑以下几个方面: 1、是否满足前提条件 有些接口需要满足前置条件,才可成功获取数据。 ; 3、业务规则、功能需求 这里根据实际情况,结合接口参数说明,可能需要设计n条正向用例和逆向用例 5、参数是否必填 逆向用例: 针对每个必填参数,都设计1条参数值为空的逆向用例 4、参数之间是否存在关联 假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例 以上几个方面考虑全的话,基本可以做到如下几个方面的覆盖: 主流程测试用例:正常的主流程功能校验; 分支流测试用例:正常的分支流功能校验 问题 如果是自动化测试呢,这里是设计一个方法覆盖多条用例呢(如上,一条数据,覆盖多条用例)?还是一个方法覆盖一条用例呢? 我个人的答案是一个方法一条用例,你的呢?

    1.5K20发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 测试用例设计之正交法

    测试用例设计之正交法 by:授客 QQ:1033553122 什么是n阶拉丁方? 正交试验设计方法 与一般的试验设计类似 ,用正交试验设计方法设计测试用例时主要包括以下步骤: (1) 确定因素 这里的因素是指对软件运行结果有影响的软件 (2) 确定因素的取值范围或集合( 正交表的构成: l 行数(Runs):正交表中的行的个数,即试验的次数,也是通过正交实验法设计测试用例的个数 l 因素数(Factors) :正交表中列的个数,即要测试的功能点。 选择正交表 表中的因素数>=3; 表中至少有3个因素数的水平数>=2 行数取最少的一个,即试验次数最少的一个 说明:并不是我们想要什么正交表就有什么正交表,有的正交表是没有被设计出来的,我们选取正交表时只能从现有的正交表中进行选择 编写测试用例 ? ? dpf版下载地址: 测试用例设计之正交法.pdf

    2K30发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 公共用例设计实践

    公共用例设计实践 by:授客 QQ:1033553122 背景介绍(大致如下): 图一:我的-个人资料-动态 图二:发现 ? ? ? ? 图三:动态转发 图四:动态评论 ? ? ? 用过新浪微博之类的应该懂的,没用过的话去用用就懂了~~ 问题: 从上图可看到,转发,评论,赞都有多个入口: 发现页面-列表、我的-个人资料-动态页面-列表、动态详情(正文)界面 转发,评论对话框都有多种情况,怎么设计用例 且动态详情页面的信息和列表页面的信息(转发数,评论数,赞数等是保持一致的) 到此:我们可以划分出两个公用模块:动态列表+动态详情 接下来,对公用模块进行用例设计分析 第二:分析操作流程 动态列表页 >返回动态列表>>评论按钮旁的评论数加1 情形2:评论按钮(评论数不为0的)>>动态详情页(显示转发标签页或评论标签页)>>评论标签页的评论数加1 仔细分析情形1,情形2,我们可以很好的划分出两个测试点 评论不转发 还有个特别 @ 功能 注:其中@功能比较特殊,单独出来 2.转发对话框 评论加转发 评论不转发 也有个特别 @ 功能 注:其中@功能比较特殊,单独出来 第四:用例设计

    59130发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 测试用例设计之因果图方法

    如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。 5)把判定表的每一列拿出来作为依据,设计测试用例。 4)用例设计 针对每一条规则(C,D列除外)设计一条用例 2.有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。 说明:因果图需要对需求和逻辑理解很透彻,不同的理解画出的因果图不同,自然设计难易程度也就不一样,个人建议少用因果图,多用场景法,因为相比之下,场景法设计用例实施起来会比较容易 3)转换为判定表 ? 5)用例设计 pdf版下载: 测试用例设计之因果图方法.pdf 参考文章: 测试用例设计白皮书_张元礼

    1.2K20发布于 2019-09-11
  • 来自专栏phodal

    设计测试策略

    恰好,最近我正在帮助客户设计和实施测试策略。 我便有了想法重新写一篇文章,体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客,正好缺失这样的一篇文章。 测试策略设计 在进行测试策略设计之前,我们确立好基本思想:每个人为质量负责。不是 QA,也不止是 QA 和 开发,而是所有人。 测试策略不是一成不变的,而是不断演进的 在我们继续设计之前,我们还需要: 收集、分析现有的缺陷类型、修复时间等 寻找适合项目的测试类型、方式 确认方案所需要的度量体系 定义『测什么?』 于是,在与我的同事于晓南讨论之后,大致有了一个总体方案设计和实施的过程: 明确总体目标。即我们做这件事的价值是什么? 可测试性调研。评估自动化测试的可行性;定位 设计测试策略。 通用的应用级测试策略模板;设计环境管理、数据管理、用例管理方案; 对齐标准的测试环境。打通自动化测试环境; 进行测试数据管理。 持续优化。

    78420发布于 2020-07-15
  • 来自专栏APP自动化测试

    有效测试设计

    对如果进行有效测试设计, 分为以下几点作说明: 测试设计概述 测试场景分析 测试对象分析 测试类型分析 交互分析与规程设计 自动化设计与环境分析 1. 测试设计概述 #1.1 定义: 测试设计技术是从特定的测试依据中得到测试用例用来实现特定测试覆盖的标准化方法. ? #1.2 测试设计能够解决的问题 ? - 正交法 正交表示一整套规则的设计表格, 其构成包括三个要素: 1 )行数:正交表行的个数 2 )因素数:正交表列的个数 3 )水平数:任何单个因数能够取得的值的最大个数 正交满足的特征: 1 )每列中不同数字出现的次数相等 #3 测试对象分析 测试对象分析 - 测试建模 ? 步骤1: 确定被测对象的范围 目的 确定被测系统的边界 只有确定了边界, 才能知道模型中应该画哪些 ? 步骤3: 建立模型 目的 把每个模型的需求点合理的组织为模型 ? 主要功能模型 ? ? ? ? 数组组合模型覆盖 ?

    87530发布于 2019-10-15
  • 来自专栏授客的专栏

    测试思想-测试设计 测试用例设计之等价类划分方法

    ; 2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止; 3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步 用例设计 覆盖有效等价类的测试用例: a b c 覆盖等价类号码 3 4 5 (1)--(4) 4 4 5 (1)--(3),(5) 5 现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。 ,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计测试用例如下(用尽可能少的用例尽可能多的覆盖每个有效效等价类): 测试数据 期望结果 覆盖的有效等价类 200211 输入有效 ①、⑤、⑧ 3)为每一个无效等价类设计一个测试用例,设计结果如下: 测试数据 期望结果 覆盖的无效等价类 95June 无效输入 ② 20036

    1.7K40发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 测试用例设计之边界值分析方法

    测试用例设计之边界值分析方法 1.定义 对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。 3.边界值分析方法的考虑: 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。 使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。 比如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。 3)将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。 pdf版下载: 测试用例设计之边界值分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼

    97540发布于 2019-09-11
  • 来自专栏Golang语言社区

    LollipopGolibrarylollipopcommon 测试3

    可以快速创建博客及商城等 git地址:https://github.com/Golangltd/lollipopgo /* Golang语言社区(www.Golang.Ltd) 作者:cserli 时间:2018年3

    1.2K90发布于 2018-03-05
  • 来自专栏自学测试之道

    接口测试3

    上篇讲解到了一次性运行多个测试用例和运行结果的情况,这边继续说下测试报告的内容输出和可视化显示以及邮件抄送等 一、增加测试报告输出 1、首先在代码目录下新建一个文件夹test_report用来保存测试结果 2、导入测试报告库文件HTMLTestRunner_PY3(这个文件在网上可以下载后[https://blog.csdn.net/cjh365047871/article/details/80181530 3、定义测试用例和测试报告存放路径、读取测试用例方法和测试报告格式 #! q=keitwo&page=1&type=note # @QQ交流 : 3227456102 import unittest,time import HTMLTestRunner_PY3 if _ 3、导入发送邮件模块 ? 4、运行结果 ?

    52120发布于 2019-09-29
  • 来自专栏授客的专栏

    测试思想-测试设计 关于测试用例设计的一点感想

    输入编号,点击“优惠券”,“会员卡”图标,可对输入的卡券(会员主卡,代金券,折扣券)编号验证,另外,如果输入是手机号,则对手机号关联会员的会员主卡进行验证 如果不考虑逆向用例,考虑正向用例,你会咋样设计用例 用例数比较多,进而花费的测试时间也跟着变长,如果再加上一些条件(本例子中还有个条件:是否携带“不可优惠金额”,验证结果会受到其影响),那就更多了,咋办呢? 综上,我们在测试用例不能仅停留在用例设计原理上,很多时候还应该从实现角度来进行设计分析,减少不必要的时间投入,特别是逻辑复杂的情况,通常我们可以做如下事情: 1、分析调用的接口请求 查看不同(相似) 1和条件2之间的关系是不一样的,对应的,用例设计也就不一样了。 3、查看调用的实现相关的sql语句 有时候,我们也可以通过日志获取开发代码调用的sql语句,作为用例设计中结果校验的手段。通过sql语句来分析界面数据是怎么展示出来的,数据取值是否正确。

    74210发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 测试用例设计之判定表驱动分析方法

    3.判定表形式 ? 1)条件桩:列出所有逻辑条件。通常给出的逻辑条件之间与排列次序无关。 2)动作桩:列出与条件桩对应的可能操作。同上,操作之间与排列次序无关。 3)条件项:列出条件桩的所有取值,每个条件项可能是多个逻辑条件取值的组合。 4)动作项:列出动作桩的所有取值,即与条件项对应的可能操作。 6.规则及规则合并举例 如下图左端,两规则动作项一样,条件项类似,在条件1、2分别取Y、N时,无论条件3取何值,都执行同一操作,即要执行的动作与条件3无关。所以,可合并,“-”表示与取值无关。 3)填入条件项。 4)填入动作项。等到初始判定表。 5)简化判定表。 pdf版下载 测试用例设计之判定表驱动分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼

    1.1K20发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 授客细说场景测试用例设计与实践

    设计实践 1.绘制事件流景 2.描述事件流 3.用例设计 例子:以学校学生申请助学金为例子 业务过程: 学生申请助学金 -> 班主任审批 -> 分院负责人审批 -> 学工处审批 ->资助领导小组审批 附加说明: 审批时可选择助学金等级:1等,2等,3等 1.班主任仅可见其管理班级的学生提交的申请表 2.分院负责人仅可见其管理院系的学生提交的申请表 3.学工处和资领小组审批可见所有审批拒绝通过的申请表 用例设计 通常情况下,可以把每个场景当作一条用例。这里需要注意的是,这里的事件流侧重事件触发逻辑顺序,设计用例时,还要注意测试数据(按我的观点,测试逻辑和测试数据一般是要分开的)。 适用范围: 通常,按场景设计用例,比较适合流程性比较强的测试,比如业务测试。 当然,这种思想,也可以应用用在局部功能的测试上,具体参见文章“测试用例设计实践总结”描述中,其核心思想和这个场景测试是差不多的。 pdf版下载: 授客细说场景测试用例设计与实践.pdf

    81430发布于 2019-09-11
  • 来自专栏全栈程序员必看

    软件测试的用例设计方法_测试用例设计

    :从测试管理的角度,测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准 可管理性:从测试管理的角度,测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准 3测试用例的八大要素 用例编号 ,对系统业务功能影响不大的模块或功能的测试用例 p2、P3:重要程度介于P0和P4之间 其他要素: 用例的设计者,用例设计日期,对应的开发人员,测试结果(pass,fail,block),测试类型( 功能,性能,压力等) 4、测试用例的设计原则 (1)明确性:测试人员要尽量避免测试用例存在含糊的因素,在测试过程中,测试用例的测试结果是唯一的 (2)代表性:尽量将具有相似功能的测试用例抽象合并,功能相似的用例要合并 (3)简洁性:测试用例简洁,可读性良好,测试过程目的明确,测试结果唯一。 约束条件: 8、设计方法:判定表法 判定表示例: 9、设计方法:正交表法 案例: 使用正交设计助手工具: 选择正交表,填写水平因素: 生成的正交表: 每一项实验就是一条测试用例

    1.4K20编辑于 2022-11-04
  • 来自专栏授客的专栏

    测试思想-测试设计 精简测试用例编写

    by:授客 QQ:1033553122 大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率。再细想想,这种核心作用的本质也就是一种“提醒”作用。 话说,写用例、设计用例是需要时间的,而在追求速度的时代,似乎连这点时间都给不起。 仅看用例名,不能预知操作步骤的,还须把操作步骤写出来 3. 仅看用例名,不能预知预期结果的,还须把预期结果写出来 4. 所谓的通用用例,本质上看,也就是设计方法的体现,与其去“记忆”这些会变化的“通用”,还不如多想想你的用例设计里面,哪里体现了、到了这些设计方法。 3、用例不仅编写者自己看,别人也要看的,所以不管咋写,一定要让人看得懂。

    87020发布于 2019-09-11
  • 来自专栏授客的专栏

    测试思想-测试设计 测试用例设计最新实践总结-来自不断的追求

    用例设计: ? 说明: ? 注意: 1、模块的层级不能太多,有必要的话可通过“2级模块1-3级模块1”的形式,减少模块的层级 2、模块下,分“字段校验”和“功能校验”,划分依据呢? 3、这样划分的好处是,比较能突出重点,特别是时间来不及的情况下,可能只执行“功能校验”的用例,当然也视情况而定,有些字段校验也很重要,属于重点测试内容。 4、有啥好想法,欢迎交流,别只做伸手党~~

    48030发布于 2019-09-11
  • 来自专栏测试理论

    测试分析设计总结

    /测试类型/测试手段 功能点/测试点之间的依赖关系, 合理的测试用例框架 3. 测试设计 ---- 1. 什么是测试设计 测试设计的过程是根据测试对象信息,不断建立模型的过程。 测试设计流程 设计流程 由测试对象的必要效能输出最高优先级测试点, 即冒烟测试用例 根据测试对象的实现逻辑进行设计, 如逻辑上需要判断/遍历/数据类型转换/序列化/循环等使用对应的测试设计方法输出测试用例 /可行性/方法效率 设计方法 根据边界值设计 根据容量设计 根据正反状态设计 根据等价类设计 根据输入多样性设计 测试合并方法 UI/功能/性能容量合并 正反合并 包含合并 过程合并 重难效测试点合并 测试分析设计总结 ---- 1.

    1.7K51发布于 2021-01-05
  • 来自专栏全栈程序员必看

    测试】黑盒测试用例设计方法

    黑盒测试用例设计方法包括: 1、等价类划分法、 2、边界值分析法、 3、错误推测法、 4、因果图法、 5、判定表驱动法、 6、正交试验设计法、 7、功能图法、 8、场景法等。 ,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计测试用例如下: 测试数据 期望结果 覆盖的有效等价类 200211 输入有效 ①、⑤、⑧ 3)为每一个无效等价类设计一个测试用例 表3-8 场景设计 场景1——成功提款 基本流 场景2——ATM内没有现金 基本流 备选流2 场景3——ATM内现金不足 基本流 备选流3 场景4——PIN有误(还有输入机会) 基本流 备选流4 场景 3、用例设计(输入部分):   (1)完成预定->已支付->已取消;   (2)完成预定->已支付->已出票->已取消;   (3)完成预定->已支付->已出票->已使用; 总结   状态迁移法实际测试了被测系统各种状态的转换 3、用例设计(确定测试路径):   需求描述及流程图中,ATM取款机的提示信息对应于测试用例中的预期输出部分,用户的操作对应测试用例中的测试步骤部分。原则是一条有效路径使用一个测试用例覆盖。   

    2.6K10编辑于 2022-08-10
  • 来自专栏VRPinea

    Meta Quest 3设计图曝光,正测试PCVR云端串流功能

    VRPinea 9月30日讯)9月29日,油管博主SadlyItsBradley (Brad Lynch)发布了一段18分钟的视频,展示了Meta将于2023年中后期发布的一款面向C端的XR设备的CAD设计图 早在2021年接受The Information采访时,扎克伯格就曾证实Quest3正在开发中,且Quest4正处于早期开发阶段。 以下是Lynch透露的Quest 3的信息,当然这些消息可能是过时的、错误的、不太精准的。Lynch自己也承认,Quest 3在大规模生产前会在有些细节上发生变动。 测试结束后,将开放给美国和欧盟的内部员工,测试结果将决定后续云VR服务的发展路线。这一阶段Meta的目标是反过来帮助第一方内容开发者试验“云支持的和云优先的内容”,以创造XR体验。 其将基于“移动边缘计算技术”和亚马逊AWS,在5G网络上测试云链接计算。

    1.1K10编辑于 2022-11-17
领券