对BUG的分析与理解 bug的分类 bug,其实就是软件期望的行为与实际行为的差异.从程序的角度来看,在软件整个生命周期中都会有bug的出现.需求分析过程中,需求理解的不足,导致的理解错位 ,遗漏甚至变化都可能导致bug:设计本身有好坏之分,但是bug本身还是比较隐晦,不是那么明显. 编码阶段,也会有理解错误,语言特性,第三方库框架,等等导致的bug. 后期打包,部署,运维也会产生 bug,打包的错误,配置错误,以及环境的错位. 自己主要谈谈编码引入的和环境的导致bug.这是最最经常碰到的bug…

1.背景 MGR是个好东西,因为他从本质上解决了数据不一致的问题.不光是解决了问题,而且出自名门正派(Oracle的MySQL团队),对品质和后续的维护,我们是可以期待的. 但是在调研的过程中,发现有个严重的bug(https://bugs.mysql.com/bug.php?id=92690),在网络有延迟.丢包和数据损坏时,会导致各个节点间数据严重不一致.而上述网络情况,在跨地域部署时候,出现的概率还是比较高的,因此,必须解决上述问题.我也一直在等待官方团队的修复(该bug在2018年11月…

一.原理分析 1.调度时机 背景不同类型的进程有不同的调度需求第一种分类I/O-bond:频繁的进行I/O:通常会花费很多时间等待I/O操作的完成CPU-bound:计算密集型:需要大量的CPU时间进行运算 第二种分批处理进程(batch process):不必与用户交互,通常在后台运行:不必很快响应.典型的批处理程序:编译程序.科学计算实时进程(real-time process):有实时需求,不应被低优先级的进程阻塞:响应时间要短.要稳定.典型的实时进程:视频/音频.机械控制等交互式进程(i…

IIS 7.0 支持两种管道模式:一种是IIS 7.0最新提供的集成管道模式,另一种是经典管道模式,经典管道模式是由先前版本的IIS提供的. 我们可以通过应用程序池设置管道模式,这项功能对IIS管理员尤其有用,因为这样既可以令一台服务器仅运行一种模式,也可以令两种模式同时运行于一台服务器上. 上述两种管道模式使用的web.config文件存在重大的区别,许多在经典管道模式下能够正常工作的web.config文件都无法在集成管道模式下正常工作.利用AppCmd.exe,我们可以将经典管道模式下的配…

前言 Context在android中的作用不言而喻,当我们访问当前应用的资源,启动一个新的activity的时候都需要提供Context,而这个Context到底是什么呢,这个问题好像很好回答又好像难以说清楚.从字面意思,Context的意思是“上下文”,或者也可以叫做环境.场景等,尽管如此,还是有点抽象.从类的继承来说,Context作为一个抽象的基类,它的实现子类有三种:Application.Activity和Service(估计这么说,暂时不管ContextWrapper等类),那么这…

Bug描述: 某大型系统的一个提供基础数据服务的子系统A进行了一次升级.升级的内容为:优化了失败重传功能,在优化的同时,开发人员发现传输数据的时间戳精度只是精确到了秒,于是顺手把精度改成了1/100秒.在程序上线数小时后,使用A数据的B系统发现少量数据缺失现象,同时监控系统提示产生Error.进过追踪日志,发现丢失的数据在插入内存数据库时失败.进一步分析原因,原来B系统在读取A提供的数据时,用到了时间戳.时间戳的长度变更引起了B系统对其解析的错误,因此入库失败. 比较有效的改进点: 1.提供基础…

上一篇文章中介绍了GWT技术的一些理论性的东西,涉及到GWT得一些技术原理及实现.接下来笔者将通过创建一个GWT工程去理解分析GWT工程架构.     GWT工程架构解析 笔者使用的是Eclipse插件的方式进行GWT开发,具体开发环境如何搭建我也就不多提了,网上可以搜到.好了我们新建一个GWT工程.展开工程的各个目录结构,如下图所示: src:该目录存放工程的源代码: client:该包下主要存放UI界面部分的代码,会被GWT编译器交叉编译成javascript代码嵌入网页进行调用: serv…

在上面一篇分析ThreadExecutedPool的文章中我们看到线程池实现源码中大量使用了ReentrantLock锁,那么ReentrantLock锁的优势是什么?它又是怎么实现的呢? ReentrantLock又名可重入锁,为什么称之为可重入锁呢?简单来说因为它允许一个线程多次取获得该锁,不过多次获取该锁之后,也需要执行同样次数的释放锁操作,否则该锁将被当前线程一直持有,导致其它线程无法获取.需要注意的是,释放锁的操作需要我们用代码来控制,它并不会自动取释放锁.在ReentrantLock…

如何去区分一个功能测试工程师的水平高和低? 可以从很多个方面去检查,比如测试的思路, 比如测试用例的覆盖度?,比如测试出bug是否能够定位到根因? 上面说的各个方面都很合理,那我们平常如何如更深的定位问题的根因呢? 1.通过我们的测试的经验 这个有点不容易掌握,也不容易传承 2.通过分析bug出现的流程来查找问题的根因, 这个思路可以通过锻炼是自己的技能不断提高 举个例子 BS架构的系统,销售统计报表中的金额不正确?这个时候我们怎么通过流程分析法去精确找到问题的根因呢? 1.分析金额的计算方法…

写在前面 Unity的用户量越来越大,越来越有钱,这几年摊子也铺的越来越大,所以各个版本总是有很多Bug.对于一些Bug官方在ReleaseNote里的说明是很不详细的,而对于一些渲染相关的Bug,有时候更是偷偷的修复,即使贴出来也信息量极少.如果你想复用它的一些内置Shader代码到自己的Shader中时千万要注意. 今天要分析的Bug是我在2017版本(本人使用2017.4)中遇到的,Shader编写完会出现一个 program 'fragXXX':Unrecognized sampler…