实时软件测试[2]

　　实时软件测试[2]   软件测试

　　显然在提高软件质量和可靠性方面，路径测试覆盖技术是最有效的。这样最大限度的路径测试覆盖将降低其它相关覆盖测试的成本。

　　越来越多的软件开发者在转向商业的软件测试工具来协助复杂的测试过程。有些软件也集成了规则分析和其它的静态分析技术来进行单元级(单个函数)到子系统级以及系统级(多文件)测试。

　　需要覆盖率工具提供什么功能呢?

　　1. 能进行全面地覆盖分析(最好能识别不可行代码和不可达代码)。

　　2. 能从单元级开始向上辅助自动测试用例/向量生成工具进行覆盖分析。

　　3. 能提供直观的可视化的报告以便于工程分析和指导。

　　结合工具的使用，开发者考虑按照下面的步骤将能更高效、低成本的到达覆盖分析的目的：

　　第一步：根据对被测程序的期望实现功能的了解来构造最有可能的功能测试。这些应该从软件需求说明书、软件规格或用户文档获得。在加载测试数据的情况下，应该能够通过测试工具监控源代码的执行。当实现功能测试的数据用完后，检查覆盖率来发现程序中的哪些部分仍然没有被测到。应该进一步的构造测试数据并进行执行、分析。覆盖率会随着每一组测试数据的执行而累加并且每一组测试数据都会显示执行了程序中的哪些部分。

　　上面的过程应该一直持续到进行功能测试的数据被执行完或者达到所需的测试度量标准。如果是前一种情况(测试数据执行完)那么进行第二步;否则的话(达到测试度量标准的要求)那么任务就完成了。

　　第二步：检查测试覆盖度量指标。如果语句覆盖率没有达到完全覆盖(也就是说不是每条语句都被执行了)，那么可能是由于某个特殊的用例运行失败，错误退出，等造成的。由于这些可能性的存在，需要对执行历史剖面进行累积，因为为了将代码中的每一行都执行到，将程序执行多次通常是必须的。通常功能测试只能覆盖程序中40%到60%的可执行语句。

　　当语句覆盖达到完全，每一条语句都被执行时，便可进行第三步。

　　第三步：检查所有没有被执行的分支。通常这些分支中的一部分可以通过构造专门的用例实现对它们的测试。因为为找出程序中未执行分支而进行的程序分析和为了找出程序中的未执行路径所要做得分析工作很相似，所以在将分支测试这种策略充分实施后再进行第四步——测试路径覆盖，将更加节约成本。

　　第四步：有些没有执行到的分支和路径，是由于相关的测试用例只有在程序执行出错或者计算出错的错误状态下才能实现。这些通常是和程序的冗余保护设计相关,这样的路径应该完整的保留。

　　最后：

　　在进一步的检查后会发现，通常很多没有被执行的路径都是不可行的，也就是说，在使用任何测试数据的情况下这些路径都不可能被执行到。这意味着代码的相关部分应该重新写，因为这些代码要么是无效的要么是不正确的。此外，当这些代码重写后，和这些代码相关的其它一些测试路径可能也会被去掉。如果是由于上面已知的原因，导致测试路径不能被执行到，那么即使没有达到覆盖率标准，这些测试路径也是可以忽略不计的。

　　一旦不可行测试路径被去掉，那么源代码将会更加有效、健壮并且占用更少的空间。

原文转自：http://www.ltesting.net