当以Bug数量衡量软件质量时,管理者如何避免自我毁灭?

软件测试以bug数来考核,软件测试能力提升及其思考 如果虽然Bug数量也是衡量软件测试人员绩效方式的一种,但是这种单纯的以Bug数量作为测试人员的绩效考核方式在我看来不太合理。该方式可能会产生许多无效的Bug,增加测试和开发的沟通间。如果作为测试领导或测试负责人我们应该避免使用该方式作为考核标准,以下是我认为不合理的几种原因:1、测试模块安排不合理如果安排测试稳定的模块不管是根据用例还是自由测试找到Bug的难度非常大,导致测试人员的Bug数量上... 阅读详情

您是否在计算bug数量以衡量软件质量?

这里有一些方法可以使它看起来更好,而不用实际去努力提高质量。

1、不要经常阅读bug报告,也不要追踪它们。

2、不要以简单、可靠的方式将bug告知客户。

3、降低找到的bug的严重性,然后制定一个好的规则来忽略低严重性的bug。

4、制定一个规则,即只有在有无可辩驳的证据证明bug违反书面要求且易于重现时,才能记录提交。

5、使用各种各样的bug报告来报告各种问题。

6、只雇用初级和未经培训的测试人员。

7、假设100%自动化是您的目标,此时您可以自动化许多简单的检查,然后炫耀“我是如何执行成千上万条的测试的”。虽然您将无法找到很多bug,但是您将看起来很忙,并且能够创建很多看起来很不错的代码。

8、每次报告bug时,都要表现出您的愤怒或悲伤,这样测试人员就不会勇于提交bug。

9、将测试任务外包,让他们知道您不想听到任何有关质量的投诉。

10、拒绝测试人员说:“质量和测试是每个人的责任。” bug的数量将大大减少,并且仅报告那些易于修复的bug。

相信经过上面十个方法,你负责软件项目的bug将大大减少,而质量看起来更好了。这离你毁掉项目,坑死老板的目标也不远了。

对每个职场人士来说,当工作步入正轨,开始稳定下来,那么关于未来的职业发展就是首要考虑的问题。测试人员也不例外,每天忙于业务测试,接触到的核心技术会比较少,如果不能提升自己的职业技能,拥有自己的核心竞争力,那么对于未来的发展会有很大的限制。

  说的稍微严重一点,如果觉得测试只是枯燥的“用鼠标点点点”的工作,那么职业发展可能很快就会遇到瓶颈,甚至还有被行业淘汰的可能!

  每个行业,每个岗位,都有自己的发展方向,测试工程师必有他的价值。有时候觉得看不到未来,也可能只是是自己站的不够高。想要未来大有可为,就需要不断的学习,提升自己的专业技能,让自己达到一定高度,毕竟站的更高,才能看的更远。对此,小编特地整理了以下测试人员需要提升的几项能力,可供参考。

抛开疑问,只做学术探讨

这次我们抛开所有的疑惑,比如自动化测试到底有什么用?自动化真的能提升效率么?学了自动化能涨多少工资等等,以上的话题,我这次将不再论述,这几个问题也是平时讨论的比较多的问题。

针对以上的问题,我做一个总结,能涨工资,能多赚钱的技术,就值得我们去学!既然自动化现如今发展的这么火,自然有它存在的价值。

小白在想什么?

想必每一个大神,都是从小白一步步走上来的。当然呢,我很能理解小白的想法,因为平时经常和一些刚入门自动化测试的同行交流,也很深入的了解到他们的一些困惑。

大部分小白想的无非是以下几点问题:

1.自动化测试好学吗?
2.不学/不写代码能做自动化测试吗?
3.怎样学习自动化测试?
4.学自动化测试要先学习哪个方向?学ui自动化?还是接口自动化?好像App自动化也比较火?要么再来个小程序自动化?
5.我没有代码基础,工作都是点点点,要不要报培训班?
6.我需要学习什么语言?java 还是 python?
...等等

我来针对以上的问题,说一些自己的看法:

