软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13373 人已学习
课程目录
已完结 63 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”,我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗?从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例?
03 | 什么是单元测试?如何做好单元测试?
04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?
06 | 你真的懂测试覆盖率吗?
07 | 如何高效填写软件缺陷报告?
08 | 以终为始,如何才能做好测试计划?
09 | 软件测试工程师的核心竞争力是什么?
10 | 软件测试工程师需要掌握的非测试知识有哪些?
11 | 互联网产品的测试策略应该如何设计?
GUI自动化测试篇 (10讲)
12 | 从0到1:你的第一个GUI自动化测试
13 | 效率为王:脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象:让自动化测试脚本更好地描述业务
15 | 过不了的坎:聊聊GUI自动化过程中的测试数据
16 | 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?
17 | 精益求精:聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮:带你玩转GUI自动化的测试报告
19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进:浅谈移动应用测试方法与思路
21 | 移动测试神器:带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1:API测试怎么做?常用API测试工具简介
23 | 知其然知其所以然:聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐:微服务模式下API测试要怎么做?
代码测试篇 (3讲)
25 | 不破不立:掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器:后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器:前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)
33 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)
34 | 站在巨人的肩膀:企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据?
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台(上)
38 | 测试数据的“银弹”- 统一测试数据平台(下)
测试基础架构篇 (4讲)
39 | 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?
40 | 从小工到专家:聊聊测试执行环境的架构设计(上)
41 | 从小工到专家:聊聊测试执行环境的架构设计(下)
42 | 实战:大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能:探索式测试
44 | 测试先行:测试驱动开发(TDD)
45 | 打蛇打七寸:精准测试
46 | 安全第一:渗透测试
47 | 用机器设计测试用例:基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计?
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目,你都掌握了吗?
结束语 (1讲)
结束语 | 不是结束,而是开始
软件测试52讲
登录|注册

02 | 如何设计一个“好的”测试用例?

茹炳晟 2018-07-02
在上一篇文章中,我以“用户登录”这一简单直接的功能作为测试对象,为你介绍了如何设计测试用例。现在你应该已经知道,为了保证软件系统的质量,测试用例的设计不仅需要考虑功能性需求,还要考虑大量的非功能性需求。
那么,今天我会重点和你探讨如何才能设计出一个“好的”测试用例。

什么才算是“好的”测试用例?

