验证漫谈

hongjian77

一直在潜水，本帖虽然是验证漫谈，但是rhythm1988通篇只做了3件事：抱怨国内的环境，重复10年一本老书的观点，最后又崇拜了一下洋人。
看到rhythm1988的团队成员居然看中文资料，我简直要喷饭了。我和同事都是中国人，但是我们写文档发工作mail都用英文，有时候需要用中文写文档反而写不出来。仔细看了rhythm1988的回帖，确实有领导风范，就是说你不行，你的层次不够，具体那不行就要靠自己的慧根了，真是牛人！记得当年打cs的时候，大家都讨论那种枪厉害，突然有人说真正的牛人就是用匕首也能杀人，你们的讨论层次太低，于是被大家无比崇拜，结果打起来却发现水平so so。所以大家得到一个结论，要想做牛人，绝对不能展现出自己的实力，要说些似是而非的话，最重要的是要掩饰自己的观点。比如大家在讨论肉车的时候，明明你非常赞同，但是你也要说：没有肉车只有肉人。语言只是工具，vmm只是应用，这样一说，别人就不好意思问你这方面的问题了，即便是你一窍不通别人也无法察觉，对你只有仰视。rhythm1988从业10多年了，应该是管理层了吧。这些人对技术细节并不了解，也不屑于了解，不是说这些人水平低，而是说在这个层次的人关心的是flow和宏观问题。但是这些问题不是engineer关心的，flow追求的终极目标就是同样的任务任何人做出来效果都一样，记住体制中是培养不出牛人的。
不过看到下面hover99的帖子倒是觉得有些新意，特别注册一个id来谈谈我的观点。本人是designer，也懂一点vmm，不过我们soc的验证环境还是verilog的。以我的经验来看，bug往往出现在你认为不会出现bug的地方，让designer自己验自己的design，总觉得不靠谱。其次，hover99所说的只改testcase不该testbench，我觉得过于理想化了，假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗？

rhythm1988

回复 11# hover99

占个位置先！待续。。。
很不幸，本人就在楼主所说的M公司，而且在最核心的部门和美国工程师合作了2年，至少在去年我们最先进的产品仍然是使用verilog来验证的。非常不幸，你对大公司的评价和对我个人的评价完全陷入了悖论。在M公司（楼主说的纯洋鬼子）和以前的公司（楼主说的土财主），都遇到这么一个问题，当我们试图用新的验证技术去替换旧的验证环境时，会发现有大量的test case需要大量的人力去移植，结果时间和人力上都无法满足，好的情况就是两套环境并存并持续若干个项目，最终转移到新的平台，有一个有趣的现象在两套环境并存的过程中，几乎所有以前抱怨过老环境的人都认为老环境还是可以接受的。验证的最终就是追求功能覆盖率，新老技术都能做到这一点，只不过新技术效率更高并且更不依赖于验证工程师的素质。结果就是在新老技术交换过程中，效率更低下。所谓大公司的包袱救治指的这个。
LZ:你看问题说具体了，就有讨论的空间了。你说的比较典型，OK!上面转换策略是你们具体执行的方式和碰到的问题，我提一个思路你看会不会好点？比如：你们的平台能否提前一到两年实现，并做好平台的测试工作呢（包括VIP）？团队的manager和leader能否深入产品去提前挖掘需求，做到一个提前量，也许抱怨的人就会少一些。
另外还有一个问题，即上面提到的大量的test case需要大量的人力去移植的说法。呵呵！上次有意没有点这个问题，看你这么执着，就说一说解决方案，非常遗憾的是，业界已经更新了大量test case的做法，具体的做法是少量的test case（少到多少有讲究）+自动更新随机种子+部分的定向测试的方式来完成覆盖率要求。
你仔细去看8楼的回答中，我压根就没有提所谓的大量test case的说法！！！你可以想象得到我看到这句话时的表情，应该说你在一个封闭的环境中，天空就那么大一点。
为了防止你吹毛求疵，我再把相关问题说透彻一些。
其实，我贯穿整个讨论一直在明确关于语言和验证工作的问题，只是没有显性的说出来。说了多少次了，开始就说牛人的做事情方式和思路，说了两个验证方法学的不存在优劣的问题，说了要把基础打扎实一些，其实都是在说这个问题，目的是希望看帖子的人自己能够有所悟！当你自己有悟的时候，才能够改变验证工作被动和地位不高的问题。
你没有悟出来吧，还把自己的一知半解给拿出来做理由，这就怪不得我下重手了。
我来解释一下最先进的产品仍然可以用VerilogHDL和VHDL来验证的理由吧。如果我们可以不怕麻烦的话呢，所有的问题都可以用C/C++，再源头就是汇编了，但很明显，有牛人用的不爽，干脆自己编一个出来，同时也造福象我等这样的平庸人士，VerilogHDL之类的就是这么出来的。
那好了，既然有牛人造出了Verilog，使C语言插上了时间性和并发性的翅膀，难道还有什么问题不可以用c加上verilog来解决呢？甚至更极端的，你们公司有大牛，干脆用c甚至汇编来解决问题，不是不可以哦！
所以说，方法学没有什么优劣的，既然systemverilog是半吊子的面向对象的方法，那么我VMM用CALLBACK，你OVM就没有资格来批评我，咱们都是半斤八两，有本事你OVM干脆搞个纯oop的硬件描述语言生态圈出来？这就是我为什么说没有优劣的原因。
不告诉你，是你整体还没有上这个台阶，贪多嚼不烂，后面居然成为攻击我不了解方法学的原因，彻底无语了。。。
最后说说M公司，不知道我说的“M”公司是不是你说的M公司，几年前听说M公司是唯一把核心业务放到中国来做的公司。我在多年（接近十年）前看看的一篇关于集成多子系统在单SOC芯片的论文，就是M公司的，文章应该是99年的DAC论文。记得看的时候是十一，没别的事，干脆仔细看看，应该承认“M”公司在新千年之前，就已经是业界领先了，想不到十年之后，还是如此而已，难怪没落得要私有化的程度，唉。。。



