验证测试点分解

ggggdddd

之前有人发帖讨论测试点分解，个人觉得测试点分解是验证人员的基本功，在此抛砖引玉。

1.测试点分解原则：

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

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

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

还有等价类划分，

因果图判定表，

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

tbb2009

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

seabeam

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

guolehaohao

very good

MaMarc

回复 1# ggggdddd


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

ggggdddd

回复 5# MaMarc


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

diyangguang

受益匪浅

飞扬紫百合

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

diyangguang

受益不小 谢谢楼主

jidanchaoren

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