1. 如何保证软件的质量
软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：
⒈一种质量管理方法
⒉有效的软件工程技术（方法和工具）
⒊在整个软件过程中采用的正式技术评审
⒋一种多层次的测试策略
⒌对软件文档及其修改的控制
⒍保证软件遵从软件开发标准
⒎度量和报告机制
SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。
软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。
SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SQA小组完成：
⑴为项目准备SQA计划。该计划在制定项目规定项目计划时确定，由所有感兴趣的相关部门评审。
·需要进行的审计和评审；
·项目可采用的标准；
·错误报告和跟踪的规程；
·由SQA小组产生的文档；
·向软件项目组提供的反馈数量。
⑵参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策，内部软件标准，外界标准以及项目计划的其他部分相符。
⑶评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。
⑷审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。
⑸确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。
⑹记录所有不符合的部分并报告给高级领导者。
2. 软件开发过程中,怎么样才能保证软件质量
摘要
3. 如何做好软件的质量管理
在实际的项目质量管理中，质量管理总是围绕着质量保证(Quality?Assurance)过程和质量控制(Quality?Control)过程两方面。这两个过程相互作用，在实际应用中还可能会发生交叉。正如引言所述，关于软件的质量，很难下一个非常明确的定义。本文主要针对软件工程中的质量管理来进行讨论。
1、做软件“大餐”的工序
软件质量保证（Software?Quality?Assurance，以下简称SQA）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。软件质量保证过程一般包含以下几项活动：
首先是建立SQA组；其次是选择和确定SQA活动，即选择SQA组所要进行的质量保证活动，这些SQA活动将作为SQA计划的输入；然后是制定和维护SQA计划，这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系；还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。
独立的SQA组是衡量软件开发活动优劣与否的尺度之一。SQA组的这一独立性，使其享有一项关键权利――“越级上报”。当SQA组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。
4. 软件测试中如何保证软件质量
软件在没有发布之前的开发过程主要分为需求分析、设计、编码和验证四个阶段，最终的软件质量与这四个阶段的各自质量之间的关系如果用C语言来表达的话应当是： 最终的软件质量 = 需求分析质量 && 设计质量 && 编码质量 && 验证质量 即，最终的质量来自于各阶段质量之“与”，只要其中一个环节质量是差，则产品的整体质量都将是差，千万不要认为是“或”的关系。由此看来每一个阶段的质量都起着决定性的作用。 以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。 完备的需求分析 需求分析的目的是让项目组明白要做什么，是决定所开发出来的软件应当是“长什么样的”，显然完备的需求分析是高质量软件的前提。如果所开发出来的软件与用户所希望的并不一致，那不可能让用户说“这个软件的质量很好” 。如果方向不对，软件开发得再“好”也没有意义。需求分析失误所带来的开发成本是高昂的，这一点在《软件工程》这类书籍中都会提及，因此，整个行业对于需求分析的重要性都具有足够的认识。当然，知道其重要性与如何获得完备的需求分析又是两回事，至于如何做好需求分析请读者参考相关书籍。 需求分析如果出现失误的话有一个特点—— 它一定会暴露！只不过存在是暴露在软件开发过程中还是在用户手中之别。因此，需求分析所造成的问题尽管严重，但它能被发现进而能得到项目组的重视，从而也一定能被修复，只是不同阶段发现这类问题所花费的成本将有所不同。 设计 设计阶段是通过设计方法找出软件实现更好的方法，注意这里是“更好”两个字，而不是强调最好。 不良设计并不会象需求分析失误那样很容易暴露出其本质，相反，它所暴露出的更多是表象，比如逻辑复杂、维护时举步为艰等等。如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质，则很有可能身受其害却不能自拔，还以为“本来就有那么复杂”。 项目的开发是一个逐步演进的过程，项目组成员对于需求的理解也是逐步加深的，一开始合适的设计到后面看来很有可能就不够全面或显得力不从心，如果仍沿用以前的设计则自然将暴露出它的不足，进而会出现需要更高的维护成本。重构思想的提出，就是用于帮助项目演进设计的，当然，在运用重构方法时，应尽可能保证项目有足够的单元测试用例，以预防重构时又引入新的缺陷。重构不只是一个词，其核心应当是一个方法论，一个用于优化设计的方法论。 编程好习惯 设计阶段输出的结果就是蓝图，但好的蓝图并不能保证最后的质量一定就好。拿造房子打个比方，图纸设计得再好，如果建造时用的材料不过关，那最终的房子一定好不了。那软件开发中的“建筑材料”又是什么呢？就是程序员所编写的代码。如何保证其质量呢？这需要通过良好的编程习惯去保证。 在现实的项目中，设计有可能与编码会有一定的揉合，即通过进行一定的编码来辅助设计。这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。 验证 验证很容易让人想到质量保证的常用方法之一，即测试。但验证应当包含更多的内涵，比如求证软件需求是用户所希望的就是其中的一种。 对于验证的理解仍需要拿房屋的建造作为一个比方，以便加深理解。在房屋的建造过程中，当建筑材料到了工地以后，需要对其进行检验，以保证它的质量是合格的，否则不能用于建造。对应于软件开发，这个阶段就是单元测试。当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢？那只能通过单元测试去验证。房子建造好了以后，还得对房子进行整体的验收以确保其最终是合格的。比如抽查墙壁所使用的水泥与沙的配比是合适的。虽然水泥和沙在进入工地时都经过了质检且是合格的，但在建造的过程中需要按一定的比例混合它们以作建筑粘合剂，而混合比例将确定粘合强度。在软件开发过程中，软件集成测试就如同房子在建造好了以后的验收。 从上面的比方能得出几个结论。第一，在软件开发过程中单元测试是必不可少的。它的缺少如同将没有检验过的建筑材料用于建造一样。第二，单元测试应当在集成测试之前完成。有的项目在一开始时并没有单元测试流程，但后来发现需要增加这个环节，于是出现了集成测试完成了以后，再进行单元测试这种情形。这种情形还是有点怪怪的，这如同房子已造好了，再将墙打掉去检查里面的砖是否是好的一样。“将墙打掉检查砖”这种行为的勇气虽然可佳，但是如果尽早地在项目中部署单元测试就能避免这种怪现象的发生。 集成（包括开发集成和系统集成）测试在软件行业被广泛采用以保证软件质量，但单元测试对于软件质量保证的重要性在整个行业还缺乏广泛的、深刻的认识，其更多地被当作是负担而不是一种有效的质量保证手段。
5. 测试人员如何保证软件质量
2. 风险评估：这个能力非常重要，项目的每个阶段都可能存在风险：需求不明确、系统设计或测试设计不完善、代码编写不安全、测试用例不充足、测试人员未完全测试、测试资源不足、回归工作量估计不当、项目进度安排不妥、其他项目对本项目的影响等等，所以项目过程中要具有高度警惕性，尤其要做到开发和测试善始善终。 3. 缺陷预防：个人认为做到很好的缺陷预防是需要综合素质的，如熟练的业务能力，最好能够熟知各产品间的关联，如果能够知道产品实现方法及过程最好不过。能够及时根据当前其他产品发布出现的问题预测对本项目的影响度并做好相关缺陷分析。 4. 沟通能力：往往测试和开发容易处于对立面，不和谐的团队对项目的质量必然带来一定的负面影响，毕竟人的情绪在工作中对工作效率的影响力是非常大的，软件质量是靠开发测试一起保证的，记得在测试技术交流大会中郭芙老大说过开发人员的测试意识不是天生具有的，当遇到开发人员测试观念不足时需要测试人员去指导开发人员，提高开发人员的测试意识。不能把开发人员测试意识不足当作产品质量不好的理由，所以在这个过程中沟通能力是一个很好的体现。 5. 时间管理：会管理时间的人往往离成功更近一步，如何利用时间解决紧急的项目问题、冲突问题、资源安排问题、测试用例的执行的先后顺序等讲究时间效率方法是保证质量的因素之一。
6. 如何提高软件的质量
一、什么是质量？ 作为软件产品的销售人员，市场人员或维护人员经常会受到客户这样那样的指责或抱怨，客户说：你们产品的质量太差，不稳定等等。那么什么是质量呢？我们该如何来衡量质量呢？ 质量具有三个维度： �6�1 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需要做的事情。 �6�1 符合需求。即产品是不是在做让它做的事情。 �6�1 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。 ISO 关于质量的定义表示如下： “ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。 ” 注意，在这个定义中包含明显的需求和隐含的需求。而往往我们会忽略隐含的需求。因此在控制一个产品的质量的过程中必须关注这些隐含的需求，并给予应有的验证。 另一方面因为我们的产品是为客户提供服务的，因此凡是不满足客户需求的，我们都认为是一个失效（ failure ）。所以我们的产品必须始终围绕着客户的需求进行开发和验证。 这里我们谈到客户，其实在一个软件的需求收集过程中需要关注客户和用户。而我们经常会忽略客户与用户之间的区别。那么谁是客户？谁是用户呢？简单的来说，客户是真正能够决定是否购买你软件的人，而用户是实际使用软件的人。了解了这个区别，对于你在分析需求的重要性的时候就可以进行参考。同时在产品质量验证的时候也可以做出不同的权衡。另一方面我们在考虑我们用户需求的时候，往往只考虑了实际使用软件的人员，而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争，这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。 每个人提到质量的时候，经常会遇到下列矛盾，在这些矛盾中隐含着对质量的承诺【 5 】： �6�1 质量需要一个承诺，尤其是高层管理者的承诺。但为了得到质量，高层管理者必须和其雇用的员工进行紧密合作； �6�1 许多人相信没有缺陷的产品和服务是不可能的。但是控制在一定级别的缺陷数是正常并可接受的； �6�1 质量经常是和成本紧密联系在一起，一个高质量的产品同时也意味着高投入。这是设计的质量和一致性质量的一个矛盾； �6�1 一个高的质量要求需求规格说明书足够详细，以便产品可以根据这些规格说明书进行定量的分析。然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书； �6�1 技术人员经常相信规范和标准会束缚他们的创造力，因此就不遵照标准做事。然而如果要得到高质量的产品，就必须遵循良好定义的标准和过程。 二、流程对质量的贡献 好了，既然已经了解了什么是质量，那么怎么才能改进软件产品的质量呢？从一个企业的长远发展来看，首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。 软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提高工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围要求。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。 无论做什么事情，都有一个循序渐进的过程，从计划到策略再到实现。软件流程就是按照这种思维来定义开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。 目前流行的流程方法有很多种，不同的过程模型适合于不同类型的项目。瀑布模型是应用的最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型会是比较适合的，因为你可以按部就班的去处理复杂的问题。在质量要求高于成本和进度要求的时候，该模型表现的尤其突出。 螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险【 8 】。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程【 9 】。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。 RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 RUP 具有两个轴，一个是时间轴，这是动态的。另一个是工作流轴，这是静态的。在时间轴上， RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上， RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。具体可以参考图 1 。 RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。 图1 RUP 工作流程示意图 IPD （ Integrated Proct Development ）流程是由 IBM 提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。 IPD 从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在 IPD 流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点，具体可以参考图 2 。 IPD 流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。 图2 IPD 流程示意图 三、流程与技术 流程和成功不是等价的。没有流程就成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。 对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。 需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 —— 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的错误所导致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想象一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。在《软件需求》一书中关于如何进行需求分析给出了比较详细的介绍【 7 】， RUP 中关于需求的指导也是很实用的。 设计是最能体现一个工程师能力和水平的环节。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在 RUP 中关于系统构架师和设计师的定位是相当高的。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。 UML 是国际上比较流行的一种建模语言【 11 】。在嵌入式方面， SDL 也是一种非常好的选择。《设计模式》是在设计思想方面总结的非常出色的一本书【 6 】，作为一名设计人员（尤其是面向对象设计人员）必须要好好研究一下。但是对这些模式的应用应当讲究一种自然的应用，千万不要因为模式而去设计模式，否则会适得其反。 现在的程序员热中于掌握多种编程语言，或者讲究语言的过分技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试性带来了大的伤害，进而损害了产品的质量。某公司曾对中国程序员和印度程序员做过一个测验，这个测验要求参加者对一组数进行排序。测试结果发现，印度程序员设计的程序使用的算法并不是最优，但却是最不容易出错的，并且几个程序员写出来的代码如出一辙。而几个中国程序员写出的代码，有的非常漂亮，很精练，效率很高；有的却很冗杂，还有错误。如果大家是在做研究性的项目或纯粹兴趣性的项目，那么充分发挥自己的编程天才也无可厚非。然而，对于一个软件公司，产品最终是要交给用户的，需要遵循的是一个软件产品的开发工程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用，还需要和别人的集成，还需要给以后版本重用和维护。 测试的技术将在第五节进行阐述。总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。 四、全面质量管理 自从 Deming 的全面质量管理（ TQM ）原则在日本工业界获得了巨大成功之后，这个原则迅速被传播到了世界各个地方，同样，全面质量管理原则也被应用到了软件开发当中。如前面提到的，软件开发也是一个工程性的工作，因此必须提高整个工程的质量。产业界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明设计活动引入的错误占软件过程中出现所有错误（和最终的缺陷）数量的 50 ％到 65 ％。根据 IBM 的研究表明，假定在分析阶段发现的错误其改正成本为 1 个单位的话，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为 6.5 个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为 15 个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为 60 到 100 个货币单位。同样该比例也适用用于发现一个错误需要的时间。我们可以看下面两条曲线图： 图3 缺陷代价曲线 为了提高产品质量，缩短产品开发进度，节约产品开发成本，必须尽早的进行产品质量控制。全面质量控制要求在过程的每个阶段每个步骤上都要进行严格的验证和确认活动。 什么是验证？ 验证 就是要用数据证明我们是不是在正确的制造产品。注意这里强调的是过程的正确行【 12 】。 什么是确认？ 确认 就是要用数据证明我们是不是制造了正确的产品。注意这里强调的是结果的正确性。 IEEE 给出的验证和确认过程可以用下图来表示。验证和确认是一个广泛的概念，感兴趣的读者可以参考 IEEE Std 1012-1998 。
图4 验证和确认模型 五、关注测试 软件测试是软件质量控制中的关键活动。业界的统计数据表明，测试的成本大约占软件开发总成本的 50 ％左右。 软件测试的目的是要发现软件中的错误。一个好的测试是发现至今没有被发现的错误。传统的软件测试专注于动态测试范畴，如：单元测试，集成测试和系统测试。而测试工程的发展已经进入到了全流程的测试，包括开发过程前期的静态测试。 一般我们可以把测试分为白盒测试和黑盒测试。 白盒测试 ：顾名思义，白盒测试应当是透明的。的确，该类测试是根据程序代码的内部逻辑结构来设计测试用例进行测试。那么什么是测试用例？ 一个 测试用例 就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 黑盒测试 ：看了白盒测试的解释，我想你很快就能猜出黑盒测试是不考虑程序内部结构情况的。事实上也是这样。黑盒测试是根据规格说明书进行的测试。 规格说明书 记录了用户的需求。比如用户希望在编辑器中增加查找功能，那么我们把该需求写入规格说明书，根据该项要求，直接调用应用程序的该项功能进行测试，而不管其内部是用什么算法实现的。 白盒和黑盒这两类测试是从完全不同的出发点，并且是两个完全对立点，反映了事物的两个极端，两种方法各有侧重，不能替代。但是在现代测试理念中，这两种测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。 常见的白盒测试是单元测试。 单元测试 是测试中最小单位的测试。简而言之，就是拿一个函数出来，加上驱动模块，桩模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：条件判断点，循环点，选择分支点等）。 驱动模块 是模拟调用被测函数的函数。 桩函数 是模拟当前测试函数所调用的函数。 常见的黑盒测试包括：集成测试，系统测试。 集成测试 是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 系统测试 的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。系统测试的内容极其广泛，包括功能测试、协议测试、性能测试、压力测试、容量测试等等。有关测试方面的概念可以参考本人已出版的《软件测试技术概论》。 软件测试是产品最终交付到用户之前的最后一道防线，有着举足轻重的地位。然而，做好软件测试却是不容易的，一方面你需要同时掌握软件开发的技能和软件测试方面的技能；另一方面产品必须给予测试充分的独立性和资源保证。 六、成功的铁三角 在一个软件企业中，如果能够良性的发展，必须关注组织，流程和人三者之间的关系。组织是流程成功实施的保障，好的组织结构能够有效的促进流程的实施；流程对于产品的成功有着关键的作用，一个适合于组织特点和产品特点的流程能够极大的提高产品开发的效率和产品质量，反之则会拖延产品开发进度，并且质量也无法得到保证；对企业来说，人是最宝贵的财富，它们是技术的载体。对于一个软件公司来说，无论是开发人员还是测试人员，都非常关心其今后的发展通道，如果有一条清晰的技术发展线为其指明今后的职业发展方向的话，这可以大大激励员工的士气和工作积极性。另外技术发展的方向应该与现在的开发流程和规范相结合，这样有利于专业技能的提高。 总之，组织，流程和人这三者是一个企业成功的铁三角，理想的情况下它们彼此促进，糟糕的情况下它们彼此制约。 七、国际上流行的质量标准 最早进入国内的质量标准是 ISO 系列。在软件方面主要使用 ISO9000 系列标准。 ISO9000 是一个非常完整的标准，并且定义了供应商设计和交付一个有质量产品的能力所需要的所有元素。 ISO9002 涵盖了对供应商控制设计和开发活动所认为重要的质量标准。 ISO9003 用于证明供应商在检视和测试期间检测和控制产品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相关的质量标准，并提供了一个完整的质量查检表。 软件能力成熟度模型是目前国内软件企业中非常受欢迎的一个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框架的指导下： �6�1 软件组织可以对其软件开发、维护过程获得控制。 �6�1 软件组织可以推进其软件工程更为科学、推进软件过程管理更为卓越。 �6�1 CMM 通过确定当前软件过程管理的成熟度，通过标识软件的质量和过程改进中关键的、要害的问题，可以指导软件组织选择正确的软件过程改进策略。 �6�1 CMM 将其焦点，聚焦在一系列具体的软件过程活动上，并以侵略方式（ Aggressively ）达到这些活动。一个软件组织就可以稳定地、持续地改进其整个软件组织过程，使得其软件过程管理能力取得持续地、持久地不断争长提高。 在 CMM 中，把软件工厂分为五个等级：初始级、可重复级、已定义级、管理级和优化级。其中： 初始级 ：软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。 可重复级 ：人们根据多年的经验和教训，总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 已定义级： 要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。 管理级 ：所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。 优化级： 的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。 美国国防部规定，重要性级别高的软件应该由质量级别高的企业承担。不同等级的软件公司提交的软件，其软件质量也相差很大，国外的一份统计资料如下： 表 1 、 CMM 级别与软件质量关系表格 每千行软件的缺陷数目
软件过程成熟度等级
软件准时提交的百分比
每人每月生产的程序行数
软件需要返工的百分比
平均软件失效时间（近似）
大于 10
初始级
<=50
Z
>=45
2 到 60 分钟
小于 10
可重复级
90
1.5Z
20
1-160 小时
小于 1
已定义级
99
2.5Z
10
不确定
小于 0.1
管理级
降低开发时间到 1/2
5 Z
5
不确定
小于 0.01
优化级
降低开发时间到 1/4
10Z
<=2
近似完全可靠
对于很多已经推行或者准备推行 CMM 的公司来说， CMM 的起步是很难的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。 CMM 是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式【 1 】。企业只有开始 CMM 改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训，合理分配项目人员，并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。 PSP 能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过 PSP 学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用 PSP ，从而有助于 CMM 目标的实现。 TSP 结合了 CMM 的管理方法和 PSP 的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用 CMM 的原则和 PSP 的技能去生产高质量的产品。 软件的生产过程及其它的许多子过程、软件的开发者和用户、以及系统的使用中存在着巨大的变化和不同，要使一个软件过程对软件生产的改善真正有所帮助，其框架应是由 CMM 、 TSP 和 PSP 组成的一个完整体系，即从组织、群组和个人三个层次进行良好的软件工程和管理实践的指导和支持。总而言之，单纯实施 CMM ，永远不能真正做到能力成熟度的升级，只有将实施 CMM 与实施 PSP 和 TSP 有机地结合起来，才能发挥最大的效力。 八、如何起步？ 质量改进需要花费成本，因此改进的途径需要视不同公司的规模、业务、财务状况、人员技术水平等多方面综合进行考虑。一般建议中型以上的较大的软件公司实施 CMM 体系。而对于一些小型的软件公司可以采取比较实际的，相对成本较少，且容易操作的方面进行，这些方面大致如下： �6�1 实施简洁的开发过程体系，根据不同业务特点可以选择瀑布模型，迭代模型等，并在这些模型上进行适当的变化以适应于短平快的产品开发特点。 �6�1 提高需求分析和设计方面的技术，例如：原型法技术，分析模式，设计模式，面向对象设计， UML 等； �6�1 加强文档化工作。文档是经验的保留，对于一个企业要想获得长期的发展，必须加强文档化工作； �6�1 加强编程规范工作； �6�1 进行适当的测试工作，建议进行单元测试和系统测试； �6�1 实施配置管理工作，加强版本控制； �6�1 开展走读、评审和检视活动，尤其要加强代码走读，建议进行每日交叉走读活动； �6�1 进行简单的度量分析获得；建议实施 PSP 活动；
7. 谁知道如何提高软件质量
【摘要】 软件质量是软件产品的灵魂。本文全面介绍了质量的概念，提出了从流程、技术、组织管理、人员技能发展等多个角度提高软件质量的重要性；并对目前国际上流行的 CMM 标准进行了介绍，提出了使用 PSP 和 TSP 来实现 CMM 的方法。本文最后还给出了中小型软件公司在提高软件质量方面的一个初步思路。【关键字】 质量管理，软件开发过程模型，软件分析和设计方法，软件测试， CMM 如何提高软件的质量已经不是一个纯粹的技术问题，而是一个工程的问题。自从计算机诞生以来，相应的软件开发就存在了。由于早期的计算机运行性能较低，软件的可编程范围也较狭窄，因此质量问题就没有那么突出。 50 年代后期到 60 年代，高级语言的相继诞生并得到了广泛的应用，随之而来的是软件规模也越来越庞大，越来越复杂。伴随着软件应用的越来越广泛，软件的质量问题就变得越来越突出。根据美国国家宇航局 NASA 的统计，在 80 年代初，软件引起的故障与硬件引起的故障，其比率约为 1.1:1.0 ，到了 80 年代末，这一比率已达到 2.5:1.0 。因此如何提高软件的质量成为软件工程研究的一个重点。自从软件危机产生以来，出现了很多提高产品质量的理论和方法，有的从技术角度出发，例如：面向对象技术的产生和推广，第四代语言的诞生等等；有的从自动化工具入手，例如： CASE 工具、过程控制软件、自动化管理平台等；有的从过程模型角度出发，例如：迭代模型、螺旋模型、 RUP 、 IPD 、净室软件工程等；也有从管理角度出发的，例如：团队管理、绩效管理、 PSP 、 TSP 等；也有从测试角度出发的，例如：加强全流程的测试等；一些相应的规范和标准也孕育而生，例如： ISO9000 系列、 CMM 、 QMS 等。然而每一种技术都不是绝对的，软件质量的提高应该是一个综合的因素，需要从每个方面进行改进，同时还需要兼顾成本和进度。一、什么是质量？ 作为软件产品的销售人员，市场人员或维护人员经常会受到客户这样那样的指责或抱怨，客户说：你们产品的质量太差，不稳定等等。那么什么是质量呢？我们该如何来衡量质量呢？质量具有三个维度：" 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需要做的事情。" 符合需求。即产品是不是在做让它做的事情。" 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。ISO 关于质量的定义表示如下：“ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。 ” 注意，在这个定义中包含明显的需求和隐含的需求。而往往我们会忽略隐含的需求。因此在控制一个产品的质量的过程中必须关注这些隐含的需求，并给予应有的验证。 另一方面因为我们的产品是为客户提供服务的，因此凡是不满足客户需求的，我们都认为是一个失效（ failure ）。所以我们的产品必须始终围绕着客户的需求进行开发和验证。 这里我们谈到客户，其实在一个软件的需求收集过程中需要关注客户和用户。而我们经常会忽略客户与用户之间的区别。那么谁是客户？谁是用户呢？简单的来说， 客户是真正能够决定是否购买你软件的人，而用户是实际使用软件的人。了解了这个区别，对于你在分析需求的重要性的时候就可以进行参考。同时在产品质量验证 的时候也可以做出不同的权衡。另一方面我们在考虑我们用户需求的时候，往往只考虑了实际使用软件的人员，而忽略了其它一些人员对软件的要求或对软件造成的 潜在竞争，这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。 每个人提到质量的时候，经常会遇到下列矛盾，在这些矛盾中隐含着对质量的承诺【 5 】：" 质量需要一个承诺，尤其是高层管理者的承诺。但为了得到质量，高层管理者必须和其雇用的员工进行紧密合作；" 许多人相信没有缺陷的产品和服务是不可能的。但是控制在一定级别的缺陷数是正常并可接受的；" 质量经常是和成本紧密联系在一起，一个高质量的产品同时也意味着高投入。这是设计的质量和一致性质量的一个矛盾；" 一个高的质量要求需求规格说明书足够详细，以便产品可以根据这些规格说明书进行定量的分析。然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书；" 技术人员经常相信规范和标准会束缚他们的创造力，因此就不遵照标准做事。然而如果要得到高质量的产品，就必须遵循良好定义的标准和过程。二、流程对质量的贡献 好了，既然已经了解了什么是质量，那么怎么才能改进软件产品的质量呢？从一个企业的长远发展来看，首先应当从流程抓起，规范软件产品的开发过程。这是一个 软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。 软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效且能够比较稳定地保证 产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提高工作效率。 并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围要求。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发 中，这就形成了软件工程过程，简单的说就是开发流程。 无论做什么事情，都有一个循序渐进的过程，从计划到策略再到实现。软件流程就是按照这种思维来定义开发过程，它根据不同的产品特点和以往的成功经验，定义 了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此， 按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。 目前流行的流程方法有很多种，不同的过程模型适合于不同类型的项目。瀑布模型是应用的最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是 显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型会是比较适合的，因为你可以按部就 班的去处理复杂的问题。在质量要求高于成本和进度要求的时候，该模型表现的尤其突出。螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险【 8 】。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。RUP （ Rational Unified Process ）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程【 9 】。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。 RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 RUP 具有两个轴，一个是时间轴，这是动态的。另一个是工作流轴，这是静态的。在时间轴上， RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上， RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。具体可以参考图 1 。 RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。图1 RUP 工作流程示意图IPD （ Integrated Proct Development ）流程是由 IBM 提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。 IPD 从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是 一个端到端的流程。在 IPD 流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评 审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点，具体可以参考图 2 。 IPD 流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过 流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对 于一些小的项目，也不是非常适合使用该流程。图2 IPD 流程示意图三、流程与技术 流程和成功不是等价的。没有流程就成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。 对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家 觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的 确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 —— 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的错误所导致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想象一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。在《软件需求》一书中关于如何进行需求分析给出了比较详细的介绍【 7 】， RUP 中关于需求的指导也是很实用的。 设计是最能体现一个工程师能力和水平的环节。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在 RUP 中关于系统构架师和设计师的定位是相当高的。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。 UML 是国际上比较流行的一种建模语言【 11 】。在嵌入式方面， SDL 也是一种非常好的选择。《设计模式》是在设计思想方面总结的非常出色的一本书【 6 】，作为一名设计人员（尤其是面向对象设计人员）必须要好好研究一下。但是对这些模式的应用应当讲究一种自然的应用，千万不要因为模式而去设计模式，否则会适得其反。 现在的程序员热中于掌握多种编程语言，或者讲究语言的过分技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试 性带来了大的伤害，进而损害了产品的质量。某公司曾对中国程序员和印度程序员做过一个测验，这个测验要求参加者对一组数进行排序。测试结果发现，印度程序 员设计的程序使用的算法并不是最优，但却是最不容易出错的，并且几个程序员写出来的代码如出一辙。而几个中国程序员写出的代码，有的非常漂亮，很精练，效 率很高；有的却很冗杂，还有错误。如果大家是在做研究性的项目或纯粹兴趣性的项目，那么充分发挥自己的编程天才也无可厚非。然而，对于一个软件公司，产品 最终是要交给用户的，需要遵循的是一个软件产品的开发工程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用，还需要和别人的集成， 还需要给以后版本重用和维护。 测试的技术将在第五节进行阐述。总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。
8. 如何保证软件开发的质量
CMM不是仅适合于外包公司。不同外包公司的情况还不一样呢。确证的说：是好多外包公司不得不拿CMM来做项目招标的招牌。个人认为：CMM或者说CMMI的选择，与企业的组织结构有很大关系。CMM/CMMI与是否外包没有必然联系。如果引入实施适当的话，CMM/CMMI对于自主研发企业，比外包企业有更大的益处。
9. 如何保证软件测试质量
我认为高质量的软件产品是一个软件团队所有成员都负责任的完成自己任务以后的必然产物。
首先说说团队，这其中涉及的需求人员、设计人员、开发人员、测试人员都应该真切的视自己为团队的必不可少的力量，都应该为了项目或产品的成功竭尽所能的去工作，只有团队真正的拧成一股绳的时候才具备了产出高质量软件的基本条件。这是我要说的第一点：团队认同感、归属感。
高质量的需求调研文档是软件成功必不可少的条件，但是不同的人对同一句话的理解往往会有差异，因为立场不同。所以想要保证需求的质量，需求人员必须把自己置身到用户的立场去感受、去调研、去理解目标用户反馈的信息。对于不确认的信息要想尽办法搞清楚。所以需求调研人员最好是行业专家。需求文档整理出来后，必须经过客户方代表和公司设计、开发、测试的共同评审才能最终定稿，并最终进入软件设计流程。这是我要说的第二点：软件需求必须用“心”去做，并且监督评审必须到位。
接下来就进入了软件的生产流程，在设计阶段，设计人员是主角，开发人员、测试人员、需求人员要可以及时获得设计文档。设计人员必须在实现需求的情况下，站在用户的立场上去设计功能，实现最好的用户体验。在设计评审时，开发、测试、需求要从用户的角度去评判设计，根据需求从用户的角度去评审设计，这真的很重要。问题如果能在设计阶段就发掘出来会极大的减少资源的浪费，缩短产品或项目周期。这是我要说的第三点：设计要注重用户体验，同时监督评审也必须到位。
软件进入开发测试流程后，实际的开发人员应该站在用户的角度上去开发每一个功能，如果有比设计更好的实现方法，应及时和设计、测试、需求人员沟通，共同确认是否更改设计。每一个功能完成后，必须进行完整的自测，然后及时送测给测试人员，测试人员也要在用户的角度进行测试，发现问题或建议及时反馈、沟通和处理。还有很重要的一点，测试必须要有测试用例。测试开始前，测使用例必须经过评审，当然评审粒度根据公司资源确定。这是我要说的第四点：开发是软件的制造者，测试是软件质量的保证者，两者相辅相成，荣辱与共。
高质量的软件是一个软件团队共同努力的结果，任意一个环节出问题都可能造成团队的灾难。团队领导者必须要想办法、尽全力将自己的团队凝结在一起，使大家具有团队荣誉感和使命感。软件生命周期的各个阶段都有工作重点，团队领导必须把握好。团队领导不能轻视任何一个环节的工作，否则高质量的软件只能是一句空话。古人说“三人行，必有我师焉”。任何一个团队，所有人的力量都发挥出来肯定比所谓几个精英累死累活搞出来的结果要好。人们说的“兵熊熊一个，将熊熊一窝”也是说团队领导的重要性。
呵呵，总结完了。最后再说一下自己的看法：高质量的软件是软件团队共同努力的结果，用户体验是软件质量很重要的方面，软件的需求、设计、开发和测试都应该是从用户的角度出发去工作。
10. 面试时，HR问我如何保证自己所写软件的质量
1局部代码的逻辑严密，最起码实现一个东西不能在逻辑上出问题。。
2局部代码的健壮，能实现功能只是第一步，但要考虑各种运行时异常；比如用到的参数是整形，参数是外部输入的，方法内在转型前需要捕获异常，如果不能保证拿到的参数就一定整形，必须做健壮性优化，这只是其中之一。。。。
3整体代码的健壮性， 你参与的是公司的产品，你修改或新加一个功能，要确保你做的东西不会对系统原有的模块产生负面影响，或者要确保如果与之前某功能逻辑上类似，则需要保证方法的逻辑统一。比如你做的新功能是向A表里插数据。先前系统里有几个口子可以往A表里插，你就要看插入A时有没有默认插入的参数，这张A表是不是还和B表有关联，是不是原先其他程序插入A表时会默认带一条B表记录等等。总之你是在别人的系统上集成，肯定不可能以你开发为主
4 如果涉及到与数据库连接（这个最重要），一定要在finally里写连接池关闭，否则连接池一旦泄露，服务就会死，这个问题可以说比数据不对还要严重