白盒测试平台的开发,我们要首先思考四件事: 我们对白盒测试手动测试到底会还是不会。 我们要做几种开发语言代码的测试 重点是主要用来管理-运行-报告,还是用来自动生成相关用例 这个事情到底值不值的去做,收益怎样 这里我就不再进行讨论这些了,各个公司和组内情况不一样。 就展示下我这里的吧:展示3种语言 的demo 这里进行设置目标待测函数 这里是手动设置各个测试用例的输入,偏于管理 执行用例和结果 关于python ,开发了自动生成白盒用例的技术。
3) 设计分析 通常,设计接口测试用例需要考虑以下几个方面: 1、是否满足前提条件 有些接口需要满足前置条件,才可成功获取数据。 假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例 以上几个方面考虑全的话,基本可以做到如下几个方面的覆盖: 主流程测试用例:正常的主流程功能校验; 分支流测试用例:正常的分支流功能校验 2:POS 3:线上 cashierId int 否 收银员 billerId int 否 导购员 pNo int 否 页码,从第1页开始,默认为1 pSize int 否 每页记录数,默认为10 shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10 消息响应 字段元素如下: 字段名 数据类型 默认值 必填项 备注 orderTotalPriceTotal 问题 如果是自动化测试呢,这里是设计一个方法覆盖多条用例呢(如上,一条数据,覆盖多条用例)?还是一个方法覆盖一条用例呢? 我个人的答案是一个方法一条用例,你的呢?
测试用例设计之正交法 by:授客 QQ:1033553122 什么是n阶拉丁方? 正交试验设计方法 与一般的试验设计类似 ,用正交试验设计方法设计测试用例时主要包括以下步骤: (1) 确定因素 这里的因素是指对软件运行结果有影响的软件 (2) 确定因素的取值范围或集合( 正交表的构成: l 行数(Runs):正交表中的行的个数,即试验的次数,也是通过正交实验法设计的测试用例的个数 l 因素数(Factors) :正交表中列的个数,即要测试的功能点。 增补测试用例 5:不填姓名、不填身份证号、不填手机号 测试用例可以看出:如果按每个因素两个水平数来考虑的话,需要8个测试用例,而通过正交实验法进行的测试用例只有5个,大大减少了测试用例数。 编写测试用例 ? ? dpf版下载地址: 测试用例设计之正交法.pdf
什么时候进行性能测试? 在功能测试完成,所有的功能都比较稳定的时候,才可以做功能测试,一般在测试的中后期执行 性能测试术语 1.并发数: 广义并发数:同一时刻向服务器发送Http请求的用户数量;(有可能不是同一个功能) 在线用户数 性能测试类型 1.负载测试: (运行15min左右) 并发测试:在一定的软硬件环境下,系统的其他指标不变,测试系统在不同用户量访问级别下,系统性能的表现 容量测试:在一定的软硬件环境下,系统的其他指标不变 ,测试系统数据库数据量在不同的级别下,系统性能的表现 2.压力测试: 高于系统的最高负载,去运行系统,查看系统的表现 3.可靠性测试(疲劳测试): 低于系统的最高负载,去运行系统,查看系统的表现 4.配置测试 ,比较每次测试结果,从而确定各个因素对系统性能的影响。
话接上回(测试基础10问-上),继续问答之旅,答案是什么并不重要,重要的是引发一些思考。学问学问,边学边问。 06 测试是否需要过早的参与产品需求讨论? 有以下几点好处: 产品把需求梳理清楚了,也知道怎么验收了 研发知道要做什么,做成什么样算是基本做好了 测试在这个过程中,就把核心用例设计完成了。还可以给到研发做为自测的标准。 测试的本质是希望贯穿整个研发周期,形成闭环,并持续改进测试流程,以终为始、系统地分析测试需求,在资源和测试目标之间寻求平衡, 基于风险的测试策略是必不可少的 在分析和设计的基础上,尽可能地实现自动化测试 测试的天花板也没有你们想的那么低。没事多看看招聘信息,多和行业高手互动。测试还是大有可为的。 10问聊完,大家对测试是否有新的认知呢? 在整理这10问题的时候,自己也做了更多的思考,测试这份职业还是比较好玩的。个人从事测试10多年,还是热爱这个行业的。测试相关的问题,欢迎沟通交流。 END 标星、点赞、关注三连走起,感谢支持。
公共用例设计实践 by:授客 QQ:1033553122 背景介绍(大致如下): 图一:我的-个人资料-动态 图二:发现 ? ? ? ? 图三:动态转发 图四:动态评论 ? ? ? 用过新浪微博之类的应该懂的,没用过的话去用用就懂了~~ 问题: 从上图可看到,转发,评论,赞都有多个入口: 发现页面-列表、我的-个人资料-动态页面-列表、动态详情(正文)界面 转发,评论对话框都有多种情况,怎么设计用例 且动态详情页面的信息和列表页面的信息(转发数,评论数,赞数等是保持一致的) 到此:我们可以划分出两个公用模块:动态列表+动态详情 接下来,对公用模块进行用例设计分析 第二:分析操作流程 动态列表页 >返回动态列表>>评论按钮旁的评论数加1 情形2:评论按钮(评论数不为0的)>>动态详情页(显示转发标签页或评论标签页)>>评论标签页的评论数加1 仔细分析情形1,情形2,我们可以很好的划分出两个测试点 评论不转发 还有个特别 @ 功能 注:其中@功能比较特殊,单独出来 2.转发对话框 评论加转发 评论不转发 也有个特别 @ 功能 注:其中@功能比较特殊,单独出来 第四:用例设计
by:授客 QQ:1033553122 一.方法简介 1.定义 是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。 如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。 5)把判定表的每一列拿出来作为依据,设计测试用例。 4)用例设计 针对每一条规则(C,D列除外)设计一条用例 2.有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。 5)用例设计 pdf版下载: 测试用例设计之因果图方法.pdf 参考文章: 测试用例设计白皮书_张元礼
恰好,最近我正在帮助客户设计和实施测试策略。 我便有了想法重新写一篇文章,体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客,正好缺失这样的一篇文章。 测试策略设计 在进行测试策略设计之前,我们确立好基本思想:每个人为质量负责。不是 QA,也不止是 QA 和 开发,而是所有人。 测试策略不是一成不变的,而是不断演进的 在我们继续设计之前,我们还需要: 收集、分析现有的缺陷类型、修复时间等 寻找适合项目的测试类型、方式 确认方案所需要的度量体系 定义『测什么?』 于是,在与我的同事于晓南讨论之后,大致有了一个总体方案设计和实施的过程: 明确总体目标。即我们做这件事的价值是什么? 可测试性调研。评估自动化测试的可行性;定位 设计测试策略。 通用的应用级测试策略模板;设计环境管理、数据管理、用例管理方案; 对齐标准的测试环境。打通自动化测试环境; 进行测试数据管理。 持续优化。
对如果进行有效测试设计, 分为以下几点作说明: 测试设计概述 测试场景分析 测试对象分析 测试类型分析 交互分析与规程设计 自动化设计与环境分析 1. 测试设计概述 #1.1 定义: 测试设计技术是从特定的测试依据中得到测试用例用来实现特定测试覆盖的标准化方法. ? #1.2 测试设计能够解决的问题 ? 测试设计能够解决的问题 有效减少测试用例的数目 避免测试用例之间的冗余 满足测试覆盖率的要求 ...... #1.3 测试分析设计技术全景图 ? 因为, 软件不仅要能接收合理的数据, 也要能经受以外的考验, 这样的测试才能确保软件具有更高的可靠性 测试设计技术 - 边界值 边界值分析方法就是对输入或输出的边界值进行测试的一种黑盒测试方法 经验告诉我们 #2.2 场景分析的目的 将被测试特性细分为功能独立的场景, 再针对各个场景进行设计, 从而从整体上降低测试设计的复杂度 场景分析的目的实际上是要搞清楚业务或功能的运行上下文是什么, 完成什么样的功能,
5.设计测试用例 在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例: 1)为每一个等价类规定一个唯一的编号 ; 2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止; 3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步 现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。 200211 输入有效 ①、⑤、⑧ 3)为每一个无效等价类设计一个测试用例,设计结果如下: 测试数据 期望结果 覆盖的无效等价类 95June 无效输入 ② 20036 .pdf 参考文章: 测试用例设计白皮书_张元礼
测试用例设计之边界值分析方法 1.定义 对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。 3.边界值分析方法的考虑: 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。 使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。 例如,如果程序的规格说明中规定:"重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……"。作为测试用例,我们应取10及50,还应取10.01, 9.99,49.99及50.01等。 pdf版下载: 测试用例设计之边界值分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼
测试通过执行软件的一系列操作,旨在发现潜在的错误、缺陷或问题,从而确保软件能够按照预期工作。而软件测试往往覆盖了不同的层次和类型,其中单元测试是针对软件中最小的独立单元(通常是函数或方法)进行的测试。 单元测试通常由开发人员编写,用于验证代码的正确性。 2、单元测试 单元测试是软件开发中的一种测试方法,用于验证代码中的最小单元(通常是函数或方法)是否按照预期工作。 单元测试旨在隔离和测试软件的各个独立部分,确保每个部分的行为都是正确的。 Python 中,单元测试是通过使用 unittest 模块来实现的。 这两个方法在每个测试方法执行前后分别被调用,以确保测试环境的准备和清理。 setUp:在每个测试方法执行之前调用。 通常用于准备测试环境,例如初始化变量、建立测试数据等,或在测试之前创建对象或设置必要的资源。 tearDown :每个测试方法执行之后调用。
最近在找资料的时候,翻出了早期从别的地方看到的关于测试基本知识30问。重新看了一遍,有很多感慨,原来自己也踩过那么多坑。故重新梳理了下,精简成10问,一起来看看那些看似小白,但又不太好回答的问题。 02 软件测试很简单么? 在软件测试的初期,你可能只是需要按照别人给定的测试用例,机械地去执行就可以了,那是相对简单的。但是接下来,你需要形成自己的测试思维,结合业务去做用例设计。 如果不了解被测试系统的架构设计知识,在开展测试时,会有处处被掣肘的感觉。不管是定位BUG还是分析BUG,如果你不了解原理,就很难有效的去处理那些问题。 作为一名优秀的测试人员,必须要能够自己画对业务的技术架构图及数据流程图。有助于你更好的去做测试用例设计和场景覆盖。 例如,当你了解了redis的技术实现,你在设计用例时,就会考虑到数据持久化、数据时效性、数据透传等等场景。而如果你不懂技术,通过业务场景,很难覆盖到这些技术特性。 05 规范的测试会增加项目成本?
输入编号,点击“优惠券”,“会员卡”图标,可对输入的卡券(会员主卡,代金券,折扣券)编号验证,另外,如果输入是手机号,则对手机号关联会员的会员主卡进行验证 如果不考虑逆向用例,考虑正向用例,你会咋样设计用例 用例数比较多,进而花费的测试时间也跟着变长,如果再加上一些条件(本例子中还有个条件:是否携带“不可优惠金额”,验证结果会受到其影响),那就更多了,咋办呢? 综上,我们在测试用例不能仅停留在用例设计原理上,很多时候还应该从实现角度来进行设计分析,减少不必要的时间投入,特别是逻辑复杂的情况,通常我们可以做如下事情: 1、分析调用的接口请求 查看不同(相似) 1和条件2之间的关系是不一样的,对应的,用例设计也就不一样了。 3、查看调用的实现相关的sql语句 有时候,我们也可以通过日志获取开发代码调用的sql语句,作为用例设计中结果校验的手段。通过sql语句来分析界面数据是怎么展示出来的,数据取值是否正确。
pdf版下载 测试用例设计之判定表驱动分析方法.pdf 参考文章: 测试用例设计白皮书_张元礼
借鉴软件设计的思想,引进“按场景设计用例”的思想 ? 基本流用黑色表示,是经过用例的最简单的路径。 : 1)用户会按模拟的那样,操作产品(不管是有意还是无意),测试投入有价值 2)用户永远不会那么操作,测试投入约等于无价值。 用例设计 通常情况下,可以把每个场景当作一条用例。这里需要注意的是,这里的事件流侧重事件触发逻辑顺序,设计用例时,还要注意测试数据(按我的观点,测试逻辑和测试数据一般是要分开的)。 适用范围: 通常,按场景设计用例,比较适合流程性比较强的测试,比如业务测试。 当然,这种思想,也可以应用用在局部功能的测试上,具体参见文章“测试用例设计实践总结”描述中,其核心思想和这个场景测试是差不多的。 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 大家都知道,测试用例的一个核心作用就覆盖测试需求,尽可能的减少漏测,同时提高测试效率。再细想想,这种核心作用的本质也就是一种“提醒”作用。 话说,写用例、设计用例是需要时间的,而在追求速度的时代,似乎连这点时间都给不起。 这不是我吹的,特别是互联网,大部分公司都采用敏捷开发模式,讲究快速,所以,时间往往是有限的,再加上很多公司对敏捷仅停留在概念阶段,以为“敏捷=快速”,把时间花在用例设计上简直就是一种浪费….这样一来,用来设计用例的时间有时候 按我的经历来看,这种类型用例,在测试的时候,用例编写人自己都懒得看用例,完全是按自己的当前时间的想法来测试,而非用例编写人呢? 所谓的通用用例,本质上看,也就是设计方法的体现,与其去“记忆”这些会变化的“通用”,还不如多想想你的用例设计里面,哪里体现了、到了这些设计方法。
用例设计: ? 说明: ? 注意: 1、模块的层级不能太多,有必要的话可通过“2级模块1-3级模块1”的形式,减少模块的层级 2、模块下,分“字段校验”和“功能校验”,划分依据呢? 3、这样划分的好处是,比较能突出重点,特别是时间来不及的情况下,可能只执行“功能校验”的用例,当然也视情况而定,有些字段校验也很重要,属于重点测试内容。 4、有啥好想法,欢迎交流,别只做伸手党~~
测试设计 ---- 1. 什么是测试设计 测试设计的过程是根据测试对象信息,不断建立模型的过程。 测试设计流程 设计流程 由测试对象的必要效能输出最高优先级测试点, 即冒烟测试用例 根据测试对象的实现逻辑进行设计, 如逻辑上需要判断/遍历/数据类型转换/序列化/循环等使用对应的测试设计方法输出测试用例 /可行性/方法效率 设计方法 根据边界值设计 根据容量设计 根据正反状态设计 根据等价类设计 根据输入多样性设计 测试合并方法 UI/功能/性能容量合并 正反合并 包含合并 过程合并 重难效测试点合并 测试分析设计总结 ---- 1. /可达到测试目的 通过测试设计可降低不同人员执行时的差异