测试人员尽早参与项目,是软件测试中的一个基本原则。但是,在测试实践中,测试人员的尽早参与常常是为了学习,例如:理解了测试对象之后进行测试用例的设计,而将尽早发现其中的问题和缺陷的目的放在了较低的优先级。这实际上很大程度上违背了评审的初衷。
下面通过笔者实际经历的一个案例,阐述这样的一个观点:测试人员参与评审,其最主要的目的是尽早发现其中的问题和缺陷;当然学习也是一个目的,但是学习的目的是为了更好的理解和设计测试用例,而设计的测试用例,其主要的目的是更加有效的发现测试对象中的缺陷,以提高产品质量。而在测试执行过程中发现和修复缺陷的效率会比评审低的多,而成本将高的多,该方面的信息,可以参考博客中的另一篇文章“用数据说话:评审如何降低成本、提升质量和帮助过程改进”。
案例中功能的简单描述:登陆某个系统,例如:某个网站,首先需要创建不同权限的用户。不同权限的用户,其对系统操作的内容是不一样的。本案例中,用户的权限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缺陷示意图
21/212>