根据bug的大小,如果影响业务逻辑及用户提醒及时处理,如果只是一些状态.文案等等对业务无重大影响可以跟版本迭代走 很严重的bug必然要回滚,想都不要想赶紧去着手安排做. 检查回滚版本是否会丢失数据,如果危害小可以让用户自己决定是否忽略(推送告知用户会丢失哪些数据一般说「部分数据」),如果危害大,替问题用户保存好数据并告知用户不要轻易回滚. 配合开发及测试人员,快速定位bug,并且锁定影响范围. 做好备份,及时发出上线公告,产生bug的功能暂且不上线,其他功能继续上线. 上线成功后,做一个上线总结

软件测试人员遇到发现的bug不能重现怎么办?   刚刚进入测试的童鞋们,想必都遇到过提出的bug,开发要求重现之后,但是在系统上已经重现不了的情况吧. 那么碰到这样的情况,不管开发还是测试都很纠结,开发考虑,如果拒绝,万一单子打回之后又出现了这个问题,那还要给我返回来;测试也会考虑,老是碰到无法重现的bug,总是给我打回来,我也觉得挺郁闷的. 那么碰到这样的bug应该如何处理呢? Sometime的bug真的要打回吗?测试人员碰到了应该怎么去做?接下来我们就一起讨论一下这种运气成分的bug. 首

请先允许我对此类bug进行吐槽,相信做测试的同学都碰见过这种bug! 我们在测试过程中经常会碰见一类很头疼的bug,就是偶现性的bug,所谓偶现性,是相对于必现而言,这类bug有些可以有重现路径,但是可能需要重复操作十几次甚至上百次才可能重现一次,重现概率比较低,这种bug我暂分类成偶现可重现.另一种则是没有重现路径,找不到任何的规律,但时不时的会出现,这个分类成偶现且难以重现.对于这类偶现bug,测试很头疼,因为需要花费相当多的时间去复现bug,修复之后还要去验证.开发也很头疼,测试如果没法复

译者按: 等待用户反馈BUG,一切都晚了!实时监控线上应用才是王道. 原文: Why relying on your users to report errors is the dumbest thing you’ll ever do 译者: Fundebug 为了保证可读性,本文采用意译而非直译.另外,本文版权归原作者所有,翻译仅用于学习. 我们热爱coding. 当我们coding的时候,就如同从零建造一栋大楼.新的特性.新的功能.绝佳的设计都在每一次更新后被用户所使用,期待他们的喜爱和赞美

怎样才能提交一个让开发人员拍手叫好的bug单 软件测试人员写得最多的文档就是测试用例和BUG,现在测试用例和BUG都没有标准的模板,每个公司使用的缺陷管理工具都有可能不一样,如果你换了一家公司就有可能接触到新的缺陷管理工具,但提交bug的方式却是大同小异,今天这篇文章主要讲解怎样才能提交一个高质量的BUG单. 目录 为什么要提交BUG单 缺陷管理工具 编写高质量的BUG单 为什么要提交BUG单 其实要提交BUG单的原因很简单,就是在测试过程中程序中出错了,那么测试人员就要提交BUG单,以便开发人

阿里QA导读:为什么要度量测试有效性?这么多的CASE,花了大量时间和资源去运行,真能发现bug吗?CI做到90%的行覆盖率了,能发现问题吗?测试用例越来越多,删一些,会不会就发现不了问题了?怎么找出那些为了覆盖而覆盖,发现不了真正问题的测试用例?本文带您探索其中的奥秘. 什么是测试用例的有效性? 我们的测试用例有两个比较关键的部分: 1)调用被测代码:例如下面的RuleService.getLastRuleByClientId(ClientId) 2)进行结果Check:例如下面的Assert

