科技: 人物 企业 技术 IT业 TMT
科普: 自然 科学 科幻 宇宙 科学家
通信: 历史 技术 手机 词典 3G馆
索引: 分类 推荐 专题 热点 排行榜
互联网: 广告 营销 政务 游戏 google
新媒体: 社交 博客 学者 人物 传播学
新思想: 网站 新书 新知 新词 思想家
图书馆: 文化 商业 管理 经济 期刊
网络文化: 社会 红人 黑客 治理 亚文化
创业百科: VC 词典 指南 案例 创业史
前沿科技: 清洁 绿色 纳米 生物 环保
知识产权: 盗版 共享 学人 法规 著作
用户名: 密码: 注册 忘记密码?
    创建新词条
科技百科——欢迎光临全球最大的互联网博物馆
  • 人气指数: 2747 次
  • 编辑次数: 1 次 历史版本
  • 更新时间: 2009-10-24
方兴东
方兴东
发短消息
相关词条
体验设计活动收敛的11件事
体验设计活动收敛的11件事
情感交互
情感交互
响应式网页设计之年
响应式网页设计之年
交互设计师价值
交互设计师价值
交互设计初体验
交互设计初体验
产品经理必读九步法
产品经理必读九步法
菲兹定律
菲兹定律
移动应用十项设计原则
移动应用十项设计原则
情境化
情境化
Web设计8个趋势
Web设计8个趋势
推荐词条
希拉里二度竞选
希拉里二度竞选
《互联网百科系列》
《互联网百科系列》
《黑客百科》
《黑客百科》
《网络舆情百科》
《网络舆情百科》
《网络治理百科》
《网络治理百科》
《硅谷百科》
《硅谷百科》
桑达尔·皮查伊
桑达尔·皮查伊
阿里双十一成交额
阿里双十一成交额
王健林电商梦
王健林电商梦
陌陌IPO
陌陌IPO
最新词条

热门标签

微博侠 数字营销2011年度总结 政务微博元年 2011微博十大事件 美国十大创业孵化器 盘点美国导师型创业孵化器 盘点导师型创业孵化器 TechStars 智能电视大战前夜 竞争型国企 公益型国企 2011央视经济年度人物 Rhianna Pratchett 莱恩娜·普莱契 Zynga与Facebook关系 Zynga盈利危机 2010年手机社交游戏行业分析报告 游戏奖励 主流手机游戏公司运营表现 主流手机游戏公司运营对比数据 创建游戏原型 正反馈现象 易用性设计增强游戏体验 易用性设计 《The Sims Social》社交亮 心理生理学与游戏 Kixeye Storm8 Storm8公司 女性玩家营销策略 休闲游戏的创新性 游戏运营的数据分析 社交游戏分析学常见术语 游戏运营数据解析 iPad风行美国校园 iPad终结传统教科书 游戏平衡性 成长类型及情感元素 鸿蒙国际 云骗钱 2011年政务微博报告 《2011年政务微博报告》 方正产业图谱 方正改制考 通信企业属公益型国企 善用玩家作弊行为 手机游戏传播 每用户平均收入 ARPU值 ARPU 游戏授权三面观 游戏设计所运用的化学原理 iOS应用人性化界面设计原则 硬核游戏 硬核社交游戏 生物测量法研究玩家 全球移动用户 用户研究三部曲 Tagged转型故事 Tagged Instagram火爆的3大原因 全球第四大社交网络Badoo Badoo 2011年最迅猛的20大创业公司 病毒式传播功能支持的游戏设计 病毒式传播功能 美国社交游戏虚拟商品收益 Flipboard改变阅读 盘点10大最难iPhone游戏 移动应用设计7大主流趋势 成功的设计文件十个要点 游戏设计文件 应用内置付费功能 内置付费功能 IAP功能 IAP IAP模式 游戏易用性测试 生理心理游戏评估 游戏化游戏 全美社交游戏规模 美国社交游戏市场 全球平板电脑出货量 Facebook虚拟商品收益 Facebook全球广告营收 Facebook广告营收 失败游戏设计的数宗罪名 休闲游戏设计要点 玩游戏可提高认知能力 玩游戏与认知能力 全球游戏广告 独立开发者提高工作效率的100个要点 Facebook亚洲用户 免费游戏的10种创收模式 人类大脑可下载 2012年最值得期待的20位硅谷企业家 做空中概股的幕后黑手 做空中概股幕后黑手 苹果2013营收 Playfish社交游戏架构

测试设计师 发表评论(0) 编辑词条

目录

测试设计师编辑本段回目录

