软件测试之面对诡异bug的经验分享

软件测试之面对诡异bug的经验分享

一、编码

01、事件顺序

当处理事件时，问以下问题富有成效：事件是否可以以不同的顺序到达?如果没收到这些事件怎么办?如果事件在同一行出现两次怎么办?即使这通常不会发生，在系统的其他部分(或交互系统)中的bug也会导致它发生。

02、处理太早

03、隐蔽故障

例如，一些最难找的的 bug 是由于出现了隐蔽故障而继续执行而不是给出错误的代码导致的。例如，系统调用(如绑定)返回未检查的错误代码。另一个例子：当遇到一个错误元素时，直接返回而不是给出错误的解析代码。调用在故障的状态下持续了一段时间，使得调试的难度加大。一旦故障被检测出，最好要及时返回这个错误。

04、If语句

含有多个条件的If语句(if (a or b)，尤其是当嵌套时，if (x) else if (y))，给我导致了许多 bug。即使If语句在概念上很简单，当它有多个条件需要追踪时，很容易出错。最近我尝试重新把代码写得简洁，避免出现复杂的If语句。

05、Else

有一些bug的产生是由于没有恰当地考虑如果条件为假，什么应该发生。在几乎所有的情况下，每个If语句都应该有个else部分。而且，如果你在If语句的一个分支中设置了一个变量，你也许应该在其他分支也设置该变量。与此相关的是标志(flag)被设定的情况。仅仅添加设定标志的条件很容易，但是容易忘了添加应该重新设定标志的条件。任由永久性设定的标志留在那里可能会在将来导致 bug。

06、改变假设

一开始最难预防的许多bug是由不断变化的假设引起的。例如，最初仅仅只有一个客户，在这个假设下写了很多代码。后来某个时候，设计发生了变化，允许每天有多个客户事件。当这种情况发生，就很难改变受到新设计影响的所有情况。很容易找到显式依赖该变化的所有项，但是难的部分是，找到隐式依赖旧设计的所有情况。例如，可能有代码读取给定某一天的所有客户事件。一个隐式的假设可能是，结果集中元素的数量绝对不会大于客户数量。我没有好的方法可以预防这类问题，欢迎读者建议。

07、日志记录

深入了解程序所做的任务是至关重要的，尤其是当逻辑复杂的时候。确保添加足够的(但也别太多)日志记录。那样你就能弄清楚为什么程序在执行它执行的任务。让一切运转良好时，它无关紧要。但是只要问题发生(这不可避免)，你会很庆幸你添加了合适的日志记录。