图2-1 不好的布局决定着失败
而如果换一个思路，进行不同的布局，如图2-2所示，不采用自然的竖直排序，而采用斜线排序，充分利用空间，而且进攻部队前进的速度会大大降低，结果就很不一样，游戏者便能轻松过关。
图2-2 良好的布局是成功的一半
这里的布局，是指处理问题的全局规划、整体设计。全局规划如何、整体设计效果如何，自然关系到后面的整个过程，所以总会受到我们重视。
说到架构，我们会想到软件架构，如C/S架构、SOA架构，甚至会想到以架构设计为中心的RUP。软件架构的概念由来已久，软件架构师的头衔容易被大家认可，但“测试架构”的概念还不够清晰，人家会有很多的问题要问：
什么是测试架构？
测试架构对软件测试有什么帮助？
软件公司需要设置“软件测试架构师”职位吗？
软件测试架构师做哪些事情？
当人们知道微软公司、阿里巴巴集团等设有“测试架构师（Test Architect）”职位时，可能会惊奇地问：什么？ 测试团队也设立“架构师”头衔吗？人们对开发团队设立架构师已经比较习惯了，因为大家知道，在设计一个软件系统时，需要考虑整个产品架构如何设计
、系统各个组件如何集成在一起、如何相互协调工作，而这些都需要“软件架构师”来完成，但对测试团队为何要设立“架构师”头衔还是不够清楚，主要是因为不了解测试架构从何而来。
在日常测试工作中，如何选择测试工具和如何建立统一的自动化测试框架？这是经常困扰我们的问题。除此之外，我们还会碰到如下的一系列问题：
如何帮助开发人员提高产品设计和代码的可测试性？
如何找到更有效的办法来设计测试用例？如何完成复杂系统的非功能性（性能、安全性、兼容性、可靠性等）测试任务？
如何通过分析系统测试结果，找出系统存在的问题？
能否对测试技术的发展趋势做出正确判断，从而更有针对性地提高测试团队的技术能力？
举例、暗喻
测试架构从何而来？其实它就是为了解决上述问题而产生的。从基本的观点看，测试架构是由软件系统技术架构和软件测试框架（特别是自动化测试框架）构建的需求而定。这些需求，决定了以下从不同方面所形成的测试架构。
大家都能理解，越早进行测试，就能越早地发现缺陷，对提高产品质量、降低企业成本就越有利，更重要的是越能预防系统 设计时出现严重的缺陷。如果所设计的系统架构存在严重的缺陷，直到系统集成测试时才发现，所造成的返工将是可怕的。这就需要测试人员对设计进行复审、评 审。测试人员应参与系统架构及其组件接口等设计的审查，包括是否全面考虑非功能特性、各个特性的可测试性评估、设计的合理性等。
从软件系统来看，如何验证系统的性能、安全性、可靠性和可伸缩性等，例如网站能否支持扩展到100M的点击率，投票系统是否安全等都需要对系统架构进行分析，建立测试概念模型，从而科学、有效地完成认证。
现在的系统越来越复杂，其设计往往不是一蹴而就的，需要不断地重构和优化，而这些工作是基于以前版本的测试结果（包 括发现的问题）来实施的。测试人员在完成系统测试后，可以通过对测试结果的分析发现问题，如系统性能瓶颈、安全漏洞等，进而可以对系统的性能、可靠性、安 全性等改善提出有价值的建设性意见。
在系统功能测试时，需要对功能进行合理的划分、归类，建立用例模型，设计合理的测试结构。
从测试工作自身来看，需要建立合适的测试管理系统，包括测试用例库的设计、缺陷跟踪机制等。
设计自动化测试框架，包括集成测试环境、测试脚本分层处理、执行结果自动生成报告等。
掌握测试技术发展趋势，研发新的测试方法，并借助测试工具来实现，例如，在安全性测试上如何采用合适的模糊测试方法。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/