在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 13906|回复: 15

[原创] 验证测试点分解

[复制链接]
发表于 2014-4-10 17:21:37 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

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

1.测试点分解原则:

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

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

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

还有等价类划分,

因果图判定表,

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

发表于 2014-4-11 20:51:02 | 显示全部楼层
技术贴,为什么没有人顶呢。LZ还是不要等到100楼吧,分享给大家吧。
发表于 2014-4-12 14:06:51 | 显示全部楼层
这个坛子顶到100层有难度,除非资源类啊。。。
发表于 2014-4-13 21:07:02 | 显示全部楼层
very good
发表于 2014-4-13 23:25:10 | 显示全部楼层
回复 1# ggggdddd


   测试点分解虽然是基本功,但是很多时候很难去协调分解的粒度和花费的时间之间的关系,分的太细工作量太大,分的太粗又担心漏掉。   另外,测试点分解时的遗漏问题也很让人痛苦,通常来说,需要考虑很多方面才能减少遗漏,功能/模块设计/数据处理流程等。
 楼主| 发表于 2014-4-14 11:17:29 | 显示全部楼层
回复 5# MaMarc


    这个测试点的遗漏问题涉及到的内容就多了,但是也是有办法去保证的,验证的目的是为了证明rtl的实现是按照规格去完成的,验证的方法是随机验证然后收集功能覆盖率,基本上90%的工作是通过随机验证,然后后面的随机不到的地方通过补充直接用例去完成。
    当然,“很多遗漏问题”,“考虑很多方面”我觉得也是有方法去解决的,无非就是些corener点的识别,然后后期跑大随机用例,各位corener点的cover cross,验证,设计和架构在一起头脑风暴,以往类似项目的易错点经验借鉴,复杂模块后期的白盒验证,还有各个TR阶段的验收标准。总之,个人觉得,规范合理的流程能解决99.99%的问题,剩下的0.01%,因为验证是无穷无尽的,没办法保证,只能听天命, :)
发表于 2014-4-21 20:01:39 | 显示全部楼层
受益匪浅
发表于 2014-4-22 09:08:26 | 显示全部楼层
这个都是建立在比较全面的feature list的基础上的。做过一个实际项目的话就知道怎么去弄了
发表于 2014-5-2 11:47:25 | 显示全部楼层
受益不小 谢谢楼主
发表于 2014-5-9 09:53:39 | 显示全部楼层
还是要前期的feature要给的很清楚,开发人员最好详细划分feature,那么验证点提取就会清晰些,建立从feature到验证需求点,再到用例的跟踪矩阵,再用功能覆盖率去统计结果,定向加随机,但是也只能在人力范围内无限逼近完备。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /2 下一条


小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-12-23 09:51 , Processed in 0.022752 second(s), 9 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表