测试用例的设计方法

本文介绍了测试用例设计的总体方法,强调基于需求的设计,包括验证需求、黑盒测试等。并详细讲解了等价类、边界值、因果图、正交排列、场景设计法和错误猜测法等具体设计方法,提供了实际案例来辅助理解。同时,讨论了测试用例的有效性和粒度评价,强调了评审在确保测试用例正确性中的作用。
摘要由CSDN通过智能技术生成

1.测试用例的总体设计方法

  • 总体思想:基于需求的设计

  • 难点:看出需求以外的测试点。

  • 如何设计基于需求的设计测试用例的方法?
    (1)验证需求是否正确、完整、无二义性,并且逻辑一致。
    (2)要从“黑盒”的角度(只考虑输入输出),设计出充分并且必要的测试集,以保证设计和代码都能完全符合需求。

案例:

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

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

测试用例
                1-1、未收到邮件,登录时输入电子邮件及密码后,再次发送激活邮件
                1-2、已收到邮件,登录时输入电子邮件及密码后,不发送激活邮件
                2-1、收到邮件,24小时内进行激活
                2-2、收到邮件,24小时后链接过期进行激活。
                2-3、收到邮件,已激活,24小时后链接过期,再次点击激活?
                页面检查:
                      1、收到激活邮件
                      2、邮件内容正确
                      3、激活URl正确,可激活
                      4、再次激活提示已激活
                      5、过期激活提示已过期

2.具体的设计方法(黑盒测试方法)

2.1 等价类

  • 思想减少测试用例,解决输入无穷的问题(用较少的测试用例达到尽量多的功能覆盖)。

  • 使用场景:输入无穷。

  • 概念:把无穷的输入(特殊情况才考虑输出)划分成若干个等价类,然后从类里面提取一个数据进行测试,只要这一个数据测试通过,则我们就认为它所在的这一类数据全部测试通过。

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

  • 无效等价类:针对系统输入或者需求没有意义的数据。根据需求说明书,不满足需求的集合。

  • 注意:有效等价类和无效等价类都需要测试

网易邮箱账户注册:账户为6-18字符,可以使用字母、数字、下划线。
有效等价类:1.6-18个字母
                      2.6-18个数字
                      3.6-18个下划线
                      4.6-18个字母、数字
                      5.6-18个字母、下划线
                      6.6-18个数字、下划线
                      7.6-18个数字、字母、下划线
无效等价类:1.小于6个字符的数字(字母,下划线)
                      2.大于18个字符的数字(字母,下划线)
                      ……

对手机号位数划分等价类,能划分成几个?三个
有效等价类:11
无效等价类:小于11   大于11

2.2 边界值

  • 思想:针对输入或输出的边界进行测试用例的设计。

  • 使用场景:输入和输出的“边界值”。

  • 边界值是等价类的补充方法,一般它们成对出现

  • 取值规则:闭区间向外取值,开区间向内取值
    eg1:[1,50] 取值:0,1,50,51
    eg2:(1,50] 取值:1,2,50,51

2.3 因果图

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

  • 使用场景:输入(原因)和输出(结果)之间的关系。输出依赖于输入(多个)

  • 因果图中的与或非如何表示?

  1. 恒等:
    在这里插入图片描述
  2. 与:
    在这里插入图片描述
  3. 或:
    在这里插入图片描述
  4. 非:
    在这里插入图片描述
  • 因果图法设计测试用例的步骤:
    (1)分析所有可能的输入和可能的输出。
    (2)找出输入与输出之间的对应关系。
    (3)画出因果图
    (4)把因果图转换成判定表。(判定表的列数计算出来的)
    (5)把判定表对应到每一个测试用例。

案例:淘宝618活动,订单已提交,订单合计金额大于300元或有红包,则进优惠。
(一) 分析所有可能的输入和可能的输出
       输入:订单已提交(未提交),订单金额大于300(小于300),有红包(无红包)
       输出:优惠,不优惠
(二) 输入与输出之间的对应关系
       (1)订单已提交,订单金额大于300元,则优惠。
       (2)订单已提交,订单金额小于等于300元,无红包,不优惠
       (3)订单已提交,有红包,则优惠。
       (4)订单已提交,订单金额大于300元,有红包,则优惠。
       (5)订单未提交,不优惠。
(三) 因果图
       在这里插入图片描述
(四) 画判定表,有3个条件,输出有2个取值,所以表的列数为2x2x2=8
       在这里插入图片描述
注:以上8个测试用例都需要测试

