如何选择嵌入式白盒测试工具.docx

如何选择嵌入式白盒测试工具 恩格斯说“劳动从制造工具开始”，人和动物的木质区别是：人会制造与使用工具。IT 产品研发也从选择合适的工具开始，工貝好坏对项忖成败往往起着关键作用，尤其是嵌入式领 域的白盒测试工具选型。尽管业界已有众多商用工具，但大部分仍处于可将H盒测试推动起來 的边缘状态,选择工具稍有不慎，就导致白盒测试整体做不起來，授终严重影响推向市场的产 品质量。 先澄清两个概念 在分析如何进行工具选型之前，我们先剖析诙入式软件，当前状况下影响白盒测试开展的最主要障 碍是什么？然后才推导嵌入武软件白盒测试工具选型应遵循的评估模熨。 先澄淸两个概念，其一，在嵌入式研发领域，影响白盒测试推行的最主要障碍是工具的使用效率， 或者说借助测试工具，你要花多长时间才将单元测试与集成测试做完整。在《企业如何推行白盒测试》 一文中，我们介绍了白盒测试的分区推动理论，如下图： 测试同比曲线反映了测试工具的使用效率，测试效率越高，该指标取值就 越高。如果测试效率偏低，测试同比小于2/3 （大致是每写2天代码要3天 才能测完整）是强制推动区，这个区域对于绝大多数企业来说，白盒测试作 为一项组织行为注定要失败I何测试效率够高，测试同比超过3/2（大致是每 写3天代码2天就测完整）是自发推动区，口盒测试即使没有相关流程推动, 研发人员也能自觉、自发的实施起来。所以，选择测试工具至少要求使用它 的效率应保证测试同比大于1,测试同比为1是个拐点，即每写一天代码只用 一天就测完整,请注意，我这里讲的是“测完整”，不是简单的比划几下， 而是用例总量、覆盖率等都达到一定的指标，另外强调“每写一天代码”， 指的是代码每次改动，都冇白盒测试跟进，I佃不是一次性编码、一次性测试, 如果是一次性测试，相信多数商用工具都能超越拐点，但保证整个产品周期 都做到这一点，就很难了。目前适用做嵌入式白盒测试的商用工具屮，大多 数都没达到该要求，所以，多数情况下必需有良好的组织，有强有力的流程 推动，白盒测试才做得起来。 另一个概念，嵌入式产品面对复杂的运行环境，形形色色的实时系统、编 译器与设备驱动，都导致白盒测试困难重重，但白盒测试必须要到实际运行 环境中去做吗？未必，也不应该这样推崇。《实施白盒测试的儿个误区》一 文己冇详细分析，嵌入式软件应在仿真机环境实施白盒测试，“上真实环境 做代码级测试”实际上是个伪命题，实践中很难行得通，或者说，行得通但 代价太高，远没突破前面所提的效率拐点，所以，在各种条件受限的实时环 境下做白盒测试，还不能将它上升到过程有保障的组织行为。 嵌入白盒工具的评估模型 评估一个测试工具的好坏，采用评估标准不同，所站的角度不同，评估结 果大相径庭。所谓每个人的心中都有杆称，让测试人员选工具，他会站在测 试的角度去选择，会更注重白盒测试能做得下去，Z后才有兴趣深入去做， 如果让质量人员去选，他会侧重于质量保障坏节，比如非常看重覆盖率评估、 测试报告提交等，但如果让企业老板选工具，恐怕他首先考虑的是这个工具 的价格。所以，测试工具的选型过程，必然是各种I大I素综合考虑的权衡过程。 进行公止的工具选型首要问题是：如何选择评估要素并赋予不同的权重，套 用一句规范术语，我们先建模，确定评估模型，再按条目打分作决策。 建立评估模型应考虑如下几个因素： 应用范围 首先明确你期塑引入某工貝?的应用范围，这个业务范围内都有哪儿类利益相关人，然厉确 定评估项H,为各评估项分配权匝。如果不明确工具适用的业务范围，或确定范围不恰当，肯 定会影响评估的准确性，比如你希望某个白盒测试工貝，既支持单元测试，乂支持集成测试， 这是一种想法，如果把它换成：想要一个能支持单元测试的工具就够了。这两种H的故终的评 估结果肯定很不一样，还有，应关注适用范围的条件限定，比如，你想要一款既支持C, 乂支持 C++的测试工具，或限定要支持某特定编译器（如GCC）的。期望工具的适用范用不仅要明确， 还耍合理，比如：你期望一款既支持白盒测试，又支持功能测试，另外还支持性能测试的工具， 最后的选型结论肯定会让你失望，没有这种万能工具。 确定适用范围后就可以分析利益相关人，比如你选择单元测试工貝，重点是考虑编码人员 的需求（注：单元测试的主体应山编码者自己承担，这是另一个话题，木文不展开），而你要 的工具既支持单元测试，乂支持集成测试，就不能不考虑测试人员的提议了。 合理选择评估项目，分配不同的权重 上而讲到先确定应用范围，由应用范围确定相关人后，选择评估要 素就容易明确下来了，最简单的方法是：把相关人叫过来，让他们一条 一条的说出他关心哪些问题，把这些问题排个序。当然，叫相关人员过 来讨论并非必须，如果评估者对各个适用领威都很熟悉，他诂在各个利 益相关人的角度细想一遍也行。 需要注意两点，一是不要漏掉