案例六：软件测试

5．6案例六：软件测试
   阅读以下关于信息系统项目管理过程中项目质量管理方面问题的叙述，回答问题1至问题2。
5.6.1案例场景
    老王在中培信息技术有限公司(Z公司 )工作，被委派到了一个新的项目担任项目经理，为客户K公司开发用于支撑业务的信息系统。这是一个规模较小，复杂度较低的系统。由于市场竞争的原因，合同额很少。出于成本的考虑，公司分派给老王的人员并不多。为解决人力资源不足的问题，老王考虑，系统复杂度不高，可以一定程度上简化测试工作。于是老王在项目中做了如下安排：
    (1)不进行单元测试和集成测试，仅进行系统测试。
    (2)不安排专门的资源开发系统测试用例。因为程序员熟悉自己开发模块的业务，由程序员对自己开发的程序进行黑盒测试，对测试中发现的缺陷进行记录并跟踪，且立即修改。
    (3)在测试过程中，每三天定义为一个测试周期，统计每个测试周期每个模块发现的缺陷数量。若连续两个测试周期没有发现的缺陷少于总缺陷的5%且发现缺陷的趋势基本平稳，则认为测试工作基本完成。
    老王的理由如下：首先，随着系统中缺陷的减少，程序员会有越来越多的时间进行测试，以发现系统缺陷。其次，当系统中的缺陷数量很少时，程序员发现的缺陷会变得越来越困难，总缺陷数几乎不再增加，这时发现缺陷的趋势变得很平稳，且发现的数量很少。
在测试阶段，老王统计到的数据如表5-1所示。

    老王认为测试工作基本完成，决定进入系统发布阶段。
 【问题1】(12分)
    请以300字内，逐一点评老王对测试工作进行的三点安排。
    【问题2】(13分)
    在人力资源有限的情况下，老王不可能找到专门的测试人员全程进行测试，那么老王应做哪些改进来提高测试工作的质量，试以300字内回答。
5.6.2案例分析
    该案例中描述的场景是很多软件公司中常见的场景，由于市场的恶性竞争或是其他原因，开发的费用被一再压缩。为了满足成本的约束，项目经理忽视测试的工作，项目组成员在项目中身兼多职，从需求一直做到测试。系统缺乏完整的测试，甚至没有测试就提交给客户。虽然案例中没有写明，但结果已经可以想像，客户为充满问题的系统而恼火，即使项目谈不上失败也绝对谈不上成功。
    人们常说：“再穷不能穷教育”，对于软件项目而言就是“再省不能省测试”。软件系统的技术复杂度相对较高，结果抽象，可以模式化的东西很少，开发过程也是一种探索的过程，在每一个步骤都会制造缺陷，这已经在无数的软件系统开发中得到了验证。成功的系统总是正视这种客观情况，通过各种各样的方法来提高质量，尽可能早地检出系统中潜在的缺陷；失败的项目则是回避，总是假设不会出现缺陷或缺陷很少，．任由错误扩大，最终肯定是缺陷的大爆发，开发人员疲于修正缺陷，同时再引入新的缺陷。
    在案例中，老王在人力资源不足和项目质量上进行了折中，进行角色复用，把开发和测试安排到一起，根据缺陷发现的趋势来判断测试是否可以结束，于是问题就出现了。
    对于软件开发中的角色复用，专门的论述并不多见。我们在这里引用MSF中关于开发角色和角色合并的内容进行讲解与分析。在微软的项目管理框架一MSF中定义了软件项目中的6种角色：
    (1)产品管理，负责产品的定义，如客户代表、产品负责人、需求人员。
    (2)程序管理，按项目的约束进行交付，如项目经理、开发主管。
    (3)开发，根据规格说明书(需求规格说明书、设计说明书等)进行系统的构建，如系统设计人员、编码人员。
    (4)测试，确定并找到系统中的质量问题，如测试人员。
    (5)用户体验，负责把握用户在使用系统时的感受，例如，需求人员、界面设计人员、系统培训人员。用户体验不同于产品管理，用户体验着重从用户处获得需求与反馈信息，而产品管理则注重于产品的定义，其定义的依据既包括用户需求也包括产品路线图等内容。
    (6)发布管理，负责系统的部署的稳定的运行，例如项目经理、系统管理员。
在MSF中给出了角色间合并的建议，如表5-2所示。

