4、非功能性测试的若干问题

　　一个关键的问题是何时进行非功能性测试。大部分非功能性的缺陷与设计有关，故要修复它们就需要修改设计，因此修复代价是很高的。这就说明非功能性测试需要在测试周期中尽可能早的进行，否则修复活动将反过来影响到提交进度的实现。提倡尽早实施非功能性测试的另一个原因是：类似可用性这样的非功能性属性在测试中出现的缺陷可能被认为是低优先级的，并且这种缺陷成为一个公开限制的可能性非常高。项目管理者倾向于把这些缺陷的修复推后，因为改变代码可能对系统功能潜在地产生影响。

　　然而，把非功能性测试安排到早期也存在问题。那就是在很多情况下系统需要获得一个最低程度的稳定性和功能完整性来运行测试用例。例如载入测试、性能测试和配置测试。这就意味着在非功能性测试完成之前，系统功能性测试应该已经完成并且从中找到的任何缺陷都应该得到修复。假如在性能测试和载入测试进行之前系统达不到足够的健壮和稳定的话，测试团队很可能在重起系统等方面等待很长时间。

　　考虑到以上因素，这里提出如下建议：

　　第一轮：功能性测试、可用性测试、安全性测试。

　　中间轮：功能性测试（剩余的和回归的）、配置性测试、恢复性测试。

　　最终轮：容量测试，压力测试和性能测试。

　　这只是一个对测试顺序的大概说明，在具体项目中还可以自行取舍。

　　如果已经通过分析完成了可靠性评估，那么还需要通过继续测试来完成最终的评估。

　　还有几点是关于对非功能性需求的回归测试的，100%的回归测试既不现实也不被提倡。以下是两个例子：

　　——容量测试中大量时间的消耗会影响项目的进度

　　——如果在可用性测试中对于同样的过程使用同样的主题，是不可能得到想要的反馈的。

　　因此，除非在实现，用户接口设计等方面有重大变化，通常情况下仅仅校验缺陷的修复。而性能测试和压力测试又属例外情况。

　　5、性能测试

　　对于客户来说，系统性能的重要性比其他非功能性需求要好理解一些。但在很多项目中，对规定需求的测试还是要进行。然而，测试往往局限于对某个值的测量，比如吞吐率或者响应时间。尽管如此，在不同的处理和配置条件下，这些测试还是要去实施。

　　系统的性能取决于很多因素，这些因素包括系统的配置，外部条件以及系统的当前状态。因此，当测试团队在做性能基准的时候需要考虑这些因素。系统配置包含所有的硬件和软件，例如处理器数量、RAM、数据库服务器软件等等。外部因素包含网络负载和交换机等。内部因素包含启动后的业务处理、系统当前负载以及任何失败条件等等。以下列出了性能测试有关的若干步骤：

　　1）确定要测量的参数。例如调用启动时间，TPS等等。这些可以从需求说明书中得到。

　　2）确定不同的外部条件、系统配置参数以及能够影响性能的内部因素。使用头脑风暴法以及鱼骨图会是个不错的主意。

　　3）确定离散值，使每一个参数都能反映出影响性能的因素并且可以对这些值可以进行测试。确定那些引起兴趣的方面并进行测试很重要。

　　4）为每一个因素确定一个默认的，最常用的值。

　　5）确定测量方法。这可能需要使用工具、产品的特殊构建、特殊的启动等等。规划并实现它们。

　　6）在保持其他所有默认值不变的情况下，每次测量的时候只改变一个参数。

　　7）对测试结果进行划分，这样可以确定每一个参数对性能的影响程度。

　　步骤1到4在测试计划阶段实施，步骤5作为测试需求的一部分，步骤6与测试执行有关而步骤7是测试报告的一部分。这样做的好处是可以基于性能和需求来为市场部或者客户支持部提供数据，以便让他们为客户提供理想的配置。

　　性能测试可以和容量测试以及压力测试并行地完成，这是因为你想在所有的载入条件下都到达性能指标。容量测试通过系统对大量数据的处理时间来找到系统的弱点。而压力测试则是通过系统在高峰期的大量的业务处理来找出系统的缺陷。

　　如果系统性能不能满足需求的期望值，那么就要使用剖析工具来找出制约系统性能的瓶颈。测试团队此时同样要协助开发团队。

　　其他与性能测试协同进行的过动是资源利用测量。它通常包含内存和CPU的利用率并且是在容量和压力的条件下进行测试。