- 综合排序
- 最热优先
- 最新优先
- 来自专栏测试开发干货
接口测试平台设计思路-7:成品总览
众所周知，接口文档各个公司都不同，而且各个模块/组/开发同学 的写法也不同。所以我们的解析算法不可能准确达到100% 或者说 不用维护了。那么就一定是一个可持续优化的过程。在这个过程中，难免出现解析失败的情况，所以我们要在交互层加入一层，来让用户自己确认解析的结果并做检查和修改。然后让用户自己去点击导入按钮，这样在后续出现问题背锅的时候，我们可以用这层来甩。^_^
27210编辑于 2022-05-18 - 来自专栏授客的专栏
测试思想-测试设计 接口测试用例设计实践总结
3) 设计分析 通常，设计接口测试用例需要考虑以下几个方面： 1、是否满足前提条件 有些接口需要满足前置条件，才可成功获取数据。 逆向用例： 针对是否满足前置条件(假设为n个条件)，设计0~n条用例 2、是否携带默认值参数 正向用例： 带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例 正向用例： 针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例 逆向用例： 针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例 针对每个参数( 假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例 以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖： 主流程测试用例：正常的主流程功能校验； 分支流测试用例：正常的分支流功能校验 问题 如果是自动化测试呢，这里是设计一个方法覆盖多条用例呢(如上，一条数据，覆盖多条用例)？还是一个方法覆盖一条用例呢？ 我个人的答案是一个方法一条用例，你的呢？
1.5K20发布于 2019-09-11 - 来自专栏授客的专栏
测试思想-测试设计 测试用例设计之正交法
测试用例设计之正交法 by:授客 QQ：1033553122 什么是n阶拉丁方？ 正交试验设计方法 与一般的试验设计类似 ，用正交试验设计方法设计测试用例时主要包括以下步骤： (1) 确定因素 这里的因素是指对软件运行结果有影响的软件 (2) 确定因素的取值范围或集合( 正交表的构成： l 行数(Runs)：正交表中的行的个数，即试验的次数，也是通过正交实验法设计的测试用例的个数 l 因素数(Factors) ：正交表中列的个数，即要测试的功能点。 增补测试用例 5：不填姓名、不填身份证号、不填手机号 测试用例可以看出：如果按每个因素两个水平数来考虑的话，需要8个测试用例，而通过正交实验法进行的测试用例只有5个，大大减少了测试用例数。 编写测试用例 ? ? 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角钱的饮料的自动售货机软件测试用例的设计。 C7：中间结果，找钱成功？ 结果： e1：送出橙汁 e2：送出啤酒 e3：高亮【零钱找完】的红灯 e4：退出1元硬币 e5: 熄灭【零钱找完】的红灯 e6：退出5角硬币 2）画出因果图 ? ? 5）用例设计 pdf版下载： 测试用例设计之因果图方法.pdf 参考文章: 测试用例设计白皮书_张元礼
1.2K20发布于 2019-09-11 - 来自专栏phodal
设计测试策略
恰好，最近我正在帮助客户设计和实施测试策略。 我便有了想法重新写一篇文章，体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客，正好缺失这样的一篇文章。 测试策略设计 在进行测试策略设计之前，我们确立好基本思想：每个人为质量负责。不是 QA，也不止是 QA 和 开发，而是所有人。 测试策略不是一成不变的，而是不断演进的 在我们继续设计之前，我们还需要： 收集、分析现有的缺陷类型、修复时间等 寻找适合项目的测试类型、方式 确认方案所需要的度量体系 定义『测什么？』 于是，在与我的同事于晓南讨论之后，大致有了一个总体方案设计和实施的过程： 明确总体目标。即我们做这件事的价值是什么？ 可测试性调研。评估自动化测试的可行性；定位 设计测试策略。 通用的应用级测试策略模板；设计环境管理、数据管理、用例管理方案； 对齐标准的测试环境。打通自动化测试环境； 进行测试数据管理。 持续优化。
78420发布于 2020-07-15 - 来自专栏APP自动化测试
有效测试设计
对如果进行有效测试设计, 分为以下几点作说明: 测试设计概述 测试场景分析 测试对象分析 测试类型分析 交互分析与规程设计 自动化设计与环境分析 1. 测试设计概述 #1.1 定义: 测试设计技术是从特定的测试依据中得到测试用例用来实现特定测试覆盖的标准化方法. ? #1.2 测试设计能够解决的问题 ? 测试设计能够解决的问题 有效减少测试用例的数目 避免测试用例之间的冗余 满足测试覆盖率的要求 ...... #1.3 测试分析设计技术全景图 ? 因为, 软件不仅要能接收合理的数据, 也要能经受以外的考验, 这样的测试才能确保软件具有更高的可靠性 测试设计技术 - 边界值 边界值分析方法就是对输入或输出的边界值进行测试的一种黑盒测试方法 经验告诉我们 #2.2 场景分析的目的 将被测试特性细分为功能独立的场景， 再针对各个场景进行设计， 从而从整体上降低测试设计的复杂度 场景分析的目的实际上是要搞清楚业务或功能的运行上下文是什么， 完成什么样的功能，
87530发布于 2019-10-15 - 来自专栏悠扬前奏的博客
Kafka-7.设计
4.1 动机 Kafka设计的目的是为能作为一个统一的平台来处理大公司可能有的实时数据流。为此，需要考虑相当广泛的用例。 它必须有高吞吐量来支持高容量事件流，例如实时日志聚合。 支持这些用途，使我们的设计具有一些独特的元素，更类似于一个数据库日志而不是传统消息传递系统。我们将在以下部分描述一些设计的元素。 并且设计合理的磁盘结构能够和网络一样快。 关于磁盘性能的关键事实是硬盘的吞吐量和过去十年中磁盘的搜索延迟不同。 这表明了一个非常简单的设计：当我们用尽空间时，与其尽可能在内存中维护，然后将其全部flush到文件系统中，不如反过来，所有数据立即写入文件系统上的持久化日志中，而不必flush到磁盘。 这种以页缓存为中心的设计风格在一篇关于Varnish设计的文章中有所描述。
65820发布于 2019-06-11 - 来自专栏授客的专栏
测试思想-测试设计 测试用例设计之等价类划分方法
5.设计测试用例 在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例： 1)为每一个等价类规定一个唯一的编号 ； 2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止； 3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步 4 5 （1）--（3），（6） 5 4 4 （1）--（3），（7） 4 4 4 （1）--（3），（8） 覆盖无效等价类的测试用例： ? 现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。 .pdf 参考文章: 测试用例设计白皮书_张元礼
1.7K40发布于 2019-09-11 - 来自专栏授客的专栏
测试思想-测试设计 测试用例设计之边界值分析方法
测试用例设计之边界值分析方法 1.定义 对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 3.边界值分析方法的考虑： 长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。 使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。 null) 0 A 65 空格 (space) 32 a 97 斜杠 ( / ) 47 Z 90 0 48 z 122 冒号 ( : ) 58 单引号 ( ‘ ) 96 @ 64 c)其它边界值检验 7. pdf版下载： 测试用例设计之边界值分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼
97540发布于 2019-09-11 - 来自专栏简尚
关于「测试时间测试周期」7 点参考
，测试1天； 4）项目周期三个月，开发一个月，测试1天 ； 5）开发一周，测试周期1小时； 6）开发3天，测试周期0小时（未测试，直接上线）； 7）当天突然知道一个需求，当天就需要你测试，当天上线 3、常规来看，3天的测试预留时间，或者1周的预留时间，一定会被开发压缩的（即：在你的测试周期里，还会存在一些开发并行工作），先做冒烟测试，开发阶段就多关注代码实现逻辑、接口情况、测试数据准备、环境准备， 测试报告，附上你的测试点、以及可能性的风险、结论，避免背锅； 测试报告模板、怎么写，见文章 从业多年，依然写不好一份测试报告 ！ ）； 6、当时间确实不够，系统会线上问题的容忍度又非常低的情况下，测试报告明确注明风险+结论（不同意上线），且邮件发出来；最终，还是要一意孤行，锅，团队一起背 ； 7、确实很多非核心系统、内部系统、纯底层代码逻辑的底层框架 ，完全不需要测试，直接跳过测试、上线也是可以的（如果能做到 单元测试、代码检查、线上监控）； 参考文章：软件测试从业者终极目标，线上零BUG如何实现 ？
4.5K30发布于 2020-05-14 - 来自专栏啄木鸟软件测试
软件性能测试（连载7）
图3-18 CPU状态转换图 7）软中断与硬中断 假设现在一家公司就有一名客服人员，这个客服人员就有一台座机，这种情况下用户碰到问题只能打电话给这个客服人员，如果有多个用户同时打入只能凭运气，先打通电话的人得到回答 /softirqs CPU0 CPU1 HI: 0 0 TIMER: 811613 1972736 NET_TX: 49 7 #ps aux | grep softirq root 7 0.0 0.0 0 0 ? PIDUSER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7 root 20 0 0
1.3K30发布于 2020-02-19 - 来自专栏授客的专栏
测试思想-测试设计 关于测试用例设计的一点感想
输入编号，点击“优惠券”，“会员卡”图标，可对输入的卡券(会员主卡，代金券，折扣券)编号验证，另外，如果输入是手机号，则对手机号关联会员的会员主卡进行验证 如果不考虑逆向用例，考虑正向用例，你会咋样设计用例 用例数比较多，进而花费的测试时间也跟着变长，如果再加上一些条件(本例子中还有个条件：是否携带“不可优惠金额”，验证结果会受到其影响)，那就更多了，咋办呢？ 综上，我们在测试用例不能仅停留在用例设计原理上，很多时候还应该从实现角度来进行设计分析，减少不必要的时间投入，特别是逻辑复杂的情况，通常我们可以做如下事情： 1、分析调用的接口请求 查看不同(相似) 1和条件2之间的关系是不一样的，对应的，用例设计也就不一样了。 3、查看调用的实现相关的sql语句 有时候，我们也可以通过日志获取开发代码调用的sql语句，作为用例设计中结果校验的手段。通过sql语句来分析界面数据是怎么展示出来的，数据取值是否正确。
74210发布于 2019-09-11 - 来自专栏授客的专栏
测试思想-测试设计 测试用例设计之判定表驱动分析方法
7.判定表的建立步骤： 1)确定规则的个数。 2)列出所有的条件桩和动作桩。 3)填入条件项。 4)填入动作项。等到初始判定表。 5)简化判定表。 pdf版下载 测试用例设计之判定表驱动分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼
1.1K20发布于 2019-09-11 - 来自专栏授客的专栏
测试思想-测试设计 授客细说场景测试用例设计与实践
借鉴软件设计的思想，引进“按场景设计用例”的思想 ? 基本流用黑色表示，是经过用例的最简单的路径。 ： 1）用户会按模拟的那样，操作产品(不管是有意还是无意)，测试投入有价值 2）用户永远不会那么操作，测试投入约等于无价值。 用例设计 通常情况下，可以把每个场景当作一条用例。这里需要注意的是，这里的事件流侧重事件触发逻辑顺序，设计用例时，还要注意测试数据(按我的观点，测试逻辑和测试数据一般是要分开的)。 适用范围： 通常，按场景设计用例，比较适合流程性比较强的测试，比如业务测试。 当然，这种思想，也可以应用用在局部功能的测试上，具体参见文章“测试用例设计实践总结”描述中，其核心思想和这个场景测试是差不多的。 pdf版下载： 授客细说场景测试用例设计与实践.pdf
81430发布于 2019-09-11 - 来自专栏全栈程序员必看
软件测试的用例设计方法_测试用例设计
，对系统业务功能影响不大的模块或功能的测试用例 p2、P3：重要程度介于P0和P4之间 其他要素： 用例的设计者，用例设计日期，对应的开发人员，测试结果（pass，fail，block），测试类型（ 功能，性能，压力等） 4、测试用例的设计原则 （1）明确性：测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的 （2）代表性：尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并 非6~8位，为空 12345，为空 qq号 类型 自然数 / 非自然数 123456A qq号 规则 不以0开头 / 0开头 0123456 6、设计方法：边界值分析法 7、设计方法：因果图法 约束条件： 8、设计方法：判定表法 判定表示例： 9、设计方法：正交表法 案例： 使用正交设计助手工具： 选择正交表，填写水平因素： 生成的正交表： 每一项实验就是一条测试用例 10、设计方法：场景法 11、设计方法：错误推断法 12、总结 版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。
1.4K20编辑于 2022-11-04 - 来自专栏授客的专栏
测试思想-测试设计 精简测试用例编写
by:授客 QQ：1033553122 大家都知道，测试用例的一个核心作用就覆盖测试需求，尽可能的减少漏测，同时提高测试效率。再细想想，这种核心作用的本质也就是一种“提醒”作用。 话说，写用例、设计用例是需要时间的，而在追求速度的时代，似乎连这点时间都给不起。 按我的经历来看，这种类型用例，在测试的时候，用例编写人自己都懒得看用例，完全是按自己的当前时间的想法来测试，而非用例编写人呢？ 可以适当做些备注(可以是一些业务逻辑、规则、需求、预期结果等)，让人看得更明白 为了避免模块层级过多，可以不进行模块划分就不划分，当然也可以采用其它技巧，比如模块名称写成“大模块-子模块”的形式 7. 所谓的通用用例，本质上看，也就是设计方法的体现，与其去“记忆”这些会变化的“通用”，还不如多想想你的用例设计里面，哪里体现了、到了这些设计方法。
87020发布于 2019-09-11 - 来自专栏授客的专栏
测试思想-测试设计 测试用例设计最新实践总结-来自不断的追求
用例设计： ? 说明: ? 注意： 1、模块的层级不能太多，有必要的话可通过“2级模块1-3级模块1”的形式，减少模块的层级 2、模块下，分“字段校验”和“功能校验”，划分依据呢？ 3、这样划分的好处是，比较能突出重点，特别是时间来不及的情况下，可能只执行“功能校验”的用例，当然也视情况而定，有些字段校验也很重要，属于重点测试内容。 4、有啥好想法，欢迎交流，别只做伸手党~~
48030发布于 2019-09-11 - 来自专栏测试理论
测试分析设计总结
测试设计 ---- 1. 什么是测试设计 测试设计的过程是根据测试对象信息，不断建立模型的过程。 测试设计流程 设计流程 由测试对象的必要效能输出最高优先级测试点, 即冒烟测试用例 根据测试对象的实现逻辑进行设计, 如逻辑上需要判断/遍历/数据类型转换/序列化/循环等使用对应的测试设计方法输出测试用例 /可行性/方法效率 设计方法 根据边界值设计 根据容量设计 根据正反状态设计 根据等价类设计 根据输入多样性设计 测试合并方法 UI/功能/性能容量合并 正反合并 包含合并 过程合并 重难效测试点合并 测试分析设计总结 ---- 1. /可达到测试目的 通过测试设计可降低不同人员执行时的差异
1.7K51发布于 2021-01-05 - 来自专栏全栈程序员必看
【测试】黑盒测试用例设计方法
黑盒测试用例设计方法包括： 1、等价类划分法、 2、边界值分析法、 3、错误推测法、 4、因果图法、 5、判定表驱动法、 6、正交试验设计法、 7、功能图法、 8、场景法等。 （1）—（7），（10） 4 4 4 （1）—（7），（11） 覆盖无效等价类的测试用例： 设有一个档案管理系统，要求用户输入以年月表示的日期。 这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。 用例设计 对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。 在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。 采用路径分析的方法设计测试用例的好处： 1、降低测试用例设计的难度。
2.6K10编辑于 2022-08-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号