评审是静态测试的重要组成部分。测试人员对评审在软件开发生命周期中的作用，例如：降低成本、提高质量等都有所了解。但是，为什么评审工作的开展还是那么困难，从参与人员对评审的理解、评审时间的计划和资源的预留等。笔者认为其中的主要原因是大家没有从实践中看到评审的作用，也就是说很多人没有直观的认识评审的作用，使得评审的过程还是流于形式。
下面通过介绍笔者在实际项目中的一个案例分析，以直观而简单的方式，阐述评审在软件开发生命周期内能起到什么作用。在这个项目案例中，没有什么数据分析，但是我们，不管是开发人员还是测试人员，我们都可以感受到：假如有效开展评审活动，我们可以省力很多。
案例中功能的简单描述：登陆某个系统，例如：某个网站，首先需要创建不同权限的用户。不同权限的用户，其对系统操作的内容是不一样的。本案例中，用户的权限UAP（User Access Privileges）分别定义为CONF、PROV、ADMIN、DEBUG和READ五种类型。
针对用户权限UAP的选择，系统的需求是这样描述的：创建的用户UID（User Identifier），可以为它们分配不同权限的UAP。但是，每个用户的权限UAP都至少包括READ权限，即每个用户都需要有READ权限。图1是用户权限UAP进行选择和删除的简单示意图。
图1 用户的UAP选择示意图
在开发人员实现该功能的过程中，包括图1的界面设计上，测试人员都没有参与进行评审。等开发人员将功能提交给测试人员之后，测试人员在测试过程中发现了下面的几个缺陷：
● 默认得UAP权限READ可以被删除，即在图1中，右边方框内的Read-only（READ）可以被移除；
● 假如在修改用户的属性时候，再选择一次Read-only（READ），那么修改之后的用户权限中会出现两个Read-only（READ）的条目，如图2上半部分所示；
● 假如在修改用户属性的时候，只选择了除Read-only（READ）之外的其他权限UAP，那么修改之后的用户权限没有了Read-only（READ），如图2所示的下半部分；
图2 用户的UAP缺陷示意图
根据系统需求中的描述，每个用户的权限都至少包括Read-only（READ），因此，上面的3个问题都应该确认为缺陷，测试人员分别都提交了缺陷报告。
在项目结束之后的总结会议上面，笔者就针对该功能的实现和GUI提出了自己的想法：假如在开发人员具体实现阶段，邀请测试人员参与评审活动，该功能的实现可以更加简单高效。笔者的建议包括：
● 根据需求的描述，Read-only（READ）应该作为每个用户UID必须具备的权限，因此将Read-only（READ）作为每个用户的默认值，不允许进行增加、修改和删除等动作；
● 根据上面的建议，在该功能的图形化，如图1所示中，将Read-only（READ）选项移除，因为改选项已经通过内部代码实现了，不需要操作人员进行选择。
假如开发人员采用了笔者的建议，在软件实现过程中，可以获得下面几个好处：
● Read-only（READ）作为每个用户的默认值，不允许增加、修改和删除，那么，在图1的示意图中直接删除Read-only（READ）选项，可以简化示意图；
● 按照上面的思路，代码中就可以省略针对Read-only（READ）异常处理，例如：在修改的时候，不需要判断用户是否重复选择了Read-only（READ）选项，或者没有选择Read-only（READ），直接可以节约开发人员的代码异常处理的工作量；
● 而对于测试人员，由于前期参与评审工作，发现了其中的一些缺陷，提高了代码的质量，可以减少后续的测试工作量。
相关链接：
