测试架构师必须具备的第一个能力："准确的商业理解力。"

　　最近看到一篇关于测试架构师介绍的文章，文章中的测试架构师原型来自微软，其描述的工作内容让不少国内的测试同业很是羡慕，但又觉得好像离我们中国人很远。不知我们中国的测试工程师能做吗?我的答案是Yes。

　　因为，我现在就在中国带领着一个测试架构师团队。了解自己所在公司测试架构师团队的运作和工作内容(后续将陆续与大家分享)，虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大，业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责，其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师，系统测试工程师再往上应该叫什么呢?最后参考软件开发的title，就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责，例如：领导负责一个产品线或一个大产品的测试技术规划，early testing，系统测试工程师的培养，与开发架构师一起设计和改进架构的设计质量，测试执行活动质量的审查保障，亲自指导重点测试方案的设计，为了不断降低公司研发成本而进行新测试技术研究实践和推广，基于风险的测试，基于模型的测试，安全性测试，兼容性自动化测试，分布式自动化测试，性能压力测试，需求测试等专项测试技术领域的研究，并支撑新领域重点市场项目活动等等。

　　与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本，不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架，针对具体的产品特点，思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率，让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型，能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动：如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求)，然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式，主要是亲自实践各种新测试技术后，再带着测试人员在实战中掌握相关的方法。

　　我们大部分的测试架构师都是写过自动化测试脚本或程序的，只是现在的工作由于需要我们去思考太多的东西，所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师，由于负责多个产品，还要抽取产品间的共性测试技术，要建立起产品线的测试架构图，统一产品间的测试技术，统一测试方案的设计质量标准，需要具备更强的抽取共性的能力。同时，还需要能在短期内快速了解和识别影响产品成败的关键测试技术，因为并不是所有产品都是性能压力测试就是最重要的。例如：某产品线有9个产品，有的产品最需要保障的是可靠性(性能，可用性不是关键);有的产品最需要保障的却是可用性，而不是可靠性;有的产品最需要保障的是安全性，而不是性能;有的产品最需要保障的是可移植能力和可集成能力，而不是性能。那么相应的每个产品测试用例设计就会有所侧重，例如：对于重视可移植能力和可集成能力的产品，测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。

　　因此，测试架构师必须具备的第一个能力就是："准确的商业理解力。"商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的，如果测试架构师识别错误了，那么有可能在需要重点保障的领域，测试技术和测试资源投入不足，导致最后产品的商业竞争力得不到支撑，得不到质量保障。例如：某产品对外宣传是业界可靠性最高的产品，可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中，对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中，该产品的可靠性得分却并不是第一，虽然性能是第一，但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。

　　某美国公司的一款产品在传统行业中主要功能基本雷同，如何才能与类似产品拉开距离，突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长，因此为了缩短用户的操作时间，该公司决定在产品的可用性领域重点投入设计，核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中，构建了业界非常丰富的可用性测试用例，这些测试用例的场景超过了产品设计考虑的原有场景，并最终通过测试驱动设计，与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品，而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。

　　所以，如果你的公司正准备招募测试架构师，请第一考评他的能力应该是他的商业理解力。具有该能力的测试工程师知道如何选择：做正确的事!确保事半功倍。而不具备该能力的测试工程师可以成为系统测试工程师，由他来保障正确的把事做好!

　　测试架构师必须具备的第二个能力："区分测试重点和测试难点"

　　重点和难点两个词汇有时能代表同样的方向，有时却是相差较远的方向。

　　为什么我要把是否有能力区分测试重点和测试难点作为测试架构师必备的第二个基本能力。因为，我曾在某产品线对测试活动的质量进行抽查时，与每个产品的系统测试工程师进行了沟通，发现只有一名有6年经验的系统测试工程师在我的的启发下，分清了自己所负责产品的测试重点和测试难点。而其他的系统测试工程师一直都把测试难点误当成了测试重点，作为他技术攻关工作的主力方向。甚至从来没有真正思考过什么测试技术才是自己所负责产品决定成败的测试重点，只是简单地把自己在工作中碰到的所不具有的测试技术都当成测试重点，其实很多都只是测试难点。的确，在某些产品测试难点和测试重点刚好重合。虽然某些产品测试重点在技术上并不难，但是却需要我们把测试重点部分的工作质量做到最佳，时间和资源投入最多，而不要把有限的资源投入到测试难点的工作中去。我很认同华为任正非对华为工程师的要求"要做工程商人"，我们其他公司的工程师同样应该以商业目标为自己的技术工作目标，不应唯技术论，越新的技术，越难的技术就越愿意投入。测试工程师同样要心中一直有一个目标指引着自己的所有技术工作方向。这个目标就是我测试架构师日记中第一篇谈到的"准确的商业理解力"告诉你的工作目标。

