软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13367 人已学习
课程目录
已完结 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讲
登录|注册

07 | 如何高效填写软件缺陷报告?

茹炳晟 2018-07-13
在上一篇文章中,我为你介绍了测试覆盖率的概念,并重点介绍了代码覆盖率的应用价值以及局限性。今天我会为你介绍如何才能写出一份高效的软件缺陷报告。
测试工程师需要利用对需求的理解、高效的执行力以及严密的逻辑推理能力,迅速找出软件中的潜在缺陷,并以缺陷报告的形式递交给开发团队,这看起来是不是有点像侦探柯南呢。
缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁,也是测试工程师日常工作的重要输出。 作为优秀的测试工程师,最基本的一项技能就是,把发现的缺陷准确无歧义地表达清楚。
“准确无歧义地表达”意味着,开发工程师可以根据缺陷报告快速理解缺陷,并精确定位问题。同时,通过这个缺陷报告,开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。
可见,缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率,同时还会影响测试工程师的信用、测试与开发人员协作的有效性。
那么,如何才能写出一份高效的缺陷报告呢?或者说,一份好的缺陷报告需要包括哪些具体内容呢?
你可能觉得这并不是什么难事儿,毕竟软件企业通常都有缺陷管理系统,比如典型的 ALM(以前的 Quality Center)、JIRA、Bugzilla、BugFree 和 Mantis 等。当使用这类系统递交缺陷时,会自动生成模板,你只要按照其中的必填字段提供缺陷的详细信息就可以了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(40)

  • 丹丹兒🍥
    我公司的开发,很复杂的问题,我写了很详细的复线步骤,他不看,直接来叫我复线
    2018-07-13
    2
    56
  • Cynthia🌸
    优先级和严重程度那块,如果还是觉得太绕的话,我觉得还可以借用时间管理里面提到的 重要 和 紧急 的概念来进行解释。优先级 对应着 事情的紧急程度, 严重程度 对应着 事情的重要程度。
    这么来对应的话,理解了重要紧急,也就理解了优先级和严重程度了!
    2018-07-13
    23
  • 「」
    老师,我打算把52 讲写一些公开的读后感,不知道会不会影响您

    作者回复: 当然不会,非常支持你,技术很多东西就是需要大家一起讨论与交流,这样才能帮助到更多的人,期待你的读后感

    2018-07-15
    12
  • 双子
    个人觉得实际测试过程中bug经办人一栏也是一个问题所在,准确定位一个bug是该分配给前端后端还是客户也是测试需要注意的问题。
    2018-07-13
    12
  • 红娟
    首先,我觉得老师的缺陷格式很棒
    回答问题
    我的实践心得,我是在一家外企,一个项目通常是多个国家合作,一个bug也是,通常会涉及到很多沟通对象。我在jira系统里能看到各式各样的bug。最简单的就一句话,然后后面就跟随者各种conments,看时间记录,跨度几天几个星期都是正常的。严重的都有以月为单位。这是我看到的问题。这都是沟通成本啊😊,所以我在我们组内部规定一个模板。都按照模板来,标题,版本信息,环境描述,复现步骤,期望结果,出现问题的结果。严重程度,是否容易复现。还有系统的一些必填信息。
    2018-07-13
    8
  • 🦀Kevin Xiao🇨🇳
    是否应该还个缺陷类型呢?便于定期统计分析
    2018-07-16
    5
  • Uni
    还有一点很重要的,是要附上测试数据。
    2018-07-13
    5
  • 西海
    感觉老师讲的是how to report or create bugs,相比这个,我更想了解如何对一个阶段的bug进行统计、分析并报告

    作者回复: 您说的这种属于测试缺陷统计,bug趋势分析,bug收敛情况,bug模块分布,bug发现阶段统计等等,都属于面向管理层和质量流程保障团队的,这类报告通常不是人为去产生的,而是在现在缺陷报告的基础上通过统计得到的,往往都是直接利用缺陷管理系统的自带自带功能来生成这类报告。比如ALM,Jira都支持这类报告的产生。

    2018-07-16
    4
  • 尐爆蝦
    对一系列的操作步骤可以使用gif截图录屏
    2018-07-13
    4
  • 卫宣安
    作为主管研发的产品经理,一直都被bug标题太笼统所困扰,每次检索和分配bug都会耗费大量精力和时间。而这虽说有制定一些规范,但毕竟每个人的语义表达能力不一,的确很难达到一个比较高的水准。所以我在尝试将bug分配方式改成由bug对应研发主动认领的方式,去除中心点,但这要求每个研发有足够的责任心,以及相关奖惩制度来把控。
    2018-07-13
    1
    3
  • Kola
    目前我公司用的缺陷管理系统是tapd,好用便捷效率高,推荐!
    2018-11-16
    1
    2
  • 晴天
    老师,你好,文章提到的有必要学习一门高级语言,您提到的这个高级语言都有哪些
    2018-07-14
    2
  • 小班
    文章中的“缺陷影响”和“优先级和严重程度”,缺陷影响主要应该写什么内容,麻烦举个例子。

    虽然文中有提到 缺陷影响决定了优先级和严重程度,但个人感觉这两者在报告中写得有点重复。难道缺陷影响要给开发列举什么情况下会发生这样的事,然后产生什么影响?

    最后,总结里的“根原因分析”有错别字。
    2018-07-14
    1
    2
  • 丹丹兒🍥
    感谢老师,
    我没系统上过测试课
    老师真的很系统地讲了
    2018-07-13
    2
  • hi !girl
    1. 出现的概率
    2. 附加信息,如log、录频等
    3. 适当增加对比性验证
    4. 对于新功能,易用性差或者不合理的地方,及早提出,加入讨论池---这一点,严格意义上不算bug,但是关乎到产品质量问题,对接的主要是产品相关人
    2018-07-13
    2
  • sylan215
    最近刚好要写一篇相关的文章,缺陷重现步骤这地方我补充一下:
    1.写必现步骤的时候,一定要用第三方的角度来面试,就是说其他人按照描述可以无脑操作,而不是带有很多隐含的自以为的潜规则;
    2.和必现步骤相关联的其他操作的结果,最好也写上去,方面开发确认具体的代码分支,和影响范围;
    3.UI 相关问题请务必附上贴图,对于描述不清的请务必附上操作视频,都可以更直接的体现问题,减少沟通成本;
    4.对于不固定重现的问题,一定要说明重现的概率,已经自己在其他环境重现的情况,方便开发决定是自己重现还是直接过来看现场;
    5.必要的问题,请务必附上程序的 dump 文件,方便开发直接分析问题;

    以上,欢迎沟通交流
    2019-02-12
    1
  • 碎碎念
    关于缺陷报告,我所用的方法是婵道,他有缺陷的模板,把那些需要的内容填进去就可以,可以大大提高缺陷报告的时间成本,和速度,步骤是:
    1,环境配置填好
    2,标题:版本-路径-缺员描述
    3,重现步骤:前置条件,操作步骤(重现步骤最好简短,明确,步骤有效)
    4,结果:如提交失败,原因是什么
    5,期望:提交成功
    6,截图:标记出错的位置和在截图上简洁描述原因
    2018-08-23
    1
  • 小琼😁
    直接使用Bug管理工具不是更方便吗?

    作者回复: 一定是使用bug管理工具的,但是你需要知道bug管理工具中的每个字段如何填写才是最好的

    2018-08-21
    1
  • yuxi
    实践中的几点补充:1.在标题中尽量按照模板提供产品、版本、发现阶段、是否线上同步、模块等信息,方便进行缺陷分析; 2.提单前尽量和开发确认,指定缺陷定位人; 3.所有有效问题必须有用例跟踪,最好自动化,有效防止复现
    2018-08-04
    1
  • 康美之心 淇水之情
    单元测试很容易追踪和统计分析覆盖率,但API功能测试,有没有一个标准或基础性的对所有API都适用的通用性场景分析和场景覆盖率统计(包括API的业务功能和非业务功能),API的覆盖分析虽然有4种high level的分类,但具体实践时,太因人而异了。
    2018-07-14
    1
收起评论
40
返回
顶部