2.4 正交排列

  • 设计理念:正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法,它是根据正交性,由试验因素的全部水平组合中挑选出部分有代表性的点进行试验,通过对这部分试验结果的分析了解全面试验的情况,找出最优的水平组合。
  • 原理:根据正交性,选出输入的最优组合进行测试,通过分析这些测试结果,以分析整个实验结果。
  • 目的:是为了减少用例数目
  • 思想:正交表(抽样) 。
  • 两条性质
    1.所有列中的数据的个数相同 ,即每一列中各个数据出现次数一样多。
    2.任何两列中的有序对数相同,即任何两列中各有序对数出现次数一样多。
  • 因素:测试中,需要考察的变量。
    水平:(一个)变量的取值。
  • 正交表的表示形式:L=行数(水平数*因素数) ,即L=N(TC)
    1.行数(Runs):正交表中的行的个数,即试验的次数,用N代表,N=(T-1)*C+1 (注意:算出来的是最小试验次数 )。
    2.因素数(Factors):正交表中列的个数,用C代表。
    3.水平数(Levels):任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到“水平数-1”或从1到“水平数”,用T代表。
  • 正交法设计测试用例的步骤:
    (1)有哪些因素(变量)
    (2)每个因素有哪几个水平(变量的取值)
    (3)选择一个合适的正交表
    (4)把变量的值映射到表中
    (5)把每一行的各因素水平的组合作为一个测试用例
    (6)加上你认为可疑且没有在表中出现的用例组合

案例:网易邮箱注册,姓名、邮箱、密码、确认密码、验证码必须全部输入,才能进行注册。
1、因素:姓名、邮箱、密码、确认密码、验证码,因素数C=5
2、水平:填写、不填写,水平数T=2
3、行数N = (T-1)*C+1 = (2-1)*5+1 = 6
      正交表的表示形式L = N(TC) = 6(25)
      选择正交表,这里选择了L6_2_5。正交表不是随便选择的,而是设计好的。
4、生成测试用例
      在这里插入图片描述
5、增补测试用例
姓名、邮箱、密码、确认密码、验证码都不填写

如果不使用正交排列, 2 * 2 * 2 * 2 * 2 = 32 个测试用例,使用正交排列大大减少了测试用例的个数。

2.5 场景设计法

  • 设计理念:现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。
  • 场景:事件触发来控制流程的,事件触发时的情景便形成了场景。
  • 事件流:同一事件不同的触发顺序和处理结果就形成事件流。
  • 场景事件法 :业务流程(一个业务流程不一定是一个场景),事件流。
  • 典型的应用:用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功能细节忽视业务流程要点的错误倾向。
  • 难点:对需求很了解。

eg: 写出场景?
在这里插入图片描述
分析:一个入口 三个出口
场景:(未列举完)
备选流1->备选流3->备选流4
备选流3->结束用例
备选流3->备选流1->备选流2

案例:银行ATM取款流程(插卡-----输入密码-----输入取款金额-----取钱-----退卡)
基本流程:插卡成功,输入密码正确,输入取款金额合理,出钞取钱成功,退卡成功
备选流:1. 插卡失败(卡芯片损坏,卡识别不出来)
               2.身份证过期
               3.连续输入三次密码错误,账户锁定
               4.前两次输入失败,第三次输入正确,输入取款金额合理,出钞取钱成功,退卡成功
               5.输入取款金额大于银行卡余额
               6.输入取款金额不是100的倍数
               7.输入取款金额大于单日银行规定ATM取款上限
               8.ATM机钱数不足
               9.断网

2.6 错误猜测法

  • 猜测的三个来源:
  1. 测试人员对项目测试的事件长,根据经验和直觉,有针对性地设计测试用例。
    1>功能、业务复杂度了解
    2>对研发人员的代码能力了解
  2. 根据用户反馈(线上、线下)。
  3. 缺陷(上市前的问题)、故障库(生产环境种的bug叫故障)。
  • eg:针对输入框的测试
    输入长度不够:错误推测法、等价类_无效
    注意:如果研发人员代码能力较差,则输入长度不够属于错误推测,不属于无效等价类。

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

  • 测试人员执行了测试用例,没有发现bug,则这条测试用例是有效的还是无效的?
    答:有效的。
  • 一条测试用例是否有效无效?
    答:看的是一条测试用例是否可执行,而不是一条测试用例是否发现bug。
  • 测试的目的?
    答:1. 验证是否有bug 2.验证是否符合用户需求

4.测试用例的粒度和评价

4.1 测试用例的粒度

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

4.2 测试用例的评价

  • 评审分为正式评审(有正式流程)和非正式评审
    1>同行评审
    2>用户检查
    3>项目组评审
  • 怎样才能确保你的测试用例的正确性?
    答:评审(同行评审、用户评审、项目组评审)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值