关于验证完备性的分析报告.docxVIP

关于验证完备性的分析报告 --曾舒婷 --2012.10.14 郑虹，您好！前段时间对 SPCU 模块进行了验证，对于完备性验证是否充分以及怎样确 保验证完备性有些自己的看法。 1、验证完备性的条件 从 UT 验证角度上看，一个模块验证是否充分，和三点有必然联系： ? 测试点分解是否充分； ? 功能覆盖率是否能全面覆盖每一个测试点； ? 测试用例是否真正覆盖到了测试点。 可以看出测试点分解得是否充分是验证完备性的首要条件。 2、如何保证验证完备性 2.1 如何保证测试点分解的正确性与完备性 如何才能够保证测试点分解正确性与完备性呢？ 首先，验证人员产生测试点分解文档：从验证角度对架构文档以及详细设计文档进 行详细分析，并进行测试点分解； 其次，需要需求人员、架构师、设计人员以及验证人员对测试点分解进行评审，从 不同角度评审测试点，以确保测试点分解的正确性和完备性； 再次，保证评审的有效性：每当架构文档改变时（一般为需求改变了）或详细设计 文档改变时，测试点分解文档也得相应改变；并再次评审。这就又有一个问题，是否每 次对测试点评审都是有效的评审呢？这需要从各个角度上对测试点分解进行评审，保证 测试点分解的正确性与完备性。如果没有提出任何意见的话，就完全成了验证人员对架 构文档的理解和把握了，那么这很有可能是一场无效的、走形式的评审了。具体原因如 下： 1. 测试点分解文档主要是验证人员通过分析架构文档和详细设计文档获得。详细 设计文档是设计人员通过分析架构文档产生。测试点分解的依据的主要来源为 架构文档和详细设计文档，验证人员通过对架构文档和详细设计文档的分析产 生测试点分解文档，也就是说对于一个模块，设计者和验证者对该模块都会有 各自的理解。 2. 若验证者的测试点分解只来自详细设计文档，而非来自架构文档，则结果会导 致，验证者的理解会完全来源于设计者。如果设计者对架构与需要理解不充分 的话，验证者分解的测试点难以保证其正确性。除非验证者也对需求与架构有 所参加，否则无法从源头上保证理解的正确性。 3. 提需求人员，往往是最清楚自己的需求。而架构文档是在对需求的理解上进行 的架构设计。测试点分解又是从架构文档上获取。所以测试点分解的正确性与 完备性也需要要求人员的参与。 2.2 如何保证功能覆盖率的正确性与完备性 那么怎么保证功能覆盖率的正确性与完备性呢？功能覆盖率直接影响测试用例的编写， 因为功能覆盖率直观地反应了关注的测试点是否完全覆盖，及哪些测试点没有覆盖。功能覆 盖率需要覆盖每一个测试点，若需要保证功能覆盖率的正确性及完备性： 首先测试点分解是正确的、完备的。 其次，需要产生功能覆盖方案，即阐述 coverpoint 及 crosspoint 覆盖到哪些测试点，是 否都覆盖完全。 再次，功能覆盖方案需要架构人员、设计人员及验证人员参与评审，确保其正确性及完 备性。 最后，功能覆盖率 100%，并不能保证所有测试点都能被覆盖到，当交叉组合过多时， 功能覆盖率只能反应被关注的测试点是否完全覆盖到。而且验证是无期限的工作，因为你永 远无法证明你验证的模块功能是没有错误。 这里又会出现一个问题，即如何保证被关注的测试点，是真正完全被关注到了呢？这里 的被关注的测试点，直接反应到了功能覆盖率上，即在评审功能覆盖方案时，需要确保被关 注的测试点是真正完全被关注到了。而被关注测试点的划分，个人认为需要需求人员，架构 人员，设计人员以及验证人员共同参与。因为只有需求人员才知道哪些功能是他需要常用的， 特别关注的；架构人员最清楚测试点是否被正确理解，也清楚需求人员的需求；设计人员从 设计角度看需要关注测试点是否正确。 2.3 如何保证测试用例的正确性与完备性 最后怎么保证测试用例是否都覆盖到了测试点呢？ 首先，最直接的是看功能覆盖率是否 100%，代码覆盖率是否则 100%； 其次要在确保功能覆盖率能够覆盖到每一个测试点； 再次，最重要的首要条件是测试点分解是否正确，是否完备。 最后，还有一点是对测试用例的分工上，即对测试点的分工上，而不能从冒烟及随机角 度对测试用例进行分工，这样很有可能出现漏测的情况。分析如下： 1. 首先我们看测试是否完毕，往往看功能覆盖率100%，代码覆盖率 100%。从功能覆 盖率上看 100%，并不能够确保验证的充分性。进行验证时，首先是需要通过定向测 试，跑一些冒烟测试用例，确保模块可以跑通。其次，对于交叉组合情况很多的情 况，必须要借助随机用例测试模块。但交叉组合情况很多的情况下，在短时间内是 无法把每一个测试点覆盖。而且功能覆盖率只反应被关注测试点是否 100%。最后是 收敛的过程，即按照功能覆盖率呈现出的哪些没有覆盖的点，单独覆盖。 2. 冒烟测试用例所覆盖的测试点，在随机测试用例下测试可能可以覆盖