　　由于项目中每个人的分工不同，因此不可能每个测试人员一开始就能知道自己工作的商业目标是什么，所以也不用去责怪大家。可是领导产品的测试架构师不能准确的识别或培养其他测试工程师具备识别测试重点和测试难点的能力，那么注定这个测试团队的工作不但质量保障会打折扣，而且会浪费不少组织的资源和成本。

　　因为资源和时间是有限的，而完美工作的追求是无限的。因此，我们如何在有限的资源和时间下，保障基本的质量目标，并尽可能提升质量目标。就需要在分清测试重点后，优先针对测试重点目标进行系统地测试技术研究，测试技术攻关，测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级，放在最后考虑。

　　测试架构师的工作应该牢牢抓住真正的测试重点来开展，甚至在整个产品测试组都方向错误时，要能从商业角度帮助测试组改变观点。那么当从测试经理到普通工程师都误理解了测试重点时，测试架构师应该如何来启发他们呢?我这里就分享一个案例吧：

　　在一次到产品测试组进行测试活动质量抽检时。我们问测试经理，你们产品测试目前最大的需求是什么?他说是如何进行压力测试和性能测试，希望我们测试架构师团队能在此领域多给予支持。我心里知道：他所负责的产品特性核心不是性能和压力测试，但我没有反驳他。而是继续问他下一个问题："你觉得会让你产品未来应用时商业失败的最大担心是什么?"他想了想说："不能对客户的生产系统产生破坏，让客户的业务中断。""依据我们的经验，与客户生产系统交互的模块虽然是个小模块，但是在其他产品上经常出现内存泄露的故障从而破坏了生产系统。那你针对该小模块做过哪些系统地测试?有无专门进行内存泄露的测试，因为内存泄露对客户生产系统的破坏最大。"我问到。这时此测试经理才恍然大悟，这个对生产系统质量影响最大的小模块居然没有系统地进行过深入全面的测试。我这时告诉他 "你之所以开始说性能和压力测试是你的重点需求，是因为你们组里没有在性能和压力测试方面的积累，有工作开展的难处，这是困扰你的困惑。但是你的产品形态的质量不是性能或所谓压力测试来保障的，而是需要不对生产系统产生破坏。因此，你唯一能破坏生产系统的那个小模块应该是你整个产品中质量最高的模块，也应该是测试最全面最深入的模块，你的技术力量应该主要投到这个地方"。后来，针对该小模块我们进行专项内存泄露的测试，结果发现了好几个内存泄露的大bug，这些bug每一个都是会导致客户生产系统中断的杀手。

　　测试架构师不是团队中专门解决测试难点的专家，而是识别测试重点，并支撑测试重点工作的专家。"区分测试重点和难点的能力"不是测试架构师独有，系统测试工程师和测试工程师一样可以具有。与第一篇"准确的商业理解力"一样，第二篇要做的是：做正确的事。

　　在开始描述我理想中的测试架构师必备素质第三篇前，我想先转载一篇来自互联网万欣的文章《好的架构师都是善良的独裁者--万欣》与大家分享，作为测试架构师必备素质第三篇的前言：

　　对于任何一个软件开发人员来说，架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时，也担任了微软公司的荣誉角色"首席软件架构师"，可见"架构师"这一称谓的吸引力。架构师是公司的"金领"，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，形成"强者愈强"的良性循环。部分优秀的开发人员在工作了一定时间后，就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力，在补充一定的项目管理知识后，可以向技术管理的方向转型。如果其对技术一直很感兴趣，而沟通能力也不弱，则可以试着进一步加强技术修养，以期向架构师的方向发展，最终"修成正果"。

　　那么，到底什么是架构师呢?所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。

