如何成为名副其实的测试架构师？

测试模型无处不在，你只有真正理解了“什么是测试架构”、拥有了测试建模能力，才能成为名副其实的测试架构师。

众所周知，“架构（architecture）”一词来源于建筑，具有 “建筑学、体系结构” 等含义。建筑学的内涵要比体系结构丰富得多，但其核心往往关注其造型和体系结构的设计，综合考虑环境需求和使用者的需求，进行空间上合理的功能分配，满足安全、经济、适用、美观等需求，达到人和环境的和谐。

软件体系架构是一个比喻(或称之为“系统隐喻”)，类似于建筑物的体系结构，主要指软件系统的基本结构及其设计规范，软件体系架构包括软件系统构成元素及其之间的关系、元素和关系的特性等。例如，一个系统由数据层、数据访问层、服务层、业务逻辑层、展示层等组成，每个层次都是系统的构成元素，各个元素之间不仅有层次关系，而且是通过接口连接起来，以降低系统的耦合性。如果需要提升系统的可靠性，系统还要增加冗余组件。

软件架构也是项目早期必须做出的设计决策，即从体系结构的角度思考软件的核心组成、决定什么是重要的，并能使这些体系结构元素处于良好的状态。而软件架构师是能够识别哪些元素是重要的，能识别出哪些元素不加以控制，可能会导致严重的问题。如果在软件开发早期没有做出基本结构的正确选择或设计出良好的结构，后续软件系统会存在某些质量问题而不得不进行修改，而且这种修改会付出高昂的代价，导致功能的实现更慢、缺陷也更多。所以，软件架构及其设计是非常重要的。

那么软件测试中存在架构或基本结构吗？即软件测试中是否存在一些测试元素及其关系，我们需要研究这些元素、关系，从而能提高测试的效率和质量？其实是存在的，其中一个显著的例子就是自动化测试框架或测试平台的架构，如图1案例所示，虽然它基本符合软件架构的特性，但同时也要满足软件测试的特定需求。所以，软件测试平台的架构不能单单看作是一类通用的软件架构。

图1 阿里云测试平台架构TestMaster示意图 除了自动化测试平台之外，面对一个具体的测试项目，也存在着一系列的测试建模：

测试需求建模（有时也包含了测试设计）——众所周知的基于模型的测试方法（MBT）,如相对简单的分类树、黒盒测试方法（如图2所示）、因果图、状态树、有限状态机等，以及更复杂的建模，符号执行、模型检验等，如图3所示；

测试方案的设计，包含着如何识别出测试项、测试风险、测试方法等众多测试元素，以及确定它们之间的关系；

测试用例的结构，如在基于脚本测试中，如何分解测试目标、如何构建测试集（test suite）、如何组织好测试用例（含层次划分）等。

探索式测试的设计，如何将测试目标分解为Mission，再将Mission分解为Session。

自动化测试脚本的设计，如何对测试脚本的封装、层次划分等。

图2  黑盒测试方法抽象为模型

图3  符号执行模型示意图

软件测试离不开业务、更离不开开发，软件测试团队或相关人员需要和业务架构师（或业务分析人员）、产品经理和软件开发架构师进行沟通，参与需求评审和（技术架构和功能结构、UI等）设计评审，理解业务架构、产品结构和技术架构等（如果不了解这些内容，不要急，后续有详细讨论），从而更好地设计出测试方案，更有效地进行测试，如分层测试、精准测试、契约测试等都有测试建模的影子。这里也不仅仅是功能测试，还有性能测试、安全性测试和可靠性测试，像这些专项测试的结果分析，需要对系统的技术结构、产品结构有很深的理解，才能完成缺陷的分析与定位。更重要的是，一些非功能性的缺陷，甚至在技术架构设计评审时就能发现问题，而且这时修复设计缺陷的成本，会远远低于在系统的专项测试之后的修复成本。

测试模型进一步延伸，可以延伸到测试过程建模，如W模型、TMap等，这里给出敏捷测试的过程模型，如图4所示。

图4  敏捷测试过程模型  

审核编辑 ：李倩