从同行评审的基本准则来看测试用例的评审过程

同行评审的作用，许多大牛们谈得比较多，在此就不详细述叙了，但要强调一下同行评审需要遵循的几个原则，个人觉得这几个原则是必须坚持的。51Testing软件测试网3s6Q F'f3P5{ W
v5y

同行评审需要遵循的原则：

1，管理层重视

如果领导不重视，啥都死翘翘，没有带头人，啥都难搞。这个不用详说了吧！51Testing软件测试网/g5d;j YsYv9u

2，同行评审成员应结构化

毕竟人无完人，每个工种所偏重的方向不同，所有的思绪也就不同，要想发现更多、更意想不到的问题，还是得拉几个方向的人进来的。所谓结构化，也就是这个意思。

3，确定工作产品检查表

这个东西，就跟马克思主义指导中国社会主义建设一样，没有思想指引，也就只能瞎摸了，自然效果肯定会大大折扣。检查表的建立，减少瞎摸时间，提供重点评审方向，这个对评审过程很重要，简而言之，这个是应该有的。

4，参评人员，做好准备工作，熟悉评审内容，且应提炼自己的关注点，最好能形成文档记录。

没有调查研究就没有发言权，不熟悉评审内容，评审时也只是打打磕睡，混过去了。这个现象是普遍存在的，我就经历过几次。51Testing软件测试网9pP1p+O{(@W8BI;]

5，主持人对内容主旨的把握

相信大家在评审的过程中，开发人员讨论技术细节的情况很多吧。要知道，评审是发现问题，而不是解决问题的，所以主持人就得充黑脸了，要不然时间就浪费了，这个也是经常发现的现象。51Testing软件测试网
_W@4o;FwuT0^

6，评审时间的把握51Testing软件测试网 zP@+x/^~K.{
O}

不知大家注意过没有，评审的前五分钟，基本处于进入状态的状态，然后跟着的一个小时，大家处于活跃状态，发现的问题较多，然后降低，最后睡着了。所以，一般说来评审时间不得超过两个小时，不过我更主张时间不得超过一个半小时，可惜啊，俺们评审一般就是4个小时，对于这个时间我很无语。

7，千万不能批评人，只能讨论问题

评审变成小型批头会的事，不知有人经历过没，反正俺体会过，对于这个得坚绝扼杀在摇篮里，要不然担误了评审时间还是小事，以后合作会很有问题的。51Testing软件测试网 iMYz LV

8，评审问题需要入库，评审结果需输出报告51Testing软件测试网1K V&l }
P;~.b-a'A:wF

既然是问题，肯定要入库啦，要追踪解决情况嘛。而且，一般说来，人都有习惯性，所以分析历史评审问题点，对于新项目中的问题，还是可以进行猜测，分析的。

9，评审通过准则的建立51Testing软件测试网*y]'H\}6v4XU

评审不能没完没了，所以还得有退出条件的。说说，最小条件吧，其它的，俺还不是很明白，就不谈了。评审通过最小原则，产品已返工并确认，主持人已经发布审查报告。51Testing软件测试网PGq/sJ"X'lod}.T

 51Testing软件测试网-N8GG;aiM3f-?

原则上面已经说得很明白了，那么基于这些原则，来看看现在咱们公司的测试用例评审。51Testing软件测试网Zlk*b*C;ZC

1，领导还是必较重视的，但好像评审人员很不重视，有的甚至认为是浪费时间，这个没啥办法，只能培训了，让大家认识到评审的作用，另外，总结每次评审的数据，用数据说明其重要性。

2，评审人员的结构化还是做得比较好的，说说用例评审的组成人员，UI设计人员，需求分析人员，开发人员，测试执行人员，执行测试组组长，用例设计人员，资深测试工程师。没办法，咱们的项目全是内研的，没有客户，更别提业务专家了。

3，确定工作产品检查表，有一份，但似乎每次都一样，没有具体更新，而且咱们是先评审，再填这个表格，根本没有事先给参评人员查阅。51Testing软件测试网.Z_Q*H'e`!h{(G&DR

