有关评审的一些问题

张志英

不知道大家做测试的时候有没有进行过评审，我觉得在测试的流程中，有两个评审会议比较重要。
一是需求评审，目的是为了确认需求
二是测试用例的评审，目的是确认测试用例的克执行性和有效性，确定测试用例的优先级
但是评审的具体过程应该是怎样的呢？先进行内审，在进行外审吗？参加的人员应该要有哪些？评审通过的标准又是什么？
我在网上查到一些资料，但是希望有经验的人士提提意见！！

chengning

这个根据公司的规模 公司的性质 以及公司对测试的态度 有所不同  因为评审需要专家 开发和需求人员同时到场  所以费时费财  呵呵  所以各公司没有统一的标准  
通过的目标 在需求审评  当然是对需求的确认 正确性 合理性等
用例方面主要是看覆盖是否满足要求  性能设计是否达到指标  环境的设计是否符合实际 等  主要看是否符合已经确认了需求要求

peag

国内好像还很少公司能够有明确滴评审

qzj_test

内审：就是内部评审么，这个都知道
外审：就会有客户参与了

千里

这个环节在国内感觉做得比较少

Jackc

确实，在国内这个评审这个概念很淡薄，但是却是无处不在的。比如经常做的代码走查、立项会议、需求讨论等等其实都是一种简化的评审，有的公司把这叫做“头脑风暴”（往往是遇到难题的时候集中大家的智慧来冲关 ）

1、可以评审的东东很多，需求、策略、计划、用例、代码.....基本上项目中你能想到的东西，都可以拿出来评审。

2、组织评审需要有清晰的目的（这个是整个环节中重要的部分），很简单，你首先要知道，你需要从这个评审中得到什么？也许是希望被评审东东更加完善，也许是希望增加大家交流的机会，甚至可能是为了应付上面的检查等等。

3、不同目的评审，参与人员自然也随之变化：
比如，希望需求更加完善的评审，理论一切与产品有关的人员，大到项目经理，小到一线销售人员都需要来参加。但是，往往评审的人员越多，时间上就越难安排，所以需要结合实际情况来删减。

当然，也不是说必须要XX人参加的评审才叫评审，比如一个BA与一个客户或开发人员私下的一次交流，只要做了详细的记录，也可以算作是一个评审。

所以，有内容的评审其实是不拘形式的，假如非得搞个内审或外审来规范，我只能说那是走过场而已。

4、在组织评审的细节上，有一点很重要：不要在评审过程中“照本宣书”。
很多公司在评审前不做准备，评审时拉个主持人上去就对着文档、PPT一阵读，半天下来，问大家有没问题，结果只能是只言片语。

所以，在评审前最好先做预审，也就是在评审前，给予评审人员一定的时间，也许是三、两天，也许是一星期，让评审人员熟悉评审目标，并提出自己的意见，由一个统一的程序收集起来，在评审中逐一解决。这样的效果会好很多。

5、最后说说比较规范的评审流程
确定评审目标——确定参与人员（包括主持人、记录员、评审员等）——安排评审时间——预审——整理预审报告——评审——整理评审报告——作者修改评审目标——复审（复审可以走简单流程，由各个提建议的评审人员查看自己的建议是否得到合理的修改）——存档