厦门安岭路网站建设,制作网页软件列表html代码,手机个人简历电子版,wordpress更换网页logo转载自#xff1a;http://blog.163.com/tech_qa/blog/static/130176349200991611173682/ 在测试行业干了有些年了#xff0c;现在中国带领一个测试架构师团队。回想当年干了一年软件测试后#xff0c;发现在中国几乎没有什么软件测试的招聘信息#xff0c;感到未来的迷茫。…转载自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.所有测试设计质量的把关 更详细些 第一步自己独立分析每个产品的商业目标专家应该独立思考才能帮助产品测试组走到正确的方向上 第二步以商业目标规划自己的测试目标测试重点。思考要支撑商业竞争力测试技术运作应该做哪些活动 第三步测试技术运作活动作为后续具体操作的目标既要考虑短期见效目标12个月的工作重点Top3就可以了又要考虑6个月内的工作重点12年的长期工作目标。这样才会短期利益和长期规划都能照顾到。不会让人觉得你的工作太好高骛远。 第四步规划如何支撑测试技术运作活动的人员组织架构人员应该是来自产品测试组的测试技术骨干他们既要负责好产品测试工作又要能担负起整个产品线的某个专项测试技术的统领责任。这样在你的产品线中既不会失去产品测试支撑的主要目标又不会失去跨产品统一规划的目标。要培养起各领域的测试技术专家但是你又不能做“甩手掌柜”你必须要指导和帮助这些专项领域的测试技术骨干能做好他所负责领域的技术规划画出每个专项领域中各产品间技术的依赖图依赖图出来了你的技术研究工作的时间计划也就出来了。 第五步就是执行你的规划。这时你另一个非常重要的作用就要显现出来。你要树立每种测试设计的质量标杆你对各类测试设计方案的质量要求通过言传身教让高级测试工程师提升自己的测试设计质量尺度从而提升产品组的整体测试设计质量尺度。 第六步在测试执行活动中你应该每周到一线了解测试活动开展的困难测试组不愿意应用新测试技术的困难和原因是什么然后自己通过各种方法如外部资源引入新的测试解决方案不断解决产品测试组新测试技术应用的困难。例如某产品未很好的开展单元测试和TDD有领导认为是下面的人态度不行。结果通过一线沟通才知道是因为开展单元测试要写测试代码工作量太大人力又不够所以没怎么开展。那我就应该从技术角度思考如何解决这个看似是人力资源的问题。通过与某测试工具供应商交流得知一种新的思路测试用例自动生成测试代码的工具。这样就可以通过技术而非大量招人来解决产品组开展单元测试最大的困难测试代码编写工作量大。单元测试自然就可以开展起来了。 第七步测试架构师要经常抽查一线的各类测试文档如测试用例测试报告测试总结bug报告等。这样你才能知道当前一线的测试活动质量存在哪些问题哪些是测试组需要改进和完善的地方从而也找到自己的工作的研究方向。转载于:https://www.cnblogs.com/lgqboke/p/6400891.html
