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

关于验证完备性的分析报告--曾舒婷--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.冒烟测试用例所覆盖的测试点，在随机测试用例下测试可能可以覆盖，但两者关注的测试点已经不一样了。而且冒烟与随机测试并没有明确测试点。无法确保每个被关注的测试点被验证到了。3、总结总结以上的分析：个人认为要确保验证完备性，贯串于验证各种环节，测试分解、功能覆盖方案、测试用例编写与分工，需要需求人员，架构人员，设计人员及验证人员的共同参与和努力。验证是项长期的，循环的，需要和多方人员相互沟通理解的工作。这是我的个人观点，可能有些不对的地方，希望您指出与修正！谢谢！