在多数软件企业,测试组在项目中的组织形式一般是1个“测试组长”+多个“功能测试工程师”,测试组长负责管理整个测试过程和测试质量,测试工程师负责编写和执行测试用例;做的比较专业的测试团队,还会配备1~2名“性能测试工程师”,1~2名“自动化测试工程师”。

这样的团队模型看起来似乎无懈可击,也许很多公司都把这样的模型作为努力的目标,可是在实际工作中,这样的团队真的能够达到最高的效率,能够最大限度的保证项目的质量么?

闲话少说,下面我就简洁的列出,这样的团队模型存在哪些重要问题:

功能测试工程师不懂技术,自动化测试工程师不懂需求,做出的自动化脚本质量较低,难以维护;或者需要花费极高的代价,才能做出让人满意的脚本;

测试组长的精力主要在测试计划的管理上,同时测试组长大都兼做“测试执行”,因此没有精力思考,如何改进测试策略;
大部分功能测试工程师对开发技术了解较少,对程序的内部结构和处理逻辑了解较少,设计测试用例(TC)一般依靠需求文档,因此测试策略单一,TC大都和真实用户行为一致,很少有一些针对性较强的TC

性能测试和功能测试之间缺乏交流,性能测试工程师难以获得性能的需求,功能测试工程师也不关注性能测试的过程。由于性能测试经常会要求开发组优化代码逻辑,而优化很容易引发功能的bug。这里,就缺少一个人从整体把握功能和性能的质量,衔接两方面的工作。

一般面临这些问题的,都是人数较多,分工比较细的测试团队。而人口多和分工细,就意味着沟通和管理的复杂度加大。要解决这些问题,就需要增加一个新的角色:“测试设计师”。

先说一下测试设计师的岗位职责:

首先,测试设计师对项目的质量负责。一旦项目发布以后出现了遗漏bug,测试设计师需要承担首要责任;
负责项目测试方案的设计,确定各种测试需求的测试策略,包括功能、性能、自动化等;
负责研究开发组的架构设计和逻辑设计,熟知程序的结构和运行逻辑,从而制定出更有效的测试方案,参与开发设计评审;
评审测试组的文档产出,全程跟踪测试执行过程,给予其他测试人员指导与支持;

说到这里,我们对测试设计师的主要工作范围有了一个整体的认识,下面,我再以时间的先后顺序,说明测试设计师在一个项目中,是如何工作的。

当项目开始做需求开发时,测试设计师就需要介入,熟悉产品需求。这时他可以对比同类软件产品,或者是公司历史上的同类项目,搜集一些必要的技术信息,做好准备。

开发组做设计时,测试设计师需要同时熟悉开发的设计,尽量指出设计的缺陷,同时,考虑测试策略(功能、性能、自动化),编写《测试计划》中“测试策略”一节。

由于测试设计师对系统的结构非常了解,所以收集性能测试需求和制定性能测试方案,都由他来做,之后可以交给性能测试工程师,后面的脚本制作,跟踪问题,都由性能测试工程师完成。

另一方面,测试设计师对需求的把握也比较好,所以他也要确定自动化测试的范围,并且完成自动化测试的设计文档和框架代码,然后交给自动化测试工程师。当自动化工程师和性能工程师在工作中遇到问题时,测试设计师负责解决。

这里不得不谈到,手工功能测试和自动化功能测试之间的关系,实际上,测试设计师需要为手工测试和自动化测试分别进行设计,但是这两份设计不是完全隔离的,而是有着紧密的联系,具体的内容,我们将在另一篇文章中讨论。

总之,测试设计师要评估测试的重点和测试的方法,找出系统最容易出问题的地方,制定出完整的测试设计方案,然后,全程参与功能测试工程师、自动化工程师,性能工程师的测试用例、测试脚本的制作过程,评审这些文档的质量,提供建议和支持。

当 开发编码完成,提交测试以后,测试执行开始,测试设计师要密切关注测试执行的进展,并且判断自己的测试设计是否合理,高效,一旦发现问题,快速进行调整。 测试设计师必须参与手工用例的执行,自动化脚本、性能脚本的开发,从而了解测试工作的质量。当然,参与的程度,视具体情况而定。总之,他不是一个脱离于项 目之外的人,而是当测试出现问题,他比谁都操心。

测试结束后,测试设计师需要协助测试组长完成测试报告,并对项目质量和测试的效果进行评估和分析。

在小型项目里(比如测试人员3-5人),测试组长和测试设计师可以由一个人担任;但是,在大型的项目,必须单独指派一名测试设计师,因为那时测试组长整天都会忙于项目进度的控制和与其他组沟通,没有精力来管测试的技术了。形象的说,这是“双塔”组合。

