软件质量保证需要系统性的方法论

软件质量保证是一个非常复杂的系统工程，高质量的软件获得不可能通过只做好软件开发活动中的某一个或某几个环节而获得，当然更不可能在没有任何方法的情形下“意外地”获得高质量，除非软件的规模非常小，且所有的开发工作是由一、二个人完成的。

 

方法论 = 流程 + 工具

 

经验告诉我们，对于复杂的问题应当通过分而治之的方式去解决，这同样适用于质量保证这一复杂的系统工程。这里的方法论是指什么呢？是指为了保证软件质量，一个个整合在一起的极具可操作性的小流程，且每一个小流程都有助于达到质量保证方面的某一个目的。当然，流程离不开工具的支撑，且工具将显著提高流程的可操作性。

 

方法论可有大小之别，应当视软件的规模和人员的多少进行“量体裁衣”。方法论不在于形式，而在于其能解决软件质量保证领域中的特定问题。下面让我们看一看，一个软件质量保证方法论应当涵盖哪些方面，图 1示例了软件开发活动中的关键活动。该图的作用不在于精确完整地定义整个软件开发活动中的所有活动，而在于重点强调与软件“生产”相关的内容。对于一个软件项目，图中的流程并不是只执行一次性的，而是存在多次。在软件行业，一次流程的执行就被称之为一个迭代，一个软件的开发可以分为多个迭代去完成。而一个迭代将完成整个软件开发中的部分工作。

图1

 

软件开发活动最为原始的起点是用户的需要，需要经过了市场部门的识别后就变成了商业机会，这对应于图中的“business opportunity identify”活动。一旦市场部决定了需要抓住某一商业机会，则需要由相关部门共同制定开发计划，以开发出所需的产品满足用户需要。

 

接着系统工程（system engineering）部门根据用户的需要捕获需求。如何正确地捕获用户需求超出了本文的范畴。但是，当需求被捕获了以后，如何对需求进行管理就是方法论的范畴了。需求的管理是直接采用一个Word文档呢？还是采用专业的需求管理工具？比如，来自IBM的DOORS就是业内很有名的需求管理工具。需求管理不能简单地理解为在哪个地方存方需求描述这么简单，而是还得考虑开发团队和测试团队如何跟踪需求。通常需求是分层次的，比如按层次的高低可以分为系统层、子系统层、设备层和测试层，且各层次的需求是由不同的团队负责的。显然，每一个层次之间的需求是有关联的，低层次的需求来源于高层次，但将高层次的需求进行了细化。如何反映各层次之间的依赖关系就是需求管理很重要的内容。在需求管理方面，DOORS被大公司广泛采用。DOORS是采用语句描述的方式来阐述用户需求的，在UML被广泛采用的时代，如何将UML运用到需求管理中去也很有学问。在作者目前所服务的公司中，就是采用DOORS和Tau（来自IBM的UML工具）共同管理需求的。

 

有了需求以后下一步就是设计（design）工作了。设计阶段最需要注意的是时间压力。设计不同于编码，是一个很抽象的创造性思维过程。其实，一旦设计做好了以后，编码和测试工作都相对省时。就作者的体会，开发最花费时间的部分就是设计阶段，设计阶段的时间如果不足，则容易造成编码和测试将耗费更多的时间，因为在设计阶段没有思考清楚而更易造成概念不清晰。当然，并不是说设计投入了更多的时间则设计质量就一定会更好，其中很重要的一个前提条件是项目组中是否存在具备高水平设计能力的人。如果没有这样的人，可能在设计阶段给再多的时间也于事无补。设计工作中，最重要的一个辅助工具是UML工具，当然，还有用于帮助思考所编写的原型代码。UML虽然因为其过于复杂受到部分人士的批评，但它却被很多行业广泛采用（不只运用于软件行业），它的衍生建模语言如SysUML、BPMN等也正蓬勃发展。UML随着版本的不断演进，其表达能力也越来越强。功能强大的UML工具更多地来自商业公司，强大是指工具能很好的遵循UML规范。比如Visual Paradigm的UML工具就很不错，不论是可使用性、还是对规范的遵循都很突出。除了Visual Paradigm的UML工具，来自IBM的Rational Software Modler也是不错的选择。除了商业软件，开源的StarUML也被很多人采用，由于它不能很紧密地跟随规范的发展，所以在使用时有时会觉得它的表达能力存在局限。

 

