测试架构师在很多公司没有这个定义,我只看到过我们公司和阿里巴巴有这样的职位。但阿里巴巴的职位描述似乎和我们公司是完全不同的。就我的理解,在我们公司,测试架构师相当于其他公司的测试技术主管。而阿里巴巴的测试架构师,是给测试平台做软件架构的,是开发测试平台和测试工具的软件架构师。
记得我刚到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,以后再慢慢说吧。
做一个测试架构师,似乎做了很多事,却没有一件是立竿见影的。有的时候,觉得自己没有以前做软件和测试时那么重要了。就好像温伯格说的,去指导别人洗盘子,没有自己洗盘子时的那种成就感,也不放心别人会和自己洗得一样干净(《咨询的奥秘》)。我觉得自己做的事情距离职位描述还相去甚远,还有很多事情想做而没做,我觉得好累也好迷惘,似乎没有精力去做到足够好。
可是一个部门总是需要有这样一个人,去关心大家都不去关心的问题,去协调大家不愿去协调的事情,去宏观地考察产品的质量,指出产品的缺陷,去帮助大家改进产品的质量。这大概就是测试架构师应该做的吧。
转载于:https://blog.51cto.com/debbie/528733