接下来,我们讨论一下,需要具备何种能力,才能担任测试设计师,我认为以下几点是关键:

两年以上测试工作经验,担任过项目的测试组长,管理和沟通能力出色;
能够独立完成一个项目的性能测试任务,不仅仅是会使用性能测试工具;
能够独立开发一个项目的自动化脚本,不仅仅是会录制回放简单的脚本;
能够大致看懂开发的设计文档,可以和开发工程师讨论设计文档,能提出设计中的缺陷
有较好的创新能力,能够定期在测试团队中进行技术创新,解决工作的问题,提高测试效率。

掌握一些编程技术,会使用公司的主流开发工具和开发语言,并能使用这些工具开发简单的应用程序(和公司的产品类似);

另外,测试设计师在测试团队中,也必须是一个虚拟的群体,他们要经常的交流,而不是各自为阵。他们需要经常针对测试工作中的问题进行讨论,寻找有效的解决问题的方式。

测试设计师在测试团队中的比例,应该达到10%,有些测试设计师还需要担任“测试组长”的角色。他们是团队中的技术核心,为团队解决实际问题,不断的进行创新,让测试团队更有活力。

如何修炼为测试架构师编辑本段回目录

  最近看到一篇关于测试架构师介绍的文章,文章中的测试架构师原型来自微软,其描述的工作内容让不少国内的测试同业很是羡慕,但又觉得好像离我们中国人很远。不知我们中国的测试工程师能做吗?我的答案是 Yes。
  因为,我现在就在中国带领着一个测试架构师团队。了解自己所在公司测试架构师团队的运作和工作内容(后续将陆续与大家分享),虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大,业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责,其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师,系统测试工程师再往上应该叫什么呢?最后参考软件开发的title,就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责,例如:领导负责一个产品线或一个大产品的测试技术规划,early testing,系统测试工程师的培养,与开发架构师一起设计和改进架构的设计质量,测试执行活动质量的审查保障,亲自指导重点测试方案的设计,为了不断降低公司研发成本而进行新测试技术研究实践和推广,基于风险的测试,基于模型的测试,安全性测试,兼容性自动化测试,分布式自动化测试,性能压力测试,需求测试等专项测试技术领域的研究,并支撑新领域重点市场项目活动等等。
  与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本,不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架,针对具体的产品特点,思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率,让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型,能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动:如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求),然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式,主要是亲自实践各种新测试技术后,再带着测试人员在实战中掌握相关的方法。
  我们大部分的测试架构师都是写过自动化测试脚本或程序的,只是现在的工作由于需要我们去思考太多的东西,所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师,由于负责多个产品,还要抽取产品间的共性测试技术,要建立起产品线的测试架构图,统一产品间的测试技术,统一测试方案的设计质量标准,需要具备更强的抽取共性的能力。同时,还需要能在短期内快速了解和识别影响产品成败的关键测试技术,因为并不是所有产品都是性能压力测试就是最重要的。例如:某产品线有9个产品,有的产品最需要保障的是可靠性(性能,可用性不是关键);有的产品最需要保障的却是可用性,而不是可靠性;有的产品最需要保障的是安全性,而不是性能;有的产品最需要保障的是可移植能力和可集成能力,而不是性能。那么相应的每个产品测试用例设计就会有所侧重,例如:对于重视可移植能力和可集成能力的产品,测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。
  因此,测试架构师必须具备的第一个能力就是:“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的,如果测试架构师识别错误了,那么有可能在需要重点保障的领域,测试技术和测试资源投入不足,导致最后产品的商业竞争力得不到支撑,得不到质量保障。例如:某产品对外宣传是业界可靠性最高的产品,可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中,对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中,该产品的可靠性得分却并不是第一,虽然性能是第一,但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。
  某美国公司的一款产品在传统行业中主要功能基本雷同,如何才能与类似产品拉开距离,突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长,因此为了缩短用户的操作时间,该公司决定在产品的可用性领域重点投入设计,核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中,构建了业界非常丰富的可用性测试用例,这些测试用例的场景超过了产品设计考虑的原有场景,并最终通过测试驱动设计,与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品,而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。
  所以,如果你的公司正准备招募测试架构师,请第一考评他的能力应该是他的商业理解力。具有该能力的测试工程师知道如何选择:做正确的事!确保事半功倍。而不具备该能力的测试工程师可以成为系统测试工程师,由他来保障正确的把事做好!

 测试架构师必须具备的第二个能力:“区分测试重点和测试难点”
  重点和难点两个词汇有时能代表同样的方向,有时却是相差较远的方向。
  为什么我要把是否有能力区分测试重点和测试难点作为测试架构师必备的第二个基本能力。因为,我曾在某产品线对测试活动的质量进行抽查时,与每个产品的系统测试工程师进行了沟通,发现只有一名有6年经验的系统测试工程师在我的的启发下,分清了自己所负责产品的测试重点和测试难点。而其他的系统测试工程师一直都把测试难点误当成了测试重点,作为他技术攻关工作的主力方向。甚至从来没有真正思考过什么测试技术才是自己所负责产品决定成败的测试重点,只是简单地把自己在工作中碰到的所不具有的测试技术都当成测试重点,其实很多都只是测试难点。的确,在某些产品测试难点和测试重点刚好重合。虽然某些产品测试重点在技术上并不难,但是却需要我们把测试重点部分的工作质量做到最佳,时间和资源投入最多,而不要把有限的资源投入到测试难点的工作中去。我很认同华为任正非对华为工程师的要求“要做工程商人”,我们其他公司的工程师同样应该以商业目标为自己的技术工作目标,不应唯技术论,越新的技术,越难的技术就越愿意投入。测试工程师同样要心中一直有一个目标指引着自己的所有技术工作方向。这个目标就是我测试架构师日记中第一篇谈到的“准确的商业理解力”告诉你的工作目标。
  由于项目中每个人的分工不同,因此不可能每个测试人员一开始就能知道自己工作的商业目标是什么,所以也不用去责怪大家。可是领导产品的测试架构师不能准确的识别或培养其他测试工程师具备识别测试重点和测试难点的能力,那么注定这个测试团队的工作不但质量保障会打折扣,而且会浪费不少组织的资源和成本。
  因为资源和时间是有限的,而完美工作的追求是无限的。因此,我们如何在有限的资源和时间下,保障基本的质量目标,并尽可能提升质量目标。就需要在分清测试重点后,优先针对测试重点目标进行系统地测试技术研究,测试技术攻关,测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级,放在最后考虑。
  测试架构师的工作应该牢牢抓住真正的测试重点来开展,甚至在整个产品测试组都方向错误时,要能从商业角度帮助测试组改变观点。那么当从测试经理到普通工程师都误理解了测试重点时,测试架构师应该如何来启发他们呢?我这里就分享一个案例吧:
  在一次到产品测试组进行测试活动质量抽检时。我们问测试经理,你们产品测试目前最大的需求是什么?他说是如何进行压力测试和性能测试,希望我们测试架构师团队能在此领域多给予支持。我心里知道:他所负责的产品特性核心不是性能和压力测试,但我没有反驳他。而是继续问他下一个问题:“你觉得会让你产品未来应用时商业失败的最大担心是什么?”他想了想说:“不能对客户的生产系统产生破坏,让客户的业务中断。”“依据我们的经验,与客户生产系统交互的模块虽然是个小模块,但是在其他产品上经常出现内存泄露的故障从而破坏了生产系统。那你针对该小模块做过哪些系统地测试?有无专门进行内存泄露的测试,因为内存泄露对客户生产系统的破坏最大。”我问到。这时此测试经理才恍然大悟,这个对生产系统质量影响最大的小模块居然没有系统地进行过深入全面的测试。我这时告诉他 “你之所以开始说性能和压力测试是你的重点需求,是因为你们组里没有在性能和压力测试方面的积累,有工作开展的难处,这是困扰你的困惑。但是你的产品形态的质量不是性能或所谓压力测试来保障的,而是需要不对生产系统产生破坏。因此,你唯一能破坏生产系统的那个小模块应该是你整个产品中质量最高的模块,也应该是测试最全面最深入的模块,你的技术力量应该主要投到这个地方”。后来,针对该小模块我们进行专项内存泄露的测试,结果发现了好几个内存泄露的大bug,这些bug每一个都是会导致客户生产系统中断的杀手。
  测试架构师不是团队中专门解决测试难点的专家,而是识别测试重点,并支撑测试重点工作的专家。“区分测试重点和难点的能力”不是测试架构师独有,系统测试工程师和测试工程师一样可以具有。与第一篇“准确的商业理解力”一样,第二篇要做的是:做正确的事。

参考文献编辑本段回目录

→如果您认为本词条还有待完善,请 编辑词条

词条内容仅供参考,如果您需要解决具体问题
(尤其在法律、医学等领域),建议您咨询相关领域专业人士。
0

标签: 测试设计师 测试架构师

收藏到: Favorites  

同义词: 测试架构师

关于本词条的评论 (共0条)发表评论>>

对词条发表评论

评论长度最大为200个字符。