软件验证的必要和使用测试工具的好处

软件验证和测试是软件开发必不可少的部分。投入到特定项目中的努力和预算取决于许多因素，如项目的功能安全性、业务风险水平或组织的质量文化。不管是什么因素促使组织实施质量管控，生产安全和高质量的软件产品需要的不仅仅是决心。

选择合适的测试方法是一项具有挑战性的任务。技术正在快速发展，公司必须选择采用哪种软件测试工具。许多情况下，在开源和商业产品之间进行选择也很困难。

这篇文章解释了自动化测试技术，如高级静态分析，运行时内存监控，自动化单元测试和数据流分析，可以组合使用以提高软件质量,并确定使用测试工具的好处。我们讨论的话题是通用的，可以适用于任何编程语言，但这里的例子是C和C++编程语言，我们使用Parasoft C/C++test。

缺陷类与工具自动化

当考虑到可能的高级软件故障时，可以将软件错误分为几种类型：由于缺失需求而导致的错误、由指定需求引起的错误以及由于需求被错误编码而产生的错误。前两类软件缺陷属于需求工程范畴，在这里将不再讨论。我们这里关注的是需求的错误实现，其中包括许多团队所面临的各种各样的潜在软件问题。那么，需求的不正确编码意味着什么呢？它能导致很多种情况，例如：需求的实现不正确——需求相关的单元测试失败并且自动化测试工具报告出缺陷。另一个例子,运行时分析工具可以在单元测试中检测到无法从单元测试结果单独检测到的关键存储器访问错误。不同的工具更好地检测某些类型的错误，如下所示。

▲

图 1. 软件缺陷和检查策略图

显然，并非每一个软件项目都需要使用所有可用的技术来测试和改进软件质量，组织面临着如何平衡预算和质量的两难困境。与功能安全相关的项目可能会选择所有可用的技术以确保质量不受影响，以及符合软件安全标准，如ISO 26262。其他团队可能会决定只选择静态分析和单元测试，因为它们似乎覆盖了软件缺陷的一大部分，并且一些团队可能会找到足够的开源单元测试框架。

不愿意使用多种的测试技术往往源于这样一种担心：使用多种技术会给开发速度带来巨大的开销，更不用说预算了。如果团队决定选择未知的工具，这些问题就更加明显。多个单独工具的成本、学习曲线以及在不同的使用模型和接口之间切换的必要性都是需要考虑的。因此，开发人员可能会避免使用工具和自动化，因为这将他们的注意力从编写代码转向工具使用，从而降低了他们的生产率。

统一测试工具的价值

在讨论一个统一的测试工具的价值之前，一定要详细说明对它的期望。理想情况下,一个工具应该具有以下功能：

·支持多种测试技术

·使用简单

·检测函数问题和回归测试

· 提供从需求到测试的可追溯性

·度量代码的复杂性、可移植性和可维护性

·通过在编写代码时提供即时反馈来改善开发人员代码编写习惯

·提供开发程序进度的信息

·综合多种技术的高级分析结果

一个统一的、集成的测试工具可以避免许多问题：

·多个学习曲线和可用性问题，使用不同接口的独立工具

·分散开发人员编写代码

·防止工具链的不同元素之间的信息交换

尽可能多的检测缺陷

软件缺陷分属于不同的类别，因此不能期望所有的缺陷都通过一种测试技术进行识别。例如，手动系统级测试。下面提供一个更具体的示例，请观察以下示例代码片段：

上面几行代码包含几个问题。具体地说，在第16行中，开发人员试图使用calculateIdx()函数中计算的索引值初始化全局缓冲区，但他们无法验证它是否在允许的范围内。即使运行了数十个手动测试会话，它们也可能不会揭示这个问题，因为向随机内存位置写入一个整数值几乎不会立即产生意外的效果。

但是有一天，最有可能在发布之后，内存布局产生改变，第16行的操作会破坏应用程序。有趣的是，由于用于计算索引的循环，静态分析也不能标记这个问题。由于性能原因，在静态分析工具中使用的数据和控制流分析会使用试探法和简化法来确保在合理的时间内完成代码分析，并且通常它们也会应用于循环中，这意味着可能会丢失一些错误。

使用内存监控工具，通过注入特殊检查和报告不正确的内存操作来检测源代码，肯定会检测到这个错误。运行时分析工具只在实际执行的路径上检测软件问题，而不进行任何猜测——这是静态分析的一大优势，因为报告的问题的准确性非常高。

在本例中，Parasoft的内存错误检测很容易发现问题:

相反的情况也是存在的——静态分析可以检测运行时内存监视无法识别的问题。例如，在下面的代码段中，第27/28行有一个空指针引用的可能性。使用的person指针参数为Null时，调用storePersonToFile函数会发生错误，但是只有当retrivePersonFromDB函数返回null时才会报错。在系统测试期间不太可能出现这种情况，因为数据库连接很可能像预期的那样运行，所以运行时内存监测工具并不能发现问题。然而，静态分析工具中的流分析很容易检测到要从这个函数返回的空指针，并报告一个潜在的空指针引用问题。

▲

