测试架构师

转载自：http://blog.163.com/tech_qa/blog/static/130176349200991611173682/

在测试行业干了有些年了，如今中国带领一个测试架构师团队。回想当年干了一年软件测试后，发如今中国几乎没有什么软件测试的招聘信息，感到将来的迷茫。在迷茫中动摇过，痛苦过，甚至短暂离开过一线测试工做，但一直都仍是围绕着软件测试这条主线在工做和发展，也许命中注定应该走下去吧。从一个普通的软件测试工程师，走到了自动化测试工程师，系统测试工程师，测试咨询，测试服务，一个测试架构师，带领一个测试架构师团队，亲自领导和负责一个大产品线70多测试人员的测试技术规划和测试质量改进，所带测试架构师团队覆盖的测试人员达100人。

 

 

若是把测试的能力分为工程能力与研究能力，那么我在从事测试架构师以前的能力应该大部分都是工程能力，51testing上99％的文章应该都属于工程能力，传统测试活动更多侧重单个测试实现技术。而从事测试架构师后主要须要的能力应该是研究能力，更多侧重对整个产品或产品线当前版本，将来版本的测试技术规划和测试技术储备，攻关。从测试技术，测试质量角度推进公司质量的不断改进。

 

 

 

 

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

 

 

    最近看到1篇关于测试架构师介绍的文章，文章中的测试架构师原型来自微软，其描述的工做内容让很多国内的测试同业非常羡慕，但又以为好像离咱们中国人很远。不知咱们中国的测试工程师能作吗？个人答案是Yes。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

重点和难点两个词汇有时能表明一样的方向，有时倒是相差较远的方向。

 

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

 

因为项目中每一个人的分工不一样，所以不可能每一个测试人员一开始就能知道本身工做的商业目标是什么，因此也不用去责怪你们。但是领导产品的测试架构师不能准确的识别或培养其余测试工程师具有识别测试重点和测试难点的能力，那么注定这个测试团队的工做不但质量保障会打折扣，并且会浪费很多组织的资源和成本。

 

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

 

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

 

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

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

 

请继续关注后续测试架构师应该具有的能力系列：

 

第三篇“全面，多样化的产品经验”

第四篇“参与产品架构工做的能力”

第五篇“识别产品测试组测试技术需求的能力”

第六篇“为产品测试组提供测试技术解决方案的能力”

第七篇“测试技术解决方案的推广能力”

第八篇“与周边部门沟通配合能力”

第九篇 “创新解决方案能力”

第十篇 “领导力和影响力”

 

 

一网友邮件问我2个问题：测试架构师的价值怎么量化体现？可否用最少的词描述测试架构师对产品测试组支撑时最主要的工做目标是什么？

 

问题1回复：

你一切的活动提高产品线总体10％的的测试质量，10％的测试效率，你的价值就体现出来了。而不是亲自作一个测试工具，或是作一个测试工具的架构，那是测试工具架构师所作的工做。

 

问题2回复：

 

我思考后这样总结：“指明测试方向，提高测试质量”；

  

具体点：

 

1.把握真正的商业质量目标，拉通产品线测试技术规划，对产品线总裁负责，而不是只对一个产品负责；

 

2.树立最高的测试质量标杆，持续帮助产品测试组改进测试质量；

 

3.培养专项测试技术专家；经过培养和指导高级测试工程师来间接提高测试组的总体测试质量；

 

4.全部测试设计质量的把关；

 

更详细些：

 

第一步：本身独立分析每一个产品的商业目标；专家应该独立思考，才能帮助产品测试组走到正确的方向上；

 

 第二步：以商业目标规划本身的测试目标（测试重点）。思考要支撑商业竞争力，测试技术运做应该作哪些活动？

 

第三步：测试技术运做活动做为后续具体操做的目标：既要考虑短时间见效目标，1－2个月的工做重点Top3就能够了；又要考虑6个月内的工做重点；1－2年的长期工做目标。这样才会短时间利益和长期规划都能照顾到。不会让人以为你的工做太好高骛远。

 

第四步：规划如何支撑测试技术运做活动的人员组织架构；人员应该是来自产品测试组的测试技术骨干，他们既要负责好产品测试工做，又要能担负起整个产品线的某个专项测试技术的统领责任。这样在你的产品线中既不会失去产品测试支撑的主要目标，又不会失去跨产品统一规划的目标。要培养起各领域的测试技术专家，可是你又不能作“甩手掌柜”，你必需要指导和帮助这些专项领域的测试技术骨干能作好他所负责领域的技术规划，画出每一个专项领域中各产品间技术的依赖图，依赖图出来了，你的技术研究工做的时间计划也就出来了。

 

 第五步：就是执行你的规划。这时你另外一个很是重要的做用就要显现出来。你要树立每种测试设计的质量标杆，你对各种测试设计方案的质量要求，经过言传身教让高级测试工程师提高本身的测试设计质量尺度，从而提高产品组的总体测试设计质量尺度。

 

第六步：在测试执行活动中，你应该每周到一线了解测试活动开展的困难，测试组不肯意应用新测试技术的困难和缘由是什么？而后本身经过各类方法，如外部资源引入新的测试解决方案，不断解决产品测试组新测试技术应用的困难。例如：某产品未很好的开展单元测试和TDD，有领导认为是下面的人态度不行。结果经过一线沟通，才知道是由于开展单元测试要写测试代码，工做量太大，人力又不够，因此没怎么开展。那我就应该从技术角度思考如何解决这个看似是人力资源的问题。经过与某测试工具供应商交流，得知一种新的思路：测试用例自动生成测试代码的工具。这样就能够经过技术而非大量招人来解决产品组开展单元测试最大的困难：测试代码编写工做量大。单元测试天然就能够开展起来了。

 

第七步：测试架构师要常常抽查一线的各种测试文档，如：测试用例，测试报告，测试总结，bug报告等。这样你才能知道当前一线的测试活动质量存在哪些问题？哪些是测试组须要改进和完善的地方，从而也找到本身的工做的研究方向。