软件企业如何“捉虫”？

软件缺陷（也称Bug，俗称臭虫）是长期困扰软件企业的一个问题，为了尽量减少“臭虫”的侵袭，软件企业也是煞费苦心。近来，美国的一些软件公司开始采用应用软件生命周期管理，试图消除软件错误，以减少因此带来的损失。

下述糟糕的经历屡见不鲜：

● 4月，一个软件故障导致美国航空集团公司损失数千美元，因为有些机票的价格被误定为1.86美元；

● 在最近的一次美国总统选举中，使用新型计算机化投票系统的几个选区传出计票不正确的说法；

● 2003年8月导致北美东北部大规模停电事故的罪魁祸首也是一个软件错误，数百万人因此而陷入一片黑暗当中。

类似的事例还有很多。目前看来，软件问题似乎正变得越来越糟。美国技术标准研究所经常引用的一个数字表明，2002年存在缺陷的软件让美国经济亏损600亿美元。如今这个数额更高，这点没有人怀疑。

低劣的软件几乎困扰着每一个使用计算机的组织：导致计算机停用期间工作时间减少、错失销售机会、IT支持和维护成本居高不下、客户满意度低下。人们沮丧之余开始认真分析错误是如何进入应用软件开发流程的，为什么预防错误似乎那么困难。

关注软件应用生命周期

大量的调查研究表明：低劣的软件质量不是由于某个具体的失误所致，而是由于参与规划、开发、测试及维护每个应用软件的IT专家彼此缺少沟通和联系。

从事软件研究的人士说，问题在于没有对软件的整个生命周期进行管理，也没有认识到：提高软件质量的任何工作都必须涵盖应用软件生命周期的每个阶段，从初期规划、部署到维护。

美国伯克希尔人寿保险公司是设在纽约的美国嘉定人寿保险公司的子公司，它一直在想方设法探究在应用软件生命周期的各个阶段提高质量。

Sorin Fiscu是伯克希尔人寿保险公司的项目经理，他解释道：“这是我们在过去的一年里，分析了自己的开发流程、需求的征集方法以及监控系统的方式后总结出来的经验。”

Fiscu对开发团队做了一些调整，譬如请质量保证（QA）人员参与早期规划、征求业务分析员的意见、提高测试阶段的自动化。这些变化让这家公司能够达到或超出软件部署后的两个目标: 保证应用软件的可用性和用户对应用软件的整体满意度。

在伯克希尔人寿保险公司，应用软件开发最初的一个步骤就是，把业务人员和IT人员召集起来，就应用软件的功能规格达成一致，列出业务人员需要的从屏幕流程到数据字段名称的每项特性和功能。

Fiscu说:“在整个过程中，人们非常详细地描述了应用软件以及它在将来如何使用。这个过程中的关键在于事先让每个人进行交流，测试员、分析员和开发员都需要尽量充分地交流，而软件应用生命周期管理有助于实现这一过程。”

应用软件生命周期管理（ALM）的基本目的相当简单，包括: 确保负责每个阶段的队伍进行了充分沟通; 防止错误进入以后的阶段，因为在开发流程的后期阶段解决错误其成本要明显高于开始阶段。

Gartner的分析师Theresa Lanowitz坚称: “实行生命周期管理很必要，但大多数组织（近90%左右）并不知道如何有效地管理生命周期。如果生命周期真正被合适的人员、流程和技术所运用，我们就会看到质量较高的软件、效率较高的IT组织。实际上，大多数IT组织浪费了相当多的预算，就因为它们的商业实践没有满足需求，也没有管理项目以达到进度、成本和质量方面的目标。”

质量控制始于需求定义

开发人员、测试人员和业务人员之间建立清晰的沟通渠道对生命周期管理的成功至关重要。因此，需要在规划阶段把这一步作为流程的一部分。

