精华内容
下载资源
问答
  • 测试用例软件
    2022-05-29 12:07:14

    在熟悉了业务之后,往往会分配来写测试用例,并且在日常测试中,有时也需要补充测试用例到现有的案例库中。本文我们将解决以下问题:

    • 测试用例的基本要素
    • 测试用例的设计方法
    • 基于需求的设计方法
    - 等价类  
    - 边界值   
    - 因果图   
    - 正交排列   
    - 场景设计法   
    - 错误猜测法
    
    • 测试用例的有效性
    • 测试用例的粒度和评价

    测试用例的基本要素

    回顾测试用例的概念:
    测试用例 (Test Case) 是为了实施测试而向被测试的系统提供的一组集合, 这组集合包含: 测试环境、操作步骤、测试数据、预期结果等要素。
    好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

    • 评价测试用例的标准:对比好坏用例的评价标准
    • 用例表达清楚,无二义性。
    • 用例可操作性强。
    • 用例的输入与输出明确。一条用例只有一个预期结果。
    • 用例的可维护性好。
    • 用例对需求的覆盖率高。

    测试用例的给我们带来的好处

    测试执行者的依据
    使得工作可重复, 自动化测试的基础
    评估需求覆盖率
    用例的复用
    积累测试的方法思路以供后续借鉴
    使用中带来困扰
    测试用例的设计是费时费力的工作,往往设计测试用例所花费的时间比执行所花费的时间还多
    解决如下问题
    不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗 余测试影响测试效率

    测试用例的设计方法

    基于需求进行测试用例的设计

    基于需求设计测试用例是测试设计和开发测试用例的基础,第一步就要分析测试需求,验证需求是否正 确、完整、无二义性,并且逻辑自洽。在需求正确的基础上细化测试需求,从测试需求提炼出一个个测 试点或者测试项,然后根据每一个测试点进行测试用例的设计;
    在分析测试需求时,一般分为功能测试需求和非功能测试需求

    功能需求测试分析

    对于功能测试中,可以借助功能框图来帮助我们进行测试的需求分析。概括起来,功能测试需求包括以 下,通常包括以下几个方面。
    (1)系统各个功能界面的验证
    (2)借助业务把功能串起来进行测试
    (3)功能的一致性,交互性(多功能互操作)的测试
    (4)系统的不同输入,结果输出的业务数据测试。
    (5)功能的错误操作,异常操作的测试(属于负面测试)
    (6)功能实现用到的算法验证,有时需要用运代码评审
    (7)用户操作的易用性,用户体验,往往结合功能测试同时验证。
    针对具体的需求,可以根据业务分类,用户角色(餐厅的会员系统)或者用户操作区域等将系统的功能 分解成若干个功能模块,然后按照功能模块分别进行测试需求分析。按照功能模块划分,业务模块划分 是最常见的做法。
    下面对一个简单的日历系统的需求进行分析

    日历

    对日历根据web界面的功能布局分析出的功能框图如下:
    功能布局分析出的功能框图](https://img-blog.csdnimg.cn/e34aa1a6427b4b1a8b42cb5899b4cfc6.png)

    也可以采用思维导图的方式,更为方便,有效,只管的呈现测试需求的分析结果,可以更好的支持测试
    分析思路的连贯性。
    下面以我们常用的百度云盘手机端为例进行分析功能

    百度云盘手机端为例进行分析功能

    在进行需求分析的时候,我们还要考虑业务规则如,上传文件的大小有没有限制;一次性崔铎上传多少 数量的文件,比如小于100个;文件夹最多有多少层等等;

    非功能需求测试分析

    非功能测试需求主要涉及性能,安全性,可靠性,兼容性,易维护性和可移植性等。从测试需求分析来 看,每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响,如安全性越高, 就越有可能给易用性,性能带来更大的挑战。
    这里要说明的是对于每一个应用软件系统,非功能特性的质量需求都是存在的,但是不同的项目类型对 各个非功能特性的要求是不一样的,这个需要根据具体的项目、具体需求和不同产品应用的特点进行分 析。
    (1)纯客户端软件,比如字处理软件(Word, PPT),媒体(音频/视频)播放软件(电脑自带的) 等。这类软件对系统的功能测试要求是最低的,但是对兼容性和稳定性,可移植性有一定的要求。
    (2)企业内部的客户端/服务端(C/S)应用系统。比如电子邮件,即时通信系统(飞Q,企业QQ)等, 在系统功能测试需求上比纯客户端复杂,要求功能正确,稳定性能好。但是整体上看,对性能,安全 性,兼容性要求不高。
    (3)外部大型复杂网络应用系统,比如电子商务,网上银行,视频网站(腾讯,优酷)等,除了有复 杂的系统的功能测试需求外,在系统的性能,安全性,兼容性,容错性,可靠性等都有很高的要求。

    此外,对于大型企业级应用系统,由于应用模式,系统架构的不同 (分布式,微服务等) ,我们必须结合架构
    和应用模式来具体分析非功能性测试需求,特别是可扩展性,可靠性,安全性等。技术架构对功能的影响小,
    但是非功能性测试就要深入架构分析,才能更好的把我测试范围和测试方法。

    例:百度云盘非功能测试
    用户需求:
    购买3000块钱以内的华为智能手机 测试用例:
    1.价格<=3000元
    2.品牌为华为
    3.智能手机
    4.手机功能验证:
    4-1.打电话
    4-2.接电话
    4-3.发短信
    4-4.收短信

    软件需求:
    1.1.1.1.5.3 异常事件流

    1、若用户未收到激活邮件,可在登录界面录入电子邮件及密码后,再次发送激活邮件。
    2、每次发送的激活邮件,仅在发送邮件后起24小时之内有效,超过24小时后需重新发送激活邮件。

    测试用例
    1-1、未收到邮件,登录时输入电子邮件及密码后,再次发送激活邮件
    1-2、已收到邮件,登录时输入电子邮件及密码后,不发送激活邮件

    2-1、收到邮件,未激活,24小时内进行激活
    2-2、收到邮件,未激活,24小时后链接过期进行激活。
    2-3、收到邮件,已激活,24小时后链接过期,再次点击激活?
    页面检查:
    1、收到激活邮件
    2、邮件内容正确
    3、激活URl正确,可激活
    4、再次激活提示已激活
    5、过期激活提示已过期

    具体的设计方法

    等价类

    依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类,从等价类中选出一个测试用例,如果 这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的 功能覆盖,解决了不能穷举测试的问题。

    • 有效等价类:对于程序的规格说明书是合理的、有意义的输入数据构成的集合,利用有效等价类验 证程序是否实现了规格说明中所规定的功能和性能。
    • 无效等价类:根据需求说明书,不满足需求的集合。

    等价类只考虑输入域的分类,没有考虑输入域的组合,需要其他的设计方法和补充。

    边界值

    边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等 价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

    日常语言中的"边界"漏洞

    考完试发成绩了 , 老师布置寒假作业: 超过60分的 , 所有题目抄写1遍 , 低于60分的 , 所有题目抄写3遍 .
    于是小明就没有写作业~~, 因为他刚好60分 .

    1. 输入框长度为1-11,取边界值为:1、11、12、0
    2. 运动员的参赛项目为1-3项,取边界值为:0项、1项、3项、4项
    3. 查询面页面有999行,每50行为一页,取边界值为:输出0行、1行、50行、51行、999行

    以注册邮箱的软件需求为例子 用户名要求长度为6-15位 边界值上点为:5,6,15,16 全了吗?

    在实际的测试设计中,会将等价类和边界值结合起来使用,那么我们最终可以确认的用例设计为: 5,6,10,15,16五个长度的字符的输入值
    继续思考:这样的测试真的完整了么?中文?半角?全角?特殊字符(扩散思维)

    错误猜测法

    错误猜测法是对被测试软件设计的理解,过往经验以及个人直觉,推测出软件可能存在的缺陷,从而针 对性地设计测试用例的方法。
    这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握,还有个人的经验和直觉。
    错误推测法和目前流行的“探索式测试方法”的基本思想一致,这类方法在敏捷开发模式下的投入产出比 很高,被广泛应运于测试。
    这个方法的缺点是难以系统化,并且过度依赖个人能力。
    案例:

    以注册为例
    1、校验中特殊字符空格的处理?
    2、密码校验中的大小写?
    3、姓名中的特殊字符?
    4、密码发送是否明文
    

    场景设计法

    现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触 发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景,有利于测试设计者 设计测试用例,是测试用例更容易理解和执行。
    典型的应用是是用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功
    能细节忽视业务流程要点的错误倾向

    以注册为例*
    注册

    想象注册的场景来设计用例,这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用 例。例如我们可以再想象以下场景:
    1、用户激活后再次点击邮件激活链接?
    2、已注册用户再次注册?
    在这里插入图片描述

    因果图

    因果图是一种简化了的逻辑图,能直观地表明程序输入条件(原因)和输出动作(结果)之间的相互关 系。因果图法是借助图形来设计测试用例的一种系统方法,特别适用于被测试程序具有多种输入条件、 程序的输出又依赖于输入条件的各种情况。

    因果图的需要掌握的基本知识

    • 恒等
      在这里插入图片描述

    恒等:如果原因为真,那么结果必定为真。


    • 在这里插入图片描述

    只有2个原因都为真,那么结果为真


    • 在这里插入图片描述

    2个原因中有一个为真时,结果就为真。


    • 在这里插入图片描述

    只有原因为假,结果才为真。

    因果图法设计测试用例的步骤如下。

    (1)分析所有可能的输入和可能的输出。
    (2)找出输入与输出之间的对应关系。
    (3)画出因果图。
    (4)把因果图转换成判定表。
    (5)把判定表对应到每一个测试用例。

    案例一:
    假设业务单据的处理规则为: “淘宝618活动,订单已提交,订单合计金额大于300元或有红包,则进优惠”。

    1. 对于这条业务规则,首先通过分析所有可能的输入和可能的输出,可以得到如下结果:
      ● 输入:订单已提交、金额大于300、有红包。
      ● 输出:优惠、不优惠。

    2. 然后,进行第二步,找出输入与输出之间的对应关系。通过分析,可以看出有以下的对应关系。
      (1)订单已提交,订单金额大于300元,则优惠。
      (2)订单已提交,订单金额小于等于300元,无红包,不优惠
      (3)订单已提交,有红包,则优惠。
      (4)订单已提交,订单金额大于300元,有红包,则优惠。
      (5)订单未提交,不优惠。

    3. 为了方便画出因果图和判定表,需要对所有输入和输出编号,现在编号如下。
      1 :订单已提交。
      2:订单金额大于300元。
      3:有红包
      21 :优惠
      22:不优惠

    4. 画因果图
      在这里插入图片描述

    5. 画判定表:有3个条件,输出有2个取值,所以表的列数为2x2x2=8

    在这里插入图片描述

    1. 最终的测试用例
      1, 2, 3, 4, 5 (包含6, 7, 8)。

    案例二:
    继续以注册的需求为例:
    姓名、邮箱、密码、确认密码、验证码必须全部输入,才能进行注册
    需要设计多少用例? 2x2x2x2x2。

    因果法设计测试用例可以帮助测试人员理清输入和输出的关系,但是对于比较复杂的输入和输出,会耗费大量时间

    正交排列

    因果法设计用例太多怎么办?

    正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

    正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法,它是根据正交 性,由试验因素的全部水平组合中挑选出部分有代表性的点进行试验,通过对这部分试验结果的分析了 解全面试验的情况,找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的 试验。
    因素 ( Factor):在一项试验中,凡欲考察的变量称为因素(变量)
    水平(位级) ( Level):在试验范围内,因素被考察的值称为水平(变量的取值)
    正交表的构成:
    行数(Runs): 正交表中的行的个数,即试验的次数,用N代表。
    因素数(Factors): 正交表中列的个数,用C代表。

    水平数(Levels): 任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或 从1到“水平数”,用T代表。
    正交表的表示形式: L=行数(水平数*因素数) L=N(TC)
    正交表的两条性质:
    每一列中各数字出现的次数都一样多。
    任何两列中的各有序数对出现的次数都一样多。
    正交法设计测试用例的步骤:
    1、有哪些因素(变量)
    2、每个因素有哪几个水平(变量的取值)
    3、选择一个合适的正交表
    4、把变量的值映射到表中
    5、把每一行的各因素水平的组合作为一个测试用例
    6、加上你认为可疑且没有在表中出现的用例组合
    案例:
    继续以注册为例(类似工具可以使用微软的PICT工具):
    1、因素:姓名、邮箱、密码、确认密码、验证码
    2、水平:填写、不填写
    在这里插入图片描述
    3、表中的因素数=5;
    表中至每个因素数的水平数=2
    行数取最少的一个,即试验次数最少的一个
    L=N(TC)=(2-1)*5+1=6(25) N=Cx(T-1)+1
    L=6(25)
    N试验次数
    T水平数
    C因素数
    选择正交表,这里选择了L6_2_5。正交表不是随便选择的,而是设计好的
    4、生成测试用例
    思路:因素取值为填写时:正交按取值个数5-3-2-1 ( 5已全了, 3, 2, 1任意排列)进行排列,实验次 数不够用取值为填写个数为2或3任意组合,但要满足正交的二条性质。
    在这里插入图片描述

    5、增补测试用例
    姓名、邮箱、密码、确认密码、验证码都不填写

    什么样的测试用例是一个好的测试用例?

    什么是测试用例的有效性?

    测试用例对应的功能已删除,不可操作了

    微信刚出来时与QQ可互发消息,下一个版本后就不可以发消息。

    执行一条测试用例未发现BUG,实际该处有BUG

    苹果7手机微信添加了mobile单车小程序,扫码不能开锁,只能使用mobile APP开锁,测试用例未涉及到苹 果7微信小程序扫码开锁。

    执行一条测试用例发现了BUG

    苹果7手机微信添加了mobile单车小程序,用例已写到了苹果7微信添加mobile小程序扫码开锁,问题被发现

    执行一条测试用例未发现BUG,实际该处BUG已修改

    苹果7手机微信添加了mobile单车小程序扫码开锁,可以正常开锁

    测试用例的粒度和评价

    好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

    粒度:指测试用例编写的详细程度。

    测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内 容,如探索性测试中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用 的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数 据,期待的结果及检验的方法, 具体到界面元素的操作步骤,指定测试的方法和工具等。
    (1)测试用例写得过于复杂或详细,会带来两个问题:一个是效率问题,另一个是维护成本问题。另外, 测试用例设计得过于详细,留给测试执行人员的思考空间就比较少,容易限制测试人员的思维。
    (2)测试用例写得过于简单,则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进 行“设计”,只是把需要测试的功能模块记录下来而已,它的作用仅仅是在测试过程中作为一个简单的测 试计划,提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理 解需求,检验需求,并把对软件系统的测试方法的思路记录下来,以便指导将来的测试。
    大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将 影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测 试用例。
    主要考虑可以参考如下内容:

    • 产品的质量要求
    • 项目对用例的要求
    • 测试时间和资源是否充分

    但是不管用例怎么简化,都不应该省略
    测试用例的评价
    测试用例设计出来了,如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一 样,测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。

    • 同行评审
    • 用户检查
    • 项目组评审

    (1)测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审,尤其是临时的 同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价 值”,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单, 测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是 存在局限性。因此需要一起设计测试用例。
    (2)除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让用户参与评审,从而体现敏 捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于如何定义测试, 如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家); 如果测试是被定义为对开发提供帮助和支持,那么顾客显然就是程序员了。
    (3) 由测试负责人组织协调开展会议,用例编写人对用例进行讲解,参会人员有异议的当场提出。

    更多相关内容
  • 软件测试用例编写规范软件测试该规范的目的是为用例设计人员提供测试用例编写的指导,提高编写的测试用例的可读性、合理性,及可执行性。使测试人员可以更好的执行测试,进而提高软件的质量。1、用例分类用例计划...
  • 测试用例模板,包含用例记录表,企业应用管理表,用户应用管理表,标签管理表,客户经历管理表,store管理表
  • 1、有详细的用例编写模板,一般的问题都已有涉及到。2、编辑测试用例的时候,只要套用这个模板就可以了。 1、有详细的用例编写模板,一般的问题都已有涉及到。2、编辑测试用例的时候,只要套用这个模板就可以了。
  • 软件测试测试用例实例(功能测试用例、性能测试用例、兼容性测试用例)汇编.pdf
  • 嵌入式软件设计规范!C语言设计,嵌入式系统软件设计。
  • 但前面文章的问题是,生成的都是手工的测试用例,如果让测试人员手工执行程序自动生成的测试用例,呃……这对于软件测试中基于模型生成自动化测试用例 在前面一文使用NModel自动生成测试用例中,介绍了如何通过给待...
  • 设计测试用例需要考虑以下问题:  o测试用例的基本格式  软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。  用例编号:测试用例的编号有一定的规则,...
  • 软件测试用例的设计

    2021-03-23 11:51:09
    一个好的测试用例使得测试工作的效果事半功倍,并且能尽早的发现一些隐藏的BUG,测试用例的设计是软件开发中的重中之重。 关键词:软件测试测试用例,TESTCASE,用例设计 ...
  • 软件测试用例模板
  • 教你在软件测试中如何书写测试用例性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、系统测试、集成测试、接口测试,这么些眼花缭乱的测试类型名称,估计很少有有人能准确的区分和说出...
  • 软件测试用例设计和软件测试用例写作软件测试用例设计:从设计层面考虑(功能性、可用性、安全性等方面);  测试用例工作过程  软件测试用例设计和软件测试用例写作  软件测试用例设计:从设计层面考虑(功能性、...
  • 软件测试中黑盒测试用例设计方法总结测试用例(TestCase)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 测试用例(TestCase)目前没有经典的...
  • 学生管理系统软件测试用例 测试用例 测试用例 软件测试软件开发时期最终一个阶段也是软件质量和可靠性确保中至关关键一个步骤软件测试基础任务是经过在计算机上实施程序暴露出程序潜在错误方便进行纠错从而确保...
  • 软件测试用例的认识误区软件测试软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性,便于测试质量的度量,增强测试...
  • 软件测试用例标准

    2021-03-23 16:34:48
    软件测试用例标准1.接口测试用例接口A的函数原型输入/动作期望的输出/相应实际情况典型值…边界值…异常值…2.路径测试的检查表检查项结论数据类型问题(1)变量的数据类型有错误吗?(2)存在不同数据类型的赋值吗...
  • 完整的测试用例生命周期过程,它通常有测试条件标识、测试用例设计、测试用例实现、测试用例的执行,以及测试用例管理等几个阶段组成。由于不同的公司的质量方针和测试策略的不同,采用的测试用例过程可能会有所不同...
  • 软件测试用例的设计-边界值法软件测试边界值分析也是一种黑盒测试方法,适度等价类分析方法的一种补充,由长期的测试工作经验得知,大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例,可以...
  • 软件测试测试用例)—写用例无压力

    万次阅读 多人点赞 2022-02-15 12:53:03
    文章目录软件测试——用例篇一、概念二、测试用例总体设计方案1、等价类 ☆2、边界值 ☆2.1 边界值法设计用例步骤3、判定表 ☆4、因果图5、场景设计法 ☆6、错误猜测法7、正交排列三、实际操作中注意的点3.1测试用例...

    软件测试——用例篇

    一、概念

    测试用例的基本概念:

    测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素 。

    主要步骤:

    测试环境——测试步骤——测试数据——预期结果

    网易邮箱注册成功测试用例

    标题:邮箱注册,邮箱输入项测试:

    简单案例:

    image-20220109225709851

    二、测试用例总体设计方案

    基于需求的设计,RBT( Requirements-Based Testing)是基于需求的测试方法,会使测试更加有效,因为 它使测试专注于质量问题产生的根源,即需求。

    1、从整体角度设计分析测试用例:基于需求

    用户需求——(整理出软件需求)产品设计文档(产品经理)——开发——测试——上线

    (1)、验证需求的正确性和合理性

    (2)、分析需求、细化需求、从需求中分解出测试项 ,根据测试项找出功能,进行测试用例的编写。

    案列:

    用户需求:
    购买3000块钱以内的华为智能手机 。

    假如说:有一个活动秒杀 5999 为1块钱,这样也是发河价格的。

    测试用例:

    (1)合理

    (2)分析:

    价格:<=3000;

    品牌:华为

    手机类型:智能手机

    手机基本功能:…

    软件需求:
    事件流

    1. 若用户未收到激活邮件,可在登录界面录入电子邮件及密码后,再次发送激活邮件 。
    2. 每次发送的激活邮件,仅在发送邮件后起24小时之内有效,超过24小时后需重新发送激活邮件

    测试用例:

    1、用户收到邮件,不在此发送激活邮件;

    ​ 用户收到邮件,再次录入电子邮件及密码,提示:已激活邮件;

    ​ 用户未收到邮件,再次发送激活邮件;

    2、24小时以内,有效

    ​ 大于等于24小时 ,无效激活邮件

    ​ 边界值:24小时点击激活,25小时 重新发送邮件

    容易忽略:24小时之内已经点击激活邮件,超过24小时又重新激活,将提示“系统已激活:。

    测试激活邮寄的基本功能:

    • 邮件能不能打开
    • 邮件的格式,内容够是否正确;
    • 邮件里面的激活链接是否正常;

    这些是逻辑来测试用例。

    1、等价类 ☆

    等价类就是把输入划分成若干个等价类,从每一个等价类中取出一个测试用例,如果这个测试用例能够测试通过,那么我们就说这个测试用例代表的等价类测试通过。(衣柜分类衣服的例子)

    通俗来讲,具有某种共同特征的数据集合进行划分!!

    使用场景:测试用例无法穷举,我们无法一样测试。

    • 有效等价类:符合程序规格说明的数据集合

    • 无效等价类:不符合软件需求规格说明的数据集合

    步骤:

    1、明确需求。

    2、确定有效等价类还是无效等价类

    3、提取数据编写测试用例

    案例一:
    需求:验证qq账号的合法性
    要求:6~8为自然数
    

    案例一:

    image-20220213174357895

    案例二(电话):

    需求:验证某城市电话号码的正确性
    要求:
    1.区号:空或者是三位数字
    2.前缀码:非“O”且非“1”开头的三位数字
    3.后缀码:四位数字
    

    image-20220214181555209

    2、边界值 ☆

    针对输入和输出的边界进行测试用例的设计。

    案例:

    购买3000元以内的华为只能手机

    价格:<=3000, 3001就不行

    等价类:

    有效等价类:小于3000

    无效等价类:大于3000

    边界值:2999 3000 3001

    2.1 边界值法设计用例步骤

    1、明确需求

    2、确定有效和无效等价类

    3、确定边界范围值

    4、提取数据编写测试用例

    案例一:

    需求:通过边界值法验证标题长度的合法性
    要求:标题大于0,小于等于30个字符
    

    image-20220214201754883

    补充:边界范围节点:

    1、上点,边界上的点

    2、离点,举例边界上的点最近的点(刚好大于,刚好小于)遵循 开内闭外 原则

    3、内点,范围内的点。

    • 优化:

    边界上的点:开内闭外。

    3、判定表 ☆

    解决多条件的依赖问题。

    1、定义:是一种以表格形式表达多条件逻辑判断的工具。

    2、组成:

    • 条件桩:列出问题中的所有条件
    • 动作桩:列出问题中可能采取的操作
    • 条件项:列出条件对应的取值,所有可能条件下的真假值
    • 动作项:列出条件项的、各种取值情况下应该采取的动作结果。

    规则:
    1、判定表中贯穿条件项和动作项的一列就是一条规则
    2、假设有n个条件,每个条件的取值有两个(0,1),全组合有2的n次方种规则

    3、步骤:

    ​ 1)、明确需求

    ​ 2)、画出判定表

    • 列出条件桩和动作桩
    • 填写条件项,对条件进行全组合3)、根据条件项的组合确定动作项
    • 简化、合并相似规则(有相同的动作)

    ​ 3)、根据规则编写测试用例

    4、案列一:

    image-20220215111953335

    应用场景:
    1、有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系
    2、判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
    3、提示:如果碰到项目中多条件组合大于4个相互依赖,可以使用
    (正交表和因果图来实现)
    

    4、因果图

    输入很多,并且不同的输入组合对应这不同的输出,这个时候用因果图法来分析不同输入组合和输出之间的对应关系。(相当于逻辑图)

    逻辑关系:恒等 与 或 非

    image-20220110195249867

    因果图法设计测试用例的步骤:

    1、分析出所有的输入和输出;

    2、找出输出和输出之间的关系;

    3、画因果图;

    4、画判定图;

    5、把判定表转换成测试用例;

    案例:淘宝618活动,订单满300,或者有红包,测提交订单后享受优惠。

    1、输入和输出

    输入:金额<300,金额>300, 金额==300,有红包,无红包,提交订单

    输出:享受优惠,不享受优惠

    2、输入和输出之间的关系:

    • 订单已提交,金额大于等于300 ,无红包,享受优惠;
    • 订单已提交,金额大于等于300 ,有红包,享受优惠;
    • 订单已提交,金额小于300,有红包,享受优惠;
    • 订单已提交,金额小于300,无红包,无优惠;
    • 订单没有提交,无优惠;

    3、画因果图:

    image-20220110201624623

    4、根据因果图画判定表。

    image-20220110205150297

    5、场景设计法 ☆

    现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,是测试
    用例更容易理解和执行。

    典型的应用是是用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功能细节忽视业务流程要点的错误倾向.

    • 案例:

    ATM机取款场景

    功能点:插卡——输入密码——输入钱数——取款(主要功能,核心流程)

    具体功能点:

    (1)、插卡:插反,插错卡(饭卡,会员卡,不是本行卡),注销,消磁,冻结,有不良记录的卡

    (2)、输入密码:密码错误,密码输入正确,密码三次错误,第一次密码错第二次密码对,前两次密码错第三次密码对

    (3)、输入钱数:钱数<=银行卡余额,输入钱数>=银行卡余额,输入的不是整百,ATM机余额不足,超过每日取款限额,超过每次取款最大上限,超过每次取款最大次数。

    (4)、取款:确认取款钱数后,ATM机吐出对应钱数;ATM机吐钞规则,操作超时,长时间不吐钱;

    (5)、其他:ATM机断网,断电,出现故障;超时,所有的操作如果超时,那么会出现吞卡(安全机制)

    每个具体功能点都是可以写测试用例的。

    如:1、插卡插反:第二次重新插入正确插入,仍可以正常取钱;卡冻结/注销,无法正常取钱;

    ​ 2、输入三次密码错误,账户冻结,无法取款;前两次密码错第三次密码对,仍可以正常取钱

    • 测试用例:

    image-20220215121219113

    6、错误猜测法

    根据测试人员的直觉,知识,经验,判断软件的那一块有问题,专门针对性的设计测试用例,适合作为一种补充设计测试用例的方法。

    如:1、验证码大小写不区分;

    ​ 2、空格搜索,把输入的搜索信息前后空格忽略;

    7、正交排列

    研究多因素多水平的一种方法,根据正交性选出最优的水平组合进行实验,用实验的结果来分析这个测试用例的结果。(选择最优的组合)

    因素:输入的变量;

    水平:因素的取值;

    因素数:变量的个数;

    水平数:变量取值的最大个数;

    正交表的性质:

    1、每一列不同数据出现的次数一样多;

    2、任意两列各数据组合出现的次数一样多;

    image-20220110221335796

    正交表设计测试用例的步骤:

    1、找出所有的输入变量(因素),确定因素数;

    2、确定变量的取值,确定水平数;

    3、确定正交表的行和列;

    4、根据正交表的性质去填写正交表

    5、把正交表的每一行对应写成一个测试用例;

    6、补充你认为重要的但没有体现在正交表中的测试用例;

    例子:姓名,邮箱,密码,确认密码,验证码(输入和不输入)——不用正交表要列出2^5=32情况

    1、因素:5

    2、水平数:2(输入和不输入)

    3、行:(水平数-1)*因素数+1=6

    ​ 列:因素数:5

    4、填写正交表

    image-20220110223037980

    5、测试用例:

    (1)、姓名输入,邮箱不输入,密码输入,确认密码输入,验证码不输入;

    (2)、姓名输入,邮箱输入,密码不输入,确认密码不输入,验证码输入;

    (3)、姓名输入,邮箱输入,密码输入,确认密码不输入,验证码不输入;

    (4)、姓名不输入,邮箱不输入,密码不输入,确认密码输入,验证码输入;

    (5)、姓名输不不入,邮箱输入,密码输入,确认密码输入,验证码输入;

    (6)、姓名不输入,邮箱输入,密码不输入,确认密码不输入,验证码不输入;

    三、实际操作中注意的点

    3.1测试用例的注意点

    image-20220212211347313

    作用:方便评审,方便执行
    1、用例标题:预期结果(测试点)
    2、验证码测试点:为空,正确,错误,过期
    3、前置条件和测试步骤,测试步骤是按前置条件后进行的,要么前置条件写的多,要么测试步骤写的多。
    

    合格测试用例标题:

    image-20220212212136181

    四、缺陷介绍

    软件中使用中任何问题都为缺陷,简称:bug

    1、缺陷的判定标准

    • 软件为实现需求(规格)说明书中明确要求的功能 — 少功能
    • 软件出现了需求(规格)说明书中致命不应该出现的错误 —功能错误
    • 软件实现的功能超出需求(规格)说明书指明的范围 —多功能 (例:理发店)
    • 软件未实现需求(规格)说明书中虽然为明确指明但应该实现的要求—隐形功能错误 (例:手机点餐,显示有哪些菜)
    • 测试人员认为软件难以理解,不易使用,运行缓慢,用户体验不好 —不易使用

    2、缺陷产生的原因:

    image-20220212152748622

    是软件就有缺陷!!!!!!

    3、软件缺陷的核心内容

    image-20220212160436183

    image-20220212161010041

    4、缺陷类型

    • 功能错误
    • 界面(Ui)错误 ,兼容性 (前端)
    • 数据,易用性,改进建议,架构
    1、如何区分是前端bug还是后端bug
    1)、如果是界面和兼容性问题——前端问题
    2)、如果是功能错误,需要 抓包 查看请求和响应!
    
    • 扩展:什么是抓包

    image-20220213163149180

    5、缺陷编写

    1、缺陷报告示例:

    image-20220212202318168

    2、缺陷的跟踪流程

    image-20220212203125572

    面试题:发现bug后,首先会怎么办? ——确认bug可复现。

    5.1缺陷练习

    错误示范:

    image-20220212212231694

    1、缺陷Id:使用了用例id
    2、标题:操作数据描述+预期+实际
    		测试数据结果描述+实际结果+预期
    		测试数据结果描述+实际结果+需求
    3、缺陷描述:操作步骤+数据
    
    • 正确示范:

    image-20220215123649487

    缺陷标题实例:

    1、测试数据描述+实际结果+预期:

    • 不合格的4位qq验证合格(预期:不合格)
    • 空密码登录成功(预期:登录失败,提示密码不可为空)

    2、测试数据结果描述+预期+实际

    • 验证4位qq不合格(实际:合格)
    • 验证空密码登录不成功(实际:登录成功)

    3、测试数据描述+实际结果+需求

    • 不合格的4位qq验证合格(需求:6-10自然数)
    • 空密码登录成功(需求:密码位6-12位数字+字母)

    以上三个模板都是可以套用的。


    ​ 以上就是软件测试用例的全部方法,重点掌握等价类,边界值,判定表,场景设计法,因为这四个是实际运用的多的,因果图和正交排列可以看看,知道下概念,写测试用例的时候尤其注意标题,标题可能影响你测试用例的好还,缺陷用例也是一样。铁汁们,觉得笔者写的不错的可以点个赞哟❤🧡💛💚💙💜🤎🖤🤍💟,收藏关注呗,你们支持就是我写博客最大的动力!!!!

    展开全文
  • UI测试,功能测试(手动),接口测试(fiddler httpwatch,后来发现接口需要设置权限令牌二次开发,普通人测不了),性能测试(loadrunner)
  • 目前,面向对象软件测试用例的设计方法,还处于研究、发展阶段。与传统软件测试(测试用例的设计由软件的输入?处理?输出视图或单个模块的算法细节驱动)不同,面向对象测试关  目前,面向对象软件测试用例的设计...
  • 测试用例设计是软件测试的执行的基础!虽然我们都认为,有效的测试计划是指导测试用例设计、测试执行的指导性文件,是成功测试的前提和必要条件,测试用例设计是测试工作的核心,测试用例的成功设计已经完成了一半的...
  • 什么样的测试用例是好的测试用例软件测试1、用例覆盖程度毫无疑问,这一点应该是最重要的,无需多说,覆盖率最大化是一套测试用例的最重要评价标准,如果漏测就杯具了。2、用例是否已经达到工作量最小化在满足用例...
  • 测试用例设计的最基本要求:覆盖住所要测试的功能。这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、...
  • 软件测试用例设计

    2021-03-23 15:10:58
    测试用例目前没有经典的定义,比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档...
  • 比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案  测试用例(TestCase)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求...
  • 软件测试用例设计之等价类划分方法软件测试一.方法简介1.定义是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒...
  • 软件测试用例编写的要点总结软件测试在工作中我们常常是对自己写的用例执行的得心应手,但是执行别人的用例却不知所措。因此测试用例的可读性、可操作性变得非常重要。我们需要的是一看到测试用例,就知道它是测试...
  • 软件测试中编写有效的测试用例及其如何进行用例评审的方法测试的指导文档就是测试用例,不光是保证产品的基本武器,同时也是测试人员的主要输入成果,因此保证测试用例的有效性及时时性就显得尤为重要。...
  • 软件测试用例之性能测试用例 软件测试 性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称,估计很少有人能准确的区分并说出定义来,至于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 160,555
精华内容 64,222
关键字:

测试用例软件

友情链接: lstm.zip