我们应当保证应用满足客户提出的所有需求。这主要取决于开发过程的一开始这些需求被确定的程度，但这可通过检验正进行的基础来保证它符合需求目的。这是一个手工完成的测试，但有些自动工具如Rational ClearQuest也可以跟踪设计、构造、测试等不同阶段。我们还必须保证为满足需求而设计的商业功能完全，用好、坏或没有输入来检验。养成用这种方法测试商业功能可以达到更高质量。
测试的另一方面是应用编码。这需要花费更多的时间，因为每一个编写的功能都必须经过检验以确保它的运行完全符合所期待的那样。这便是这些能够生成测试案例的自动工具的有价值之处，但并不是所有自动工具都能达到这样的水平。有些工具能够通过运行测试案例看应用软件的每一部分是否经过了检查，如Rational公司的 Teamtest、Mercury公司的 WinRunner产品，但没有一个自动工具能生成你所必需的测试。
我们要强调的第三个方面是应用软件能否实现设计的功能，更重要的是它是否有效，这就需要开发人员与用户之间进行交流，比较初始步骤和需求，检查它们在应用中是否相符。
最后，我们应该确保应用软件具有要求的一切功能。一个有效的应用软件能完成一半需求不是非常有用，而一个能够完成所有需求的应用软件却附加了一些用户不需要的过程和商业功能，也不是有效的，而且容易导致用户及软件支持程序员的混乱。这也应该由需求管理。
显然，关键因素在于需求。需求必须详细列出，在整个过程中保持记录，并且所有应用编码都应由需求证实。需求管理十分重要，它形成了CMM的脊柱——允许企业检验自己所处的等级。这里有五个等级。所有公司至少在等级1，极少数在等级5。通过这些等级，我们可以看出关键问题是需求管理。需求带动了应用的整个最高目的。根据SEI，达到等级3的公司可以在产量及质量方面提高200％到300％。
性能
这是软件质量的注意力最集中的方面。性能是每个应用的表现。性能可以分为以下四个部分：用户性能、客户端应用性能、网络性能、可伸缩性性能。
用户性能是最难度量的部分。用户对两个方面感兴趣：第一，完成任务的速度。如果它比以前的方法耗费时间还长，那么，即使是世界上运行最快的编码用户也感觉很慢。第二，感觉上的性能。如果用户感觉一个过程太慢，那它就慢。这就是说，在严格的时间控制下性能的度量并不总是精确。感觉上的性能有时比真正的性能更重要。
当然不总是这种情况，当发生比较重大的延迟时，你只要能够保证用户对发生的过程清楚，三秒钟是可接受的延迟极限。
但如果我们发现一个应用的性能比较困难，可以使用包括PowerBuilder版本6及更高的版本在内的工具是Profiler，它可以为对象、功能甚至编码行提供更精确的时间测试。这种工具很容易使用，可提供出色的图像结果帮助你发现性能的真正问题。
度量网络性能是一个经常不被开发人员重视的方面。那么当数以千记的用户同时下载庞大的会计报表时我们怎样测试应用呢？实践证明适合这种类型的性能检测工具要比其它方面的多。经销商有高质量的装载测试工具。它只需要很小的测试环境就可以模拟产品环境。你仅需三台机器就可模拟数以千记的用户上述行为的概况。用这些工具你可以发现瓶颈可能出现的地方并制定与之适应的对策。也许你需要附加硬件来运行应用。或许要建立控制以预防同时发生上千个对会计报表的需求。或许你需要开发一种方法，使你一旦得到会计报表，别的用户可以共享。在这方面我们也对数据库进行受压测试。有些公司用一些产品来度量多个请求对数据库的影响或者长时间运行的交易对数据库有无影响。越早发现问题意味着解决问题的费用越少。
度量的最后方面是可伸缩性。这种度量是看用户数的增加应用表现如何。有时又称它为压力测试。我所见过的最好压力测试是期望用户数的两倍。压力测试的精确定义是：通过超过事先期望的用户数并发访问来测试你应用的结构、客户端机器、应用服务器、网络和数据库。经过这个过程，你就能知道何时需要额外的硬件，你具有的硬件能否支持用户，能准确预见确保维持一定性能需要做什么。
结论
关于软件质量还有许多事情要做。要知道自己写的每一行编码从简单的GUI、命名标准到压力测试复杂的网络配置都是马虎不得的。需要提醒的是：我们为用户开发应用软件，用户在使用我们的系统时花费了很多金钱和时间。我们应该为他们提供可运行的、可维护的、可扩展的、高性能的应用。我们要有责任感。虽然许多工具可以帮助我们，但最终还是要靠我们的责任心去完成。
文章来源于领测软件测试网 https://www.ltesting.net/