　　什么是架构师最具价值的技能呢?就是要了解不同的知识，做一个"杂家"或者说"博学家"。当然，如果你的数据库技术非常棒，或者你在工作流引擎方面具有不可超越的专家知识，那也是很不错的。好的架构师有好多都是从专家成长过来的。但是，这不是架构师应该做的事情，架构师应该做的是了解所有的东西，既了解技术的宏观面，又了解技术的细节。真正的架构师不仅仅要了解软件，也要了解硬件，在关键的部位使用合适的硬件来取代软件，可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例，向大家讲解作为架构师应该具备的知识。

　　互联网行业是当前最激动人心的行业之一，很多的创新都来自于这个行业，而每一个大型的网站如Google，Yahoo，Myspace等都需要解决一个非常复杂的问题，就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题，需要最优秀的架构师对业务进行剖析，利用软硬件将网站进行重构，甚至根据业务研发相应的分布式技术，解决网站复杂的分布式计算的问题。

　　如果你想在这个行业中成为一名架构师的话，需要至少掌握网络知识，硬件，软件，网站优化等方方面面的知识：

　　网络知识

　　当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业，任何一个行业的软件，都要求其具有网络功能。因此，网络知识是架构师必备的知识。我们所说的网络知识，不仅仅包括TCP/IP，http等互联网行业常用的软件协议，也包括网络规划，甚至更具体的说，根据网站应用所处的地理环境进行网络规划。比如人们常说："这世界上最远的距离不是生与死的距离，而是电信到网通的距离"(笑)如果应用是建立在中国的，就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种，比如采用CDN(Content Delivery Network内容分发网络)使得网站的内容发布到离用户最近的服务器，又可以采用把服务器放在一些所谓的双线机房中，甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师，要对这些知识都有所了解，才有助于在遇到问题时找到最佳答案。

　　硬件知识

　　了解硬件的极限，是架构师的基本功。我见过一些人，他们的眼中软件硬件都是没有极限的，需要资源就申请，系统性能下降了就买更高级的设备。然而，硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动，这种运动是有极限的。因此当资源访问量增大到一定的程度时，这种物理运动将成为瓶颈。比如说，在开发网站的过程中，记录访客的状态是一件很重要的事情，一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战，尤其是多机共享Session时，将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案，然而，架构师必须考虑到这种方案是有I/O极限限制的，很难扩展到超过一定规模的大型网络。同时，架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响，比如在多核的条件下是否对软件编程有新的要求，是否会对运行在虚拟机和非虚拟机上的程序有影响等等。

　　软件知识

　　软件知识所包含的范围就更加广泛了。对于互联网行业来讲，架构师要了解操作系统，数据库，应用服务器等各方面的知识。比如说，如果网站使用的操作系统是 Linux，就要了解这个Linux版本的性能与局限性，比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的，虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况，但是作为架构师，请时刻注意，这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中，而你所负责的应用又没有经过优化的话，可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因，也可能是数据库不支持大文件。不论如何，架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题，如果一个站点由多个数据库支持，架构师需要考虑如何在保证数据一致的情况下，让多个数据库分担压力。有些解决方案是将数据库的读写分开，使得大多数的查询sql不经过核心数据库，而只是访问数据库的副本，但事实上，这种方式也只能维护规模不大的网站。对于大型的网站来说，把业务分散到不同的数据库中，只共享必要的数据，才是合理的提高网站扩展性的解决方案。

　　其他知识

　　作为系统架构师，可能还需要对分布式系统，负载均衡，网络安全，数据监控等等各方面都有所了解。不仅仅是了解理论知识，也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么，有什么缺点。如何使用缓存，如何做好日志分析等等。

　　刚刚谈到的是架构师需要掌握的知识，然而，冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发，请时刻关注你所开发软件的性能与可扩展性，而不仅仅局限在功能上，时刻想着任何一个简单的问题：我开发的模块如果放在多人并发的环境下会怎样，慢慢的就会有所心得。如果你还是一个在校学生，不要想着自己离架构师这个职位还很遥远。要知道，成为架构师的修炼之路是很长的，甚至可以说是终身的，因此早点进入学习状态，不断修炼自己。在学校期间学好离散数学，数据结构，操作系统，编译原理，体系结构，数据库原理等关键课程，并积极寻找机会到外面实习，增长自己的工作经验。如果有机会去到一些技术主导的公司中工作，就一定不要放弃这种机会，慢慢就会成长起来。最重要的，你会养成关注技术，勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质，并能够将其分解为一个个可轻松解决的模块，你会由衷的感觉到知识给你带来的快乐，或许那一天，你已经是一个架构师了。