软件架构与测试架构分析论

    序言:在做自动化测试的过程中，曾努力的对软件设计学习过一段时间，间间断断的，突然发现接触到了软件流程，软件建模（包括数据库建模）、web设计，当然，更多的是用的java设计（数据结构、模式应用、算法等）。虽然不够深入，但是将这些细碎连接起来，在软件架构上也有了自己的一点思考和总结，其实不管做测试也好、做自动化测试也好，还是进行软件设计，都有着一套理念类似的架构学。

     一、生活中的架构

相信大家都知道“马斯洛需求层次理论”，在其理论中，把人类需求分成生理需求、安全需求、归属与爱的需求、尊重需求和自我实现需求五类，依次由较低层次到较高层次排列。这里不讨论其理论的正确性，这也是一种架构，将人类需求实现的各个层次进行了细分，每一个层次之间都有详细的职责细分，每个层次之间都有清晰的关系接口，因此普通人能够快速基于此架构拓展自己的特性需求。

在我想来，人的思想意识也需要自己的架构，你的最底层是你的原则，也就是做人方式，是固定的，不会轻易更改，变动越大，影响越大，然后依次是做事方式和表现方式，可以随着环境的不同进行适应。

二、软件设计架构

1、软件设计流程：

一般的软件设计基本流程会是：需求分析—架构设计—系统设计—系统开发—测试上线。当然，从产品整体上而言，需求分析前期还有战略制订以及可行性研究，上线后期还包括应用数据分析等。

2、软件架构介绍：

软件架构简单而言，觉得有一句话说的很好：在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。其实说的简单点：软件架构就是从整体上定义软件系统的运作流程、各个模块以及模块间的接口。

3、软件架构作用

软件框架的作用是使软件设计层次清楚，可以达到不同模块细分到不同个人开发的效果，各个接口之间能够无缝连接。但是架构虽好，也需要看实际情况，不能一味为了追求花哨的架构，而忽视了其成本。软件架构的真正作用是分离关注点、提升软件需求灵活性和维护性。但是相应的，其前期复用的成本效益也显著提高。因此，需要根据软件项目的规模综合考虑，选择一套合适自己的架构，只是为了临时住而搭建一个草房子，就没必要又是设计地基、又是设计扩展性等问题了。

4、软件架构师发展

从一个从软件实现角度上说，写代码并不是其最重要的工作，最重要的工作就在于其架构的设计，当架构设计好之后，其具体代码细节则是一个填充的过程。就像做房子，房子图形架构都设计好了，那么水泥和各材料就只是按照其形式搭建而已。

而根据我的总结，要成为一名软件架构师：则必须经历这么一个过程：

软件业务学习——开始能够写函数和类（即能够写得了过程性的函数和对象性的类集合，能够应用数据结构和算法实现）———写模块和引擎（能够写一些给外部调用的模块和引擎，能够应用模式，能够定义好自己的接口）——写框架与平台（能够应用抽象思想，善于利用各种架构以及搭建自己的架构，能够区分和选择技术重点、快速验证技术实践等）。自我认为自己还在第一个阶段。反思以前开发的测试项目，大都接口定义太少，更多的是面向类实现的编程，而不是面向接口的编程，最近一直在看java的源代码，才深有体会面向接口的编程和一些简单模式的真正应用——软件业务分析。

三、测试架构

1、测试架构介绍

测试架构，业界常分为“测试管理架构”和“测试技术架构”，也许很多公司，大多数测试经理就担任着这两类的测试架构师，他们往往对测试流程设计负责，也对测试技术的应用选型负责。

其作用不言而喻，但是很多人将架构误认为测试框架，其实不然，测试架构不等于测试框架，其架构还包括测试业务应用定位，例如：一个公司刚开始做自动化测试时，最容易犯的错误是没定位好实施自动化测试的架构流程，一开始就大规模的套用测试框架，然后开始调用测试人员写脚本，到头来却发现这套框架根本不适合测试的形式，其实脚本录制算是一个必然要经历的阶段，只是这个阶段可以大可小，可以通过录制去满足好一部分的测试业务需求，然后等需求稳定和饱和之后，再设计发展适合自己的框架等。所以说，凡事都如造房子，得一步一步来，才能建出好的房子，否则一味的求快，架构不牢固，只会吹散在风中。

2、测试架构师发展

测试技术架构，从业务角度而言，可以是以可重用的测试框架来思考测试点和测试方法，例如：采用的测试方式是功能测试、探索性测试、例行测试、实验局测试还是性能测试等。然后规范出各个测试设计模板。深入技术角度而言，就是对测试方法的技术重点的选择和部署，例如，功能自动化测试和性能测试架构设计。因此，测试架构在技术上是与软件架构理念相通的，而成为一名技术型的测试架构师，需要经历为：

测试业务执行学习—开始写测试脚本或者使用工具进行测试——搭建自己的测试框架或者基于工作设计框架——设计测试平台，能够从整体运营上把握整个测试执行过程——测试业务分析。

四、分析论

1、 大家注意到上面的红字，我个人觉得，每个人都会开始于业务，回归于业务，再好的架构只是架子，而架子上没有衣物的话，太大的架子反而是浪费，所以，角度上而言，架构是服务于业务的，业务是驱动架构的，即：测试业务驱动技术，技术带动测试业务。

2、 架构的能力发展不在于架构本身，而在于一个的分析和抽象能力的发展，我们平时总觉得做测试没有技术含量，但是个人觉得，恰恰相反：一个开发人员，编程是他的工具，如果他只会工具，那么他永远只是个”码农”；一个测试人员，测试执行和测试软件是他的工具，如果他只懂工具，那么他永远只是个“测试执行者”。一个开发人员，如果他永远只会架构，那么他只能算是一个开发者。一个测试技术人员，只懂得设计框架和平台，那么他只能算是一个测试者。真正的架构师们都是能够将实际业务相结合，能够分析和提取各种信息和资源所用的。或者，可以这样说，每一个架构师都是一位管理者，他们掌握了“合理分配和利用资源的能力”。每一个架构师都是一位思想者，他们掌握了“思考业务和架构的最佳融合的方式”。他们以最小化的成本实现了最大化的价值。当然，这只是我的一番杂乱说辞罢了，是对是错，还待研究。

3、对于我们个人人生架构设计，则是一个出发和回归的过程，在这个过程中，我们只需保持不急不躁，一步一步的打好基础，不间隙的慢慢向前即可，这样，也许才能走的更远更稳。