可维护性、可扩展性（Maintainability、Scalability）反映当环境改变或出现错误时，执行修改或修复的难易程度。系统的设计是否很好地考虑日后扩展的需求，架构是否灵活等因素决定可维护性和可扩展性。系统测试可以获得系统的可扩展性指标。

　　健壮性（Robustness）衡量系统在接受异常或错误输入后能否返回正确的提示信息且不影响正确运作的指标。详细的功能测试是检验健壮性的主要方法。

　　安全性（Security）衡量系统对攻击性或不当的访问的抵御能力，检测的方向包括在受到没有授权的访问时系统对自身及数据的保护程度，系统的安全机制是否正确地实现，系统在受到攻击时是否能保持正常的业务运作等。系统测试有专门的测试涵盖安全性的审核。

　　有了诸多衡量质量的指标，软件的好坏就可以量化了，可见有效的测试是软件质量的重要保证。测试除了提供量化指标以外，还可以作为动力来驱动开发的进度，这就是极限编程倡导的测试驱动开发（Test-Driven Development，TDD）。

　　测试驱动开发的要点是先写测试程序，然后再编码实现使其通过测试。测试可以有效推动需求的实现，但是测试场景的覆盖度不足以涵盖所有的分支，因此，开发前的完整设计及第一轮开发过后的详细功能测试能够避免测试场景的覆盖问题。这样，测试场景相当于提供给开发人员的指导性主线，加快主要功能点的开发速度。

　　测试驱动开发的方法为开发提供一种新的方式，测试处于主导的位置。但测试的更重要作用还是在于提供衡量软件质量的量化指标。因此，我们认为，软件的好坏是由测试决定的。

　　1.2.3  测试也有大学问

　　既然软件测试对于软件质量有非常重要的影响，那么，如何有效地进行软件测试，则是非常值得关注的问题。

　　测试的目标是发现软件系统中存在的缺陷，这其中有一个关键的原则--尽可能早地发现问题。

　　在软件开发的前期甚至是设计阶段，某些缺陷可能已经存在，然而在这个时期要发现问题并不是件容易的事情。原因是多方面的。首先，在系统的很多功能模块尚未开发完善时，由于相互依赖关系而引起的缺陷一般难以被发现，因为缺陷只有在系统进行了集成以后才会真正暴露出来。例如，有些模式在简单的系统架构下可以带来不错的开发效率和运行效率，但是随着新模块的加入，这种架构的集成复杂度会急剧提高，系统原有的"精简"优势在这种条件下不复存在，新模块的运行效率会受到明显影响。这是个很明显的缺陷，但是这种设计的缺陷在新模块加入以前不可能很容易地暴露。其次，有些缺陷在开发前期看起来也许算不上是个缺陷，测试人员很容易忽略或仅仅把它当做一个"事件"。这种问题的严重性随着开发的深入才会逐渐显现。一个典型的例子是数据库查询的效率问题。使用全表扫描（Table Scan）可以获取完整的数据集合，全表扫描的效率缺陷在开发初期常常不容易被察觉，随着越来越多的数据和查询的加入，全表扫描的问题才会变得越加明显。另外，在开发周期的前期，项目人员通常会把注意力放在开发新功能上，在测试方面投入的资源相对较少，因此发现问题的可能性也降低了。

　　从图1-2中可以看到，一个相同的问题如果在不同的开发阶段解决，所需的开销是不一样的。越到开发后期，解决问题所需的开销越大。

　　有人对“尽可能早地发现问题”这个观点持怀疑态度。既然问题在开发的前期隐藏得非常好，而在后期更容易暴露，那为什么不干脆等到后期才专注于缺陷的发现和解决？这样不是更能降低测试的成本吗？

　　就测试本身而言，这种想法有道理，减小测试的开销同时让更多的问题暴露，似乎是个很理想的策略。然而，从软件项目的整体上考虑，这就是个非常糟糕的选择了。同一个缺陷，在不同的时间段发现，对其进行修复所需的努力很可能极不相同。一个典型的例子是使用了不恰当的消息模式而导致系统与外围通信效率低下的问题。如果问题在需求分析阶段即被发现，那么只要考虑更换一种消息模式。因为这个过程中任何实质性的劳动都不存在，所以并不需要额外的劳动开销。如果问题是在设计阶段出现的，那么更换消息模式还是必需的，同时，还需要考虑更换模式对外围接口的设计是否有影响。当然，这种考虑主要是评估性质的。假如是在功能实现的前期发现问题，那么除了评估对外围的影响以外，重写一部分代码是必不可少的。随着开发的进一步推进，可能有很多模块对消息模块存在依赖，如果针对依赖的开发已经完成以后才发现问题，不可避免地，相应的依赖模块的设计和实现就得重做，所需的代价变得更加高昂。