验证测试点分解

1.测试点分解原则：

测试点必须覆盖所有的规格feature；

一个测试点必须在一条tc里面覆盖，一条tc可以覆盖多个测试点；

2.测试点分解方法：
边界值验证：黑盒测试方法，对输入或输出的边界值进行测试。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。Eg：以太网normal报文的长度是64B-1518B。需验证长度为63，64，65，1517，1518，1519的报文。
还有等价类划分，

因果图判定表，

对象流程图等等其他的方法。具体的方法介绍顶到100楼给出 ：）

技术贴，为什么没有人顶呢。LZ还是不要等到100楼吧，分享给大家吧。

这个坛子顶到100层有难度，除非资源类啊。

very good

测试点分解虽然是基本功，但是很多时候很难去协调分解的粒度和花费的时间之间的关系，分的太细工作量太大，分的太粗又担心漏掉。另外，测试点分解时的遗漏问题也很让人痛苦，通常来说，需要考虑很多方面才能减少遗漏，功能/模块设计/数据处理流程等。

这个测试点的遗漏问题涉及到的内容就多了，但是也是有办法去保证的，验证的目的是为了证明rtl的实现是按照规格去完成的，验证的方法是随机验证然后收集功能覆盖率，基本上90%的工作是通过随机验证，然后后面的随机不到的地方通过补充直接用例去完成。
当然，“很多遗漏问题”，“考虑很多方面”我觉得也是有方法去解决的，无非就是些corener点的识别，然后后期跑大随机用例，各位corener点的cover cross，验证，设计和架构在一起头脑风暴，以往类似项目的易错点经验借鉴，复杂模块后期的白盒验证，还有各个TR阶段的验收标准。总之，个人觉得，规范合理的流程能解决99.99%的问题，剩下的0.01%，因为验证是无穷无尽的，没办法保证，只能听天命， ：）

受益匪浅

这个都是建立在比较全面的feature list的基础上的。做过一个实际项目的话就知道怎么去弄了

受益不小 谢谢小编

还是要前期的feature要给的很清楚，开发人员最好详细划分feature，那么验证点提取就会清晰些，建立从feature到验证需求点，再到用例的跟踪矩阵，再用功能覆盖率去统计结果，定向加随机，但是也只能在人力范围内无限逼近完备。

可以考虑用二叉树来进行细分工作，然后划到某个层级结束就要去进行权衡了，我们一般的做法是到四级就结束了，其余的层级用覆盖来保证。个人看法，仅供参考。

谢谢小编的分享，看小编的分享，知道小编对验证工作有很多经验，想请问小编如何开展以太网的验证工作，小编有没有验证的资料能分享一下呢?

谢谢小编分享，看了后知道您有很多经验，想请教您验证以太网，有没有什么资料可以分享，或者可以推荐?