现象1：没有遵循2/8原则注意评审的重点
要评审的对象内容需要有侧重点，一般按照2/8原则确定主要内容进行评审，而不要泛泛地对整篇文章进行处理。
现象2：就某个文档而孤立地评审该文档，没有对照已有的成果和标准
需求和设计是软件开发项目的中间文档，前面会有一些约定输入，也可能会要求遵守相关标准。除非是对这些输入的内容已经了如指掌，可以敏感地发现互相之间的不一致性；否则一定要考虑仔细对照相关的输入。
就某个系统而评审该系统，没有考虑相关系统。当客户或企业已经开发了多个软件系统之后，系统之间的相关性必须是考虑的因素，这些相关性包括数据之间的关系、业务之间的关系、用户管理、系统管理的一致性，操作习惯和界面的关联性和软件复用等。
现象3：会议上过多地讨论问题如何改正
评审的目的主要在于定位问题，一旦正确地确认了问题，大多数都能很快找到解决方案，对于一时无法给出解决方案的问题可以在评审后研究讨论。
因此，一般的同行评审会建议如果在一个问题上超过3分钟，可以做出结论并到下一个问题；如果评审专家之间有不同意见，做出记录，得到结论并到下一个问题。
当评审专家讨论起解决方案时，主持人可以要求他们在会后讨论。
现象4：评审与评价混淆
评审的目的是指出具体问题以便改进，评价是给最终工作结果及人员工作绩效下结论。不能把这二者混为一谈，尤其是把评审结果作为评价个人能力的指标时，对评审活动的进一步开展很不利。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