首先,自动化测试,很好学!但是要记住,一定要明确学习的方向,不要剑走偏锋,白花力气。

第一,不写代码当然可以做自动化测试,但是个人建议还是学习一门语言,至于学习什么语言的话,很简单,不用纠结,第一看你是否有编程基础,没有选py,有的话选java py都可

第二需要看你们的开发用的什么语言,和开发用同一门语言能在学习自动化测试的同时,降低你和开发之间沟通的门槛,提升你在公司的话语权。

第三,学习哪个方向?我建议:web ui自动化=》接口自动化=》App自动化/小程序自动化,当然,着重学习接口自动化,ui自动化要学,但是没太大必要深究。

第四,要不要报名培训班?这个看你个人,如果你觉得自己学习理解能力很强,本身自己又很自律,同时学习的方向又很明确,那么你当然可以不报名培训,多省点钱不香么?

假如你对自动化测试或者一些编程语言毫无理解,身边又没有能带你学习的人,那么报名培训绝对是一个快速提升的途径。

盖楼之前先打好地基,首先需要学习一门语言

在上面我们也提到了,自动化要想做得好,必须要学习至少一门语言。当然至于学习语言要到什么程度了?我不可能一直学下去吧?答案是,会用就行!

掌握大部分的语法基础,已经能够满足你的自动化的日常需求了,因为我们写脚本并没有像开发那么难!

语言你需要学习,for循环,if判断,数据类型,运算符,面向对象编程等等,不管是java还是python,这些都是需要的,其实也差不多,会一门语言,其他的都类似。

语言入门后,正式踏上开始自动化成神之路,入门篇Selenium

selenium作为自动化的老祖宗,已经被玩烂了,基本上只要是做自动化的,无人不知无人不晓。为什么要先学习selenium?

它能帮助你快速理解,自动化到底是个什么东西,并且能直观的在页面上面反馈给你。咱当初也是,看着selenium的api,一点一点啃下来的,几乎每个方法都去尝试了一下。

selenium有1.0 2.0 3.0,建议你学习之前,先去了解以下它的历史,u以及它的运行原理,这样可以勾起你的学习兴趣。你学习selenium,需要去安装浏览器,强烈建议使用Chrome而不是FireFox,前者兼容的更好。

安装好Chrome,你需要去安装驱动,恭喜你,这时候你就会踩到自动化的第一个坑了!大部分原因还是因为你的驱动版本和浏览器版本对不上。等能访问百度后,这里印象很深的su和kw(具体是什么等你学了就知道了)

你会再去尝试各种selenium的方法,去操作浏览器,这时候仿佛打开了新世界的大门,奥!原来自动化测试是这么个东西!真神奇!

玩腻了Selenium

等你玩了几天,或者几个星期之后,你好像对Selenium提不起什么兴趣了,脚本也写的越来越6,能写出一些线性的自动化脚本了,这个时候,有点骄傲自满,自动化不过如此,就这?

我想说的是,不要高兴的太早,你仅仅只是刚跨入自动化测试的大门,走了一小步而已。此时,你可以开始尝试,把项目中一些重复的操作,写成脚本去跑,满满的成就感有木有!自动化的成效初步形成,仿佛你开始懂得如何用自动化提升效率了。

开始接触自动化框架unittest/testNG

等你学会单元测试框架unittest/testNG,当你学会了selenium后,你会发现大部分的线性脚本,很难去管理,并且每个脚本需要去一个个run,而且还无法统计测试结果,这个时候,就需要单元测试框架登场了!

你会开始学习,单元测试框架的用法,如何创建一个测试类,如何写测试方法,如何把你的脚本写成测试用例,如何校验测试是否通过,用例的执行顺序怎么去控制,断言怎么去写,这些都是你要去探究学习的。

不满足于单元测试框架的功能

等你脚本写的很6,用例也会组织了,然后每次领导告诉你,跑一下测试,然后把测试结果发给他,要总结成测试报告的形式。

