什么是测试架构

                                                                什么是测试架构

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

        《完美测试：软件测试系列最佳实践》一书已由电子工业出版社正式出版，本书由朱少民 主编
        图书信息：http://blog.csdn.net/broadview2006/article/details/7464609