1、概述

　　本文所指的测试，包括了对工作产品进行质量控制的所有相关工作，如：理论分析与类比、专家评审、代码走查、程序运行验证等。

　　测试，并不是一个独立的阶段，它不是仅在将产品交付给用户之前才进行，甚至也不是在软件生命周期中每个阶段结束时进行，而是和所有的软件生产过程并行。

　　架构测试，主要是为了降低系统在可用性、易管理性、性能、可靠性、可伸缩性和安全性等方面的风险，利用系统原型，对系统主要架构、关键技术、核心数据设计、统一规范等进行的测试，在项目早期阶段确认系统能否满足用户需求及对产品的定位。架构测试由产品研发团队组织，相关人员参与，特别是需要尽早获得客户的反馈和认可。

　　在以往的开发工作中，很多项目组已经自发进行了很多架构测试相关的工作，但完备的架构测试还没有上升到组织级规范和约定。

　　2、架构测试定位

　　2.1 应用需求决定软件架构

　　对应用软件存在着各种需求：功能需求、非功能需求、变更案例等等。一般来说，功能需求决定业务架构、非功能需求决定技术架构，变更案例是将来可能要（或可能不要）满足的，但现在不需要满足的需求。功能需求定义了软件能够做些什么，我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的约束、规则、标准，而我们的技术架构要能够满足这些约束和规则。变更案例是我们在验证软件的可扩展性、可维护性时需要重点考虑的内容。

　　我们希望一个好的架构能够：重用、可靠、延展、简明、高效、安全。如果说功能需求定义了架构设计的目标的话，非功能需求就对如何到达这个目标做出了限制。进行系统设计初期就需要开始注意非功能需求，因为如果忽略它们，在后期需要花费很大的精力来调整架构模型。

　　2.2 架构测试的主要工作内容

　　目前公司在架构测试方面需要进行的工作主要有：

　　1. 验证系统整体架构是否满足需求：

　　软件的处理能力是由其架构决定的，良好的架构模式是应用高性能的基础。面对不合理的系统架构，即使编码技巧再高，应用也不可能有良好的性能。所以，需要“尽早测试、不断测试”，以便验证系统整体架构是否具有可靠性、高性能。

　　2. 验证应用主要技术实现的可行性

　　在编码开始前，需要对应用主要技术实现的可行性进行验证，主要包括：资源的使用与释放，数据库连接模式，页面数据量的合理分配，数据传输压缩技术的使用，识别应用可能的性能瓶颈。

　　3. 验证系统核心数据设计的合理性：

　　很多应用面临着大量数据处理，数据表存储空间的划分、数据库结构的设计是否合理、索引的建立是否正确等，都会影响系统的整体性能。而且很多时候数据库结构的变动对应用的影响非常大，因此在项目早期需要对系统核心数据管理设计的合理性进行验证。

　　4. 应用架构易维护性、易扩展性的测试和验证：

　　软件在设计时都为未来业务的伸缩和扩展留出了空间，在做架构设计的时候，变更案例也是设计的考虑因素之一，为了尽量减少软件的后期维护、修改、测试工作量，良好的软件架构应该具有很好的易维护性、易扩展性，这也是架构测试的验证内容。

　　5. 项目组统一规范的测试和验证：

　　合理的设计和编码规范，对提高系统整体风格的统一和软件的易维护性、易测试性很有帮助。有一些组织平时并不注意标准（风格）的积累，认为这种积累属于雕虫小技，但正是这些小技，能够非常有效的提高沟通的效率和降低开发人员的学习曲线。对涉及到具体实现技术的编码设计规范，必须经过测试验证后才能纳入组织的统一规范中。

　　3、架构测试总结

　　3.1 架构测试与性能测试

　　1. 架构测试

　　有的系统，虽然从在一定条件下的某些测试看，性能比较理想，但是随着数据量、用户量的提高，系统的性能难以满足业务的扩展，并且整体性能难以优化，这说明其从设计架构上就存在致命的缺陷，架构的延展性不够好。

　　实践证明：系统的可靠性和性能是由其架构决定的。如果能抓住架构测试的核心内容，对协助项目组控制技术风险、提高开发质量、降低开发成本都可以起到很好的促进作用。