你这时候,屡次打开你的编辑器,run test,然后刷刷刷的跑完测试,一条一条的统计测试结果,累得半死,发给了领导。

第二天领导又说,下班前你再跑一下测试,给我份报告,想死的心都有了。那么你开始去逛百度,逛论坛,想要得到解决方法,那么“框架”一次就会映入眼帘。

学习自动化框架

此时,你已经开始琢磨如何写一个自动化框架出来了,那么说明你的自动化已经开始入门了,并且往着中级的方向发展,你开始研究框架的结构,发现有用例管理,日志,测试报告,邮件,基础封装类等等,还有一种框架的设计模式(经典PO模式)

你开始对你的用例进行整理,封装基类,编写页面类,封装日志,邮件模块等等,经过了几个星期的打磨,你的第一个自动化框架诞生了!

此时你可以去各个技术群去炫耀了,自动写出了一个自动化框架,很多小白也开始吹捧你,叫你大神了。

初始接口测试

以上结束了UI自动化的学习,那么下面到接口这边。一般公司用的都是http接口,那么你就从http协议开始学习了,了解它的结构,请求头,请求参数,请求地址,请求方式等等等,尝试学习一些抓包工具

如fiddler,chales,wireshark或者浏览器的开发者工具等等,去抓包获取一些接口,慢慢的观察它的请求构造,但是这时候还是云里雾里,对接口一知半解。于是下载了一个接口测试工具,尝试把参数录入到工具中,手动发起调用。

当工具返回200 code时,奥,原来是这么回事。好像就是和服务端来传递和接受数据的,然后前端页面会把数据展示到前台!

尝试学习Request/HttpClient库发起请求

在用完postman后,就会想到,那么我怎么用代码去发起一个请求呢?这时候就需要去学习这两个东西。pip install & import requests后,就开始了你的接口自动化之旅。

你尝试也是把之前ui自动化的增删改查,用接口来实现,你把抓包的请求参数拿过来,一个一个方法的调用,然后一键运行!一绿三红!为什么?然后发现接口返回了401,无权限!奥!我没有登入啊,那么怎么才能登入呢??

抱着很多的疑惑开始研究,这时候你需要去了解cookie和token的工作机制,再配合你的代码,去缓存cookie,达到登入。等解决了这个问题,但是接口还是报错了啊,删除接口提示我没有这条数据!

查来查去,原来是我那条数据已经用掉了,那么怎么可以保证我每次录入的参数都是新的呢?这时候就需要去了解接口关联,如何把参数从上个接口的响应提取出来,给下个接口用。

request/HttpClient结合unittest/testNG+allure

一样的,等你学会了 request/HttpClient,自然也会想到用单元测试框架把他们集成起来,然后又发现了一个高大上的allure测试报告,再结合一些日志模块打印参数,轻车熟路的这么一个接口框架就出来了,和之前的差不多!小意思。

尝试用yaml/Excel管理测试用例

等你拿自己的框架,重复枯燥的写着测试用例,这时候你想了,我为啥每次都要request.post,方法都是一样的,只是数据不一样,为什么我要一直写代码呢,很累啊!为什么不用一些文件来读取测试数据,做参数化呢?

这时候你开始研究读写excel/yaml了,你想把所有的测试用例都放在文件里管理,就不用每次去写代码了,然而事情并没有那么简单!那么我在文件里如何去处理关联数据呢?如何去缓存cookie呢?如何做断言呢?如果做一些动态的输入呢?

以上问题就留给你们自己去想了。

高级货?git?jenkins?docker容器?分布式?

走到这一步,你已经写过好几个框架了,并且基于自己的框架做了优化,那么你此时发现一个很严重的问题,我的代码居然只能在我本地运行,如果要给别人用,还需要去别人电脑上配置环境,copy代码给他。

那么为什么不用一些代码管理工具去管理我的脚本呢?那么就会需要去学习git,了解如何add commit push推送我的代码到公司的gitlab,这样别人也可以使用,那么有了gitlab,我想做一些定时任务,让它自动执行呢?