在日常开发过程中难免会因为一时疏忽而留下一些Bug,这些Bug就是埋在程序里的定时炸弹,如果不能及时铲除就会导致程序的不稳定,异常或闪退的现象,从而导致用户的体验的下降.那么怎么才能找出这些埋在程序里的定时炸弹呢?   对程序员来说最头疼的事情莫过于找Bug了,尤其是找自己程序中的Bug,因为人的思维是有误区的,他很容易陷入当时开发程序时的思维,这样就很难发现埋藏在程序中的Bug.接下来就给大家分享一个Bugs分析的工具FindBugs.   Findbugs是由 National Scienc

导读:在互联网企业,任何一个APP都要事先规划好数据体系,才允许上线运营,有了数据才可以更好的科学运营.因此本文将为大家介绍APP的基础数据指标体系.主要分为五个维度,包括用户规模与质量.参与度分析.渠道分析.功能分析以用户属性分析.正文 作者:傅志华  来源:鸟哥笔记

群友半夜2点被产品叫起来改东西,然后他打车去公司加班,群友愤慨,特为此创作一个小段子 产品:XXX出bug了你赶紧看看 修复一下 开发:我宿舍没电脑 没网络啊 产品:你看看周围有没有网吧远程一下 或者打车来公司 开发:我住的很偏僻,这边没网吧,现在打车的话要七八十块钱,工资还没到账,你看看能不能先帮我垫付一下 产品:……(欲言又止 思考片刻 整理语言 重新说话) 产品:那你看看有没有其他办法,毕竟问题要解决啊! 开发:你说的那个问题你确认了吗?自己体验了吗? 产品:体验了啊,就是有问题啊! 开发

issue中查询是否有相似bug assert / try-except / IDE单步调式 框架可以查询源码或者查询官方文档

一.判断前后端 Safari中可以右键,选择“检查元素”,再选择“网络”同样可以抓取到http请求,如图 怎么区分是前端错误还是后端错误? 1.在开发者工具中,如果console中有报错,则表示前端代码有错误:2.可以network中http请求的headers下的form data来查看传入参数,进而判断是否前端参数传入错误:3.在network中http请求返回错误,则表示后端代码错误.我们可以根据http的请求再进行debug 二.通过查看日志定位后端问题排除掉前端的问题之后,需要逐层分析

原文: http://blog.sina.com.cn/s/blog_6cf812be0102viuh.html 上一次分享了google测试分享-分层测试,有很多自动化测试的策略和实施都要有一个重点和计划,那这次会把google是如何来对SUT制定测试计划的分享下. 为了让这些blog分享更有逻辑性,我打算分几个专题来分享google测试相关的测试理念. google测试分享-SET和TE google测试分享-分层测试 google测试分享-GTA google测试分享-测试经理 googl