在正式开始讨论之前,我先跟你聊聊,什么才是“好的”测试用例,这个“好”又应该体现在哪些方面。这是一个看似简单实则难以回答的问题,即使深入思考后,也很难有非常标准的答案。
通常,你的第一反应很可能会是“发现了软件缺陷的测试用例就是好的用例”,我可能会反问你“如果说测试用例发现了缺陷就是好用例,那么在该缺陷被修复后,同样的用例难道就不是好用例了吗?”。
你可能还会说“发现软件缺陷可能性大的测试用例就是好用例”,这话看起来还是蛮有道理的,但是我同样会反问你“你打算用什么方法来量化测试用例发现缺陷的可能性?”。
类似地,你可能还会说“发现至今未被发现的软件缺陷的测试用例就是好用例”,那么我想问你的是:如何评估是否还存在未被发现的缺陷?如果软件中根本就没有错误了呢?
其实,是你定义“好的”测试用例的思路错了,这就有点像“傻子吃烧饼”,连吃五个不饱,吃完第六个终于饱了,于是他说:早知道吃了第六个就会饱,何必吃前面五个呢。细想,他吃的六个烧饼其实是一个整体,一起吃下去才会饱,而你无法找到吃一个就能饱的“好”烧饼。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(78)

  • sylan215 置顶
    其实一直以来,我都是把宣称「能发现 Bug 的用例就是好用例」,在讨论用例有效性的时候,我也经常问别人一个问题「你的 Bug 里有多少是通过用例跑出来的」,现在想想,这些都只是针对当前需求修改点而言的用例,毕竟在有效的时间内,用例的有效性还是非常关键的,而且针对的是具体的用例而言。

    如果换个角度,从茹老师说的软件质量的角度看,确实不应该这么说,这时候覆盖面最全的用例集才是好的用例集,毕竟我们要保证的是软件的质量,那么所有可能出现质量问题的地方,都是应该有用例覆盖的。

    但如果是回归测试的话,我还是更推荐「能发现 Bug 的用例就是好用例」,毕竟规定了迭代时间的话,每次都全覆盖的回归,投入产出比有点吃不消。

    另外,关于全面性,我再补充一个对于互联网产品必须要考虑的一个测试点,就是需求的合理性,传统的测试,我们主要关注的是需求的详细程度以及实现细节,但是对于互联网产品,用户体验已经是一个绕不开的话题,也是商家必争之地了,所以在所有的需求和功能验证之前,建议增加一个「需求合理性测试」。

    以上,欢迎沟通交流,公众号「sylan215」

    作者回复: 非常棒的讨论,其实关于什么是好的用例并不存在严格的定义,最关键的是建立全方位以及多角度的思维模式。关于需求合理性性测试,我们有对应的UX就是用户体验测试,应该就是对应您说的这一点,很好的补充。

    2018-08-16
    29
  • 么西卡
    首先肯定是要保证用例覆盖全面。很多同学写用例就是直接把需求一段段的copy下来就成用例了。写用例重要的是对需求的分解和补充。能够加上自己的经验以及对产品的理解,覆盖各种显性和隐性。功能和非功能的需求。

      另外用例还要简洁清晰。你写的用例不仅仅是给你自己看的。要解决用例重复。描述冗余,层次结构混乱的问题。在这样快速迭代的敏捷开发节奏下。没有时间也没有必要把一条条用例写的那么复杂。重要的是把测试点写清楚。不是要把那些显而易见的步骤,环境,预期等写的那么尽善尽美。

        还有一个很重要的是用例的一个持续维护。测试用例的复用性也是其核心的价值,需求经常会有变更,用例也要跟上,另外很多问题要在实际测试的过程中才暴露出来。一定要及时对用例进行补充和完善,发现一些需求的漏洞,并总结反思自己考虑不周的地方,每个人都有自己的盲点,要多沟通

    作者回复: 非常棒的总结,很到位!厉害👍厉害👍

    2018-07-03
    47
  • 阿廉
    1:老师 我上星期由开发转测试 想问一下 您的课程会讲测试用例如何写的吗 ?
    2:你讲的对于我来说偏经验和概念 我连测试案例如何写都不会
    3:或者老师你可以给我推荐一个更基础的测试学习课程或者网站吗 老师老师谢谢您
    2018-07-02
    3
    21
  • wangq
    文中很多方法在平时的工作中不谋而合,也是一直强调的。另外,即使是黑盒测试,在测试过程中,与需求确认业务规则,与开发了解代码逻辑,业务规则是准则,代码逻辑是参考,但很多测试人员容易犯的就是跟开发人员确认业务规则

    作者回复: 你说得非常正确👍

    2018-07-11
    18
  • 双子
    分享一些个人的想法,首先补充一个角度从用户体验出发完善测试用例,例如一些UI交互设计、push短信发送节点、banner按钮位置、不同客户端的手势快捷操作习惯等,测试人员应该是比产品和开发更了解用户使用习惯的。其次,我觉得测试不仅不能依赖开发也不能过分依赖产品,测试人员应该是对全线产品逻辑细节最熟知的,需求设计的业务漏洞也需要测试来把控,所以需求评审的过程中测试人员就应该能凭经验构思出初步的测试策略并推测出常见错误予以提醒避免开发阶段浪费时间。再次测试用例的后期归档整理也属于测试人员需要注意的事项,系统科学的整理用例有利于后期的阶段性回归测试,可以减少在编写测试用例上浪费不必要的时间。

    作者回复: 非常棒的分享👍 你说的这几个点我都非常同意

    2018-07-02
    1
    15
  • 刘斌宇
    在快速迭代的互联网环境下,我们公司测试用例都是采取xmind思维导图的形式。对于移动端来说常见的如安装卸载,版本兼容等常见测试思路可单独提取出来。

    作者回复: 是的,列出测试点,我们也经常使用思维导图,我自己用的也是xmind

    2018-07-02
    14
  • 小志
    文章从事前的角度阐述和衡量“好”的概念很系统。大部分项目受限于时间和人力成本,很难完全从覆盖率提升上评估case的“好”。所以另一种思路是从事后的角度,从漏测率和问题严重程度上来评估。漏测率和覆盖率相折中,形成一定的测试策略,最后形成好的case

    作者回复: 非常有启发性的观点,感谢和大家分享👍

    2018-07-02
    11
  • 玉楼人
    老师,请问数据库连接方式,缓存分级是如何影响功能的?我们如何设计测试用例呢?能举例说明吗?迫切想知道具体操作。谢谢。
    2018-07-18
    9
  • 小星星
    请教怎么深入理解软件的设计架构?

    作者回复: 首先我觉得先要想明白作为测试为什么要了解软件架构,然后才能有所侧重的去了解和测试密切相关的架构。

    2018-07-02
    6
  • arthur
    感谢老师非常棒的分享,我也非常赞同老师说的需要对被测软件的架构和实现细节有很好的理解,这样能更好的进行测试用例的设计。但是对架构和实现细节的理解需要有开发的知识。平时测试工作量很大的情况下,怎样才能提高技术,去了解软件背后的架构和实现方式呢?老师有木有什么好的建议?

    作者回复: 测试前置,也就是测试人员去参加系统设计的review会议,一方面可以了解被测系统的架构设计和实现细节,另一方面可以向开发突出可测试性需求

    2018-07-03
    5
  • Kola
    测试是一场考验耐力的运动,必须坚持到上线前最后一秒,无痛上线是测试人员毕生的追求,但是再好的测试用例也跟不上日新月异的需求,所以上线前临时改的需求必须予以极大关注并且争取更多的时间,用最快时间评估改动可能涉及的影响点;最后,千万不能让开发跳开测试,总之一句话,可以没有测试人员 但是不能没有测试!

    作者回复: 很棒

    2018-07-30
    4
  • 胜杰
    @阿廉,测试用例的编写没有固定样式,但大体上是由测试点、测试步骤、期望结果、实际结果等部分构成的。到网上找几份来看看就知道了。

    作者回复: 嗯嗯,很好的建议

    2018-07-02
    4
  • keven
    看到老师写的很棒,还有很棒的留言,从这也看出对于用例每个人都有自己的思路和方法,说下个人方法,一个是对需求的理解,要有场景化,对于业务的理解,要有出入口,从哪里来到哪里去,全面覆盖。对于功能,考虑功能本身的实现,考虑关联功能的实现,考虑功能存在哪些状态,每种状态都有哪些场景可互相转换,这是我写用例的习惯
    2018-07-16
    3
  • 天天开心
    Web Service 的 API 测试,需要考虑被测 API 所依赖的第三方 API 出错下的处理逻辑;对于这句话,我想询问老师,被测试的API接口需要包装第三方API出错的信息吗?还是直接把第三方API出错的信息抛出来呢?
    2018-09-25
    2
  • 才子
    结合自己的理解,测试的目的是对产品质量的验证,随着现在的敏捷开发,测试已经转变为质量的提升的推动者。好的用例是用来进行质量守护的,发现bug的多与少不是衡量测试用例的主要标准,衡量测试用例的主要标准是需求的覆盖,功能性需求和非功能性需求。但是需求覆盖率高,意味着编写时间长,现在快速迭代的情况下,测试人员要把握好覆盖率和编写效率的平衡。
    2018-08-09
    2
  • 任大树
    我最近用到的一个经验:先根据需求和用户使用方式整理出一份用例初稿,然后找出需求中几个重要节点(时间允许的范围内越多越好),针对这些节点 请教开发他的实现逻辑(如根据那些数据库表 的哪些字段 做哪些判断等),此判断逻辑对哪些场景会有关系,针对这些场景进行发散,看看自己的用例中有没有遗漏的,会有意想不到的收获哦
    2018-08-01
    2
  • Cynthia🌸
    文中所阐述的缺陷知识库这一条,个人觉得很有意义。虽然最终目的都是一致的,但是对于不同规模的企业,考虑到具体的投入产出比,会有不同的工程实践形式:建立wiki页面,或者作为自动生成测试数据的输入来源。
    2018-07-14
    2
  • 红娟
    我的测试用例一般分为几个阶段
    1:一般基础阶段,软件实现了什么功能,测试用例一般是围绕功能或者需求来
    2:边界值,异常值阶段。测试用例围绕在什么条件,不会怎么样?边界值之类,异常之类的测试用例。还有一些场景组合测试用例
    3:压力测试阶段,如果以上两类测试用例都通过了,那么考虑压力测试用例。比如说长期运行,高频运行等等。
    这三类测试用例都通过了,一般软件的质量还是有一定的保证

    作者回复: 非常棒👍

    2018-07-04
    2
  • kilyun
    老师,您好,请教下怎么让设计和执行测试用例的过程更高效,当前我公司主要依据excel模版来录入测试用例是比较耗时的,在执行用例时也不方便使用,可维护性比较弱。

    作者回复: 这个取决于你们的用例形式,如果你们是大量的数据驱动测试,那么excel还是比较高效的做法,而如果都是大量操作的用例,那excel就有点不好用了。一般的企业通常会有用例管理系统,有些用例管理系统还可以直接发起测试。比如testlink,ALM之类的系统

    2018-07-03
    2
  • yiluo
    看到老师写的什么是好的测试用例,想到另外一个角度,就是测试用例可以完整地评价软件的质量。测完了可以知道真实的软件质量,是否可以发布

    作者回复: 很不错的见解👍

    2018-07-02
    2
收起评论
78
返回
顶部