学jenkins。再更多,要是我想多个用例一起跑呢?学习selenium grid,docker等等。。

自动化顶端之测试平台/工具开发

等你搭建好公司的自动化生态,你还是不满足,我为什么不把这些东西可视化管理呢?做个平台?管理用例,管理任务,管理测试报告?我还可以把公司的一些部署任务也集成过来?

想法很好!此时的你已经不仅仅是一名优秀的自动化工程师了,已经迈向了测试开发的道路!开始学习,了解了测试框架httprunner,开发框架django/flask/springboot,懂得了接口开发的流程,了解了mybatis,shiro,quartz等等,开始学习前端

vue/react,懂得了什么是组件开发,父子组件传值,开始了解很多东西,甚至运维方面的知识,开始了解k8s docker,微服务。。那么你越来越往着大神的方向去了,希望你还没有秃头,此时的你可以骄傲的称自己为一名合格的测试开发,或者叫全栈开发了有木有!到此告一段落。

PS: 以上就是我个人,也相信是大部分学习和喜欢自动化测试的一个学习路线,当然本次没提到一些App端/小程序端的自动化测试,其实也都大致类似。希望各位看完本文章点个赞!祝大家少走弯路

因此我建立了一个软件测试开发自学团,正在学习测试的小伙伴可以通过点击下面的小卡片

软件测试之bug统计分析的重要性 复盘统计bug不是目的,真正的目的是从中吸取经验,提高产品质量。 阅读详情

相关推荐

如何做好Bug分析

Bug分析是QA的一项主要技能,需要针对项目中遇到的经典问题进行分类分析, 直达问题本质。 并且能够给团队其他项目或者成员起到典型的借鉴作用。 当然也有一些非常经典的问题可以进行技术深挖, 以供参考。 个人认为比较典型的「Bug分析」是stackoverflow, 当然, 一个完善的bug分析库, 可以进行问题分类总结。 对于测试新人是有很大的帮助的。本质上, 在测试领域很多问题是可重现可整理可规避的。另外, bug分析本身是为了拓宽每个人的认知边界, 缩小团队间的乔哈里窗以达到最佳的合作状态。一个「好的B

weixin_51482243的博客 1889

Bug的质量衡量

注:节选自《软件测试技术大全》  7.6.1 Bug的质量衡量某些测试人员认为录入的Bug描述不清晰不要紧,如果导致开发人员误解的话,开发人员应该主动来找测试人员问个明白。这话有一定的道理,这确实有一部分沟通上的问题。但是测试人员如果尽量清晰地描述缺陷,尽量让开发人员一看就明白是什么问题,甚至是什么原因引起的错误。这样岂不是节省了更多沟通上的间?因此需要引起测试人员注意的

软件质量优化 3766

通过可视化数据分析提升测试质量

作者: Deadwalk 某位高人曾说过:日复一日地重复着既有的测试,然后被类似的Bug折磨得无可奈何,不如稍作停顿,分析总结找到Bug的源头,以除之。本篇文章我们就来聊聊如何通过可视化的数据进行分析,进而提升测试质量。 为了让产品的质量可度量、可视化,我们可以建立一些指标数据,以帮助我们发现产品质量的各种问题,比如:被测功能模块发现Bug太晚,某位开发同学的代码质量一直很低,某个功能总是在兼

36大数据 1437

软件测试BUG分级标准及通过标准

软件测试BUG分级标准及通过标准 原文:https://blog.csdn.net/lansky54/article/details/5414188 编制目的 本文件作为软件测试过程中各阶段的通过标准,旨在合理有效的对软件阶段质量进行控制,同为软件测试的深度选择和资源投入的决策提供参考。 主要内容与适用范围 主要内容 本标准规定了软件测试中缺陷、错误、故障等问...

yaoyao4959的专栏 8725

在测试阶段中,按bug数量评定开发人员的标准是否靠谱?