其实这种例子有的是，最典型的莫过于塞班，诺基亚算不算大公司？大家都知道塞班落伍了，但是提高技术甚至推到重来，诺基亚偏偏就是做不到。
LZ:这个问题我是外行，但尽量交流一下。其实类似的情况业界也有，新千年的时候是网络股火爆的时候，Intel花了60多亿美刀买了个做网络处理器的公司，Intel公司的技术实力不可以质疑吧，结果呢？一塌糊涂，最后公司好像不到7亿卖给了Marvell!
关于塞班的问题可能很复杂，但和Intel类似，根本上应该是高层在不熟悉的子领域中的策略有问题，一个正面的例子是Apple，其实我们看IPAD的硬件成本和售价，对比IMAC的成本和售价，就知道，在数据业务这个移动子领域中，商业模式发生了很大的变化。诺基亚的策略上没有苹果的策略合适，不是技术问题。
个人理解不应该拿来支持你的看法。

另外一个例子，synopsys的vip很多都是vera的，在大家看来太落后了，为什么还能存在？这是因为这些vip已经经过了大规模的验证，重写虽然可能提高效率甚至不用花费大量的时间开发，但是必须要重新花费大量的时间来验证vip本身的可靠性。所以这些vip从vera时代一直延续过vmm时代，最终到uvm终于无法适应了，只能重写。
LZ:这是你们自己的内部矛盾，按理我没有发言权。反证一下吧，但业界推出UVM来统一方法学，难道是推UVM的那帮人走路集体撞墙了，或者在集体梦游！业界大公司M明明发现VMM过渡不到UVM，还要硬推融合？
唉，都是我在给你们出主意，你们是什么公司啊？说得都有点不耐烦了！
有空请你们的leader多看看书和资料，去查查DAC2011的UVM主题，讲UVM中的tlm2的就是伯格龙老兄，synopsys公司的，实在不行请你们高层协调一下新思的资源，给你们制定一个转换路线。
路线大致说两句：vera是捐献给SV的，所以synopsys在VMM上特别用心（所有早一点推出来），从vera到vmm再到uvm，怎么可能走不通呢？UVM还要不要基于SV来开发了？
你说了这么多，除了证明你们的团队不思进取，我真看不出来还有什么内容！！！



所以说，技术上的革新都是被动的。革命在西方就是贬义词，大家更喜欢用进化，而进化本来就有被动适应的意思。
验证方法学只是一个手段，产品才是目的。对于pm来讲，最好是可以使用最简单的技术来完成任务。这就是工程和研究的区别！
LZ:请不要说一些似是而非的东西，我自认为想引导大家走向一个正确的职业道路，不希望象这种水平的来浑水摸鱼！

