10年测试工程师总结分享,一文教会你怎么快速找bug以及测试用例的编写

软件测试工作中找bug就是这个岗位本身立足的职责,那么对于很多测试新人和新入行的小白来说,这个过程会有点苦逼,毕竟经历的项目经验不多,想快速的切入寻找bug往往会比较痛苦。

那下面我就以自身的经验来普及下如何在工作快速找出系统的不足或缺陷。

1、熟悉你做的产品

不管你是Dev、Test或者PM,熟悉自己开发的产品越多越好,你不但应该熟悉自己开发的模块,也应改熟悉和自己模块相关的其他模块,他们之间是怎样协作的。比如数据库中的某个字段,是如何被各个模块使用的,这利于你在设计阶段就能够找到Bug,把修复的成本降到最低。

同样,你需要熟悉这个产品以前的版本,因为无法向后兼容和升级的产品恐怕很难获得用户的认可。在测试过程中,如果你发现你的产品和以前不兼容或者不一致,80%的情况,这是一个Bug。

2、尽早的去发现Bug

我们大家都知道,Bug修复的成本是和Bug被找到的时间成指数关系的。越早开始找Bug,你能找到的Bug也就越多,对项目的贡献也就越大。

3、每天Review别人的Bug

如果你的团队没有每日的Bug Report,我建议你们建立一个,其实技术上应该没有任何的难度,通过Bug追踪系统的API或者数据库,你完全可以得到你要的数据,这样,整个团队通过学习每天察看别人的Bug,你可以更加容易发现Bug,也不会发现那种Duplicated Bug。现在经常有人跑过来问我,某个Bug是不是一个已知的问题,因为我每天都看Bug Report。

4、在你的日常生活中多准备一些测试的模式

模式是一个很时髦的词,因为它很有用。在日常的测试中,多准备一些测试模式,你会有非常大的惊喜,有时候一个使用一个模式,你可以找到10来个Bug也不是不可能的。比如,使用特殊字符作输入数据;断开网络看UI是否会Crash;在本地化版本中,各个字符串提示是否被本地化;

5、多测试各个模块之间的合作

各个模块之间的测试往往是我们测试中的薄弱点,对于用户来说模块间的合作却至关重要。往往一个数据在模块A中是合法的,在B中却是非法的,一定要找出这些数据,往往者都是Bug

6、编写自动测试代码

你肯定不原意每天都去做同样的事情,那样太没有意思了,简直就是对你的智慧的侮辱。但是一旦我们不进行这些测试,突然有一天早上,我们发现我们的产品以前能够很好工作的功能突然就不工作了,于是大家乱作一团,有人急着修复它,有人在找是谁Check in的。

7、查看产品代码

通过查看产品代码,你往往能找到一些Dead Code或者逻辑上的Bug,这些Bug常常是你无法通过手工测试找到的。

为什么要写测试用例

为什么要写测试用例,实际中产品出现问题,第一责任人首先想到的是测试为啥没有测到?

产品出现问题了,你为啥没有测出来呢?

请添加图片描述
当然,除了避免“甩锅和背锅”,其实写测试用例更重要的作用如下:

  • 技术上将需求转化为具体可验证的指标
  • 以文档的形式记录软件可能存在的问题
  • 防止测试过程的活动出现遗漏,提高工作效率
  • 测试工作量的展示

测试新人怎么写用例?

有很多初入测试职场的朋友刚开始编写用例,不知道从何下手,虽然有的公司给出了相关说明文档,但是写起来还是不能得心应手,编写用例方法有很多种:功能导向用例(边界值、等价类等等),用户导向用例(场景法),用户、功能相结合导向用例……

那么对于新人编写用例,应该怎样高效率的编写用例?应该注意点什么?

一、功能导向用例是按照系统需要达到的每一个功能,进行编写用例,这样的用例着重点在功能实现上,而没有考虑到每个功能之间的关联,因而虽然用例已经达到功能覆盖,却不一定达到逻辑覆盖,因而这种方法通常会和其他方法结合使用。功能导向用例是每个用例编写者前期最常用的方法。