经典名言 提到这个问题, 我想到了一句流传在程序员之间的经典名言: 按代码的行数评估开发的标准就像按重量评估飞机的质量一样愚蠢。 bug和代码量这两种平不标准, 有相同之处, 也有不同之处。那么,用bug数量来评估开发质量到底靠不靠谱呢? 很幸运的,我遇到了这个问题那么这个评估标准的可行度到底如何呢? 一些似乎有用的评论 这些内容来自于网络人事的一些观点 通常情况...

Only丿阿海的专栏 2736

Bug量分析,Bug是否越多越好?

经常会听到有人讨论,某某一个月发现了500多条bug,还有谁一天发现了100多条bug,公司的绩效是根据bug量多量少来衡量等问题,但是,我们能仅从bug量上就看出来一个人的工作质量吗?显而易见,这样太过片面了。首先,bug量显示了哪些问题,代表了什么?在这里我们认为bug多的软件质量可能不好,为什么说是可能,而不是肯定,因为这里面缺少了参照点,下面将从bug量配合查看的因素来进行分析。

weixin_45189665的博客 3106

遇到bug怎么分析,这篇文章值得一看

为什么定位问题如此重要? 可以明确一个问题是不是真的“bug” 很多候,我们找到了问题的原因,结果发现这根本不是bug。原因明确,误报就会降低 多个系统交互,可以明确指出是哪个系统的缺陷,防止“踢皮球”,提高问题解决的效率 增强开发对测试的信任度,沟通更有效,配合的更好,开发修改bug效增强 更有效的了解系统的内部逻辑、数据流处理流程,更能提高测试人员的水平,缺陷修复后,影响的测试范围评估更精准,复测更准确 可以降低缺陷率 这个可以说是最重要的。在bug系统中,会要求开发人员记录bug产生的原因。只有我

软件自动化测试技术交流、资源分享 2750

如何进行bug分析,有什么作用?

例如,如果某一类型的Bug在特定的模块中频繁出现,可能表明该模块存在结构问题。在开发过程中,bug的产生是无法完全避免的,但是通过对bug的分析,可以找出开发流程中的薄弱环节,进而采取措施提高软件质量。随着产品的演进,新的Bug会出现,而有效的分析可以帮助团队持续学习和改进。确保有一个健全的Bug跟踪系统,如JIRA、Bugzilla或其他类似工具,用于详细记录和存储Bug。识别并修复bug有助于减少软件中的错误,提高产品的稳定性和可靠性。分析bug的过程可以提升开发团队的问题解决技能和技术知识。

huace3740的博客 1165

每次提出一个bug都让测试重现,描述得那么清楚,自己操作下不会吗?

很多候不仅仅是把自己手头的工作做完就结束了,大家是在同一个团队为了同样的目标在努力。如果仅仅是为了更快的完成自己的工作而延误了别的小伙伴的工作,就最终将要达成的目标来说也是得不偿失的。因此,在日常的工作中多站在对方的角度思考问题,多体谅对方,将自己能力范围内的工作做好,问题解决好,为对方营造一个舒适的解决问题的环境,对方自然将你的好看在眼里,记在心里。即便是前世的宿孽,今世的冤家也能有情人终成眷属。

主要分享测试的学习资源,帮助快速了解测试行业,帮助想转行、进阶、小白成长为高级测试工程师。 247

【质量管理】bug处理优先级规范

此文档旨在合理定义缺陷的修复优先级,以期将资源优先集中在投资回报率高的缺陷修复上,以最大化投入产出收益。能以高效-流程化-通用的Bug处理准则,可以让大家按照共识的准则快速处理。

maidou2020的博客 593

软件质量BUG等级定义

1、 Bug严重程度的分级    缺陷级别定义     A类――致命BUG  包括以下各种错误:   1.由于程序所引起的死机,非法退出。  2.程序死循环。  3.数据库发生死锁。  4.与数据库连接错误。  5.主要功能没有实现。    6.因错误操作导致的程序中断。                 B类――严重BUG  包括以下各种错误:  1.程序

鹏javatar的专栏 7209

测出Bug就完了?从4个方面教你Bug根因分析_测试发现的 bug 比客户发现的 bug多(1)