如果你的验证平台在设计freeze之后，每一周都能找出若干个bug，我想pm不会觉得你的工作有多出色而是对你的验证感到绝望。
LZ:很不好意思，pm是对你的工作感到绝望的，一个正规的验证过程的bug/时间曲线是个指数曲线，而不是你现在的状况！

我这里所说的验证可靠性，是指的是在流片之前pm有多大的信心来保证芯片回来是work的。
LZ:请不要越描越黑，我们是做技术的，说话要有依据。流片成功不是靠PM的信心，而靠科学地客观地设置一些流片条件来保证！合理而有效地设置这些条件，是PM应该因地制宜的或者坚定不移地执行的。回来能不能工作很大程度上依赖整个团队能否有效地执行PM设置的条件。

如果我的验证平台一个bug都没发现，但是我能保证所有的可能情况都测试过了，你能说这个验证平台不合格吗？
LZ:你还真会钻牛角尖！说句实话，帖子回到这基本上比较完整地了解了你的一个侧面。有一个感觉，你在验证原理和验证技术的学习方面没有形成系统观点，学习中思考量不够，特别是在基础理论上，可以预见你的知识体系相当零散，非常不幸的是，你用自己的臆想去填补了你知识体系中的空余部分，可惜非常遗憾的是，这些臆想绝大多数都是海市蜃楼！我对你的忠告在5年之内还绝对有效！！！
这样的问题我还是留给初学者思考吧，记住，这种问题在你学习验证理论的时候就应该解决，也就是说在你做学生的时候就应该解决了，可以看看这个问题问的方式，条件这么绝对，答案甚至不是选择题，你以为是本科生考试啊！
BTW:这个问题跟你们团队中的2个精通人士去讨论讨论，看看他们有什么看法吧！

