展开

关键词

编写BUG报告有诀窍?Toulmin模型来帮忙

前不久,桓哥的分享PPT中提到了Toulmin论证模型,并在其中提到了这么一句话“尝试建议:用Toulmin模型指导编写BUG报告(特别是容易被忽略限定部分,即BUG隔离)”。 了解完Toulmin论证模型,最后,我们尝试在BUG报告中引入该模型,以如下BUG为例: ? 参考桓哥的PPT资料,并且跟桓哥探讨后,汇总了Toulmin论证模型BUG报告各字段之间的关联关系,如下图: ? 、不断缩小复现步骤; 予料是触发手段,直接原因; BUG报告中不能简单的写予料主张,没有环境配置、版本反驳,尤其是不必现的问题; 利用Toulmin论证模型进行思考,不断的寻找反驳,是有助于找到BUG 的必现条件; 好的BUG报告应该符合这样的逻辑结构,尤其是保证、限定部分; 由此而输出的清晰的bug描述,不仅可以帮助开发快速定位问题,还可以因此减少开发要求测试不断复现的时间成本沟通成本,一举两得

65881

横向双倍外边距BUG — IE6盒模型

另一方面,我们几个讲师一直将IE6作为辅助测试的工具-如果子级盒模型大小超出了父级大小,那么在IE6下必然是崩溃的。 对于这种低级错误,虽然其他浏览器都能够处理调整,但是却绝不是一个专业开发人员会犯的~ margin双倍间距bug IE6存在不少的兼容问题,今天要说的是IE6的横向双倍外边距。 触发条件 当浮动元素的浮动方向浮动边界的方向一致。此时用IE6查看网页,就会发现,设置的横向的边距变成了双倍。 例子:元素向左浮动并且设置了左侧的外边距出现了这样的双边距bug。 同一行如果有多个浮动元素,第一个浮动元素会出现这个双边距bug,其它的浮动元素则不会。 修正bug 只需要给浮动元素加上display:inline;的CSS属性就可以了。