*缺乏反馈机制:**没有及的反馈机制,测试人员可能难以得知他们提出的问题的分析结果和解决方案。针对每一个bug,分析根本原因,有一些自己测试过程中就已经了解了可以写上,不了解的或者记不起的内容可以统一咨询相关开发人员,他们是最了解问题的第一人。**忽视根本原因:**有测试团队可能只关注问题的表面症状,而忽视了问题的根本原因。**工具和资源不足:**没有合适的工具和资源来支持深入的BUG根源分析。现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。

2401_84264468的博客 598

软件评估--->Bug的价值(产品市场角度分析)

  总是在考虑,谁是公司直接财富的创造者,谁又是公司财富间接创造者,他们在各个岗位上的价值是怎么评估出来的。而公司的品牌价值又是怎么评估出来的?可是显然问题的范围太广,完全超出我的理解范围了。所以呢就从工作中的最小单位来评估,可能比较容易得出结果!评估Bug的价值这个思考过程应该很有创造性的!   评估的第一个切入点问题:Bug的等级和每个等级Bug的价值是多少?   公司内部对Bug分成P10,

bravochen的专栏 1428

如何保证测试质量之Bug管理规范及流程

目录 Bug属性规范及流程1 1.目的2 2.范围3 3.工具3 4.角色和职责3 5.Bug属性定义3 5.1.bug类型4 5.2.bug严重性4 5.3bug优先级5 6.Bug管理流程6 6.1提交bug6 6.2分配bug6 6.3解决bug7 6.4验证bug7 6.5遗留bug7 6.5.1跟踪遗留bug7 6.5.2产品发布后发现的bug8 6.6bug分析8 目的 本文档定义bug的整个生命周期,...

m0_67034352的博客 6332

【已解决】asyncio.Task exception was never retrieved 任务异常未捕获隐形bug深度排查与根治方案

本文深度剖析 Python asyncio 中 Task exception was never retrieved 高危隐形 Bug。该警告不会导致服务崩溃、监控无异常,却会造成异步任务静默失败,引发订单归档、积分发放、消息推送等业务数据错乱,线上偶现且极难排查。文章详解异步底层异常机制,纠正常见误区,提供四套生产级解决方案,结合真实线上故障复盘,对比修复前后 FastAPI 可落地代码,并总结编码规范,帮助开发者彻底根治异步隐形异常隐患。

姜的blog 391

区日期显示 Bug复盘

本文通过一个实际案例分析了前端间显示偏差问题。问题现象为列表创建间比数据库记录早8小。排查发现数据库存储正确,但后端返回的间格式不规范(无区标识),导致前端new Date()按本地区解析,最终显示错误。解决方案包括:1)后端统一输出带区标识的ISO 8601格式;2)前端封装工具函数强制UTC解析;3)复杂场景使用dayjs等库处理区转换。核心建议是全链路采用ISO 8601+UTC标准,避免隐式区解析,并通过工具库规范间处理流程。

2401_84182005的博客 230

Linux 系统 Bug 调试操作手册

本文是一份Linux系统Bug调试操作手册,主要面向有基础Linux经验的后端开发人员,指导如何独立定位中低复杂度问题。手册适用于Ubuntu 20.04/22.04/24.04(systemd体系),覆盖崩溃(Crash)、挂起(Hang)、OOM、性能劣化、服务启动失败五类问题。 手册首先提供了60秒快速信息采集清单,包含12个关键命令用于获取系统状态快照。随后给出了分层排查决策树,按照「内核层→系统资源层→服务层→代码层」逐层缩小问题范围。最后针对五类常见问题分别提供了专项排查步骤和流程图: 进程崩溃

m0_37772174的博客 337

bug分析记录

bug分析定位总结

weixin_44073050的博客 334
上一篇: 使用Postman创建Mock Server
下一篇: 想要转行的一定要看软件测试发展简史+学习路线
荔枝味奶糖
博客等级 码龄4年 8048粉丝 302原创
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值