谈软件开发中的质量问题在软件开发过程中，软件质量是软件工程中一个经常被忽略的要素。
在现代的RAD领域和视频开发领域，软件质量几乎是被人忽略的。
标准组织不厌其烦地对软件质量作出规范，有些甚至提供了用来度量软件质量的工具、评价等级及证明。
许多政府要求软件承包商遵守一定的公共标准。
但对于大多数人来说，软件质量是由用户喜欢使用软件的程度决定的。
如果软件运行得好，则视其质量好，反之，则不好。
这给人们对软件质量的评价标准方式造成错觉。
越来越多的公司在购买软件时有了这样一个概念，即软件质量是一个过程，从软件应用开始，直到停止使用为止。
许多组织都确认自己在软件质量方面投入了大量资金，但同时又承认在许多关键任务的应用中，许多软件质量标准是强制执行的结果，而非通过严格控制成本的战术或战略来实现。
软件质量工程耗资不低，而且也不易实现，但如果实施的早，达到高水平就相对要容易些。
质量从分析和设计开始，贯穿整个构造过程，并在测试和开发过程中不断完善。
在使用应用软件的维护阶段，质量不易完善。
度量软件质量并不是件容易的事。
我曾经做过调查，问一些开发人员在他们的应用软件出台之前进行多少次合理的编码检查？回答是28％。
没有检查编码的原因是由于计划完成的期限太短，时间和资源不充足。
组织不能简单地为全职的软件测试者提供时间和资金。
由于这些客观原因，我们需要找到提高质量的方法。
在这里我们不但强调软件质量的重要性，也想找出度量软件质量的方法，以及确定我们要达到怎样的质量水平和借助何种工具才能及时正确地完成任务。
什么是软件质量所谓软件质量就是对应用软件的质量进行三个主要方面的度量：编码、功能、性能。
没有充分的分析和设计就不可能达到较高的软件质量。
过于简单，难以满足功能或性能上的需求，也就谈不到编写出好的软件。
一个不符合用户需求的软件就是失败。
要说清楚正确的发现和设计路径需要许多笔墨，并不是区区一篇文章就能够完成的，但有些公司如Rational 及Riverton等公司花费了大量的时间和金钱创建了能够帮助提高分析设计阶段质量的产品。
我向大家强力推荐Riverton公司的HOW系列产品，它运载于PowerBuilder上，是免费的。
提高了第一阶段的质量也就等于提高了整个应用软件的质量。
本文更侧重软件质量的物理方面，让我们从编码开始谈起。
编码质量编码质量是应用软件的健康诊断。
你可以想象编码就是应用软件的肺。
无论看起来多小的缺陷都会影响整体健康，可能引起呼吸（运行）的中断。
我们学习怎样更好地做事，但我们学到的往往是经验。
经验的不利之处在于只有在我们经历过之后它才成为经验。
而对目前应用的软件来说已太迟，没有什么帮助，只能寄希望于下一次的软件。
更有利的办法是与其他软件开发者共同学习，分享经验。
SEI的研究表明，经过软件质量培训的开发人员编写的软件错误更少，能减少50％以上。
研究还表明稍稍经过培训，便会加速经验的获得。
培训是一个解决办法，对已完成工作进行度量是另一个方法。
我们可以建立几个可度量的编码质量的目录：遵守工业及企业标准，遵守编码规则和结构标准，可提高其可用性及可维护性、最佳实际应用。
企业标准依据其背景而变化。
微软的商品遵循微软标准，Unix商品遵循Unix标准。
直到PowerBuilder 基础等级（PFC）的数据库出现，PowerBuilder的开发人员才获得了对买方标准的一些提示。
现在许多公司遵循PFC命名约定，因为它最接近于工业标准体系结构。
这就是说，甚至连Sybase都不遵循自己的标准，而是遵守PFC标准。
PFC的版本6集成了一些它自己对外公布命名规范的结构标准。
关键的一点是如果什么也不做就谁也帮不了你。
学习的关键是经验。
如果你不知道自己已拥有经验，你就无法从中获益。
你知道的越早就越有效。
你可以通过实施一些标准加速此过程。
这完成了两个目标：要实施标准，必须先度量。
如果你度量应用标准及质量，开发人员就会对所度量的要素及他们出的错误更清楚，加强了目标的认识。
纠正发现的问题并找到错误原因，可以再次提醒开发人员要达到的目标，并指出达到的方法。
一旦进行度量，应用软件中不通顺的地方立刻被纠正。
可以达到两个目的：最终的编码十分整洁，具有高质量；开发人员完成这一步就会得到最重要的益处——经验。
功能性质量功能性质量是度量应用软件与其用户需求的匹配程度，即完成必要性功能的好坏，以及是否完成了所有必要的功能。
你可以想象这是应用软件的大脑。
如果所有必需的功能并没有全部完成，那么其结果难以预测。
由于许多应用已事先规定应该怎样，所以功能性质量比编码质量更难度量。
只有对开发完的应用才能度量。
这意味着改变代价很大。
我们应该怎样度量?在开发周期的早期阶段应该做什么才能保证我们正朝着更高质量的目标前进？我们应当保证应用满足客户提出的所有需求。
这主要取决于开发过程的一开始这些需求被确定的程度，但这可通过检验正进行的基础来保证它符合需求目的。
这是一个手工完成的测试，但有些自动工具如Rational ClearQuest也可以跟踪设计、构造、测试等不同阶段。
我们还必须保证为满足需求而设计的商业功能完全，用好、坏或没有输入来检验。
养成用这种方法测试商业功能可以达到更高质量。
测试的另一方面是应用编码。
这需要花费更多的时间，因为每一个编写的功能都必须经过检验以确保它的运行完全符合所期待的那样。
这便是这些能够生成测试案例的自动工具的有价值之处，但并不是所有自动工具都能达到这样的水平。
有些工具能够通过运行测试案例看应用软件的每一部分是否经过了检查，如Rational公司的 Teamtest、Mercury公司的 WinRunner产品，但没有一个自动工具能生成你所必需的测试。
我们要强调的第三个方面是应用软件能否实现设计的功能，更重要的是它是否有效，这就需要开发人员与用户之间进行交流，比较初始步骤和需求，检查它们在应用中是否相符。
最后，我们应该确保应用软件具有要求的一切功能。
一个有效的应用软件能完成一半需求不是非常有用，而一个能够完成所有需求的应用软件却附加了一些用户不需要的过程和商业功能，也不是有效的，而且容易导致用户及软件支持程序员的混乱。
这也应该由需求管理。
显然，关键因素在于需求。
需求必须详细列出，在整个过程中保持记录，并且所有应用编码都应由需求证实。
需求管理十分重要，它形成了CMM的脊柱——允许企业检验自己所处的等级。
这里有五个等级。
所有公司至少在等级1，极少数在等级5。
通过这些等级，我们可以看出关键问题是需求管理。
需求带动了应用的整个最高目的。
根据SEI，达到等级3的公司可以在产量及质量方面提高200％到300％。
性能这是软件质量的注意力最集中的方面。
性能是每个应用的表现。
性能可以分为以下四个部分：用户性能、客户端应用性能、网络性能、可伸缩性性能。
用户性能是最难度量的部分。
用户对两个方面感兴趣：第一，完成任务的速度。
如果它比以前的方法耗费时间还长，那么，即使是世界上运行最快的编码用户也感觉很慢。
第二，感觉上的性能。
如果用户感觉一个过程太慢，那它就慢。
这就是说，在严格的时间控制下性能的度量并不总是精确。
感觉上的性能有时比真正的性能更重要。
当然不总是这种情况，当发生比较重大的延迟时，你只要能够保证用户对发生的过程清楚，三秒钟是可接受的延迟极限。
但如果我们发现一个应用的性能比较困难，可以使用包括PowerBuilder版本6及更高的版本在内的工具是Profiler，它可以为对象、功能甚至编码行提供更精确的时间测试。
这种工具很容易使用，可提供出色的图像结果帮助你发现性能的真正问题。
度量网络性能是一个经常不被开发人员重视的方面。
那么当数以千记的用户同时下载庞大的会计报表时我们怎样测试应用呢？实践证明适合这种类型的性能检测工具要比其它方面的多。
经销商有高质量的装载测试工具。
它只需要很小的测试环境就可以模拟产品环境。
你仅需三台机器就可模拟数以千记的用户上述行为的概况。
用这些工具你可以发现瓶颈可能出现的地方并制定与之适应的对策。
也许你需要附加硬件来运行应用。
或许要建立控制以预防同时发生上千个对会计报表的需求。
或许你需要开发一种方法，使你一旦得到会计报表，别的用户可以共享。
在这方面我们也对数据库进行受压测试。
有些公司用一些产品来度量多个请求对数据库的影响或者长时间运行的交易对数据库有无影响。
越早发现问题意味着解决问题的费用越少。
度量的最后方面是可伸缩性。
这种度量是看用户数的增加应用表现如何。
有时又称它为压力测试。
我所见过的最好压力测试是期望用户数的两倍。
压力测试的精确定义是：通过超过事先期望的用户数并发访问来测试你应用的结构、客户端机器、应用服务器、网络和数据库。
经过这个过程，你就能知道何时需要额外的硬件，你具有的硬件能否支持用户，能准确预见确保维持一定性能需要做什么。
结论关于软件质量还有许多事情要做。
要知道自己写的每一行编码从简单的GUI、命名标准到压力测试复杂的网络配置都是马虎不得的。
需要提醒的是：我们为用户开发应用软件，用户在使用我们的系统时花费了很多金钱和时间。
我们应该为他们提供可运行的、可维护的、可扩展的、高性能的应用。
我们要有责任感。
虽然许多工具可以帮助我们，但最终还是要靠我们的责任心去完成。