楼主认为test case是testbench的一部分（看来你不是这样认为！而我认为除了DUT/DUV外，都是testbench，下面有人说的十年前的老书第一张图就表达了这个意思，你没有看出来，说你基础知识不到位不为过吧，OK！我孤陋寡闻了，你要不把你的理论基础说说吧？原创还是借鉴），我觉得你并没有理解vmm或者ovm的精髓（理由呢？理由呢？一句话就打发了，情何以堪！），。如果仔细研究vmm或者ovm，你就会发现，vmm/ovm花了很大的努力去把二者分开（My God！你把VMM/OVM也算验证平台的一部分了吧！要不把操作系统也算进testbench去算了，怎么说操作系统也是软件哪！CPU就不算了，毕竟是硬件，上面开个玩笑，回去看看OVM的白皮书，有个层次图，以你的起点一定会得到你的结论）。楼主说的大客户支持（CAE）里面的工程师是验证架构工程师，所谓验证架构就是开发testbench的人（不知道啊！我看干脆以后IC公司的BOSS给伯格龙他们发工资算了）。而且按照vmm或者ovm的理念，在testbench完成之后，需要改变的只是test case而不是testbench（你这个意见有没有和EDA的AE或者FAE交流过，如果是的话，把这个（些）AE和FAE的名字发给我，我们公司以后他们不用来了）。我们用oop技术去屏蔽验证平台的实现细节，只开放最顶层的部分给test case，就像操作系统向开发者提供api一样。我们把写test case的人看做是验证平台的用户。我们部门20多人精通验证的只有2个人，但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验。如果testbench和test case由同一个人完成，那么当他用1个月的时间写完testbench之后，又要花费3个月去建test case来验证。如果很快有第二版出来，那么他又不得不重复上面的工作，试想在这种情况下，验证工程师除了对他所验证的模块更熟悉之外，在验证方法学上有学到了什么？更可悲的是，当他对设计熟悉到一定程度的时候，很可能会把他熟悉的这部分交给他设计，然后又找一个新人给他做验证，如此循环。（你们组织的现状我可能需要花更长的时间去理解，感觉有几个问题：1）精通验证的人比例太少，我对团队成员的要求是所有人都通晓几个基础，但个人有所突出，有方法学源码精通的、有覆盖率精通的、有脚本精通的、还有其它方面，你们组织的形态很古怪，是历史原因还是人文原因？你是不是2人之一？2）简略解释一下platform、testbench和VIP的概念，假设testcase属于testbench，通过下面的解释，大家会知道为什么有这个属于关系，platform是基于语言和验证方法学而言，范围比后两者更广泛，testbench和VIP是在platform的基础上针对某个IC而言，但后两者有联系也又有区别，按照testbench的定义是完成DUV的输入和观察对应的输出（可选），那么testcase就是完成testbench工作的一个步骤，所以有这个归属关系，为什么说VIP和testbench有联系也有区别呢？我们说testbench一直没有说到RM，只有RM可以不属于testbench，讲到这里应该明白为什么platform的范围更广了吧！当然RM可以不存在，也可以很复杂，如果复杂到可以多个项目重用就快接近VIP了，当然这还不是一个完整意义上的VIP。VIP和testbench的这种我中有你，你中有我的特点决定了要复用，必须基于某个flatform来做，因为必须基于某个具体方法学和语言来做，现在不是十年前个人英雄的时代了，一个人可以从汇编一直做到界面，甚至硬件，基于平台来做可以做到事半功倍。3）现在可以讲讲OVM等等的意义了，方法学提供了一个使用语言的套路，具体讲应用方法学可以很快地搭建好testbench（这话不是我讲的是Mentor的人讲的！相关资料很好找，网上到处都是），使工程师可以尽快投入到RM的开发中，而RM的开发才是验证工程师需要重点投入的部分，如果是多项目的复用，那么RM的开发需要遵照VIP的方式来实现，这个过程当然需要精通验证的人来把握咯，呵呵，换做港台的讲法就是“拿捏”。最后我们来大致分析一下结合hover99的部门情况，只是我觉得很悲哀，有18个人在做可以简化、没有技术含量的工作，另外两个人基本上是神仙，包罗万象，无所不能是其次，还能身体力行地做到做完做好，证据是“我们部门20多人精通验证的只有2个人，但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验”，顺便明码一下，能不能把那两人的电话给我，我给业界的朋友们推荐推荐！中国IC界太需要这样的人才了！），。
实际情况是，相当一部分验证工程师在工作1，2年后会转为设计，还有一部分会专注于写test case，对他们来讲debug是一个重要能力（话说回来，写RTL和debug自己的RTL都不是什么技术活（如果你维持这种观点的话，对你的忠告也没有什么意义！））。对于那些验证架构工程师来讲更重要的是用软件方式对testbench debug，两种debug根本就不是一回事。
LZ:说句实话我不想回复这部分内容，但为了防止半瓶水害人，也为了防止有人借此来评价我不了解技术细节，算了！好事就做到底了。
本来想写在整段下面，后来发现错误太多，一句一句写算了！这里最后总结一下为什么你错误这么多吗？
因为你开始就错了，开始就把test case和testbench分开看，所以你后来看所以的后续资料都带了个有色眼镜，最惨绝人寰的是，你在错误的轨道中，还不断地用错误的思路来强化错误，诸位围观者不要以为这会负负得正，只能是技术地狱再往下一层。

rhythm1988

回复 12# hongjian77


很厌烦换马甲出来的行为，是谁我不猜了，但这是阴险小人的行径，只能让人鄙视你。
对于这个回帖，我只会毫不留情！
这里把底线划在这里，注册马甲进行攻击的，一律BS加鄙视！
有能耐你就真刀实枪地站出来讲，总想躲在阴暗的角落，不是有健康心理的人的行径。
下次有类似情况，先问侯你家人！