4，参评人员，做好准备工作，熟悉评审内容，且应提炼自己的关注点，最好能形成文档记录，这个就太差了，不说开发人员，看看用例内容了，连测试执行人员都懒得看，当然原因有是多方面的，但据现在观察，主要还是主观上的。另外，有些时候用例设计人员甚至都对用例不是很清楚，“怀具”啊，究其原因还是跟现在用例设计方法有关，因为，咱们现在只能叫写用例，不能叫设计用例，没有整体构思，很散乱的，一旦评审时有人打扰，全乱了。51Testing软件测试网 p&Eb/G+d B

5，主持人对内容主旨的把握，还好，这个还行

6，评审时间的把握，说起这个，就是“杯具”，有一天评审两次，上午4小时，下午4小时，效果可想而知的，反正超过1.5小时后，我选择睡觉。51Testing软件测试网1o8nF#h/j"w6W/?

7，千万不能批评人，只能批评事，这个还行，很少出现“批斗会”的情况，不过也还是出现过的。

8，评审问题需要入库，评审结果需输出报告，报告这个是有的，至于入库嘛，没看见过。51Testing软件测试网I SqS%b/q

9，评审通过准则的建立，这个没有形成文档，默认最小原则吧。不过，改正之后是否正确，就没下文了。51Testing软件测试网h ut4oF_

那么基于以上现象，怎么改进呢？我认为可以在准备阶段下工夫，要知道一般说来准备阶段发现的问题数应该是正式评审结果的1/2，效果还是很明显的。

准备阶段：1，确定参评人员，分配不同角色的关注点

         2，确定评审检查表，可分不同角色进行检查表的建立

         3，通知相关人员准备评审，把用例发给所有相关人员，并要求按检查表进行检查，收集检查表问题点，且收集其它问题

         4，确定评审范围，可抽查某个模块51Testing软件测试网
xu.UTN/Y;M^
u!e

         5，确定评审通过准则51Testing软件测试网Xl&l2C^\:v`

         6，确定评审过程中需要注意的事项51Testing软件测试网9nv/fY(tL*X(H q9v

         7，确定时间和地点

         8，确定输出报告人和检查修改情况的人员51Testing软件测试网j"vYU
r

剩下的事，就是正式评审了，评审过程中会发生啥事，也只有看“天”了。下面给一个具体的例子吧！51Testing软件测试网\|ZnS T g

1，预通知，发邮件，抄给老大和相关人员

XXX项目的XXX测试用例设计工作已接近尾声，按照公司流程和项目要求需要对XXX项目的XXX测试用例进行评审，按照计划，测试用例正式评审在X时进行，为提高测试用例评审的效率，请A人员参考AXXX检查表，请B人员参考BXXX检查表，请C人员参考CXXX检查表，对XXX模块进行检查，并于X时，反馈此内容于X某且X某与正式评审给予回复！

2，正式通知，发邮件，抄给老大和相关人员

  按计划XXX项目XXX模块与X时X地，进行评审，请A,B,C,D按时参加！为确保测试用例的评审效率，请A人员重点关注：XXX；请B人员重点关注：XXX51Testing软件测试网9~V ?Z-n3N

注意：51Testing软件测试网2t-oI Jts1L0{

1，评审完毕之后，X某输出评审报告，此模块用例责任人X进行修改，X进行检查，检查之后，将用例发给相应人员，请A人员参考AXXX检查表，请B人员参考BXXX检查表，请C人员参考CXXX检查表，对XXX模块进行检查进行反馈，如检查表99.99%通过，则此模块评审完成。51Testing软件测试网-R?g[ Y8b

2，评审过程只发现问题，不讨论具体技术细节，如讨论具体细节，主持人可要求相应人员，停止讨论。51Testing软件测试网Z/g'z4jWBZw

3，评审只对事不对人，请注意用语。

4，如文档质量，60%的人觉得太差，可停止评审。

                                       qwen 2009-12-31