二、用户导向用例是按照用户的习惯,将用户使用系统的每个目的作为一个目标,以每个目标实现为基点设计测试用例,但是设计这一类用例,初写者,可能会产生很多困惑(下面写一下我第一次写的时候有哪些困惑,并针对这些困惑,后来采取了怎样的解决方案)

1、编写用例的第一步我该做什么?

理解系统,首先站在测试的角度深入理解系统的每个功能与系统业务逻辑,画出业务逻辑图(即:系统能做什么)。

其次站在用户的角度,列出用户使用系统的目的(即:用户使用这个系统,想干什么?)

在这里插入图片描述

2、怎样确定用户目标?

不能确定用户目标,可能由2方面原因造成:a>对系统不够熟悉,b>不了解用户背景。对于第一点原因,那是你自己的原因,只有回过去头看文档了,对于第二点原因,可以从‘系统能做什么’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’,当然这样做的前提是你对系统已非常熟悉。

3、这个月我将做什么?

刚进入测试行业是怎样总结的(利用测试管理工具进行总结):

1)把测试管理工具中的缺陷全部分类导出,总结一下哪些模块容易产生哪些缺陷,重点看一下自己没发现或没有考虑到的缺陷。

2)如果说测试新人工作的第一层次是从执行用例开始,那么第二层次就是编写测试用例了。把测试管理工具中的用例详细看几遍,学习别人的用例编写方法和思想,空闲时间可以自己试着编写,看自己编写的与别人编写的用例差距在哪,从而不断完善。重要说明;着重用例编写方法和思想的学习,而不要死搬硬套。

3)进入一些测试论坛,把自己的困惑和经验和大家一起分享,在学习中,不断进步。

总结

正所谓功夫在诗外,测试理论知识就是那么多,理论知识掌握之后就要不断的参与到项目中来,一个一个项目的练习,锻炼自己的发现Bug的能力,就算随机测试,一个好的测试和一个坏的测试,他们发现问题的能力也是完全不同的。以上完全是个人的一点体悟,各位看官,看的时候也请多多指教。

为了支持一下新入行的朋友们,这里也把笔者测试生涯整理的上百份学习资料和讲解视频良心分享,新手入门绝对用得上,一并放在下面了,废话不多说,只需要加入技术分享群:769146372 自提链接。学习软件测试是件需要坚持的事情,学习的过程可能会很枯燥,不过有一些人一起学的话大概就不会了吧,加入我们,跟我们一起学习,有人陪伴,不会孤单

在这里插入图片描述
以上资料,对于学软件测试的小伙伴来说应该会很有帮助,希望也能帮助到你。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
软件测试Bug管理器是一种专门用于跟踪、记录和管理软件开发过程中发现的问题(或称为“缺陷”或“bug”的工具)。它的主要功能包括: 1. **问题追踪**:系统化地记录每个bug的信息,如描述、重现步骤、优先级、严重程度等,便于团队成员快速和理解。 2. **分配与跟踪**:自动或手动将bug分配给相关的开发者或测试人员,并跟踪其状态,如新发现、已修复、待验证等。 3. **版本关联**:与版本控制系统集成,比如Git,以便于查看bug何时被引入,以及哪些代码更改影响了bug。 4. **沟通与协作**:提供讨论区或评论功能,团队成员可以在同一平台上交流bug详情、解决方案及修复情况。 5. **报告生成**:生成各种报告,如缺陷率分析、修复时间趋势等,帮助管理层了解项目的健康状况。 6. **自动化集成**:支持与其他工具如持续集成/持续部署(CI/CD)系统结合,实时更新bug状态并触发相应的自动化流程。 7. **优先级和紧急度设置**:根据bug对产品的影响和项目进度设定优先级,确保关键问题得到及时处理。 使用软件测试Bug管理器有助于提升团队的效率,保证产品质量,同时促进开发和测试之间的良好协作。常见的Bug管理工具包括Jira, Bugzilla, TestRail等。如果你正在考虑使用其中一个,可能需要考虑它们的功能特性和是否适合你的团队需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值