一直在潜水，本帖虽然是验证漫谈，但是rhythm1988通篇只做了3件事：抱怨国内的环境
（I服了you，你用“抱怨”这个词QJ了所有做验证的人，很遗憾的是，也许是这个工作QJ了你，而不是我们所有人。
我写这个帖子，是为了有志于做好验证工作，进而可以有尊严地做个工程师的人提供一个思路。
只有那些整天躲在阴暗角落、苟延残喘的人才会用抱怨这个词！）
，重复10年一本老书的观点
（ 这更好笑了，诸位这辈子学的书有几本小于十年的！或者你给大家指导一本新一些的验证基础的书，说说感想？敢不敢？）
，最后又崇拜了一下洋人。
（“崇拜洋人”，我还以为你是义和团呢？
自己从来都是得过且过，还妄想出来装B，装了还想高薪，天底下那有那么好的事情。
群众的眼睛是雪亮的，就你这点能耐，还敢站出来撒野！）
（我先问大家一个问题，所谓70%的工作量在验证上，有谁去认真统计或者找过资料来印证的，做过了的不妨举个手。这个提法大概就是97年提出来的，北电有位老兄在98年DAC，发表一篇论文是关于多芯片复杂协议系统的开发和验证的，其中说到了这个问题，起先他肯定也怀疑过，怎么办？就在项目中统计一下，所以文章中专门列了一个小节来说明统计了那些，结果是什么？说到这大家都可以猜的到结果。说这个往事的目的是希望大家对自己的职业生涯要严谨和认真，做个有自尊的工程师（人），不要信口开河，知道了一点，可以吹出一头大象来）
看到rhythm1988的团队成员居然看中文资料，我简直要喷饭了。我和同事都是中国人，但是我们写文档发工作mail都用英文，有时候需要用中文写文档反而写不出来。
（惭愧呀！惭愧！我们的团队只想站着当人，不想趴着当狗！只针对一个人！这话还能拿出来显摆，这不是阿Q吗！）

仔细看了rhythm1988的回帖，确实有领导风范，就是说你不行，你的层次不够，具体那不行就要靠自己的慧根了，真是牛人！记得当年打cs的时候，大家都讨论那种枪厉害，突然有人说真正的牛人就是用匕首也能杀人，你们的讨论层次太低，于是被大家无比崇拜，结果打起来却发现水平so so。所以大家得到一个结论，要想做牛人，绝对不能展现出自己的实力，要说些似是而非的话，最重要的是要掩饰自己的观点。比如大家在讨论肉车的时候，明明你非常赞同，但是你也要说：没有肉车只有肉人。
（多年前我也玩CS，后来玩不动了，主要是费时间，体力也更不上了，其实大家都知道CS最吸引人的地方是团队，上面的说法也只能忽悠一下子猪头三而言，明眼人那能上这当啊，这个道理就像是江湖骗术，从古到今都有，为什么还常盛不衰，道理很简单猪头三不是年年都有，而是天天都有！）

语言只是工具，vmm只是应用，这样一说，别人就不好意思问你这方面的问题了，即便是你一窍不通别人也无法察觉，对你只有仰视。rhythm1988从业10多年了，应该是管理层了吧。这些人对技术细节并不了解，也不屑于了解，不是说这些人水平低，而是说在这个层次的人关心的是flow和宏观问题。但是这些问题不是engineer关心的，flow追求的终极目标就是同样的任务任何人做出来效果都一样，记住体制中是培养不出牛人的。
（我一开始就说了我绝非牛人、高手！VMM/OVM可以很坦诚地和大家讲，我不是专家，专家是厂商的AE和FAE们。任何人有技术问题都可以和厂商联系，即使是没有厂商的学习者，比如：OVM可以上OVMworld去，是个开放论坛，其实Mentor和Cadence的那些专家特别喜欢回答问题，如果是有质量的问题，他们是绝对欢迎的，比如vi的做法就是先在OVM World中讨论出来，最后写到OVM COOKBOOK里去的。这就是心态开放的好处，三人行必有我师！当然问得都是文档和手册已经讲过的问题或者是一些初级问题，回答就不一定那么积极了，也许是让你再看看书或给个链接等）
（既然说到本人的工作内容，就八卦一下。本人不是管理层，那不是兴趣所向，管理的工作繁琐，管理者是我沟通来投钱和投人的，其它的事情我一切帮他搞定的人，到时候就收结果的人，兴趣所在，没办法！
你对管理者和管理工作的理解太肤浅了，幼稚并可笑，不要以为你跟过几个废物点心，就好象看穿了世事一样。
我诚意地奉劝看过本帖的人士，把管理者看成是女（男）朋友，不是对立面，想想你和女（男）朋友还有个互相支持和体谅呢，和管理者不妨也这样。
管理者有其缺点，一定也有优点，人都是这样。这就像是找朋友，如果你实在是容忍对方的缺点，就天涯何处无芳草吧！如果你是个大帅哥，富二代，还怕没有女朋友，工程师的工作是类似的。
最可发一笑的是井底之蛙，总是流着口水，在YY！）

