为什么要使用 Bug 跟踪工具?
用 QQ 或者邮件报 Bug 的这种方式,看起来快捷简单,但是问题很多:
- Bug 不能有效被跟踪,不知道一个 Bug 是不是已经被修复了;
- 效率很低,开发人员频繁的被这样的报 Bug 的消息打断,不得不停下手头的工作去甄别Bug;
- 不能直观的了解当前项目的 Bug 状态,比如说:修复了多少,还有多少没有修复,近期Bug 数量是增加了还是减少了。
不难看出,通过 QQ 等方式报告的 Bug,都是文字配合图片等信息,很难检索和分类,而Bug 跟踪工具,采用结构化的数据来定义 Bug,每一个 Bug 都有一些关键的信息可以对Bug 进行分类和检索。
在 Bug 跟踪工具使用中,一个基本的 Bug 信息包括:
- 标题;
- 描述(包括期望结果、实际结果和重现步骤等关键信息);
- 优先级;
- 指派人;
- 状态(New、Open、 Rejected、Fixed 等);
- 其他。
那这样的话,就很容易的对 Bug 进行分类和检索,比如说:
- 张三想查看所有分配给他的 Bug,那只要列出所有指派人是张三的 Bug;
- 想列出所有未解决的 Bug,只要列出所有状态不是 Close 或 Rejected 的 Bug 即可。
这样对于开发人员来说,可以直观的看到自己有哪些 Bug 需要处理,Bug 的描述信息也可以帮助重现 Bug、快速定位到 Bug 的原因;对于项目经理或者测试人员来说,可以直观的看到哪些 Bug 还没解决,及时了解项目进展。
你平时在 Bug 跟踪系统中看到的 Bug 状态,看起来只是一个有限的状态列表,但背后其实是一套解决 Bug 的流程。就像下面这张图表示的这样,一个 Bug 从创建到最后结束,其实是有一个完整的流程的。
通过这样的流程,开发人员就可以集中对 Bug 进行分配、按照优先级分别解决,而测试人员则可以第一时间知道 Bug 处理的状态变化,及时验证,方便跟踪整个过程。
使用 Bug 跟踪工具的注意事项
报告 Bug 的目的是为了能跟踪 Bug,以及帮助开发人员重现直到解决问题。要想做到测试和开发高效协作,这里面有一些需要注意的事项。
- 首先,所有的 Bug 都应该通过 Bug 跟踪系统管理和跟踪,不应该再通过 QQ/ 微信 / 邮件的方式跟踪 Bug。如果客户、同事通过 Bug 跟踪系统之外的其他途径反馈 Bug,应该统一提交到 Bug 跟踪系统管理跟踪起来。
- 然后,不能把多条 Bug 合并成一条,一个 Bug 创建一个独立的 Ticket。我遇到过有些测试为了省事,把几条 Bug 合并成一个 Ticket 来报,导致的问题就是,必须这几条 Bug 都修复了,这个 Ticket 才能改变状态,如果其中一个 Bug 没有验证通过,需要 Reopen 整个 Ticket。
- 再有,描述清楚如何重现 Bug 非常重要。一个 Bug 如果无法重现,也没有日志、截图等辅助信息,那是非常难以定位的,会浪费很多开发人员定位 Bug 的时间。
- 最后,不要把 Bug 跟踪系统当成讨论板用。
- 在项目中一个常见的场景是,一个 Ticket 下面,跟讨论版一样添加了很多留言,开发认为不是 Bug,测试认为是一个 Bug,开发又觉得是产品设计没定义清楚,应该让产品经理来讲清楚,皮球踢来踢去,最后问题还没解决。
- Bug 跟踪系统的主要功能是用来跟踪 Bug 的,不是用来讨论和扯皮的。遇到上面的情况,其中一方就应该主动一点,拉上相关人面对面讨论,当面确认清楚这个 Bug 到底是什么问题,然后马上解决掉。
自动化测试工具
除了 Bug 跟踪工具,软件测试中还有很重要的一个工具就是自动化测试工具,未来自动化测试会占据越来越多的比例,很多手工测试的工作会逐步被自动化测试代替。
这就意味着对于软件测试人员来说,要求越来越高了,不仅要会设计测试用例,还要能写自动化测试脚本。同时对于开发人员来说,不仅要写功能代码,还需要实现一定量的自动化测试代码。
这些年自动化测试工具的快速发展,也降低了自动化测试的实现难度,可以方便地搭建自动化测试环境,通过简单的脚本语言就可以模拟人工操作
但很多团队还是不愿意投入在自动化测试的开发上面,宁可雇佣更多的初级测试人员手工测试。
其实这个问题还是要整体来看,这就像修路,如果你从一个地方到另一个地方(类比测试所有用例),偶尔走几次,那么可以不修路(手动测试),如果你未来一段时间需要频繁的在两个地方通行(反复测试),那么最好现在就开始修建高速公路(自动化测试),这样可以节约你大量通行的时间 (测试时间)。
当然更多的情况其实是团队不知道该如何实施自动化测试,比如说测试人员不会写程序,开发人员太忙,或者开发人员不会写测试用例,或者不知道该选择什么样的自动化测试工具。
对于这种情况建议:
- 测试人员可以学习一些基本的编程知识,尝试自己实现自动化测试。自动化测试所需要的技术,主要是对 API 的调用,并不需要复杂的逻辑,其实学习门槛并不高,而且这种技术在工作效率、薪资、个人职业发展等方面的投资回报都是巨大的。
- 从项目的角度,应该加大对自动化测试的投入,让开发人员参与到自动化测试代码的开发中。增加自动化测试代码的覆盖,对于提升软件质量是有明显好处的,通过自动化测试可以提升测试效率,及时发现软件质量问题。对于开发人员来说,如果已经有了测试用例,完成自动化测试并不复杂,这个投入其实比做一些重要性不高的功能回报更高。
自动化测试工具的选择,需要根据你的软件的特点,去找出来适合你软件自动化测试的几款,然后自己搭建环境试用一下
其他帮助发现bug的测试工具
软件测试的一个主要功能就是发现bug,而要发现bug,就需要对软件的各个领域进行测试,比如说性能、安全性、兼容性等领域。
这些不同领域的测试,要求也不一样,比如说性能测试要求能测试出软件是否有性能瓶颈,能达到多少用户的访问量,需要模拟大量用户并发访问;安全性测试则要求对软件可能存在的安全漏洞进行扫描、验证;兼容性测试则要针对不同环境不同设备,对软件进行测试,以确保不会因为环境不一致导致功能不正常。
这些测试要么很难人工完成,比如模拟大量用户并发访问;要么需要很深的专业知识,比如安全性测试;要么需要大量的设备和巨大的工作量,比如兼容性测试。所以这些领域的测试,就需要借助工具才能进行测试,从而发现问题。
应用这些测试工具其实并不难,毕竟都有很成熟的 API,网上也有很多教程,真正需要的是去执行。另外如果想要最大化工具的价值,及时发现问题,还要考虑将测试工具的应用自动化,加入到你的持续集成流程中去。
以压力测试为例,你用 Jmeter 完成了压力测试脚本后,还可以考虑和 CI 集成,在每次构建时,运行一遍压力测试代码,可以在构建完成后看到直观的图表,还可以设置性能数据的阈值,如果性能指标低于阈值,会导致构建失败,这样就可以第一时间发现性能问题,缩小问题范围,并及时解决。
工具
Bug 跟踪工具:
- 一些任务跟踪系统,比如说Jira、禅道、TAPD、云效等,都可以用来跟踪 Bug。
- Bugzilla 是由 Mazilla 公司提供的一款开源免费的 bug 跟踪系统。这是一款历史很悠久的产品。
- MantisBT 是一个简单但功能强大的开源 bug 跟踪系统,可以通过各种插件来扩展其功能。
- Redmine 是一款开源的综合性的项目管理工具,不仅可以用于 Bug 跟踪,还可以用来跟踪项目进度。
自动化测试工具:
- Selenium 是一个 Web 端的自动化测试工具,直接运行在浏览器中,用来模拟用户操作。类似的还有WebDriverIO 和 Nightwatch.js ,支持 Javascript,API 更简单更方便。
- Appium 是一个开源、跨平台的自动化测试工具,用于测试移动原生应用,支持 iOS,Android 系统。
- Macaca 是阿里巴巴开源的一款面向多端的自动化测试工具,支持桌面端、Web、移动端、真实设备和模拟器。
压力测试工具:
- JMeter 是一款开源的压力测试工具,纯 Java 应用程序。
- LoadRunner 是惠普旗下的一款商业自动负载测试工具,可以通过录制的方式制作测试脚本,上手容易功能强大,可以方便的监控和分析性能测试结果。
- 阿里云性能测试 PTS 是基于云端的压力测试服务,可以模拟从全国各地域运营商网络发起的流量,报告真实反应用户体验情况。
- WebPageTest 是一个可以用来测试和分析网页性能的在线工具,支持不同浏览器,支持API。
安全性测试工具
- Fortify On Demand 是惠普旗下的一款安全检测工具,可以通过分析源代码、二进制程序或者应用程序 URL 检测程序安全漏洞
- Sqlmap是一款开源免费的检测 Sql 注入的工具
- APPScan 是 IBM 旗下的一款漏洞扫描工具,支持网站和移动 App
测试用例管理工具
- TestRail 是 TestRail 是一个专注于管理测试用例的工具,可以用它来创建测试用例和用例集,跟踪测试用例的执行和生成报告。
- 飞蛾 是 Coding 旗下的测试管理工具,对中文支持好,界面美观
疑问
对于自动化测试一直有些疑问,如果每次发布都对所有方法自动化测试:
- 一定会耗费很多时间;
- 数据库产生很多测试历史数据;
- 写测试用例能达到覆盖率高的写代码技巧,如边界测试代码、幂等测试代码如何实现。
- 自动化测试确实会耗费很多时间
自动化测试代码通常是金字塔结构:
- 单元测试(小型测试)代码最多,执行也最快,占总比例的70%左右,通常1分钟内
- 集成测试(中型测试)代码其次,执行比较快,占比20%左右,控制在10分钟以内
- 端对端测试(大型测试)最少,执行慢,占比10%左右
一般CI里面跑单元测试和集成测试,耗时10-15分钟左右,其实还可以接受
- 跑自动化测试,数据库有不同策略
- 单元测试不访问数据库,完全模拟
- 集成测试只访问本机数据库,或者模拟的内存数据库,每次创建新数据库,或者使用完清空数据库
- 端对端测试,每次创建唯一数据(例如增加固定数据+时间戳),连接真实的测试环境,可以不清理数据
- 高覆盖率的关键在于在写代码就注意让代码方便的被测试。也不必过于追求100%覆盖,70%以上就不错了。
测试脚本、测试用例、测试数据这三者如何配合一起通过CI进行自动化测试?
CI本质上只是一个像流水线传送带,你的代码提交了,流水线传送带开始工作,你可以在传送带上面添加任务。
简单来说,你可以想象成CI的一个任务启动后,给你一个干净的虚机(实际是运行Docker Container),然后帮你把当前代码下载下来,帮助你配置好运行环境,然后你就可以在里面安装任何软件、服务和运行任何脚本。
举例来说,你可以在传送带上增加以下任务:
- 安装所有的依赖包
- 运行模拟服务(比如一个内存数据库)
- 运行单元测试
- 运行集成测试
如果上面所有任务都成功了,那么这一次的CI任务就成功了,其中一个失败这一次的CI任务就失败
了,然后你就要检查什么原因导致的,然后修复再重新执行,保障CI任务成功执行位置。