软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?

宝玉 2019-05-16
你好,我是宝玉。十多年前,当我还是个野路子程序员时,我在外面接私活做项目,客户在使用过程中遇到了 Bug,直接就截个图,或者是用 Word 文档整理在一起,从 QQ 或者邮件上把 Bug 信息发送给我,我收到后再修复更新上线。
而现在正规的软件项目已经不会再用这种原始的方式来报 Bug 了,而是会借助测试工具来帮助报告和跟踪 Bug,即使你偶尔能看到有项目还在采用原始方式报 Bug,你肯定也会觉得这样做不专业。
但不知道你有没有仔细想过这个问题,为什么现在不通过 QQ/ 微信 / 邮件报 Bug,又有哪些测试工具可以帮助你更好地发现、报告和跟踪软件中的 Bug 呢?今天我们会展开讨论这个问题。

Bug 跟踪工具

我想你对与 Bug 这个词一定不陌生,它是我们软件中的缺陷或错误。这个词的诞生也很有意思。
1947 年 9 月 9 日,一只小飞蛾钻进了哈佛大学的一台计算机电路里,导致系统无法工作,操作员把飞蛾贴在计算机日志上,写下了“首个发现 Bug 的实际案例”。
(图片来源:WikiPedia《Software bug》)
虽然 Bug 的历史已经有 60 多年了,然而 Bug 跟踪工具却没有出现太久。软件项目中最早也是通过邮件、即时通讯等原始方式报告 Bug,直到 1992 年才有第一个专业的 Bug 跟踪软件GNATS
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 果然如此
    对于自动化测试一直有些疑问,如果每次发布都对所有方法自动化测试:
    1. 一定会耗费很多时间;
    2. 数据库产生很多测试历史数据;
    3. 写测试用例能达到覆盖率高的写代码技巧,如边界测试代码、幂等测试代码如何实现。

    作者回复: 1.自动化测试确实会耗费很多时间
    自动化测试代码通常是金字塔结构:
    单元测试(小型测试)代码最多,执行也最快,占总比例的70%左右,通常1分钟内
    集成测试(中型测试)代码其次,执行比较快,占比20%左右,控制在10分钟以内
    端对端测试(大型测试)最少,执行慢,占比10%左右
    一般CI里面跑单元测试和集成测试,耗时10-15分钟左右,其实还可以接收。

    2. 跑自动化测试,数据库有不同策略
    单元测试不访问数据库,完全模拟
    集成测试只访问本机数据库,或者模拟的内存数据库,每次创建新数据库,或者使用完清空数据库
    端对端测试,每次创建唯一数据(例如增加固定数据+时间戳),连接真实的测试环境,可以不清理数据

    3. 高覆盖率的关键在于在写代码就注意让代码方便的被测试。也不必过于追求100%覆盖,70%以上我觉得就不错了。

    2019-05-17
    5
  • kirogiyi
    在集中办公的时候,很多人喜欢用微信/QQ去聊工作上的事情,一会儿@这个,一会儿@那个,一些重要的信息很快就被淹没了,很难去挑出对自己有用的信息。对于这种情况,我一般很少去理会别人发了什么信息,也不会随时在电脑上开着微信/QQ等着闪亮的出现,要么通过各种管理工具沟通(邮件、Bugfree、Jira等等),要么当面或电话沟通,这样问题才能得到有效的、高效的解决。但在这样做之前,我会在合适的场合说出这样做的原因和相应的解决办法,避免让他人误解。

    作者回复: 确实,这样的频繁打扰特别影响效率。

    不过我在用了Slack之后,还是改变了看法,觉得从沟通的角度看,尤其是异地办公。

    沟通很及时,跟当面沟通一样

    通过Channel可以对消息进行区分和过滤

    通过Thread可以展开讨论以及避免对不想干人员的打扰

    2019-05-16
    4
  • 宝宝太喜欢极客时间了
    老师,对测试这块一直很疑惑,测试脚本、测试用例、测试数据这三者如何配合一起通过CI进行自动化测试?

    作者回复: 是这样的,CI本质上只是一个像流水线传送带,你的代码提交了,流水线传送带开始工作,你可以在传送带上面添加任务。

    简单来说,你可以想象成CI的一个任务启动后,给你一个干净的虚机(实际是运行Docker Container),然后帮你把当前代码下载下来,帮助你配置好运行环境,然后你就可以在里面安装任何软件、服务和运行任何脚本。

    举例来说,你可以在传送带上增加以下任务:
    1. 安装所有的依赖包
    2. 运行模拟服务(比如一个内存数据库)
    3. 运行单元测试
    4. 运行集成测试

    如果上面所有任务都成功了,那么这一次的CI任务就成功了,其中一个失败这一次的CI任务就失败了,然后你就要检查什么原因导致的,然后修复再重新执行,保障CI任务成功执行位置。

    2019-05-16
    3
  • 谢禾急文
    看到这篇文章,我想到了我之前的一个想法,就是通过用一个工具记录我自己开发过程中遇到的所有bug,通过记录、分析、反思这些bug,能够有助于提升我的编程能力,有助于避免犯同样的错误。我觉得你上面说的那些工具,能够满足我的需求。如果有一个网站,能够提供bug记录、分享、解答的工能,是不是能够满足某些用户的需求(好像stackoverflow就是这样的工具)。

    作者回复: 我觉得是有帮助,但这个问题的关键在于分析反思Bug。

    自己对自己Bug的反思才是价值最大的,其他人看过之后不一定能有那么大的共鸣,因为一个Bug都有复杂的业务背景,是很难被记录,缺少上下文也很难理解。

    StackOverflow是很有价值的,因为它是从问题切入,而问题是有很多共性的,很容易引起共鸣。

    2019-06-16
    2
  • 一路向北
    用qq和微信等作为bug管理,与其说是用它来做管理,不如说是用它做驱动。很多问题是在客户那边发现,因此他们第一反馈就是即时通讯工具反馈,我们也就根据这个来解决bug问题。
    对于小公司(10来个人)来说,管理一套系统和维护一个流程,总觉得需要付出比较大的代价,是不是这样呢?以前试过禅道,用了一段时间之后也放弃了。需要专门的人员来维护推动。

    作者回复: QQ作为Bug反馈是没有问题的,但是无法有效对Bug跟踪,另外效率太低。及时是通过QQ报的Bug,也应该重新录入到Bug跟踪系统,进行管理和跟踪。

    自己维护一套Bug和任务跟踪系统成本是有点高,建议直接使用在线托管的,Gitlab、GitHub、腾讯、阿里云、Coding、微软都有现成的,小团队的话价钱也不高。

    2019-05-18
    2
  • 宝宝太喜欢极客时间了
    老师,测试用例英文test case为什么叫测试用例而不叫测试例呢?有没有test use case一说?

    作者回复: 抱歉这个问题我真不知道,test case的翻译也算是约定俗成的吧。

    test use case我也没见过🤦‍♂️

    2019-05-17
    1
  • 服务端通过编写单元测试没啥问题,app方面好像少不了人工测试,现在测试人员主要覆盖app测试,并且每个迭代测试时间比较长,上线后问题还不少。app测试如何更好引入自动化测试?

    作者回复: 可以试试App的自动化测试框架,比如说appuim、katalon。

    2019-05-16
    1
  • yasuoyuhao
    程式碼就像程序員的名片,要對寫出來的代碼負責,最好的負責方式就是寫測試代碼,讓每次代碼變動,都不會影響到其他代碼的運行,避免所謂的改 A 壞 B,節省迂迴的時間浪費。也為 CI/CD 做好準備,無論目前有沒有。

    程序員不想寫測試在我們公司的原因大多是,不知道怎麼開始寫,不知道重點應該測試什麼。先寫測試的開發模式讓他們覺得不習慣,但這些都是過程,培養良好的撰寫測試代碼習慣後,開發品質更有保證,提升開發效率,提升個人能力,我想都是有幫助的。

    程序難免有 Bug ,透過追蹤軟件,良好的管控 Bug 數量與修復進度,並且補足測試。

    作者回复: 👍謝謝你的精彩分享

    2019-05-16
    1
  • 邢爱明
    自动化测试,个人理解最大的困难是开发人员的心理和认知,理解测试工作不只是测试人员的职责,开发人员应对软件的交付质量负起更大的职责。

    作者回复: 像开发写自动化测试这样的事,一方面要提高开发人员的认知,另一方面还必须要有一些规章制度强制要求执行。

    2019-05-16
    1
  • 小老鼠
    1、软件测试不仅仅是发现Bug,另外更重要的是预防Bug,还有为领导者作决策。2、DevOps 中测试还可以左移(预防)和右移(在生产环境中测试)。3、测试工具不是银弹,作为一名优秀的测试工程师,主力应该在分析与设计测试用例。

    作者回复: 👍赞总结。
    帮你补充一条:
    4. 自动化测试很重要

    2019-10-02
    1
  • จุ๊บ🇸
    目前java 主流的测试工具有哪些,比较稳定的,测试web及测试接口

    作者回复: 一般都是自己写框架,基于TestNG + Selenium,应该也有很多其他的选择,但是抱歉我对Java了解不多,建议可以问问其他人或者通过搜索引擎搜索一下。

    2019-06-27
收起评论
11
返回
顶部