设计质量需要通过设计审查（design review）这一流程去保证。设计审查不同于代码审查（code review，后面将会谈到），设计审查的重点应在于把握概念，且相对抽象。而代码审查则侧重于检查编码质量，比如数据结构的合理性和更为精细的业务逻辑，以及运用项目积累的经验去检查编码中是否采用了积累的最佳实践或违背了所吸取的教训。在设计审查时，如果设计者不能通过讲解设计概念让与会者了解其设计意图，那很有可能表明设计质量并不高。在设计审查会上，重点不在于检查数据结构，而在于检查设计概念。如果设计概念清楚了，数据结构如何组织是顺其自然的事。在项目组中要真正做好设计审查，其重点在于项目组存在设计能力很好的工程师。如果不存在这样的人，则设计审查的效果将显著地下降。但无论如何成立一个设计审查小组是很有意义的，它可以成为大家讨论设计和共同进步的一个平台。设计离不开编写一定的设计文档，设计文档采用Word的形式也就足够了，当然如果能适当地运用UML进行设计表达就更好了。另外，设计文档应当随着工作的进展而不断地被修订，在文档中增加修订历史记录显得很有必要。一方面能让文档的读者知道文档中的各部分是由谁修订的，当需要求助时也有人可找；另一方面，修订历史的存在也显得我们做事更加的专业。

 

在接下来的编码（code）活动有很多方面需要考虑方法问题。第一个需要考虑的是源代码如何管理，在软件行业这被称之为软件配置管理（software configuration management）。源代码版本控制工具应当是开发团队不可或缺的工具之一，没有有效的源代码管理工具，想要做到多人同时进行有效的编码活动是不可思义的。源代码版本管理工具可选择的范围较多，不论是商业软件还是开源软件。作者认为在大多数的软件项目中，使用开源的版本管理工具足以应付日常的开发工作，象Subversion、Git和CVS都可以用作项目源代码版本管理工具。版本管理除了选择工具之外，更需要在项目内制定好代码版本的命名规则，可以说代码版本的命名规则也牵涉到了最终对外发行软件的版本问题。一个好的版本命名规则即能让开发工作更加有序，也能让外部人士看出项目的开发工作是否专业。对外发行的软件版本如果没有很专业的命名规则，很难让别人相信开发工作是有序的。

 

除了源代码版本管理和版本命名规则，在编码活动中另一个很重要的内容是如何管理开发活动中所发现的和用户现场所发现的缺陷。作者看到过一些小软件公司，每当出现一个缺陷时，就将全部的三、四个开发人员叫到一块去分析问题的根源。这中方式在工作中给人感觉可能是“其乐融融”，但是很低效。每一个开发人员，其工作思路及所从事工作的优先级都会有所不同。一出现问题就将大家叫到一块往往打破了其现有的工作思路。好一点的做法是，项目组需要配置缺陷跟踪（defect track）工具来管理出现的缺陷，比如开源的Bugzilla就被广为采用。有了缺陷管理工具以后，每当发现一个缺陷，就在缺陷管理工具内提交一条缺陷记录，提交人在记录中详细地描述缺陷是在哪一个软件版本中发现的、什么样的具体操作将导致这一缺陷的出现以及缺陷的严重性和紧急程度。当缺陷一提交时，所有的开发人员都将收到一封邮件（这是缺陷管理工具的最基本的功能之一），开发人员可以先阅读邮件以了解问题，并根据自已的工作状况、缺陷的严重性和紧急程度来按排自己的工作。或者有的开发人员读完邮件以后清楚地知道，与自己所负责的软件模块无关就可以忽略邮件并继续自己手头的工作。从缺陷管理看来，版本管理是其先决条件，一个连版本管理都没有的项目其缺陷管理也将陷入困境。试想想，当一个缺陷出来了以后，如何知道它是否被修复过以及在哪一个版本被修复过了呢？版本管理与缺陷管理在局部上很好地体现了软件质量保证的系统性。

 