29130
  • 广告
    关闭

    开发者专享福利,1988元优惠券限量发放

    带你体验博客、网盘相册搭建部署、视频渲染、模型训练及语音、文字识别等热门场景。云服务器低至65元/年,GPU15元起

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    判别模型 生成模型

    这种方法一般建立在统计力学bayes理论的基础之上。 如果对条件概率(后验概率) P(q|o)建模,就是Discrminative模型。 利用正负例分类标签,focus在判别模型的边缘分布。目标函数直接对应于分类准确率。 - 主要特点: 寻找不同类别之间的最优分类面,反映的是异类数据之间的差异。 ,从NLP领域产生的,正在向ASRCV上发展。 CRF(条件随机场),又称为马尔可夫随机域 一种用于标注切分有序数据的条件概率模型。 从形式上来说CRF可以看做是一种无向图模型,考察给定输入序列的标注序列的条件概率。 标号场为隐随机场,它描述像素的局部相关属性,采用的模型应根据人们对图像的结构与特征的认识程度,具有相当大的灵活性。 空域标号场的先验模型主要有非因果马尔可夫模型因果马尔可夫模型

    48660

    生成模型判别模型

    生成模型可以产生数据,判别模型只能根据数据做判断。 生成模型的指导思想是贝叶斯,判别模型的指导思想是频率学派 生成模型 生成模型(Generaive Model)一般以概率的方式描述了数据的产生方式,通过对模型采样就可以产生数据。 我可以用最大似然方法,根据已有的样本估计出模型的参数,再对这个模型进行采样,就可以得到更多的样本,这些样本之前的样本在空间分布上可能差不多。 判别模型 判别模型(Discriminative Model)对数据之间的映射关系建模,而不考虑数据本身是如何生成的。 常见模型的分类 生成模型 高斯混合模型其他类型的混合模型) 隐马尔可夫模型 贝叶斯网络(例如Naive bayes,Autoregressive模型) LDA 玻尔兹曼机器(例如受限玻尔兹曼机器,深信念网络

    54910

    判别模型生成模型

    判别模型生成模型总结与对比: 判别模型(Discriminative Models) 生成模型(Generative Models) 特点 在有限样本条件下建立判别函数,寻找不同数据间的最优分类面, 3.可用于多类对的学习识别。4.简单、容易学习。 1.面向整体数据的分布。2.能够反映同类数据本身的相似度。3.模型可以通过增量学习得到。 2.在训练时需要考虑所有的数据元组,当数据量很大时,该方法的效率并不高 3.缺乏灵活的建模工具插入先验知识的方法。 黑盒操作:变量间的关系不可视 1.生成模型分类器需要产生的所有变量的联合概率,资源使用量大。2.分类性能不高,类别识别精度有限。3.学习计算过程复杂。 性能 较高 较低 NLP应用 所有的序列标注结构化学习 文本分类、词性标注等 原文链接:https://www.jianshu.com/p/e57aabf32c18

    24440

    判别模型生成模型

    监督学习方法分为生成方法判别方法,学习到的模型分为生成模型判别模型。 例子 对于简单的二分类问题 判别模型:学到一个好的分界线,直接把两类区分开 生成模型:学到两类各自的分布,当新的数据来的时候,看看属于哪个分布从而区分数据 判别模型与生成模型的对比 特点 判别模型 生成模型 )=P(X|Y)P(Y) 特点 反映异类差异;学习准确率更高;不需要数据分布的假设 反映同类的相似度;反映数据本身的特性;收敛更快,适合数据较小的情况 典型方法 逻辑回归、SVM 朴素贝叶斯、马尔科夫模型 、高斯混合模型

    484100

    生成模型判别模型

    生成方法判别方法 监督学习方法又分生成方法(Generative approach)判别方法(Discriminative approach),所学到的模型分别称为生成模型(Generative Model )判别模型(Discriminative Model) 判别方法 由数据直接学习决策函数 或者条件概率分布 作为预测的模型,即判别模型。 基本思想是有限样本条件下建立判别函数,不考虑样本的产生模型,直接研究预测模型。典型的判别模型包括k近邻,感知级,决策树,支持向量机等。 这样的方法之所以成为生成方法,是因为模型表示了给定输入X产生输出Y的生成关系。用于随机生成的观察值建模,特别是在给定某些隐藏参数情况下。典型的生成模型有:朴素贝叶斯法、马尔科夫模型、高斯混合模型。 这种方法一般建立在统计学Bayes理论的基础之上。

    7930

    贫血模型充血模型

    贫血模型是指领域对象里只有 get set 方法(POJO),所有的业务逻辑都不包含在内而是放在 Business Logic 层。 在使用 Spring 的时候,通常暗示着你使用了贫血模型,我们把 Domain 类用来单纯地存储数据,Spring 管不着这些类的注入管理,Spring 关心的逻辑层(比如单例的被池化了的 Business 充血模型层次结构上面的差不多,不过大多业务逻辑持久化放在 Domain Object 里面,Business Logic 只是简单封装部分业务逻辑以及控制事务、权限等,这样层次结构就变成 Client 充血模型的层次模块的划分是一门学问,对开发人员要求亦较高,可以考虑定义这样的一些规则: (1)事务控制不要放在领域模型的对象中实现,可以放在 facade 中完成。 例如,考虑到性能的需要,我需要一次查询出满足某种条件的用户某种条件的产品,他们二者之间通过订购关系关联起来,可能发现这种情形下,上述的模型层次划分变得无解了…… 怎么办呢?

    8410

    用例bug描述规范参考

    一一 BUG描述基础知识 Bug标题中需包含Bug的具体位置并以【】标注 举例:【模块-子模块-页面】XXXXXXXXXXXX Bug标题中切勿出现错别字 错误示例: 奔溃(崩溃),电击(点击),登陆, 特殊条件下的Bug必须详细描述产生Bug的前提。 示例:只有在使用附件中的图片(大图片:60M)时,会出现此BugBug的附件中包含的截图需增加相应的红框标识,便于Bug的定位。 所提Bug附件的命名需要与Bug标题相呼应,不能出现名称怪异或冗长。 描述Bug过程中“预期结果”与“实际结果”必须有条理且符合逻辑。 Crash的Log取的时间尽量不能超过10分钟。 Bug截图、视频、Log以及描述需Bug内容必须相符合。 交付过程中需对提出Bug内容进行梳理归类不能出现明显的重复Bug。 二一 用例设计基础知识 用例执行前,需要制定严格的测试计划,而且测试计划中必须留出半天的内部审核时间。

    70451

    检测代码潜在bug质量之SonarQube

    >通用–>通用中设置) 项目分析参数,通过WebUI设置,覆盖全局参数(在项目级别的配置–>设置中设置) 项目分析参数,定义在项目的分析设置文件(如:sonar-project.properties)分析器的配置文件 关键字 描述 默认值 sonar.host.url 服务器地址 http://localhost:9000 sonar.projectKey 项目Key唯一标示,可以是字母、数字、’-‘、’_‘、’.’

    48510

    如何优雅地分析防范前端 BUG

    两个公式 开发效率 = 1 - (思考时间+编码时间+debug时间+改bug时间) / 迭代总时长 bug率 = bug数 / 测试用例数 八种问题 需求理解不透彻 视觉交互没过细 语言基础待加强 错误异常未处理 代码逻辑太混乱 边界情况欠考虑 后端接口常变动 二次修改漏东西 需求评审 需求理解 bug原因: 开发产品对需求的理解不一致 前期经过沟通达成一致的需求,在开发后期忘做了 多个模块关联同一份代码 Q:本地缓存接口中的题目顺序信息同时存在,题型顺序以哪个为准? 拆分功能点,形成todolist,并附上优先级,在完成阶段性功能时, 逐一检查git提交文件 团队一起讨论解决方案,自己想出来的不一定是最好的,不成熟的方案会导致后期维护成本高,隐藏bug多 示例1 再次提测是补考 在考试完后看到成绩进步时,动力会更大,更期待下一次的检验 小学考满分次数多,其次初中,高中;能力提高,写法更高级,bug越难发现,但解决完bug后自我提升更明显,程序设计能力开发效率都会提高

    10610

    bug?

    12430

    Actor模型CSP模型的区别

    首先这两者都是并发模型的解决方案,我们看看ActorChannel这两个方案的不同: Actor模型   在Actor模型中,主角是Actor,类似一种worker,Actor彼此之间直接发送消息,不需要经过什么中介 ,消息是异步发送处理的: ?    Channel模型   Channel模型中,worker之间不直接彼此联系,而是通过不同channel进行消息发布侦听。 消息的发送者接收者之间通过Channel松耦合,发送者不知道自己消息被哪个接收者消费了,接收者也不知道是哪个发送者发送的消息。 ?    通道channel: 类似Unix的Pipe,用于协程之间通讯同步。协程之间虽然解耦,但是它们Channel有着耦合。 Actor模型CSP区别   Actor模型CSP区别图如下: ?

    1.1K10

    彻底搞懂Reactor模型Proactor模型

    在高性能的I/O设计中,有两个著名的模型:Reactor模型Proactor模型,其中Reactor模型用于同步I/O,而Proactor模型运用于异步I/O操作。 想要了解两种模型,需要了解一些IO、同步异步的基础知识,点击查看 服务端的线程模型 无论是Reactor模型还是Proactor模型,对于支持多连接的服务器,一般可以总结为2种fd3种事件,如下图: Reactor模型 无论是C++还是Java编写的网络框架,大多数都是基于Reactor模型进行设计开发,Reactor模型基于事件驱动,特别适合处理海量的I/O事件。 但是这个模型存在的问题: 多线程数据共享访问比较复杂。如果子线程完成业务处理后,把结果传递给主线程Reactor进行发送,就会涉及共享数据的互斥保护机制。 通过配置bossworker线程池的线程个数以及是否共享线程池等方式,Netty的线程模型可以在以上三种Reactor模型之间进行切换。

    29.4K1914

    Bug之路-串包Bug

    Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPUIO有大量的尖刺,CPU示意图下图所示: ? Bug复盘 此次Bug是由Redis本身Server负载太高超时引起的。Bug的现象是通过Jedis去取对应的Key值,得不到预期的结果,简而言之包乱了,串包了。 缩小Bug范围 首先:Redis是全球久经考验的系统,这样的串包不应该是Redis的问题。 第二:Redis刷新了key后Bug依然存在,而业务系统重启了之后Okay。 在客户端每次接收到数据的时候,获取包中的packetId之前发出的packetId相比较,如下代码所示: if(oldPacketId !

    40710

    Bug之路-串包Bug

    笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑。 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget、hset操作将Redis拖垮,通过监控发现Redis的CPUIO有大量的尖刺,CPU示意图下图所示: CPU达到了100%,导致很多 Bug复盘 此次Bug是由Redis本身Server负载太高超时引起的。Bug的现象是通过Jedis去取对应的Key值,得不到预期的结果,简而言之包乱了,串包了。 缩小Bug范围 首先:Redis是全球久经考验的系统,这样的串包不应该是Redis的问题。 第二:Redis刷新了key后Bug依然存在,而业务系统重启了之后Okay。 在客户端每次接收到数据的时候,获取包中的packetId之前发出的packetId相比较,如下代码所示: if(oldPacketId !

    13710

    瀑布模型快速原型模型的共同点_增量模型瀑布模型的区别

    软件开发过程模型 在软件开发的几十年实践中,人们总结了很多软件开发模型用来描述表示一个复杂的开发过程,如: 软件测试与软件的开发模式有着紧密的联系,作为一名测试人员,应该充分理解软件的开发模式, 瀑布模型 1、是线性模型的一种,在所有模型中占有重要地位,是所有其他模型的一个基础。 2、每一个阶段执行一次,按线性顺序进行软件开发。 螺旋模型 螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,螺旋模型沿着螺旋线旋转,即在坐标的4个象限上分别表示了4个方面的活动,如图所示: 制定计划 风险分析 实施开发 客户评估 螺旋模型优点 螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。 螺旋模型缺点 采用螺旋模型需要具有相当丰富的风险评估经验专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失。过多的迭代次数会增加开发成本,延迟提交时间。

    11940

    Bug之路-Druid的Bug

    Bug之路-Druid的Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。 前言 此Bug是Druid低版本的Bug,此Bug至少在1.0.12版本就已经修复。 大量create connection error 当笔者同事追查错误的源头的时候,在有大量的create connection error,奇怪的是,到了一个时间点之后,就只剩GetConnectionTimeoutException 于是通过笔者同事在无数的错误日志中用肉眼发现了一个不寻常的日志隐蔽在大量的错误日志间: Druid:create holder error 在这个错误出现之后,就再也没有了create connection 终于这次的连环Bug算是填完了。 总结 追查Bug,日志源码是最重要的两个部分。最源头的日志信息量最大,同时要对任何不同寻常的现象都加以分析并推测,最后结合源码,才能最终找出Bug

    47850

    Silverlight ToolKit-AutoCompleteBox bug(Style bug)

    Silverlight ToolKit-AutoCompleteBox bug(Style bug) 现象 第一次选择输入a没有问题 ?

    463100

    图灵图灵模型

    艾伦·麦席森·图灵(Alan Mathison Turing,又译阿兰·图灵)是英国计算机科学家、数学家、逻辑学家、密码分析学家和理论生物学家,他被视为计算机科学人工智能之父。 2015年2月23日,图灵的家人向英国首相府邸发出一份超过50万人签名的请愿书,要求英国政府赦免49,000个图灵一样因同性恋而获罪的人。

    46630

    扫码关注腾讯云开发者

    领取腾讯云代金券