总结：开发容易出Bug的代码或操作

又有一段时间没有发表文章了，感觉在同一个公司待久了，能写出来的东西就少了，呵呵，大家是不是有一样的感觉。 今天来总结一下开发常见的易引发错误或影响效率的东西。

又有一段时间没有发表文章了，感觉在同一个公司待久了，能写出来的东西就少了，呵呵，大家是不是有一样的感觉。

 

今天来总结一下开发常见的易引发错误或影响效率的东西。

开发对于懂开发的人来说其实很简单，做开发这项工作简直就像日常吃饭一样熟练，但是，开发过程中，由于各种各样的问题，例如：业务逻辑不清晰、开发人员粗心、开发人员经验不够、生产环境不同等等，这些问题导致各种BUG，是需要特别重视的，下面整理了一些情况来说明问题。

svn文件漏提交影响他人开发，这个在实际开发中出现比较频繁.

A:漏提交文件（自己不知道，他本地代码编译没报错）

B:获取编译报错，在群里大叫“谁的代码，编译不过”

…………过了半天没有回答，去查下svn提交记录，查出是A提交后就出问题了

B: 在QQ群里，“@A，你提交的有问题，自己去看下”

A: 看下自己果然有文件没提交，赶紧把漏提交的文件提交了，在群里回复“可以了，再获取下”

……然后，就ok了。

 

 

非空判断

B2bDistributorOrderMapping distributorOrderMap = allDistributorOrder.Where(o = o.OrderId == order.OrderId).FirstOrDefault();

var amount =  distributorOrderMap.CreditAmount.GetValueOrDefault(0M);//如果distributorOrderMap为空，则必定报错

循环内多次连续读取数据库-最大可能导致数据库服务器cpu高

while (hasData)//每天订单数10000的情况下

{

var orderListQuery = OrdersRepository.Entities.Where(o = o.CheckInDate = usedDate (o.FinanceReceiptDate = usedDate || o.CheckOutDate = usedDate) o.CancelStatus != (int)OrderCancelStatusEnum.OrderCanceled o.OrderStatusId == audited);

if (loopCount == 0) order = orderListQuery.OrderBy(o = o.OrderId).FirstOrDefault();

else order = orderListQuery.OrderBy(o = o.OrderId).Skip(loopCount).FirstOrDefault();

if (order == null) hasData = false;

else hasData = true;

loopCount++;

}

逻辑不严谨-粗心导致

//正确代码

{

if(a==1) return 100;

else return 0;

}

//错误代码

{

var retVal;

if(a==1) retVal=100;

retVal = 0;

return retVal;

}

测试代码写死临时本地配置（如:192.168.9.220）被误提交，本地测试没问题，一发到线上就报错

 

索引超出范围报错

如：

var a=new int[2]{0,1};//两个元素，下标为0，1

Var b=a[2];//取下标为2的元素，报错

 

数据库基础数据或网站配置不同

比如：

测试环境数据库加了个字段线上忘记加，或本地config配置文件加、改配置，线上忘记改，造成各种报错，也是最常见的错误。

 

 

高级问题：

环境冲突，未考虑测试环境和正式环境

比如：

测试环境上传文件用cdn传文件：http://cdn.xxxx.com/2016-01-01.txt

正式环境文件也是：http://cdn.xxxx.com/2016-01-01.txt

有可能测试环境刚生成文件，造成文件覆盖，正式环境正好在获取，就获取了测试环境的同名文件内容，造成数据错误。

环境不同导致

比如，财务事务补偿正常的操作流程图：

出错情况的正常情况分析：

 

 

总结：

其实有BUG也是正常的，发现后及时修复就行了，但是如果大量的BUG是因为人粗心或思维不严谨、遗漏等原因造成的，那就太不应该了。

所以平日里，我们开发时必须要考虑仔细，提交前至少保证先编译通过，那样问题就会减少很多。

 

接口测试平台代码实现40:修改bug 我们的这个系列已经进行了长达12章成品预览和40章纯开发章节，但是基本还没做过完全一点的测试修复bug章节，每次新开发的功能也仅仅停留在单元/函数层面上的自测。
程序中的Bug是如何产生的？ Bug，总是令人讨厌的东西。那Bug是如何产生的呢？作为高级软件架构师和软件测试工程师的易哥将在这篇文章中解答这个问题。 说起Bug，大家都认为它是被“写”出来的，即主要在开发阶段产生。 但其实Bug的产生最有可能是在需求阶段（意外吧！这是有统计数据证明的），且在需求阶段产生的Bug影响最大。当然，在设计、开发、使用阶段也会出现Bug。 接下来我们详细了解下Bug的相关知识。
代码没有任何改动，为什么程序执行会有Bug？ 题记：工作中经常遇到开发不同的版本，如版本5.1、版本5.2，5.2版本是在5.1版本上的升级，会修改已有几个模块的功能或者新增功能。但对于其中一个模块M，没有做任何修改，奇怪的是，为什么5.2版本的模块M会有Bug？