《软件测试的艺术》：

    软件开发人员通常不会考虑到的一种测试形式：人工测试。大多数人认为，因为程序是为了供机器执行而编写的，那么也应由机器来对程序进行测试。这种想法是有问题的。人工测试方法在暴露错误方面是很有成效的。实际上，大多数的软件项目都应使用到以下的人工测试方法:

• 利用错误列表进行代码检查

• 小组代码走查

• 桌面检查

• 同行评审。

    另一种人工测试(基于人的测试)就是本章开头提到的可用性测试，这是一种黑盒测试技术，需要测试人员站在最终用户实用的角度来评估软件的可用性程度。这一部分将在本书第7章介绍。

软件测试的一种分类方式

关于代码检查和走查等概念，读者可以自行阅读相关章节。

验证芯发现：

• 芯片bug的修复成本

    《软件测试的艺术》中本章节提到：人们普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大。

    对于芯片bug的修复成本和该说法基本一致。芯片bug的修复成本根据所处开发流程不同，相差较大。一般来说，在越靠前的环节，修复的成本越低，修改引入的风险也越低。

    在模块的block级设计验证阶段，发现问题，直接修改RTL代码，然后进行block级别验证回归测试即可。在系统测试环节发现bug，则需要block级验证和系统验证都要做相应的回归测试。

    在RTL代码fix以后，代码综合阶段，验证发现问题后，修复的成本就会远大于block级和系统测试级。此时则需要使用ECO方式，修改综合网表，进而使用Formal技术，保证RTL的修改和综合网表的一致性。同时所有级别的验证则需要根据最新的RTL进行回归测试。更为严重的，如果在PD阶段发现bug，受限于项目交付时间，可能需要进行PD层次的ECO，该成本则又远大于综合网表的ECO。

• 对事不对人

    《软件测试的艺术》中本章节提到：要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查视为对其人格的攻击、采取了防范的态度，那么检查过程就不会有效果。....对代码检查的结果进行保密，仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。

    与人打交道是一件比较微妙的事情，可能同样一件事，不同的说辞和态度就会给人不同的感受，处理的结果也会截然不同。从验证的角度看，验证是为了发现更多RTL代码中的问题，也就是说要发现别人的错误，“揭对方的短处”，尤其在和设计人员交流和定位问题时，有时需要注意相关的语言表达。比如可以对比下两种方式：

    （1）你这个代码写的有问题；

    （2）仿真出错了，我们一起看下是验证环境问题还是代码问题。

    另外一个角度是对于管理人员，比如验证leader。我们不可以把偶然的一个结果，上升到对人的评价。主管对团队成员的评价，一定是基于事实而不是主观的定论。

• 验证的代码检查、走查与评审

    原书本章内容，其实是在介绍针对设计代码的自检，对应到芯片的开发，应该是属于设计代码的检视和根据checklist的自检。不同的公司和部门都会有自己积累的“自检列表”，一般这种自检表中，除了一些通用的检查项，还会有一些“特色”，即每个小组以前犯过的错误。

    在这里想从另外一个角度分析，即验证的自我检查。从整体上看，RTL代码和验证环境是一个有机系统的两部分，RTL的正确性可以由验证来保证，而验证环境的正确性该如何保证呢？RTL代码有自己的自检，那么验证环境也会有类似的动作。

    验证环境包括：driver、monitor、RM、随机约束以及testcase等组件，每个组件的代码检查和评审在流程上必须要设置相应的环节。在受限于项目周期，以及验证环境的成熟度，某些检查的程度会有所不同，可以灵活实施。验证环境的检视和评审，一般由环境开发人员、主管leader以及其他干系人。和RTL代码检视的错误列表类似，验证也会有对应的checklist，至于checklist的内容和角度，每个公司或部门的思路会有所不同。

---

验证芯发现：《软件测试的艺术》第3章：代码检查、走查与评审 (qq.com)