请教测试点分解的问题
我是根据规格书分解的测试点，完全遵守规格书的各个模块的处理顺序，可是这样
就存在两个问题：
1>有些规格是隐含在规格书里的，需要自己去挖掘或联想。这些点都没有在规格书
或者协议中明确说明，但是这些点确和逻辑的整体功能或者逻辑设计的处理等方面
相关，这些隐含的点很肯能就是设计bug隐藏的地方
2> 原原本本仿照规格书来写测试点，有些规格会导致测试点无限膨胀，导致测试工作量
很大。目前我所知道的就是边界点，特殊点需要重点关照，其他点随机取一个就可以。
可惜 很多情况下并不这么简单。
各位大侠能否指点一下? 不胜感激！
btw:软件测试点分解的书籍能否推荐一下? thx
我还没发现有书中详细讲了功能的（你们叫测试点?）的提取的方法，我就讲讲我们的一般做法吧。
1、一定要按照TOP-DOWN的方式，从总体功能划分(接口、控制、运算.......等) -> 每个功能的不同子功能 -> 子功能的不同的应用场景(只针对该子功能) -> 该应用场景涉及的功能点。
2、根据不同的DUT，还可以按正常工作、异常情况(错误注入等)、边界情况等等并行划分。
3、至于隐含的功能点，一般可以通过应用场景的分析、运算公式(如果涉及复杂)、总线协议规范、以及外接的Device的配置等就基本能全部提取出来。
4、SPEC中往往不会写得很详细，对于外接的Device，大多有标准，去查看标准即可。对于内部接口或内部时序控制或内部运算，设计方式多种多样，这种情况下，在制定SPEC时，验证工程师一定参与，充分了解设计SPEC，且与设计人员多交流，还可以查看IC的总体SPEC。
5、“原原本本仿照规格书来写测试点，有些规格会导致测试点无限膨胀”，该问题可以试试有些功能点不采用黑箱测试，采用灰箱或白箱测试，可以大量减少随机测试的次数，从而减少验证时间。
6、Professional Verification.pdf和functional verification.pdf和SOC Verfication Methodology and Techniques.pdf可以参考一下。
个人浅见，欢迎批评、指责、讨论
我还没发现有书中详细讲了功能的（你们叫测试点?）的提取的方法，我就讲讲我们的一般做法吧。
--就是功能点，也就是需要测试的点
1、一定要按照TOP-DOWN的方式，从总体功能划分(接口、控制、运算.......等) -> 每个功能的不同子功能 -> 子功能的不同的应用场景(只针对该子功能) -> 该应用场景涉及的功能点。
--由整个系统划分到我们这个级别基本都看不到应用场景了。这点受教了，以后我要更关注应用，否则只见树木，不见森林，更高级别的应用场景可能就会漏了
2、根据不同的DUT，还可以按正常工作、异常情况(错误注入等)、边界情况等等并行划分。
3、至于隐含的功能点，一般可以通过应用场景的分析、运算公式(如果涉及复杂)、总线协议规范、以及外接的Device的配置等就基本能全部提取出来。
--应用场景和外接器件的配置一般没有关注，以后要多注了
4、SPEC中往往不会写得很详细，对于外接的Device，大多有标准，去查看标准即可。对于内部接口或内部时序控制或内部运算，设计方式多种多样，这种情况下，在制定SPEC时，验证工程师一定参与，充分了解设计SPEC，且与设计人员多交流，还可以查看IC的总体SPEC。
--以前工作的时候设计部分的东西没有关注，现在正在改进。制定SPEC倒是没有参与，不过有评审流程和评审会议，这个以后需要更关注
5、“原原本本仿照规格书来写测试点，有些规格会导致测试点无限膨胀”，该问题可以试试有些功能点不采用黑箱测试，采用灰箱或白箱测试，可以大量减少随机测试的次数，从而减少验证时间。
--ok，以后尝试使用断言和其他的定位手段
6、Professional Verification.pdf和functional verification.pdf和SOC Verfication Methodology and Techniques.pdf可以参考一下。
--前两本都看过。第一本感觉没什么价值，就我看来，好像就反复强调从系统建模，然后各个小模块可以重用到block级和更
低级的验证上来
第二本没看全，不过个人感觉就那个功能点转移图比较有用，可以缩减验证空间
第三本正准备看
感觉我的感悟能力不是很强，有些书中的东西转化不成自己的能力，苦恼中…
个人浅见，欢迎批评、指责、讨论
感谢大侠回帖！
小编你好，我是应届毕业生，一个刚刚进门的菜鸟。
现在希望学习分解测试点这边的东西。
有什么资料关于分解测试点这方面的东西介绍一下吗?
关于分解测试点这方面，是怎么一个成长过程呢?还是只能通过不断的项目过程来学习?