图 4. 静态分析结果示例.

检查函数问题和回归测试

那些总是执行起来无缺陷，但不符合要求的代码呢？静态和动态分析在识别这类问题时没有用处。要检测预期结果与实际结果之间的差异，需要将计算结果与预定义值进行比较。实现这种检查有许多的方法，包括手动系统级测试、集成测试和单元测试。在许多领域，统一的测试工具可以促进单元测试过程。优点如下：

·在创建测试用例时提高开发人员的执行力，例如，通过提供图形向导来创建、编辑和配置测试用例

·与Test Double框架相结合,允许简单的mock和stub来模拟复杂的测试场景，而不涉及大型代码库。

·相关测试用例代码覆盖率报告评估测试的完整性

·通过自动计算验证代码增量所需的最小测试用例集来优化测试用例

·将代码覆盖率报告与其他测试技术相结合，如手动或系统级测试或集成测试以识别未经测试的代码

·跟踪结果并与需求关联以更好的理解失败测试的影响

使用图形化向导或编辑器创建测试，可以让QA团队参与到编写单元测试的过程，从而提高整个组织的生产力，使他们积极地为开发过程做出贡献。对于QA团队成员来说，使用图形向导比在代码编辑器中编写适当的测试代码更容易，因为使用输入表单(如下所示)配置值不需要高级的编码技能，而且更省时，尤其是在团队成员缺乏经验的情况下。例如，下面的屏幕截图显示了Parasoft C/ C++test在实现C/C++单元测试能力的一个示例，该向导帮助创建单元测试。

使用统一测试工具的另一个好处是它提供了关于测试完整性和关键业务需求的状态反馈。MC/DC覆盖率报告中的低数字可能表明分支覆盖率不足，即使报表覆盖报告显示了高值。这种分析需要一个支持多覆盖率度量的工具链，允许团队从简单的东西开始，比如行或语句覆盖率，并在改进测试用例的过程中继续进行更彻底的代码覆盖率。

测试可追溯性需求

单元测试和系统测试覆盖报告是关于测试过程的一大信息源，尤其是当它们结合在一起时。但是，如果测试结果与需求不相关，团队就会缺少一些关键信息。通过查看测试到可追溯性的需求报告，您可以快速确定需求覆盖率的状态。此种情况的一个例子如下：

将需求与来自不同类型测试的结果关联起来的能力是使用统一测试工具的一大好处。单元测试，系统测试，集成测试结果，编码标准和代码度量结果可以通过关联来提供对关键和非关键需求的状态反馈。

结合不同技术的结果进行高级分析

当你组合来自项目中使用的各种测试技术的数据时，你可以获得二级度量和更复杂的分析。使用统一的测试工具使团队能够从全新的角度来审查代码。单元测试用例执行失败对于开发人员来说可能有不同的含义，这取决于它是发生在代码度量分析中的高风险还是低风险代码中。如果将这些信息与来自源码控制的统计信息进一步结合，并与需求相关联，团队就可以更好地决定何时以及如何纠正代码。

使用Parasoft的工具套件，你可以利用基于变更的测试来提高团队的生产力。基于变更的测试通过捕获源代码、测试用例和代码覆盖结果之间的关系，来计算并验证特定代码增量相关测试用例的最优集。实际上，团队可以通过只运行整个回归套件的一小部分测试来限制他们的测试会话。这种只专注于绝对需要部分的测试，节省了大量的时间与资金，特别是对于中型或大型项目更是如此。

结合使用：ParasoftC/C++test and DTP

上面讨论的所有测试技术都可以在Parasoft C/C++test和Parasoft DTP中使用。Parasoft C/C++test是针对C和C++项目的统一测试工具。C/C++test 作为插件嵌入当前主流的IDE中,如 Eclipse和Visual Studio与IDE的紧密集成可以防止上面讨论的问题。开发人员在编写代码时即可立即运行编码标准遵从性检查或执行单元测试。QA团队成员可以执行手动测试场景，同时监视应用程序的代码覆盖率和运行时错误。离线分析，例如由静态分析提供的流分析，可以在连续集成阶段中执行。使用支持命令行接口的服务器会话，将分析结果报告给Parasoft DTP，以便于收集来自开发环境的信息。Parasoft DTP提供了广泛的报告能力，包括集成来自第三方工具的数据、在工作流的每个阶段提供测试反馈的能力，这加速了敏捷开发并降低了符合安全标准的成本。

还应该注意到，这里讨论的质量保证相关的过程和体系结构并不局限于C/C++项目。Parasoft为Java和C#/.NET提供相似的解决方案。

总结

软件质量改进不是同质化的工作，它需要不同的技术来消除不同类型的软件缺陷。关键的挑战是如何以一种有效的方式来实现这个目标，从而避免破坏项目预算并削弱开发人员的积极性。集成到开发人员IDE中的统一测试工具为开发测试提供了最有效的环境。一个统一的工具，比如Parasoft的C/ C++ test，它具有统一测试软件各个方面的能力，并提供统一的度量和结果，允许团队将测试集中在高风险和最近修改的代码上，从而提供了更多的好处。