Low-hanging Fruit

14 Sep 2014   Category: Testing

业界，尤其是测试界，最近几年反复被提及的，除了Agile/Scrum/TDD，可能就是Exploratory Testing（ET）了。个人觉得，不过是新瓶装旧酒，强调的无非还是“学习-积累-应用”这一套行之四海的方法。有心人一定或多或少都用ET的方法进行过测试。不过事实就是这样，任何事一旦套上名头，唬起人来似乎也格外有自信。

不过我今天想说的可不是ET，而是一种不需要花费大量心力和时间，但也能收获一些bug的方法。也就是人们常说的Low-hanging Fruit，我个人简称为LHF .

ET确实是谁都可以做，不过想做得好，学习积累的过程必不可少。而经验丰富的工程师，也更易于找到软件有风险的地方，并且有针对地创建不同的场景来做ET。进而快速地搭建环境并验证，这样才能发挥ET最大的功效。而这一点，对我们现在的团队，受限于测试工具/框架/软件复杂度/外部依赖等各种原因，如果想创建一套稳定的测试环境来快速验证各种场景，还是需要花费不少功夫的。这样就极大限制了ET在团队中的推广，大家也更倾向于在已有稳定的环境中工作。

当然，环境和场景如果一成不变，也就意味着有大量的bugs，可能因为场景缺失而泄露。但如果我们能在有限的空间内，用很少的effort找到更多的bugs，是否也是一件有必要且极划算的买卖呢？事实上，过去两三年，我一直在跟踪统计我们组测试过程中泄露出去的defects。发现有1/3强的问题都是和“check points缺失”有关，排在所有原因中的首位。

这就意味着，其实我们的场景和环境都已经搭建好了，甚至case都有的，只是因为各种原因，未对某些结果检查，导致问题漏过去了。光想想就让人沮丧：如果能先期对case和pass criteria进行一番refactor，我们就能减少1/3的bug泄露。

亡羊补牢犹未晚也。那就来总结一下，那些容易被我们忽视的low-hanging fruit. 请注意，low-hanging fruit绝不等于low value fruit.

1. 软件打印log的检查。系统打印出的任何error和warning都可能是潜在的问题，尤其是老版本上没有，新版本上出现的这种打印尤其要注意。而log打印也会占用CPU load，因此如果发现massive log printing，一定也是某个component出现了异常导致的；
2. CPU load检查。在容量测试和功能测试中都应该注意，尤其是软件开发初期，可能压力并不大的情况下，就出现了高到异常的CPU load（可通过经验或简单的比例来推算满负荷时的CPU load）。这样就不用等到软件开发后期，容量测试进行中发现问题再进行refactor。问题发现得越早，refactor或优化的成本越低；
3. 增加loop数来测试简单的stability。比如让软件在晚上或者周末自动跑成千上万个loop。软件中某些bug，可能通过简单的几次循环，未必能发现得到。尤其是一些内存泄露的问题，往往要积累到一定程度，才能彻底爆发出来。而这种问题，一旦发现一个，也是价值非常高的bug了。
4. 尝试不同的参数值和参数组合。虽然场景不一定好轻易改变，但参数改变还是很容易的。作为系统测试人员，我们不用遍历所有参数值（事实上不可能也没必要），但我们可以基于经验来选择一些关键参数来验证它们的边界或者组合条件。

个人而言，ET带给我最大的感受，是先学习后印证想法的快乐，以及目标是A功能结果斜刺里杀出个B功能的bug这种意外之喜。而LHF，就是躺在地上捡钱的快乐–大量的bugs被人视而不见–稍微动动手就可以摘到那些挂得很低的果子。而这，对一些新人而言，是可以积攒大量bug经验的绝好机会。量变引发质变，才有机会摘到那些high-hanging fruit.