斯特普尔斯公司（Staples Inc.）强调的重点就是，参与应用软件开发、测试和使用的每个人都要加强协作。Kathy Murray是这家总部设在马萨诸塞州弗雷明汉的办公用品零售公司负责质量管理的高级经理。她说：“我们与业务合作伙伴一起开会，讨论业务需求，QA人员也到场，这样他们也能明白需求。我们在需求定义阶段投入的时间越多，以后阶段的状况就越好。有调查表明，60%到70%的错误是在需求定义阶段引入的，我们的实践证明也的确如此。”

Arthur Povlot是提供质量保证服务的Tescom软件系统测试公司派驻亚特兰大的企业发展经理，他说，不正确的需求是造成大多软件质量问题的根源，“很少有公司在需求定义阶段严把‘质量关’。事实上，你应当让参与各方：业务分析员、营销经理和专题专家审查需求，并得到他们的认可。”

编程人员往往喜欢按自己的方式行事。虽然利用一套规矩捆住开发人员的手脚可能达不到目的，但针对一致性和质量控制实施一些流程和程序却是个好办法。

Fiscu强烈建议: 开发人员把自己编写的代码（连同错误）交给质量控制人员进行测试之前，先要对代码进行特定的测试。他说：“我们的开发队伍会收到一组单元测试脚本，就像是一份高级检查表。惟有核对完毕后，开发才算完成。这样，我们可以确保不会把缺陷从开发阶段带入到测试环境。”

开发当中导致软件错误的另一个常见问题就是，难以跟踪软件变更和版本。配置管理和变更管理策略及工具有助于为编写及测试代码执行标准流程。

譬如说，设在克里夫兰的美国贺卡公司就依靠冠群公司（CA）的AllFusion变更管理器，跟踪代码在整个开发过程中的变更情况，并且执行公司的开发标准。

美国贺卡公司的软件经理Tom Brown说：“比如，谁也不能决定使用不同的编译器，或者略过测试，因为这完全被融入流程当中。管理生命周期意味着，对我们使用的流程和编译器的类型而言，需要确保源代码内容最新、保持一致。”

测试、测试、再测试

虽然开发人员自己应当进行一些早期测试，但成熟的测试流程和部门对查找及解决错误至关重要。开发人员编完代码后，应当对代码进行全面的检查，包括功能测试（评估程序的流程和功能正确与否）、集成测试、性能测试、安全测试以及对程序更新和变更进行的回归测试（Regression Testing）。

芝加哥交易所平时对应用软件进行许多人工和自动测试，包括开发人员进行的单元测试、使用Compuware公司的QACenter进行的性能测试、用户验收测试，以及由将来使用该软件的交易人和经纪人进行的功能测试。芝加哥交易所在进行测试时还关注将来的发展以及更繁重的流量。

芝加哥交易所质量保证主管David Burkhart说: “我们应积极主动，而不是消极应对，我们针对系统将来可能遇到的负荷进行测试。”

由于时间、技术和人员能力所限，连最敏感的关键任务系统经测试后也不能保证100%的正确性。于是问题出来了：要进行多少测试？需要测试多长时间？Povlot建议为应用软件最重要的需求全部建立测试用例（test case）。测试用例具体列出了测试特定的一项特性所需的用户意见和预期响应。他说，总的来讲，你至少应当对全部需求的90%进行测试。

自动化工具有助于加快测试规划和执行，尤其是回归测试。“我们把测试周期所需的工时缩减了50%，从而把测试对象扩大了300%。”Murray说，他把这种改进归功于斯特普尔斯公司使用Segue软件公司的SilkTest和Star Quality公司的StarTest。

伯克希尔人寿保险公司使用Empirix公司的e-Test Suite来管理测试流程，并加快回归测试。Fiscu说：“我们所做的改进越多，测试的回归阶段用时就越长。现在，自动化工具节省了资源，还确保了一致性。”

将软件开发过程变成闭环

一旦应用软件部署完毕，就要加以监控及维护。软件更新后，很快就会开始新一轮的应用软件生命周期，所以实际使用期间收集的信息必须反馈到下一个版本的需求规划当中。