编码的质量又如何保证呢？第一，开发人员需要有良好的编程习惯，这一点与个人的职业修养有关。要让开发人员养成良好的编程习惯，除了需要开发人员自我培养，开发团队也应当努力创造这种氛围。就这一点，项目组中的管理者和技术能力强的人将起非常重要的作用。如果一个团队中的管理者和技术能力强的人有这方面的意识，那团队就更容易形成编程好习惯；反之，要形成这种好习惯就很有可能不可能。第二，单元测试（unit test）是很重要的编码质量保证方法。对于这一点的理解，作者认为在业内还不是很深刻，或者说具有深刻体会的面并不广。第三，即使有了单元测试，还需要通过代码覆盖统计工具以保证单元测试的效果。通过代码覆盖报告，我们可以知道一个模块的单元测试效果如何，是否存在重要的逻辑没有测试到的情形，进而提供决策信息以确定是否需要增加更多的单元测试用例。第三，通过运用代码静态分析（static analysis）和程序动态分析（dynamic analysis）工具，也同样有助于保证编码质量。第四，需要有代码性能分析工具，以分析所编写的代码的执行效率。虽然编码质量的保证方法和工具在图1中被放在编码和代码审查之间，但这些工具的运用应当涵盖在编码阶段，或者说工程师在编码时应当使用这些工具去保证其所编写代码的质量。

 

尽管在编码阶段有编程好习惯和各种工具的“保驾护航”，但是代码审查流程还是不能被跳过。每一个项目都有其特点，因此造成软件的架构、设计时应注意的具体事项等内容都不同，且这些不同不能被前面提到的编码质量保证工具所覆盖，因此必须通过代码审查的方式去发现潜在的问题。代码审查会议更多的是使用项目已沉淀的经验，看看代码是否遵守或违背了成功经验。值得一提的是，代码审查工作应当在使用了编码质量保证工具之后再进行，这样能显著地提高代码审查的效率。因为工具能发现的错误，并不应是代码审查所需关注的。

 

软件一旦进入了验证阶段，那就存在一个如何管理测试用例的问题。验证阶段需要注意的是，不只是验证软件行为是否是正常的，而应当验证软件的行为是否符合需求。测试用例的设计也应当是源于需求的，一个正常但却不是用户所希望的功能，也是验证阶段需要将其“揪”出来的。验证阶段不可避免地需要使用到缺陷跟踪工具，一旦发现一个缺陷就应当通过缺陷工具对其进行跟踪。对于每一个软件版本，都需要通过测试对其功能进行验证，如何方便地做回归测试，也存在方法问题，比如，将回归测试做成自动化。图中的验证包括三方面的，分别是开发集成测试、组件集成测试和系统集成测试。

 

经过了验证的软件就可以发布（release）了，软件发布与版本管理应是紧密相关的。发布后的软件就可以部署（deploy）到用户现场，当然不可避免地会发现软件缺陷，这同样需要用到缺陷跟踪工具进行缺陷跟踪。

 

最后，作者想谈一谈质量保证方法论中的一个容易被忽视的关键因素 —— 时机。比如，如果部署单元测试是在项目开发末期，那很有可能让开发团队更多地感到它是负担和“对质量无益”。在开发末期部署单元测试，很有可能因为项目的模块性不好，而造成部署单元测试时需要大量的工作，甚至不可行。一个应当在早期部署的流程或工具，如果被推迟到后期，也将象需求分析错误被遗留到软件开发后期那样，将产生具大的、额外的成本开销。理论上，所有的流程和工具都应当在开发工作启动时就被部署，不适时机所引入的流程和工具，很有可能最终让团队误认为“它们只是负担”和“并没有效果”。