本文是一个系列,欢迎关注 查看上一篇文章可以扫描文章下方的二维码,点击往期回顾-日志系列即可查看所有相关文章 概览 上一篇我们讨论了为什么要使用日志框架,这次我们深入问题的根源,为什么我们需要日志? 大多数开发人员会纠结日志该怎么输出,什么时候输出,输出了会不会有人看等问题,让我们跳出开发人员的局限来考虑这个问题:谁需要日志?日志有几种?日志都需要输出什么?如何输出日志? 谁需要日志? 开发者 开发人员在开发过程中需要输出一些变量方便调试,正确的做法是使用日志来输出(使用 System.out来

make命令以及makefile使用RCS与CVS进行源代码控制编写手册页使用patch与tar发布软件开发环境 多源代码的问题 当我们编写小程序时,许多人都是简单的在编辑后通过重新编译所有的文件重新构建我们的程序.然而,对于大程序,这种简单构建方法的问题就变得明显了.编辑-编译-测试的循环时间将会变长.即使是最为耐心的程序员也会希望避免当只修改一个文件时而编译所有的文件. 当创建多个头文件并且在不同的源文件中包含多个头文件时就会出现一个更为困难的问题.假设我们有三个头文件a.h,b.h以及c.

Windows基础 一.什么是软件(software) 计算机(computer)=硬件(hardware)+软件(software) 软  件(software)=程序(program)+文档(document) 注意:软件测试的对象既要测试程序又要测试文档 扩展:软件开发阶段划分 1.需求分析阶段 由需求分析人员完成.产出物:<需求规格说明书> 2.设计阶段 由系统架构师(分析师)来完成设计工作. 产出物:<概要设计说明书>.<详细设计说明书> 3.编码阶段 由开发

Beta阶段团队成员贡献分分配规则 Alpha阶段贡献分分配有些负责,在这里进行一些修改: 对任务完成得分部分进行了简化 对发现bug的惩罚措施进行了修改 移除了优化得分,不鼓励修改他人代码 移除了帮助加成,剔除主观因素 1. 得分细则 1.1 任务完成得分 L=预期任务量(1~8):在布置任务的时候预计所需时间,不再更改 D=难度(0.0~2.0):由于难度产生的时间变数,由之前会议商讨决定,遇到坑的时候及时在群里求助,可以更改 下面是难度系数(D)的评定参考: 评价成绩 效果 0.5 基本没

DevOps在你的组织内部运行的如何?如果你需要一些帮助来度量它的运行情况,我们已经准备了一个用于跟踪的关键DevOps指标的列表,这些度量可以帮助了解你的团队是如何随着时间的推移而运行的. 在团队内部明确DevOps的定义意义重大 DevOps这个词不同的人有不同的理解,有人说这是一种文化,业内的每个厂商都声称他们的工具帮助了DevOps,根据你如何定义DevOps,其中的一些度量可能对你的团队有重要的影响. 我将DevOps定义为与部署和监视应用程序相关的所有内容,从很多方面来说,这都是现实

DevOps在你的组织中运行的如何?如果你需要帮忙衡量它运行的如何,我们准备了一些DevOps的关键指标来进行追踪.这些指标可以帮助理解你的团队过去做的如何. 定义DevOps对你的组织意味着什么 DevOps这个词,不同的人不同理解.有些人说他是一种文化并且行业中的每个供应商声称,他们的工具有助于DevOps.取决于你如何定义DevOps,这些指标会对你和你的团队多多少少有些帮助. 我把DevOps定义为与部署和监视应用相关的所有内容.从许多方面来说,这都是现场可靠性工程的问题.在Stacki

1. 引言 本文所讨论的内容为笔者对外文文献的翻译,并加入了笔者自己的理解和总结,文中涉及到的原始外文论文和相关学习链接我会放在reference里,另外,推荐读者朋友购买 Stephen Boyd的<凸优化>Convex Optimization这本书,封面一半橘黄色一半白色的,有国内学者翻译成了中文版,淘宝可以买到.这本书非常美妙,能让你系统地学习机器学习算法背后蕴含的优化理论,体会数学之美. 本文主要围绕下面这篇paper展开内涵和外延的讨论: [1] Siddiqui M A, Fer

就在昨天(2020年1月14日),服役十年的Win 7正式退出了微软舞台,从2009推出到2019,这十年也是很多90后的青春. 当然微软官方也做了送别,当然其目的也是为了推广Win10! 甚至面对痛恨的盗版,微软也在所不惜,只要你装Win10,就给你免费洗白. 这不禁让我想起了上一代的“钉子户”XP,都快20年了还有人在用XP,为什么呢?稳定.兼容.安全. 其实在XP和7之间还有个“过渡人”——Vista,由于当年微软眼高手低,在硬件达不到软件运行标准的情况下推出Vista,就算高端外星人电脑

引用自:https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md 说明: 个人在学习Git工作流的过程中,从原有的 SVN 模式很难完全理解Git的协作模式,直到有一天我看到了下面的文章,好多遗留在心中的困惑迎刃而解: 我们以使用SVN的工作流来使用Git有什么不妥? Git方便的branch在哪里,团队多人如何协作?冲突了怎么办?如何进行发布控制? 经典的master-发布.develop-主开发.hotfix-