这正是密歇根州米德兰的陶氏化学公司所采用的策略。陶氏公司的IT人员使用Mercury Interactive公司的LoadRunner，对新的应用软件运行各种测试脚本。部署后，这些脚本有许多还要再次运行，不过为了比较结果，这回用的是Mercury公司的监控软件包之一：Topaz或者SiteScope。如果发现应用软件存在问题，陶氏公司的操作人员就会进行事故分析流程，以查明原因。

陶氏化学公司信息系统部门的首席架构专家Rich Guidotti说: “随后，我们把这些信息反馈给开发队伍，或者是基础设施或服务队伍，以便进行适当的变更。”

芝加哥交易所也使用Compuware监控软件来发现问题。Burkhart说：“在应用软件投入实际使用后，我们还会进行跟踪。要是投入实际使用后出现问题，我们会开会讨论，获得的反馈信息会直接转给质量控制人员。”

众多IT厂商提供软件应用生命周期的一个或多个阶段的工具。几家厂商正开始组合面向生命周期全面管理系统的套件。IBM的Rational部门就提供全面的产品线，从用于收集需求的RequisitePro、建模工具和测试工具，到IBM的Tivoli软件中的部署后进行监控及维护工具，应有尽有。Borland也有类似的比较全面的工具。

同样，Mercury、Compuware、冠群和Segue软件公司都声称或者计划扩大产品范围，覆盖应用生命周期的各个重要阶段。

虽然综合平台是很理想，但更普遍的情况是，一家组织必须从不同厂商选择不同产品，以便对生命周期的某部分实现自动化，譬如需求管理、自动化功能测试和部署后监控。有些厂商还提供与互补产品间的接口。但许多厂商不提供，或者至少不是为客户拥有的每个互补产品都提供接口。

不过对生命周期管理而言，流程与用来支持生命周期管理的自动化技术工具同样重要。所以，专家们说，无论是不是综合平台，ALM的目的就是尽量减少错误和疏忽，提高产品质量。或者，正如芝加哥交易所的Burkhart所言，这是个吸取以往经验、不让过去的错误在应用软件的新周期中重演的问题。他说：“我的基本目标之一就是绝不让错误重演。谁都会犯错误，要是大家不犯错，我们也就用不着测试什么了。不过我们竭力落实质量流程，就是为了防止我们再犯错误。”（沈建苗译自《Computerworld》）

链接

软件开发方法之ABC

软件开发界有几种广为人知的方法。一种常用方法就是IBM Rational公司的Rational统一过程，即RUP。这个框架包括了最佳实践和技术工具，并且明确了应用软件开发的四个阶段：起始阶段、细化阶段、构造阶段和移交阶段。RUP的扩展方案—企业统一流程（Enterprise Unified Process）由Ronin国际公司的Scott Ambler创建，他在RUP的基础上增加了两个阶段：生产阶段和停用阶段。

另一个标准是软件工程协会（SEI）的能力成熟度模型集成（CMMI），这是SEI早期的能力成熟度模型（CMM）的升级版。CMMI认为，周期性反馈和改进这个概念是品质一流的IT组织的一个特点。CMMI定义了软件流程成熟度的五个级别：从第一级（初始阶段，特点是采用临时方法，结果不可预测）到第五级（优化阶段，组织对流程不断改进，改进效果可以衡量）。另一种知名的方法是极限编程即XP，它也强调迭代开发、不断测试及合作开发。

设在佛罗里达州杰克逊维尔的Ajilon LLC的顾问Joshua Barnes说，迭代开发是一个关键问题。 它不像“瀑布法”，项目顺序地从一个阶段进入到下一个阶段，而迭代开发是让项目的每次递进都要经历一个循环周期，以便不断获得反馈和纠正。Barnes说: “在我看来，使用瀑布法根本没有帮助。但迭代方法是一种文化上的变化，人们要采用它往往难度很大。”

来源：CCW