不过看到下面hover99的帖子倒是觉得有些新意，特别注册一个id来谈谈我的观点。本人是designer，也懂一点vmm，不过我们soc的验证环境还是verilog的。以我的经验来看，bug往往出现在你认为不会出现bug的地方，让designer自己验自己的design，总觉得不靠谱。其次，hover99所说的只改testcase不该testbench，我觉得过于理想化了，假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗？
（你这个马甲比hover99还差一些，error注入的问题，是要改testbench吗？有没有学过OOP，有没有学过设计模式？错误注入类总的思路采用工厂模式在testbench中调用的，还修改testbench？以你的经验来看，验证这两个字都不知道怎么写的，还来谈验证！
为了防止你还是无中生有，错误注入的问题可以多说两句，整个错误注入的策略是以工厂模式为基础，可能包括其它设计模式，动静结合的复合策略。如何实现好，可以算是一个验证平台实现的亮点！
这么基础的思路你都不了解，还敢说懂一点VMM，VMM的那本书很怀疑有没有认真看啊！
BTW:soc的验证环境是不是verilog或SV不重要，重要的是你们的人才是否能支撑达到验证的那些目的，如果你是Leader，很悬，具体原因看上面一个回复的内容）

beginner001

看牛人争吵，很有新意。
不过error injection确实不需要改动testbench。

luyuan_0922

都是牛人啊！

hongjian77

我已经说了我是designer，在验证上面你怎么挖苦我都无所谓。要不是我们的团队需要做正规的verification，我才懒得注册id呢，没那个闲工夫。hover99，我已经把我的联系方式短消息给你了。如果有兴趣可以和我联系。
vmm除了generator之外有工厂模式吗？我知道error injection可以通过callback来实现，但是事先没有加callback，如何来实现error injection。

没想到对楼主冷嘲热讽了一下，楼主居然气急败坏到要问候我的全家。还好楼主没啥权利，否则我恐怕还有灭门的危险。

beginner001

还是讨论问题本身吧。
VMM需要callback来实现才能实现error injection，OVM和UVM用factory 可以实现。

rhythm1988

回复 17# hongjian77


   1）不要以为本人在design上就没有资格批评你，本人的设计生涯只比验证要长，是单纯的时间跨度，不是夹杂的时间段哦！要不你也写个设计体会，让我也冷嘲热讽一次，也做一次小人？很不好意思本人是跨界发展！
2）下面回答begineer001的问题也顺便帮你解个疑惑，让你占个便宜，因为你的人格我很鄙夷！
3）小人以退为进的风格不是没见过，哦！你说过很忙的，估计也没时间写设计体会了，又是我多情了。

rhythm1988

回复 18# beginner001


你已经到门口了，如果VMM是callback，而ovm是工厂，又没有人规定VMM只能在一个地方用工厂模式，那么你就把工厂套在VMM上面就行了,这就是平台的工作。
其实，VMM的错误注入就是工厂模式，callback只是实现手段而已，只是VMM的错误注入方式，包括OVM的工厂，我还嫌不够灵活，在目前的错误注入的基础上，已经对此进行了创新，在回马甲的帖子中已经写出来策略了，不具体讲，这是吃饭的家伙。已经指了路，有悟性的人只好自己去琢磨，抱歉！
BTW:
有个怀疑希望是错觉，hongjian77是不是你的马甲？因为你们都太关心错误注入的问题，而这个问题我说过了是平台的亮点部分，很考验设计平台人员的综合素质。
任何验证平台只要一天没有在错误注入上有突破，那永远是瘸腿的验证平台。
诸位有没有注意到几个方法学上，在错误注入上都没有说具体，老外也很鬼的，吃饭的家伙哦！

当然是不是马甲，都无所谓啦，我这个帖子是诺亚方舟，但也只给有缘人。

diligent15

讨论还蛮激烈的，好像每个人都说的有道理呢，可能只是出发的角度不一样哩，还在慢慢的摸索验证，讨论了才能出新意，让自己看到工作中暂时无法看到的一面，不管怎样，都是为了提高工作效率，完善验证工作。
很早以前刚刚入行的时候是想着未来能有个验证公司，专门做大公司的外包验证，可是自己能力一直都不够哎，讨论归讨论，没有错的也没有对的，有的只是实践中出的真理，是驴子是马拉出来溜溜，希望在众多的高手中能有人干的多点，开个自己的专门验证公司，到时候自然也就牛B了。