根据表5-2可以看出，开发人员虽然是程序的创造者，但不推荐和其他任一种角色合并。MSF是微软总结了其多年的开发经验整理出来的项目管理框架。也就是说，即使是在微软这样的公司，虽然每个人都有足够的能力，但开发人员仍需要独立出来，不能够与测试混为一谈。
    这一点也不难理解。首先开发人员与测试人员的技能侧重点不同，开发人员侧重于技术的细节，关注于系统实现所采用的技术和方法，更需要把握如何应用技术手段构建满足规格说明书的系统；测试人员侧重于技术的结果，关注于系统实现后的表现和效果，更需要把握实现的系统是否满足规格说明书的要求。其次，开发人员与测试人员的目标不同，开发人员希望能够构建出完全符合要求的系统；测试人员则需要在看似完全符合要求的系统中寻找缺陷和漏洞。因此，开发人员同测试人员的视角不同，开发人员总是倾向于构建后的系统是完美的，而测试人员则倾向于构建后的系统是有缺陷的。这种种不同，造成开发人员很难发现自己构建的系统中的缺陷，存在盲点，而测试人员更容易发现系统中的问题。
    再回到这个案例，不难发现，老王正是在这一点上犯了错误，把开发和测试结合到了一起，让程序员测试自己开发的程序。
    在问题1中，要求对老王进行的测试安排进行点评，上面我们已经谈到，第二点是肯定有问题，那么其余两点呢？
    对于第一点来说，是完全可以的。虽然在严格的软件开发模型中定义了单元测试、集成测试和系统测试，但在实际项目中完全可以根据项目情况进行裁减。如果系统复杂度不高，系统规模又比较小，我们可以考虑仅仅进行系统测试。不过在裁减过程中应该注意，单元测试相对集成测试更重要。集成测试可能会同系统测试部分重合，但单元测试相对独立，可以发现一些极端情况下的问题和程序上的低级错误。在案例中，即使是程序员自己测试自己的程序，前三个测试周期中仍发现了不少缺陷，就是由缺少单元测试造成的，系统中还存在不少低级错误。
    对于第三点来说，根据缺陷发生的趋势来判断测试工作是否完成，是一种可行的方法。如果测试过程公正客观，发现的缺陷具有代表性，以此为依据进行判断是有效的。但反之，若测试过程不充分、不客观，这种方法毫无意义，因此在案例中这种方法加剧了开发人员与测试人员合并的恶果。
    第二个问题也是项目中的常见问题。当人力资源有限时，我们应该如何在保证项目质量的前提下压缩团队规模。
    我们根据MSF中的角色合并建议来回答这个问题，见表5-2.表5-2中列出可以和测试角色合并的角色包括：产品管理、·用户体验和发布管理，在某些情况下，测试可以和程序管理相合并。
    除了角色合并外，还有一些方法，可以以较少的人力投入换取更高的项目质量。其中包括：
    (1)程序员间进行交叉测试，最好可以同其他项目组的程序员互换，让程序员在互换中变更自己的角色。
    (2)在程序员自己发现的缺陷区域平稳后再提交给测试人员进行测试。这样可以避免测试人员陷入低级错误中，减少其工作量。
5.6.3参考答案
    【问题1】(12分)
    (1)不进行单元测试和集成测试，仅进行系统测试。在低复杂度的小规模项目中，这种做法尚可，通过系统测试可以发现大多数系统中的缺陷。(4分)
    (2)不安排专门的资源开发系统测试用例，由程序员对自己开发的程序进行黑盒测试，并对测试中发现的缺陷进行记录并跟踪，由发现者立即修改。
    这种做法问题会造成很严重的问题。程序员是程序的创造者，是无法进行黑盒测试的。这种所谓的黑盒测试会造成测试的盲点，一些缺陷始终无法发现。(4分)
    (3)在测试过程中，每三天定义为一个测试周期，统计每个测试周期每个模块发现的缺陷数量。若连续两个测试周期没有发现的缺陷少于总缺陷的5％，且发现缺陷的趋势基本平稳，则认为测试工作基本完成。
    若有专门的测试人员，公平客观地进行测试工作，这种判断测试工作是否完成的方法是有道理的，可以保证绝大多数的缺陷都在测试中发现。(4分)
    【问题2】(13分)
    在人力资源有限的情况下，老王应做如下方面改进来提高测试工作的质量：
    (1)根据项目实际情况，由项目经理、需求人员或客户业务代表进行测试。(7分)
    (2)采取程序员交叉测试的方法。(3分)
    (3)若情况允许，可以在程序员自己发现缺陷趋于平稳后，再提交给专门测试人员进行测试。(3分)