启亚监理公司的项目总监蔡高工刚吃完早饭，就急急忙忙地往市政府办公大楼赶。因为上午九点市政府部门信息中心的金主任要主持召开项目会议，会议议程前两天就发给参会各方了，主要是关于市政府办公自动化系统用户测试的总结会。老蔡走在路上一直在想着这个项目，“项目已经进行了2年多了，前期需求调研、设计、开发都比较顺利，无论是质量、进度等方面，业主都比较满意，这次用户对开发成果进行测试，效果如果不错，就可以初验了……”老蔡想着项目的事情，丝毫没有注意到城市早晨的车水马龙，不知不觉就到了市政府大楼前。

    测试结果出人意料

    老蔡走进会议室，里面已经坐满了项目各方人员，有市政府各业务部门的项目负责人、开发商的项目经理和技术人员。九点钟刚到，金主任推门进来，会议准时开始了。金主任首先请各业务部门负责人发言，谈谈用户测试的情况。出乎老蔡的意料，几个业务部门都反映对这次用户测试的结果不满意，主要是发现很多比较“幼稚”的问题，比如：有的报表的数据明显不符合业务数据的要求，而且觉得系统的性能达不到要求，上报个数据表要等好几分钟……。

    老蔡边听边记，但是心里在琢磨：“在质量控制方面，监理工程师依据信息工程监理规范做了很多工作，比如：项目在实施前就要求开发商制定了质量保证计划；实施开始前监理仔细审核了实施方案，而且实施方案与合同、设计方案、实施计划是符合的；开发完成后，也审核了开发商的测试计划、测试用例，并要求开发商进行了完善，并且审核了开发商提交的有关测试记录、测试分析报告；在交给各业务部门测试前，还专门安排了工程师进行抽测，从抽测的结果看，监理认为还是很满意的，没有发现明显的缺陷。应该说，监理在质量控制方面已经做了很多工作，怎么会有这么多问题呢？

    摆脱“形式监理”

    金主任听完汇报，神色也沉重起来，对老蔡说：“蔡总监，刚才大家就测试情况进行了汇报，发现了不少问题，而且很多问题是不应该出现的，你怎么看待这次用户测试中发现的问题？”老蔡看了一眼开发商的项目经理小王，小王正低头忙着记录问题，于是他首先对小王说：“王经理，你们在交付用户测试之前，内部是否已经进行了测试？”小王连忙解释：“蔡总监，我们按照质量保证计划的要求，多次对代码进行了评审，并且还依据监理方审核后的测试计划、测试用例进行了测试，对发现的问题也进行了修改，并且也提交了测试报告；至于系统性能的问题，我们调试环境感觉还是很不错的，在数据库设计时就考虑到了系统性能的指标，优化了数据库设计；程序当中涉及的一些算法我们也进行了优化。”听完了小王的发言，蔡总监说：“开发商应及时改进用户测试中发现的问题，并且再进行测试，并把测试结果提交给监理方进行审核；监理方在开发商完成测试后，将继续组织工程师进行抽测。”

    这时，市政府信息中心的一位工程师忍不住插话道：“蔡总监，在软件开发项目上，监理在质量控制方面有哪些好的手段？比如：性能测试如何验证系统的性能指标达到了前期设计要求？功能测试方面，我们倒是可以通过亲自操作，直接发现问题，可是性能方面，很多情况是凭感觉，有时感觉系统很慢，有时倒是很正常，到底系统支持多少个用户并发操作？质量控制是监理的一项工作内容，能不能也采用loadrunner等测试工具进行性能测试，关于抽查测试，覆盖面能否放宽？”

    还没等蔡总监继续发言，市政府业务处的陈处长补充说：“现在很多监理在项目过程管理方面还不错，但这只是一部分内容，如果只做这些工作就是‘形式监理’。在质量控制方面，监理应该多采用一些测试手段和技术，只是评审测试文件或者进行一些简单的抽测，是远远不够的。”

    老蔡感觉今天这个会和自己早晨想的完全不同，业主方看来对项目的质量很不满意，作为监理也的确采取了措施，评审测试有关文件、参加抽测，可是系统太大了，好几百个新功能，不可能都抽测到。而且，性能测试一般监理工程师也无法做，太专业了。如果监理方亲自做测试，角色就类似开发商的测试工程师了，而且怎么评价项目质量呢？

    老蔡正在琢磨着，金主任发言了：“听了大家的汇报，我认为项目质量的确存在不少问题，开发商应尽快改进，监理方就如何在质量控制中有效应用测试手段，给项目办做个具体汇报。”

    会议散了，老蔡心里乱糟糟的，走出市政府的大门，还是来的那条路，老蔡脑子里不停地转着：监理方如何在质量控制中有效应用测试手段？难道我们的测试手段不够有效？路上的喧哗声也没有打扰老蔡的思绪。

    把握每一个质量控制点 （翁沧南 陕西计用信息技术监理有限公司 总监理工程师 ）

    对软件开发项目的监理工作，应该把握软件开发过程中的每一个质量控制点。

    启亚公司所监理的项目，在系统测试阶段遇到了问题，如果仅在测试阶段来找原因，恐怕是不够的，应该彻底反省一下公司所监理的办公自动化软件开发的全过程，寻找哪个环节上下的功夫不够。2006年开始，我们公司监理了一个省级电子政务社会保险本地化应用软件开发的项目，项目已通过验收，目前正在全省推广使用。历时两年的开发与监理，确实不易，下面说说我们的几点体会，供蔡总监参考。

    选择相当资质的开发商

    选择具有相当级别资质的开发商作为项目承建方，是规避项目建设风险的一个关键环节。该开发商必须具备三个层面的人才，一是资深的软硬件系统专家级人才，一旦发生深层次的系统故障，即可将他们调到项目实施现场，分析解决问题；二是具有管理经验的、责任心强的项目管理人员，由他们来担任项目经理的职务，组织领导开发人员实施现场开发工作；三是熟知项目相关政策、行业知识的人才，以把握用户需要，力争软件编程一次到位。

    把握用户需求分析

    用户需求调研、分析阶段是一个非常关键的阶段。对于不同的政府部门，往往需求不同，有的还会涉及一些政策性很强的特殊规定，因此，不可能套用所谓通用的某个电子政务软件产品，一般应作二次开发。在这一阶段中，软件开发及现场监理必须有计划、有目的地与建设方一起，一个单位一个单位地实施需求调研，与相关人员面对面座谈，向他们介绍软件编制的设计思想，直接了解一线用户的要求，深入了解所涉及的相关政策及行业知识。

    依据实地调研得到的素材，编写出用户需求报告书应返给相关单位，由相关单位进行审核确认。这个过程可能会反复几次，只有把需求调研工作做扎实了，才能避免开发工作的返工现象，才能使编出的软件让最终用户所接受。本案中，蔡总监他们在这一阶段的某个环节，可能有疏忽之处，因而造成案中所说“对这次用户测试的结果不满意，主要是发现很多甚至比较“幼稚”的问题，比如：有的报表的数据明显不符合业务数据的要求……”如果是这样的话，建议蔡总监协调相关人员回过头来，再做需求调研阶段的补充工作。

    审核设计阶段的可行性

    概要设计与详细设计阶段。本阶段的工作应在对用户需求报告书进行细致分析的基础上进行，对每一个模块设计的效果都应与需求相符，不能想当然。这一步的工作是由承建方来实施，监理方应随时掌握其进度，概要设计与详细设计均应形成书面文档，提交监理方审核，审核每一步设计的可行性、合理性。必要时，将相关用户请来，向他们介绍详细的流程。在讲述的过程中，设计者往往会发现项目的不周之处。另外，请用户一起来参与设计，更直接，更到位，还能对用户进行培训，为后阶段系统软件的测试与试运行打下基础。

    以上两个阶段，表面上看费了很多时间，但是，是不可缺少的两个阶段，没有这两个阶段脚踏实地的工作，再好的编程高手，也编不出用户欢迎的、实用的软件。不知蔡总监他们在本项目的监理过程中，是否特别注重了这两个阶段。

    重视系统测试

    软件开发的系统测试阶段。通过了对详细设计的审核、承建方即可进行程序的编码、调试，一直到系统测试。系统测试应参照软件工程所要求的方式、方法来进行。

    如果所编制的软件比较简单，功能不多，系统测试工作可以遵照如下步骤进行：先由承建方提交测试方案、测试计划，由监理方及建设方相关人员进行审核，三方一起确认。然后由承建方进行自测试，并出具自测报告，再由监理方与建设方人员一起进行复测。整个测试工作，按需求逐条进行，应搭建真实的使用环境，对系统的功能、性能进行模拟运行测试，用户并发测试，最后撰写出系统初验测试报告，三方确认。

    对于那些比较庞大、功能比较复杂的软件，一般应聘请软件测试的专门公司，来介入项目的系统测试工作，实施对系统性能、功能、压力等方面的全面测试，最后由测试公司提供系统测试报告，对承建方所开发的软件作出权威的评价，或提出整改意见，整改后再做全面或局部的复测，直至符合要求。在我们所监理的省级社会保险系统软件的本地化开发项目中，就是聘请了一家专门的测试公司，他们派出测试人员，跟踪了项目开发的相关阶段，并对承建方所编制的每个模块及整个系统，进行了功能、性能、压力等方面的全面测试，出具了上千页的测试报告，在测试的过程中，提出了许多有益的整改建议。

    从本案例中，所进行的测试过程，似乎过于简单，试图仅经过承建方自测及监理方抽测后，就提交给业主方测试或使用，还想一次通过，这的确是不太现实。建议启亚公司根据本项目的实际情况，与业主方一起，重新确定测试方案，将测试阶段的工作真正做扎实。另外，还应注意到以下两个方面：

    第一，承建方参与软件开发的技术人员，未必对业主方一线的业务流程了如指掌，由于理解方面的差异，暴露出问题是很正常的。

    第二，如果在整个开发过程中，对用户第一线的操作人员培训不到位，用户在接受一个新的应用软件时，往往受旧的应用软件的操作习惯的影响，出现这样那样的抱怨也是难免的。

    要规避上述情况，作为承建方应注重开发项目所涉及的政策、法规的学习和理解，多深入用户第一线，从而使所编程序真正被用户认可。监理方应协调好项目开发过程中的培训环节，要求承建方技术开发人员花一些时间，与第一线用户进行技术沟通、交流，达成共识。

    在本案中还提到了“上报个数据表要等好几分钟……”的问题，这就需要监理方协调相关专家进行分析，是系统硬件配置不到位，还是部分软件模块需要进一步优化，要尽快拿出个结论来，好做相应的对策。

    当本工程通过测试验收后，即可进入系统试运行阶段，在这一阶段中，用户还会提出许多问题，仍然要花费很多时间与精力来加以解决，使系统逐步完善，对于这一点，蔡总监要有充分的思想准备。

    工程监理是个系统工程（陆兴潆 厦门东晟信息工程监理有限公司 总工程师）

    软件工程监理是一个系统工程，不是“在交给各业务部门测试前，专门安排工程师进行抽测”就能解决问题的。

    启亚监理公司在政府部门办公自动化系统项目中监理两年多了，“在质量控制方面已经做了很多工作，怎么还会有很多问题呢？”从用户反映的情况看，提出下面一些建议供蔡高工改进今后工作时参考。

    首先，该项目监理的对象是办公自动化系统，它的某些业务虽然与其他知识管理系统相类似，但由于其鲜明的特点，目前办公自动化系统已自成体系。它的首要特点是擅长处理类似公文、公告等流转类型行政办公类的应用需求，以及相对独立的个人相关资料、记事等个人事务类的应用需求；另外一个不同于其他应用软件的特点是其业务流程的权限管理。

    系统的测试分析应与其特有的业务处理方法紧密联系，针对流转型的行政办公之需求，最好使用现成的公司体制来进行分析，这样做沟通方便，且测试数据准备容易，不易产生歧义；针对独立型的个人事务之需求，首先要考虑统一给不同用户打上特殊标记，在准备测试数据时应避免不同用户具有相同的个人信息和相关资料的情况产生。以常见的办公自动化系统为例，其功能模块主要有行政办公、个人事务、综合信息和基础服务四个部分。

    进行功能模块测试时，行政办公流程需要重点注意批示的并行和串行情况，还要注意其组合方式是否能够全面覆盖；个人事务方面，以个人名片为例，需要特别考虑正确性、惟一性、保密性等；至于综合信息，不仅要保证其内容和格式的正确，还要保证传输准确、及时和可靠；基础服务部分，重点要注意用户登录名及其密码长度设置是否正确；存储大小设置是否正确、有效；预定义的行政办公中各个流转模块是否能被正确应用。

    其次，正如市政府信息中心的工程师对蔡总监提出的：“在软件开发的项目上，监理在质量控制方面有何好的手段？比如：性能测试如何验证系统的性能指标达到了前期设计要求？”这是软件工程监理的核心问题。监理的目的是验证软件系统能否达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，提出优化软件的建议，最后达到优化系统的目的。性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。其工作内容包括评估系统的能力、识别体系中的弱点、系统调优及验证稳定性（resilience）和可靠性（reliability）等。

    如何选择性能测试策略是我们在具体测试前就需要明确的，而软件架构在实际测试中制约着测试策略和工具的选择。在实际工作中我们经常会对两种类型软件进行测试：对于B/S（Browser/Server）基于浏览器/Web服务器的三层架构，一般会关注Web服务器指标；对于C/S（Client/Server）基于客户端/服务器的三层架构, 由于通常软件后台为数据库，所以我们更注重数据库的测试指标。当然，在实施时我们还会查看多用户测试情况下的内存、CPU及系统资源调用情况等。

    性能测试的需求由业务需要驱动，并由一组基于历史数据或预测的近似值之用例阐明。在每种不同系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。还因工程和项目的不同，所选用的度量评估方法也有不同之处。所以，性能测试的工作千头万绪，我们需要拟定步骤分阶段地执行，一步步向目标前进。微软公司的研究表明，性能测试的过程应该为六个阶段，包括发现、探究、提案、执行、复查、收尾阶段。

    本案例是由用户委托软件公司代为开发的一套应用系统, 各类应用环境、由不同供应商组装起来的复杂产品、难以预知的用户负载以及愈来愈复杂的应用程序，都可能使用户遭遇反应慢、系统失灵等问题。

    政府部门的办公自动化系统需要支持成百上千名用户，不仅测试时会遇到问题，今后用户实际使用时往往还会产生疑问,正如该市政府部门那位应用工程师提出的：“性能方面，很多情况是感觉，有时感觉系统很慢，有时倒是很正常；到底系统能支持多少个用户并发操作啊？”这就需要用压力测试工具辅助模拟实际情况进行自动负载测试，通过可重复的、真实的测试彻底地度量应用的性能和可扩展性，确定问题所在以及优化系统性能的方案。这样，预先知道了系统的承受力,就能为用户规划整个运行环境配置提供有力的依据。

    性能测试及调校还需要有耐心和毅力，例如负载平衡管理器的主要任务就是处理那些空闲的线程占用资源等问题，以避免因系统资源不足导致严重后果。我们可以这样估计系统资源什么时候被耗尽：分析当前系统可用资源量以及系统资源被蚕食的速率（一般我们是以天为单位来计算的），我们还要跟踪系统资源变化（以天为单位）以估计我们什么时候应该开始增加系统资源的工作。跟踪系统的反应时间（接收请求到发出响应的总时间），当这个时间达到某个值的时候我们也需要进行相应的处理或者增加系统资源。

    这个过程需要与用户充分地沟通与协调，尽量扩充团队的知识广度与深度，并且每一个步骤都要小心翼翼，升级系统才会比较顺利。

    只有在充分认识测试对象的基础上，我们才知道每一种测试对象需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）；考虑到其它因素，如网络锁、网速、显示分辨率、数据库权限及容量等对测试结果的影响，如条件允许，最好能配置几组不同的测试环境。这类问题都要借助于科学的软件测试手段和先进的测试工具，而且必须有一个适应该项目软件的、完整的监理测试计划，全面进行性能指标的测试，才可以及早发现，及时解决，不至于出现很多甚至比较“幼稚”的问题。  

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。