国内为数不少软件企业虽然经过多年的发展，但仍处于疲于奔命、停滞不前的局面；另一方面，规模像“作坊”一样的小公司，几乎每天都在诞生、消亡。导致公司兴衰成败的原因是多方面的，笔者以为其中一个最重要的原因是软件产品质量的好坏。（当然，市场策略也是其中一个极为重要的因素。）几乎所有的企业都想对自己已有的技术成果或项目成果进行产品化，然后再把产品市场化、国际化。可是，绝大多数企业的软件产品一旦走向市场就会遭遇重重困难，例如，软件质量不过关，软件可维护性差，软件使用学习周期过长等等问题。本文不打算深入剖析决定软件企业及其产品成败的各个因素，而是侧重于测试角度，以案例的形式，对软件企业中影响产品质量提升的常见错误认识作一些分析并给出解决方案。
软件公司在产品开发中，通常存在三大不合理现象，它们严重影响了产品质量的提升：
1）为了保证产品的工期和进度，文档、质量管理、测试、评审等一系列工作统统可以忽略；
2）为了早日推出产品，不进行正规的缺陷管理，导致缺陷反复出现，缺陷较多的问题不能从“源头”进行控制；
3）发生质量问题不好好反思自己产品开发管理方面的不足，进而从最根本处入手解决问题；而是掩盖真实原因，追查个人责任。
本文将针对这三大现象，以真实的案例为蓝本，逐个进行剖析。
1、进度 VS 质量
本案例是非常典型的产品开发案例，几乎是很多中小公司的典型做法——以按时发布产品和进度为理由，不实施任何测试工作，就更不用说质量保证工作了。
下面是案例的一些基本信息：
产品信息
内容
产品名称
系统为J2EE结构的某行业的ERP系统。本产品是一个来源于项目的产品，原有客户和新的客户已经投入使用部分功能。
开发人员
产品开发人员10人。
功能模块
含有工作流流程的模块有30个，不含工作流流程的普通功能模块20个左右。
进度要求
当时计划一年内开发完成，实际目前已经耽误进度0.5年。
产品现状
主要功能基本完成，而且在一些新的客户中投入使用，反馈问题较多。
下面是产品开发的过程：
阶段
过程
大事记
项目立项阶段
三家大客户准备采用该产品，公司把三个项目在内部作为一个项目来开发，同时制定要把该项目成果产品化的目标。
为了赶进度，采取封闭开发的方法，同时决定第一版不进行测试。
第1个月
项目在没有文档的情况下进入开发状态，主要参考依据是公司内部基于另外一个平台的同类产品，该平台有些过时是开发这个产品的主要原因。
产品整个开发过程基本没有进行关键方案、文档的评审工作；没有进行任何测试；没有任何质量保证人员。
第2～5个月
产品正常开发，大多数功能由程序员做主进行开发。同时，开发完成的部分准备安装试用。
第6～12个月
开发团队进一步开发产品；
实施人员在现场安装已经完成的部分，同时做缺陷修改工作；
第六个月时，客户开始对公司施压，要求尽快安装全部产品，同时拒绝使用已经安装好的部分产品；
几个实施工程师以超人的“救火”能力，解决了现有缺陷，在几乎没有提供新产品的条件下撑过了半年。
第13个月
把主要功能提供给客户进行安装；
前面的几位实施工程师在季度会议上，被公司评为了“英雄”，给予了一定的奖励，鼓励他们继续坚守阵地。
第14～18个月
公司决定把产品交给现场的实施人员进行维护，专注产品化工作；
确定在接下来的6个月推出新版本的目标；
由于缺陷较多，现场用户抱怨不断；
实施人员忙于现场“救火”。
第19个月
所有的开发人员不再兼顾项目，加班加点准备按时发布产品。
……
……
……
现实中很多公司目前都是这样进行软件开发的，几乎很少进行测试工作，最多也就是在产品发布后进行最后的“用户测试”和一些功能性测试。当软件系统在用户那里出故障了，现场补救成功的人成了公司的英雄，好心的用户甚至还会因此寄来感谢信。然而这并不是真正合理的做法。如同案例中描述的那样，这会导致现场用户抱怨不断，分配用于“救火”的工程师越来越多，最后导致企业不堪重负，不得不放弃部分现有客户的系统维护工作。要想改变这种现状，应该从以下几个方面入手：
不但要主观认识到测试对软件质量的重要性，同时还要落实到行动中。
测试的重要性已经逐渐被软件开发团队认可。但是落实到实际工作中，通过测试真正提高软件质量，还有一段很长时间的路要走。因为几乎所有的软件公司都灌输着“进度高于一切”的思想，只要是为了赶进度和发布产品，所有影响进度的工作都可以忽略。
从表面上看，测试、质量检查、评审是在耽误进度，实际上则不然。如果软件缺陷被遗落并流落到客户那里，其结果就是代价高昂的电话费或者现场支持费 用，还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。这种成本付出非常高，几乎是在内部修改缺陷时的几何级数倍，一 般高达100～1000倍（可以参考PhilipCrosb的相关著作）。
案例中的情况，实际上就是为了赶进度而不进行测试，如果第一版进行规范的测试，后面那些“救火”英雄肯定会少些，同时也会得到客户对公司更大的认可。很多公司尽管对这个道理已经耳熟能详，但接下来如何进一步落实到行动中却是不容乐观的问题。
树立提高质量就是尊重客户的思想。
作者注意到目前不少公司存在着“愚弄客户”的嫌疑。不管是有心的还是无意的，很多公司认为只要能拿到“钱”就已经达到目的了，因此也不在乎是否 掩盖缺陷和敷衍客户。案例中的做法肯定是不尊重客户的，因为没有产品可以安装时，不说明实情，反而提供一个“满目疮痍”的产品来临时应付客户，甚至最后安 排实施人员“硬撑”半年。
生活中大家都讨厌假冒伪劣产品，但是软件行业从业者的却很少意识到质量不好的软件也是假冒伪劣产品。对客户负责，就是对公司负责。“树立客户是 上帝”的思想，一定要把重视质量落实到行动中，这样我们就不至于拼命的去生产那些“假冒伪劣”软件，最后被市场淘汰。在软件产业发达的今天，已经是客户的 买方市场，客户永远会选择质量好的、服务好的产品来满足自己的需求，只有质量好的产品，才可以不断的向前发展。
建立规范的测试体系和质量保证体系，逐步使软件开发进入良性循环状态。
在没有开发规范的前提下，软件团队是很少能开发出高质量的软件。因此软件团队一定要建立规范的测试体系和质量保证体系，同时把规范体系逐步落实 到工作中。案例中的公司就是没有“开发法律”的小软件作坊，所以才倒行逆施。不但做了很多浪费人力、物力的无谓工作，还给客户留下了不好的印象，造成了不 良后果。类似案例中这样的开发团队在现实中很多，都是处于混乱的开发状态。解决的根本办法就是逐步规范测试体系，进而建立全面管理的质量管理系统，最终形 成一个良好的开发体系。在好的开发体系下，片面重视进度的情况是不容易发生的。
2、缺陷反复出现，谁的责任？
下面的案例取材自某公司产品开发部开发某网络教育平台软件的工程过程。本产品在历时一年半的研发后开始投入测试。测试工作允许的时间为7个工作日。
测试工作过程记录如下
| 进度 | 测试人员 | 开发人员 | 其他问题 |
| 第一天 | （1）熟悉软件 （2）阅读项目文档 （3）制定测试策略（2人） （4）制作测试跟踪表格（1人） | 其它工作 | 无 |
| 第二天 | （1）确定测试策略 （2）划分测试任务 （3）阅读各自测试模块的文档 | 下午做整个系统的业务功能串讲（部分开发人员）。 |
| 第三天 | 开始执行测试 | 其它工作 | 缺陷总数70多 |
| 第四天 | 执行测试 | 其它工作 | 缺陷总数200多 |
| 第五天 | 执行测试 | 其它工作 | 缺陷总数500多 |
| 第六天 | （1）执行测试 （2）总结测试 （3）撰写测试缺陷报告 | 其它工作 | 缺陷总数600多 |
| 第七天 | 撰写测试分析报告 | 其它工作 | 无 |
经过7个工作日的测试，得出结果，此系统不可用，需做重大修改。系统经过重新设计，保留了部分原有业务功能和业务逻辑之后重新开发，并进行了测试。测试工作允许的时间为三个月。
测试工作过程记录如下
| 阶段 | 测试人员 | 开发人员 | 其他问题 |
| 单元测试 | 无 | build通过，操作均实现 | 无 |
| 集成测试 | 无 | 数据流转执行正常 |
| 系统测试 | 随着开发过程测试 | 无 | 缺陷总数500多 |
| | 全部开发完成集中测试 | 无 | 缺陷总数4000多 |
在最后的系统测试结束后，对测试结果进行了分析，发现如下现象：
第二版中的4000个多缺陷基本包含了第一版发现的600多个缺陷；
相似缺陷较多，例如：如果一个程序员写的模块中发现某个页面邮件输入格式没有校验，那么他写的所有页面中包含邮件数据项的内容都不会校验；
数据校验遗漏较多：如果在一个系统输入了不合法的数据项，那么，整个系统中就会出现几十个数据项合法校验遗漏；
细节错误较多，例如：页面Title不对应的错误在系统中有600多个；
程序设计风格不统一。相同的功能点，如分页、翻页处理，做得五花八门，并且以测试人员的理解来判断是否为缺陷，导致某些功能点在不同页面就能发现个3到5个缺陷。
通过上面的案例信息，可以看出这个产品的开发过程本身就是不规范的，而且测试工作介入的太晚，同时在软件产品设计、过程管理、文档评审等诸多方 面均存在问题。产品开发工作和项目开发工作相比，一般进度压力较小。但是产品要进行商业化最终转化为通用的商品软件，质量方面的要求要比项目成果高很多。 缺陷反复出现几乎是软件产品开发的一个常见现象，要想解决这个问题，作者建议整个团队要从下面几个方面入手：
规范化产品开发流程：产品开发是应该遵循软件工程规范的，开发过程不应该跳过必要的环节。例如这个案例中的产品，无疑就是开始系统设计和评审工作没有做好，才导致二次开发，并且还有一个严重的遗漏就是首次开发忽略了测试工作。测试、质量保证等相关工作应该从立项开始就同步启动。
需求分析要明确：如果开发人员都不知道完成的内容是否正确，而是由测试人员来判断是否符合要求，那简直是需求分析的的巨大“失误”。用户或者设计者想要达到什么目标一定要清晰的描述出来，模棱两可的需求是没有办法设计测试用例的，更不用说进行测试了。
开发人员的调试一定要到位：开发人员一定要认真调试代码，至少要把自己负责的部分和其它模块的接口部分进行 详细的测试。这项由开发人员进行的基础测试是不可缺少的。目标就是把尽可能多的缺陷消灭在开发阶段，这也无疑是最节约成本的。现代软件系统十分复杂，程序 员写了程序不仔细检查代码，大多会有很多缺陷存在。如果凭着侥幸心里把所有的测试工作都交给测试工程师来完成，那只能适得其反。这些本来在开发阶段解决的 缺陷由测试人员来发现会有如下的后果：
耽误进度——首先，缺陷要经过一定的测试流程。例如上面的案例中，网页的Title写错这样的缺陷折腾了两个部门，简直是“劳民伤财”。
转移测试人员注意力——大量的低级缺陷使测试工程师无法进行更加深入的测试。测试工程师的注意力分散在对于开发工程师来说“无关痛痒”的缺陷上，使得更深层次的缺陷隐藏起来。
降低开发人员斗志——尽管这些缺陷是开发人员自己“制造”的，但是一看到上百、上千个缺陷，无疑会影响心情，降低效率。
当然，增大开发人员测试力度会带来一定的投入，因此需要在项目初期进行合理的规划，否则开发工程师就会拼命赶进度，自然把测试工作“寄厚望”于测试工程师。
加强缺陷管理：缺陷管理在这个案例的前期做的不好。在缺陷管理中，我们不但应该把缺陷修改工作能否一次通过 作为考核开发师的标准之一，更应该把一些常见的缺陷是否存在作为考核开发工程师的标准。在经过一定的积累后，开发团队应该形成一些常见的程序缺陷列表，以 引起开发组成员注意。在此基础上，还需要做到下面几个要求来提高质量：
修改缺陷要彻底——彻底不单单是要修改好测试人员提交的缺陷，还要争取不带来新的缺陷、这就要求开发工程师修改缺陷时要对相关联的部分进行检查。
低级缺陷不存在——常见缺陷列表中的错误尽量不应该由测试工程师发现并提出。
3、产品发布后，缺陷谁来负责？
本案例发生在一个正在建设测试团队的组织中，这个研发团队有独立的测试小组，但不是独立的测试部门，产品部经理兼任测试经理。在产品提交给代理商后，代理商发现了一个严重的缺陷，并对其进行了投诉，最终的结果是公司领导层对开发队伍的相关人员进行了一系列惩罚。
测试过程简要记录：
| 测试阶段 | 测试人员 | 备注 |
| 单元测试 | 主要由开发人员负责。 | 开发人员一边开发一边测试。 |
| 集成测试 | 开发人员负责，测试人员没有参与。 | 没有作为一个独立的测试阶段进行，在开发过程中进行。 |
| 系统测试 | 由测试小组进行，共5名工程师，测试了进15个工作日。 | 测试过程采用了缺陷管理工具。 |
| 回归测试 | 测试工程师和开发工程师进行交互的测试、修改。 | 开发工程师修改完最后的缺陷后，把所有的模块打包，发送给客户。 |
| 验收测试 | 由软件代理商的测试队伍自己进行验收测试。 | 根据用户手册进行测试。 |
在代理商验收测试进行的第三天，测试人员发现了一个严重缺陷——“流转后的文档无法正常归档”。代理商立刻向公司的客户服务部进行了投诉。在此之后的10多天里，代理商的测试人员又陆续发现了近30个缺陷。
公司对产品的质量十分“震怒”，详细调查后，发现了这个问题产生的过程如下：
这个缺陷实际发现过一次，开发人员进行修改时，发现难度较大，决定暂停修改，得到了测试人员的认可；
接着大家忙于新的测试和修改工作；
产品发布前，开发工程师进行了修改，然后直接发布，在开发环境下问题确实得到了解决；
最后公司对相关人员进行了连带惩罚：
产品部经理、项目经理、开发工程师本季度绩效考核降为最低，即下个季度每个月份都要扣除一定比例的工资；
测试工程师绩效考核降为最低，同样扣除了工资。
上面案例的执行过程中，有几处显而易见的不合理的地方：
缺少文档，尤其是需求文档。文档是测试的主要依据。如果交给测试组仅仅是一个软件系统，然后告诉他“你们来测试吧，发现缺陷就提交”，我相信提交缺陷后开发与测试双方几乎会陷入喋喋不休的争吵状态。
测试介入太晚。只在系统测试阶段才安排测试人员进行测试，实际上质量已经失控了。尤其是没有文档，测试人员 无疑会把一些“缺陷”认为是合理的，而开发人员通常会自信地人为自己的开发工作是正确的。这样，一些问题是否是缺陷就会最终交给客户来完成。质量控制和测 试的相关工作没有按照合理的流程进行必然会产生这种结果。要改变这种现状测试工作就应该尽早地介入整个产品的开发流程。
回归测试做的不合理。案例中在回归测试时，“开发工程师修改完最后的缺陷后，把所有的模块打包，发送给客户”，这里明显还缺少一次测试。所有的缺陷应该经过修改验证后才可以发布产品，最后阶段发现的缺陷也不应例外。必须经过这道工序才可以发布产品，因为修改可能会带来新的缺陷。
产品发布的出口不对。案例中的产品最后是由开发人员发布的，这是十分不合理的。这些产品来自于开发环境，众 所周知，很多缺陷在开发环境下运行时是不出现的。产品在经过最后的回归测试并且确定可以发布后，应该把经过测试的产品而不是来自于开发环境的产品纳入配置 管理基线库，最后发布的产品应该从配置管理库中提取的。
缺陷流程不合理。这个带来严重后果的缺陷其实就是从不规范的流程“空隙”中逃脱的，原因主要如下：
缺陷的用户权限控制不严。开发工程师无权决定是否延期或者暂时停止修改某一缺陷。案例中开发工程师自己决定延期修改，测试工程师也进行了认可，这是不合理的做法。
没有对每个缺陷进行全程跟踪。测试工程师应该跟踪每一条缺陷，并确定修改后才可以进行关闭操作，而不是发现缺陷就完成了任务。
缺少了缺陷审核步骤。产品发布前，项目经理应该对产品发现的缺陷进行审核，根据修改状况来决定是否可以发 布。产品带着缺陷发布也是正常的行为，例如微软的大多数产品都是带着缺陷发布的。重要的是对最后未关闭的缺陷进行合理的处理。这些缺陷要由项目经理甚至是 技术总监进行审核签字后确定不进行修改后，才可以转入产品发布。本案例中如果事先对缺陷做过审核并确认，就可以规避风险。
上面的诸多原因，必然导致了产品会遗漏很多缺陷。实际也是如此。开始发现的这个“严重缺陷”只是个开端，后面陆续发现的30多个缺陷才是上面这 些原因的“所以”。如果这30多个缺陷都要进行惩罚，公司可以收入一大笔。虽然公司根本目的是想把产品质量做好，并不希望处罚大家，可是找不出提高质量的 根本方法，只能出此下策以儆效尤。
产品发布后的责任究竟应该由谁来承担？作者认为，应该根据具体的问题来决定。首先要意识到产品带着一些缺陷是正常现象。如果纯属个人原因造成， 个人是应当承担责任的，惩罚永远不是最有效的办法。实际上，本案例中的开发工程师在不到20天就提出了辞职并离开公司，给公司的产品开发带来更大的损失。 提高质量必须从提高项目管理水平处入手，同时加强质量控制来避免类似问题发生。
4、小结
通过对上面三个案例进行分析，我们应该已经意识到质量、进度、成本是相辅相成、同等重要的，决不可以忽略任何一个方面。尤其是软件质量，决不要 因为它是非硬性指标就敷衍了事。此外，软件测试作为质量控制的最重要手段，必须引起足够的重视。本文所讨论的案例，都是直接从实践中来的，且具有相当的代 表性。那么，为什么为数不少的软件企业会陷入上述“怪圈”呢？归根结底就是短期利益心理在作怪。希望企业能够通过本文的案例剖析，意识到问题产生的原因的 所在，进而提高软件质量管理水平，建立合理的质量管理体系。