测试架构师在很多公司没有这个定义，我只看到过我们公司和阿里巴巴有这样的职位。但阿里巴巴的职位描述似乎和我们公司是完全不同的。就我的理解，在我们公司，测试架构师相当于其他公司的测试技术主管。而阿里巴巴的测试架构师，是给测试平台做软件架构的，是开发测试平台和测试工具的软件架构师。
 
    记得我刚到WiMax部门去做测试架构师的时候，很多同事觉得很好奇，说测试需要什么架构师呢？是啊，这个问题也困扰了我好久，因为架构师的称呼更应该给那些设计架构的人，而不是做测试的人。
 
    那么我就介绍一下我们公司的测试架构师应该做些什么吧。
 
    从职位的描述来看，这个职位似乎是什么都要做的。首先要分析新feature的内容，思考如何来测试这个feature，察看现在的测试设备是否到位，如果没有到位，要如何选择和购买。然后要参加现在正在做planning的那些feature的review，检查是否符合需求，覆盖率是否足够。还要帮助项目经理对新的feature做一个时间上的预估，和项目经理一起将feature拆分和分配。还要和质量工程师一起分析当前测试中存在的问题，思考如何改进测试方法，提高产品质量。还要帮助测试工程师解决测试上遇到的问题，帮助他们和其他测试部门及软件开发部门沟通，提高测试工程师的工作能力。等等。
 
    看到这个描述，哇，我的头都晕了。一个人能做完这些工作吗？想想以前无论是做软件开发，还是做测试，都觉得是很明确很简单的事，需要解决的都是技术上的问题，对该做些什么，如何去做，从来也没晕菜过。可是现在，首先连做些什么都成了问题。要知道，这些描述中，无论哪一件事要做好都是需要全心全意、全部精力投入的，这些事情都混在一起，根本不是我一个人能做完的啊。
 
    记得我在WiMax部门开始工作以后，我先跟着一个老员工开始学习测试。我以前没在这个部门做过，所以从最基本的测试开始学起。好在我做测试多年，学起来倒也轻松，升级固件、升级系统、安装测试工具、跑case，我很快就把这些流程摸熟了。通过和测试人员交流，我知道了不少这个系统目前存在的问题。一开始我很兴致勃勃地去参加架构师组和项目组的会，这也是对我的工作要求之一，就是要加强测试部门和软件部门的沟通。可惜去了一次以后我就不想去了，觉得他们讨论的东西太细了，似乎得不到我想要的东西，他们也不重视测试人员的意见，只是在讨论该如何测试的时候，才会想起测试人员来。我开始对这个系统存在的问题感兴趣了。从测试人员的反馈里，我得知大家对这个系统的架构不是很满意，也都清楚系统的瓶颈在哪里。可是当我把这些反馈反映给软件架构师的时候，却发现他们根本不重视这些问题的存在，反而寄希望于提高测试覆盖率来解决系统的问题。而当时测试部门对软件部门最大的不满就在于，他们总是把非常不稳定的软件拿过来测，让测试人员反复地纠结于最基本的功能测试，浪费了测试人员的时间。
 
    其实类似的事情在很多公司一直反复不停地发生着，就是项目进度的压力导致软件在做架构和设计的时候，没有考虑充分，匆忙上马，而管理者寄希望于测试部门来找到问题，解决问题。这是不可能的。测试部门有一句名言，叫“垃圾进垃圾出”。就是说，如果开发人员做出来的是垃圾，到了测试部门，出去的也只能是垃圾。作为一个测试架构师，我觉得我的首要任务，应该是和软件架构师及项目经理一起，把这个关系理理清楚。
 
    敏捷的鼓吹者总是喜欢压缩写文档的时间，其实这是很不正确的。大家如何看过《人月神话》就知道，一个产品的代码开发时间只占了1/6，而有一半时间应该用于需求分析和架构设计上。而对产品质量影响最大的，就是设计思想的一致性。记录需求分析和设计思想的方法，就是文档。这些文档不仅不能压缩，更应该越详细越好。我常常发现，后人在阅读设计文档的时候，总是对前人的思想摸不着头脑，不知道为什么这么设计，有什么好处。因为不知道设计思想，也就无从谈起设计思想的一致性了。一个不重视需求分析和架构设计，一开始就要写代码的项目，最后肯定会备受煎熬。需求分析文档和架构设计文档必须分开，而且都必须有非常正式的review，邀请所有的软件牛人、架构师及测试负责人参加。测试人员应该基于需求文档做测试计划。需求分析文档必须关注产品设计的方方面面，比如对产品的架构、效率、资源、稳定性、安全性等影响，架构设计文档必须明确模块对内对外的接口、系统资源的共享和占用等。
 
    我们的产品有外包的平台，验收测试是必须要做的，这一点几乎是空白。我们的合作伙伴也有一些验收测试，但是我们必须要看过他们的case及测试报告，我们自己也要测一下，并且根据使用中的问题不断增加验收的case。这不是在浪费时间。要知道，每个涉及到外包的问题，因为环节众多，都要浪费大家很多时间，还会影响到很多case的测试进度。可以考虑将验收的测试自动化。
 
    测试人员应该做什么，这也是需要明确的。我们的测试人员经常花时间在帮软件人员做测试，这是不对的。有的时候，软件人员改完了bug，会直接找到系统测试人员帮他们做测试，测那些仅仅通过了编译的代码。这是绝对要拒绝的。软件人员上传的代码必须经过模块测试的，模块测试也应该被不断地加强。当时软件部门号称自己的模块测试通过率有80%，可是这些测试都不测错误的返回值，这所谓的80%有什么用呢？
 
    理清关系本身就是一个很难的事情，项目经理们、软件开发人员，对测试如果没有一个正确的理解，沟通起来就很难。很多人认为，开发引入的问题应该由测试来发现，甚至连需求引入的问题也应该由测试来发现。这是不正确的。要知道，大多数的问题（60%~80%）应该在代码review和模块测试的时候被发现，否则功能测试根本就没有办法进行。而且，问题越晚被发现，代价越大。如果不重视代码review和模块测试，在后期发现不仅需要更多的时间，有些问题也很难被发现和重现。
 
    我当时还有一个任务就是和项目经理一起写一个check list文档，将所有需要考虑的问题列出来，给测试工程师在做测试计划的时候检查覆盖率用。这个check list文档涉及到了产品的方方面面，功能性的覆盖率检查应该从需求文档中引入，非功能性的覆盖率检查从产品的基本需求引入。还有就是feature和feature之间的关系，哪些需要放在一起测，哪些是互斥的，哪些互有影响，需要更多的case来覆盖。可惜的是，当时的需求文档并不完善，给测试计划定立带来很大的问题。
 
    我们当时很大的一个问题就是非常依赖于仿真器，因为基站的开发进度还在我们后面，我们不能用真实的基站做测试，基本上都是用的仿真软件。这一方面也给我们带来了便利，因为仿真软件比真实的基站要好控制和跟踪，但是也有一些问题，就是无法保证我们是正确的。因为仿真软件来自一个小公司，存在一定的不稳定性，我后来就领了一个任务去选择一些大公司的基站模拟器。基站模拟器，简单的说，就是模拟一个基站所有的行为和消息，对我们来说，就是要产生所有的消息组合及用户数据。我很想我们自己来做这个模拟器，这样我们不仅可以仿真基站，还可以仿真很多目前还没有商用的服务器，可以完全解决我们今后测试的问题。这是个很有意思的topic，以后再慢慢说吧。
 
    做一个测试架构师，似乎做了很多事，却没有一件是立竿见影的。有的时候，觉得自己没有以前做软件和测试时那么重要了。就好像温伯格说的，去指导别人洗盘子，没有自己洗盘子时的那种成就感，也不放心别人会和自己洗得一样干净（《咨询的奥秘》）。我觉得自己做的事情距离职位描述还相去甚远，还有很多事情想做而没做，我觉得好累也好迷惘，似乎没有精力去做到足够好。
 
    可是一个部门总是需要有这样一个人，去关心大家都不去关心的问题，去协调大家不愿去协调的事情，去宏观地考察产品的质量，指出产品的缺陷，去帮助大家改进产品的质量。这大概就是测试架构师应该做的吧。