感受项目的磨难，渴望快乐的项目—H项目总结5，项目质量控制

项目质量控制：
H项目的系统测试开始于2006-10-8截止到2006-10-15，全阶段参与的包括：项目经理、技术经理、5个开发人员、2.5个测试人员。共2.5人月
用户测试开始于2006-10-18截止到2007-1-30，全阶段参与包括：项目经理、2个测试人员、技术经理、4个开发人员。共28人月。其中2个月是现场实施并测试。在测试阶段主要存在以下问题：
1.        在开发阶段缺乏有效的质量监控手段，绝大部分的质量问题都是积累在系统测试、用户测试阶段发现解决，使用户测试所占的总时长、工作量都过大，并导致用户满意度降低。
分析原因有以下：
1、前期合同制定的计划太过理想化，到进入编码阶段时，进度就开始落后了，要求大家加班、封闭开发等的措施，虽然加快了进度，同时也导致开发阶段对质量的控制力下降；
2、在开发过程中没有执行代码走查。这也是进度压力下做的阶段性质量妥协。
3、在开发阶段，开发人员的自测效果较差，代码在开发阶段基本无法通过冒烟测试（即测试人员一测试就会遇到导致测试中断的问题，无法继续测试）；在系统测试、用户测试阶段，开发人员解决旧问题的同时产生较多的新问题并且自测也没有发现并纠正，这使质量改善的效率很低。
****建议（下面的建议不涉及计划的制定，因为关于计划的问题已经在前面的总结中讲过了，只讲提高质量的方法）：
1、强调开发人员必须重视自测。技术经理对于开发人员的代码质量也要有监控，最好能组织代码详查，通过代码审阅的方式，较早发现并纠正质量问题。
2、在每日构建中加入冒烟测试，要求开发人员按照每日构建和冒烟测试都必须保证通过的标准，安排开发工作。强调开发人员必须重视解决冒烟测试的问题，最好要求每天做冒烟测试（至少每周两次），最好可以是自动化冒烟测试。
3、建议从小的项目，由技术骨干带领开始使用测试驱动开发，执行自动化单元测试。再逐步推广其他项目。
 
2.        测试用例没有持续完善，导致测试工作的质量不可控，软件质量改善的效率降低。在概要设计完成后，测试人员就开始在TD中编写测试用例。因为测试人员经验不足及当时还没有可以运行的软件，当时编写的测试案例质量和可执行性都不高，在系统测试时通过实际测试软件，才对软件和测试案例有了进一步的理解，但是因为时间紧迫，没有再完善测试用例，以致后面若干轮的系统测试，都没有可以衡量评估测试工作质量的依据，使测试工作处于一种混沌状态。
****建议：在测试过程中要持续完善测试用例，只有通过测试用例文档化，并记录测试用例的执行结果，才能衡量并提高测试工作的质量。
 
3.        在开发阶段没有做性能测试，在用户第一轮测试时就暴露出较严重的性能问题，用户负面反馈很强烈。用户测试的数据库里一个最常用的物料基本信息的数据量是3万条，访问物料信息的一个系统公共视图当数据量较大时性能很低，这导致系统很多界面的性能表现低下。
****建议：在开发阶段，就需要测试人员和开发人员合作，在开发库中模拟建立较多的数据。并在专门的压力测试数据库中进行压力测试。这项工作如果做了，虽然在开发阶段需要增加投入10人天，但是可以提高用户满意度。
 
4.        在编码、系统测试、和实施阶段测试人力不足。在整个项目周期中，全时的测试人员只有2个，项目经理的主要精力在和项目团队沟通需求，编写结算、条码导入代码，和客户现场沟通，编写准入评审、验收评审文档，在测试上分配的精力较少。所以测试组从开发到用户测试结束阶段，实际人力投入不到2.5个人。测试人力不足导致系统整体的测试工作质量和进度都不能令人满意。以H项目二期的规模，测试人力4个人较合理。以后项目测试人力和开发人力的比重建议1：2。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/pekingsun/archive/2007/04/24/1583413.aspx