测试技术管理(测试团队建设宝典new).ppt

1、测试技术管理 关志勇 Mail:,测试技术管理,前提 测试技术管理_理念 测试技术管理_技术观点 测试技术管理_团队建设 测试技术管理_测试管理 测试技术管理_研发测试流程 测试技术管理_组织架构 测试技术管理_体会收获,测试技术管理,前提 文档当中的所有观点都是建立在系统测试的层面去阐述 文档当中涉及的内容面较广，很多观点都是简略阐述，如果有兴趣可以下来展开交流 文中体现的测试管理观点没有门派之分，都是在实际测试管理工作当中的真实体会 文中观点需要根据不同的公司环境灵活运用 文中重复提到的观点就是精华当中的精华,测试技术管理,个人职业简介： 职业经历：网络通信公司、网络安全通信公司、互联网p

2、2p视频媒体公司、电子商务公司 测试产品经历：网络二三层交互设备、网络私有管理协议、国内第一个网络安全操作系统、计费网关、综合网络安全管理平台、国内第一款asic芯片防火墙、RMI多核防火墙、p2p产品测试、web应用产品测试、电子商务交易平台 管理过的团队：4人团队-50人团队（测试组长、测试项目经理、测试部经理、QC&QA部经理、QA总监） 接触过的管理风格：华为、中软、三一重工、IBM NPD、netscreen、juniper、北电,测试技术管理_理念,测试工作的定位 引用一位在美国硅谷网络上市公司从事超过10年测试工作的专业人士的话：“测试是一门科学” 引用一位网络大侠的话“测试是一

3、门武功，流程是套路、工具是武器，有简单的花拳秀腿，也有深奥的少林武功！测试好比战争，知己知彼，方能百战不殆！测试好比破案，精心推断，方能柳暗花明！有人说世界不缺少美，而是缺少发现，我看：其实软件不缺少问题，而是缺少发现！以精深的少林武功、用艺术工程的眼光、战争破案的缜密思维去发现软件世界“美”吧！” 测试工程师就是一个艺术家，把那些凡夫俗子眼中平淡无奇、简单的测试工作不断的加入各种不同的技术元素和方法，体现这份工作的深刻价值所在,测试技术管理_理念,培训的课程名称为什么叫测试技术管理，当前中国的测试行业现状是：纯管理没有技术背景的测试职业经理人很难获得成功；原因有3： 1、中国测试工程师有英雄

4、情结，以技服人是一种普遍的现象，没有测试技术背景的职业经理人很难有生存空间2、中国绝大部分的公司的管理流程体系和测试工程师的职业素养不足以保证测试管理指令高质量的执行3、中国的测试团队缺乏测试架构师，团队的测试技术方向缺乏舵手； 只有靠测试leader把目光定位于国际先进的测试技术，牢牢的把握测试团队的测试技术发展方向，不断的研究并应用新的测试技术，提高测试用例的深度和覆盖度，保证产品的发布质量，取得相关兄弟部门的信任，才能不断的实现测试工作的价值，向公司提交一份满意的答卷，才能获得更好的生存空间，不断的把测试工作做大做强、做深做透,测试技术管理_理念,续上 测试leader作为测试团队的领头

5、人，首先要领悟测试技术的境界，测试技术就像一门可以独步天下的武林秘笈。如果持有人成立一个武林门派，并且想跻身武林名门，那么其必须要把本门武功秘笈领悟达到一流武功的境界，否则其成立的门派不可能成立一流的门派，同理，测试leader如果把测试技术当作一门简单学科对待，那么他和他的团队未来的造诣也不可能很高 很多刚从事测试管理工作的leader对测试管理的工作定位比较简单：开会接受上级任务、开会向下级分配任务、收集测试结果、提交测试结果，这样不单会制约团队的发展，也会大大降低测试团队在公司的作用和地位,测试技术管理_理念,测试工作的战斗精神 情况1：我们当前团队的测试工作水平落后于国内一流水平 情况

6、2：我们当前的团队的测试工作水平落后于国际一流水平 我们的测试团队要营造战斗的气氛，我们的团队成员要有高昂的斗志，持之以恒的精神气，这样才能够迎难而上，在技术上追赶领先者 华为能够走出中国，战胜国际的电信巨头，立足于世界，其充满战斗气息的狼文化是关键 亮剑当中李云龙的部队形成超强的战斗力的原因就是部队注入了李云龙个人的精神气 狭路相逢勇者胜也是这个道理 一个团队如果能够塑造一种战斗的氛围，工作指令就像战斗指令一样执行，执行效果可想而知 在团队当中能从不同的个人工作中感受到到相同的追求、工作纪律和斗志，那么标志着团队的风格就形成了,测试技术管理,测试工作的4赢原则： 对公司有利 对团队有利 对下

7、属有利 对自己有利 对公司有利：所有工作（包括团队建设）必须要和实际测试工作结合起来，各项工作都对保证产品的测试质量有帮助 对团队有利：要形成技术储备和积累，聚合能量并分享之，促进团队整体不断进步，降低个人依赖性，减少离职人员的影响度实现“铁打的营盘流水的兵” 对下属有利：要创造一个好的平台，让员工在这个平台上面工作可以不断的获得提高（不单单是技术，也包括工作方法、测试的领悟、沟通交流等，综合素质方面的全面提高） 对自己有利：注意记录在实现前面3个目标的实现过程，积累宝贵的经验教训 只有4者都兼顾了，测试团队才能赢得广阔的发展空间，才能取得超出期待目标的成绩，团队才能形成核心战斗力 忽略了公司

8、，测试团队将失去发展空间，失去领导、兄弟部门的重视和信任，忽略了团队，团队将会异常脆弱，疲于奔命，忽略了下属，将会不得人心，忽略了自己，如果一个人对自己都不负责，何以对别人负责，会考虑自己，也显得自己不虚伪，更容易获得大家的信任,测试技术管理_理念,测试工作发展生存原则 现状 当前国内许多公司的测试工作都存在这样那样的问题：研发测试流程问题、测试人员水平问题、测试资源问题、测试的地位问题等等 现状的解决误区 心急求成：容易开发测试关系全面恶化 心灰意冷：容易导致测试工作越来越边缘化 解决建议： 先立足于解决测试队伍自身存在的问题，给出一份好于从前的成绩，再寻求机会解决外部问题，逐步扫除外部制约

9、测试发展的因素,测试技术管理_理念,续上 当前中国绝大部分it公司中测试和开发相比都是处于弱势，因此不能和开发起正面冲突，否则很容易被打压，永无出头之日 测试自身肯定存在一堆问题，这时候先把精力投在内部改造和建设上面更加有效，这样会为团队赢得更好的发展空间，对于已经正视自己的问题并且拼命改善和提高的人外部还能对其说三道四？ 测试工作的提升离不开开发和其他部门的全力配合，谦虚很重要 本人 在一家公司经历了3任cto，第一任是创业团队的技术元老，第二任是外归背景，第三任是国内优秀的职业经理人，我在这3任领导手下经历了由员工组长-测试项目经理-组建测试部任测试部经理的成长历程，最深刻的体会是先修炼好

10、内功，切忌不要把精力放在处理外部矛盾（比方说外部流程、公司流程、内部资源等，可以提建议，或者发力做容易水到渠成的事情，切忌生搬硬套强行推行）,测试技术管理_理念,续上 加强和开发经理的沟通，做他们的思想工作，多帮助他们，用自身技术水平的提高帮助他们提高工作效率，让他们逐渐依赖测试人员，信任测试人员，这样可以赢得研发领导/公司领导的眼球，获得更多的生存发展空间 多对其他有技术背景的部门如产品部、运维部、客服部提供技术支持和技术培训或者技术成果输出，获取他们的信任和认可，赢得发展空间 观察公司和研发体系的形势，及时洞穿潜在的稍瞬即逝的发展机会，主动出击把握好每一个有利于测试发展的机会，必要的时候还

11、需要自己创造合适的机会去争取测试的生存空间。审时度势，洞察机会对于测试leader来说至关重要 可以分析开发经理、cto有没有改革当前现状的决心，开会的时候列举开发存在的问题时尽量注意语气，以陈述的语气来描述问题，千万注意语气，否则日后的测试开发关系就很难维护，测试工作的开展和进步切忌破坏开发测试的工作关系，不要和开发当面发生冲突和争论，可以换个时间、换个地点、换种方式去解决问题，如果工作开展的目标开发经理不接受，可以从他身边的骨干开始做工作，或者去争取其他开发team达成一致，产生实际效果后，再来解决他的问题，条条大道通罗马,测试技术管理_理念,测试技术管理_理念,测试技术管理之奉献理念 在

12、团队管理当中奉献和收获是并存的（个人英雄已经是 一个传说，现在讲究的是团队作战） 一个人创造出来的经验和技巧总是存在局限性，个人的精力是有限的，把经验、技巧奉献出来，传授给自己团队的同事，并且主动推广应用在工作当中，这样你自己的经验和技巧可能会在实践当中的应用不断完善、不断扩展，这时候自己再坐享其成去吸收大家完善拓展的成果，何乐而不为呢。单凭自己的力量很有这样的收获的 从另外一个角度来分析：你在奉献自己经验和技巧的同时也令团队的战斗力增强，令自己的精力得以释放，可以站在更高的角度去分析自己的工作、研究新技术、创新管理手段或者把话精力开拓新领域 测试leader除了要主动从自己的上级领导或者技术

13、专家身上吸取所需外，其实下属也有很多值得自己吸取的地方：比方他们的工作执行细节、执行策略、对问题的见解 、沟通协调方法等。“海纳百川，有容乃大“,测试技术管理_理念,测试技术管理_理念,测试工作的监督 问题：一个团队的成绩直接和leader的决策能力和工作方法有关，对于一些刚走上领导岗位的测试leader来说，工作当中不可避免的经常犯错，在工作当中设立能及时发现错误并进行调整的工作措施非常关键 根据“三权分立”的思想，测试的组织架构当中必须要设立监督、监控测试工作执行效率、工作质量的组织或者岗位 如果公司的组织架构不完善，没有监督、监控测试工作的部门或岗位（或者监控、监督达不到预期效果 ），必

14、须要设法在测试内部创建这样的角色,测试技术管理_理念,续上 很多公司同时存在质量部和测试部，目前很多质量工程师往往对测试工作的众多问题往往没有实质性的指导和建议，比方说 ：“没有按照流程走”，至于走的如何其就不关注了；“有没有提交文档”文档写的如何、效果如何也不关注；不过也不能怪QA，除非其本身是测试专家或者资深的项目经理 测试部可以考虑在内部设立一个人或者让一个小组配合测试leader监督各项工作的执行效率和执行质量 测试leader经常需要把握大方向，如果事事俱细的话那其必然在整体把握上面会有所削弱，精力有限，左右不能同时兼顾 例子：因为某个项目发生调整，取消了测试团队，我把这个团队的测试

15、负责人调到系统组，完全执行技术监督、规划的任务，最终测试部的技术储备、团队建设的工作质量都取得了较好的成果，团队建设工作任务的执行性有了较大的进步，测试部经理有更多的时间在系统的层面上面去考虑团队的技术方向，同时在具体执行细节上面也可以第一时间获得真实的数据和反馈，经过一段时间的努力，测试部统一的工作风格基本形成,测试技术管理_技术,在技术上登高望远,照耀、守护着测试团队的技术方向,测试技术管理_技术,对于测试leader，测试技术创新、创新的技术的推广应用是其首要任务，必须要把技术创新和应用融入到管理工作当中 要把测试工作做好，高超的测试技术必不可少，测试技术有很广的范畴，我们测试团队要规划

16、自己领域的测试技术，这样才能有找准测试团队发展提升的方向,测试技术管理_技术,测试技术=自动化测试技术？ 我个人认为测试用例设计技术代表了测试技术；自动化测试技术提升测试工作执行效率的手段 测试技术终究要转化为测试案例，可以这样理解测试用例设计技术：产品需求细化业务和实现逻辑+产品实现技术（概要设计、详细设计、算法）测试手段（工具应用及反推）测试角度+用户场景+功能关联/依赖法+测试点反推法+bug反推法,测试技术管理_技术,续上 测试团队要打造属于自己的测试技术平台，就像武林门派必须要有自己的武功秘诀一样 这里说的技术不是单纯的开发技术、集成测试技术、自动化测试技术，而是团队统一的测试案例设

17、计理念； 中国的测试团队很少配备测试架构师，测试案例的设计基本都是测试工程师来完成，测试案例的设计水平直接影响版本测试质量，因此团队的测试案例设计水平至关重要，测试leader必须要根据自身产品技术特点不断总结提升团队的测试案例设计水平 目前很多团队对于测试案例设计的方法多少来源于网上或者某些书本上面，从本人工作体验来分析，这些方法其实很难运用在实际的测试案例设计当中，或者应用效果不太理想，因此测试团队必须要根据自身的人员水平、产品和技术特点确立适合团队执行的测试案例设计方法,测试技术管理_技术,续上 外面的世界很精彩，一个绝好的机会到来了，我们到了一个和现在决然不同的领域，上面提到的“产品需

18、求细化业务和实现逻辑+产品实现技术（概要设计、详细设计、算法）测试手段（工具应用及反推）测试角度+用户场景+功能关联/依赖法+测试点反推法+bug反推法”还有多少能发挥作用？ 需求细化的方法、技术分解的方法、测试手段反推法、测试角度、功能关联/依赖法、bug反推法还可以继续应用，但是需求本身、业务和实现逻辑、产品实现技术、测试手段已经不能继承使用了 真正可继承的是测试角度还有其他方法的本身，并且测试角度可以集成众多同事的智慧，让团队智慧应用在每个人的工作当中,测试技术管理_技术,续上 要想在测试行业当中长期立于不败之地，就必须要找出适合自己长期发展的测试技术路线，测试角度就是可以无限扩展的测试

19、技术 一个人总会遇到瓶颈，但是如果用适当的方式调用团队的力量就可以轻易突破个人的瓶颈，测试角度就可以突破个人在测试案例设计水平的瓶颈 不同人的年龄、性格、工作经历、生活经历、技术水平，其看待相同的产品会产生不同的测试角度，我们把这些测试角度收集起来供团队设计测试案例时使用，就能实现吸取大家经验智慧，从而突破一个人设计时候遭遇到的瓶颈 每个测试功能点都有其产生的思路（出处），功能点本身具有很强的功能特性，有很多配置条件的限制，比方说一个测试人员同时负责3个模块，每个测试功能点只对应于各自的功能模块，如果能把测试功能点的产生思路抽象出来，去除掉配置条件的限制和功能的特性，那么这种思路就可以在他负责

20、的其他模块应用，同时可以被其他同事在其负责的功能模块当中应用，甚至可以被其他产品应用，这些思路统称为测试角度,测试技术管理_技术,假设我们现在是5000元工资的技术水平，如果我们要甩开现在和我们处于同级水平的对手，要保持或者拉大达不到5000元水平对手的差距，要不断追赶在5000以上的对手；我们在进步，对方也在进步，我们并不比对手聪明，我们的时间并不比对手多，我们甚至也不比对手刻苦，那么如何实现上面的目标？ 我们要把测试角度写成checklist，这就是checklist思想 checklist就是把大家在设计测试案例的思路提炼出共性和特性，方便后面的人研究学习，也可以供其他功能模块其他产品编

21、写测试案例时借鉴 我们把团队当中不同成员的测试角度从他们的脑子里面提取出来，以文字的方式记录下来，并且抽象封装成日后可以在不同领域使用的测试角度 当你换到一个和以往经历过产品和技术完全不同的领域，封装好的测试角度将是一笔宝贵的技术财富积累,测试技术管理_技术,续上 checklist的共性和特性抽象出来后，要注意其可理解性和可推广性，我们在抽象出一个共性时，要根据其变化规律和定义范畴进行细化，比方说状态同步这个共性，其定义范畴有状态同步_时间（时钟），状态同步_标志位、状态同步_表项、状态同步_总线等，其变化规律有状态同步_进出，状态同步_主备等，变化规律和定义对于共性应用在不同的功能和产品、

22、不同的行业领域内的表现形式非常多，并且随着技术、环境、时间等条件的变化而变化，因此共性是通用的，特性及共性的变化规律和定义范畴是无限的！测试技术的深奥有一部分是体现在这里 有些测试角度是可以拆分或者细分的，没细分出一个就代表着相应测试点的增加 比方说兼容性测试，兼容性针对不同的产品可以细分出很多点，操作系统的兼容性、同类软件的兼容性、接口的兼容性等,测试技术管理_技术,测试角度举例1 事件 数据库分表测试 测试时发现因为此次分表把每月的数据分成上，中，下三旬分表储存。所以在查询客服人员工作量，无法一次查询出每月的全部客服工作量，需要分三次查询之后进行人工统计。而且金华那边的客服是通过该表的数据

23、来进行客服当月客服的绩效考核的。但是产品人员没有考虑到这一点 上面的事件和数据库的表技术有关，事件体现了要把3个表合成一个表的思想，可以考虑数据库关联表项为第一级测试角度，往下分析，这个事件表明了表项设计不合理，表项没有合并，第二级测试角度可以抽象为关联表项的合并/拆分，这是从事件本身抽象出来的角度，通过我们自身的经验，我们还可以针对数据库表关联功能进行抽象，数据库表关联的特性还有同步特性，从同步特性我们有可以联想到互斥特性，最终抽象出来的测试角度为数据库表关联-表合并/表拆分/表同步/表互斥 以后采用了数据库表关联技术的功能都可以从上述测试角度考虑，同时同步和互斥功能又不单单可以用作数据库的

24、表关联，还可以用在有状态特性的功能，有表特性的功能,测试技术管理_技术,Checklist思想的应用 当前很多测试思路已经融会在大家的实际工作当中，我们当前要采取的策略是要把大家的已有的测试思路融会进checklist里面，形成共享 checklist一旦形成，可以作为一个质量规范去强制执行，要求大家在设计新的功能的测试案例必须要参考checklist里面的每一项，形成记录存档，保证以前优秀的设计思路得以继承，使产品的测试案例的质量拥有一定的保证 Checklist并不只是应用在测试案例的测试思路收集中，其最基本的应用是事件checkpoint，可以针对各种工作事件的处理、各种工作规范来编写c

25、hecklist，比方说版本上线需要遵循的事项就可以编写成为checklist Cheklist思想还可以用到很多测试工作当中，比方说评审工作的checklist，可以指导如何开展一次成功的评审活动 Checklist思想比较抽象，我们如果要推广应用，很多时候的确先把当前工作当中属于checklist思想的内容整合起来，形成文档，这样便于理解和推广 Checklist思想的层次比较高，要推行，需要有测试架构师/测试leader跟进执行效果 ，用绩效杠杆来推动,测试团队建设_目标,测试技术管理_团队建设,测试leader要打造一个好的工作平台，这个工作平台能给团队中的成员带来综合能力的提升 我们

26、要用合适的方法把有共同目标的团队成员的智慧集中起来，团队当中的每个人都无私付出自己的智慧和经验，彼此共享各自的智慧和经验，这样团队成员的技术和能力的提升速度会远远超过单兵作战的提升速度，团队个人能力提升快了，相应的团队的战斗力也会有很快的提升，我们才能追赶国际先进的测试技术和测试理念，缩短差距 团队建设的工作贵在坚持、要根据不同的条件环境灵活调整方向和执行方法 华为的狼群战术就是成功的例子，一头狼不太可怕，如果是一群狼，那就。 如果团队能够把个人力量聚合起来，那么就会事半功倍 良好的版本测试质量是依靠整个测试团队去保证，因此团队建设工作必不可少 团队建设的工作思想尽量要让下属成员理解，但是每个

27、人的实际情况不一样，很难让所有下属都全部理解并执行（全部理解并执行应该是leader的工作目标，不能轻易放弃，要坚持）很多时候测试leader必须要在团队当中强力推行团队建设工作（把思想转化为执行手册或者模板），思想统一工作在接下来的时间再想办法去做（能完全理解团队建设思想的组员具备了日后成为测试leader的素质），思想统一是有效执行的最终保证,测试技术管理_团队建设,团队建设的内容(一切为了加速度) 技术文档库和交流社区平台建设（统一思想，沟通交流） 新员工培养流程及导师制度 监控机制的建立 考核机制的建立 培训机制和评审机制的建立 成立系统组,测试技术管理_团队建设,团队建设是为了让我们

28、技术、工作进步的加速度保持在一定的水准，团队建设不是简单的吃饭、K歌 内部技术文档库和交流社区平台建设 技术文档库的内容包括技术理解文档、测试案例/测试列表、测试角度checklist、各种方法、模板、报告、工作文档、技术文档、重点故障分析文档（内部、外部）等 交流社区平台的目的：文档存储和查找、文档质量审核、技术交流、文档任务监控 文档库是团队建设当中的重点，是团队技术积累、技术推广应用的平台 文档库存在于交流社区平台当中，交流社区平台有助于提高工作质量和工作效率，促进团队和谐 社区可以有文档库、部门公布栏、灌水栏、测试案例设计技术、集成测试技术、性能测试技术、自动化测试技术等等，可以根据具

29、体需求构建，平台建议采用web论坛/wiki方式,测试技术管理_团队建设,新员工培养流程及导师制度 新员工学习工作计划和提交成果 导师职责 技能列表 答辩 学习内容主要分为两个部分 公共知识技能培训-公司制度，企业文化、研发测试管理流程规范、工作方法、团队文化-由导师负责培训和提供资料。 专业知识技能培训-工作范围内和技术相关的内容讲解-由导师负责培训（或者导师联系其他更合适的同事来培训）和提供资料 导师的选取原则： 熟悉公司的规章制度、工作流程，熟悉研发体系、测试部的规章制度、业务工作流程 导师误区：导师必须在技术上面要强于新员工新员工的技术强于导师也很平常，这时候导师的作用就是尽快让他融入

30、到测试团队当中，尽快熟悉各种工作流程，令其尽快进入正常工作状态，把自身能力在工作中发挥出来,测试技术管理_团队建设,续上 技术级别评定和晋升的人必须要满足一定的导师积分 个人能力再强，工作表现再好也不能代替整个团队，一个人扛一个产品的时代已经成为历史，要通过导师制度，把每个有能力的人都变成一个导热体，不断的把自身的能量传递到其他人或者其他团队 导师工作一定要专注，要和绩效考核挂钩，切实体现效果 导师分为技术专业类导师和工作导师，都是通过新员工的技术数据（可参考红黑牌的维度）、工作成果（计划指标的完成情况）、答辩会的评分、工作相关兄弟部门同事的评价等角度来综合衡量 新员工答辩会可以帮助新员工成长

31、，有条件的话可以一个月举行一次 新员工要多输出技术文档和工作文档，如果有存在以前缺失的文档任务可以交由新员工去补漏，文档是我们有效观察新员工的眼睛,测试技术管理_团队建设,监控机制的建立 工作日志 工作分类（周任务、当天任务、版本测试工作、团队建设工作、沟通交流工作等） 工作计划（优先级别、时间安排、预期目标、完成标志） 任务执行（优先级别、开展时间、进度描述、结果、数据描述、收获总结） 工作评估：收获和不足（原因及解决方案） Bug信息（提交数量、回归情况、bug状态统计信息、提交版本质量评估、亮点bug） 工作周报（从工作日志当中提取） 月度总结（从周报当中提取） 年度总结（从月度总结中提

32、取）,测试技术管理_团队建设,续上 工作日志不是纯粹为了达到监控目的，工作日志更深层次的目的是为了让员工养成良好的工作习惯（计划习惯、跟踪、回顾总结的习惯），具备良好的职业素养 中国大部分的公司测试部的流程和公司的流程很不健全，对测试人员的要求不够严格，这样测试人员容易养成各种不好的工作习惯，对将来的职业生涯非常不利 工作日志虽然会耗费一定的时间，但是对其个人、团队以及公司而然都是利大于弊，如果我们节省了编写工作日志的时间，那么我们可能会失去工作效率 日志是leader和下属不可多得的一扇沟通窗口 我曾经问过我的手下：“如果取消了工作日志，你是轻松了还是放松了” 注意周报、月度总结、年度总结必

33、须环环相扣，不能各自为政，否则工作就会重叠，效率低下，计划和结果有偏差,测试技术管理_团队建设,考核机制的建立 考核的原则：做不到完全的客观和公平；简单操作为上策； 考核的目的：不是为了打分，不单纯为了突出先进鼓励先进，更重要的是让员工理解考核标准当中透露出来的工作原则和工作要求，在工作过程当中能够自己根据原则和要求系统性的主动的应对工作，而不是被动的接受指令，从而有可能达到预期目标甚至超过预期目标 考核很耗费资源，大公司的考核流程都是有专门的部门投入大量的工具去收集考核数据，最终还是会存在不满意的结果，因此一般的中小型公司的测试团队的考核更加不要片面追求公平和客观数据，最终不单达不到效果，还

34、会产生部门动荡 许多人认为考核就是自上而下的打分，我认为这种理解比较片面，举个例子：厨师带徒弟，如果他只告诉他每道菜如何做，而不告诉徒弟菜的特性和营养特性，不告诉它色、香、味的含义，那么这个徒弟就只会做师父教过的菜，哪怕菜的搭配稍微换了，色香味就不能保证了，更不用谈什么创新了，同理，测试leader也不应该只是打分，而是要让下属理解考核的原则，了解工作怎么样开展才能符合考核原则，才能拿高分 技术和工作的考核kpi维度的设定，很能体现一个测试leader的能力,测试技术管理_团队建设,续上 对于新组建的团队或者改进型团队考核的依据：突出发现自身存在的问题（技术层面、工作方法层面、工作策略层面、团

35、队工作层面等）及解决方案，突出相对之前工作的进步/亮点 考核的方法：采用能力/工作提升比较法，使用红黑牌的运作方式，用红黑牌的数量去比较得出排名，红黑牌的发放维度和尺度由测试leader根据当前的工作重点去把握； 测试工作的评价：测试人员的进步突出测试工作的进步；兼顾能力提升、工作结果的数据；要从多个维度去考虑红黑牌的发放，以各种形式的文档数据（技术理解文档的质量和作用、测试案例质量（深度、广度）和更新（数量、角度）、测试角度checklist的质量和数量、案例分析的深度和影响作用、工作建议的数量和影响作用、bug数据（外部故障、内部故障的数量、发现的思路和技术含量）、新技术的拓展及应用、技术

36、人员（开发、运维、客服等）的评价等去展现测试人员的进展、进步,测试技术管理_团队建设,续上 人的缺点很多，每补上一个就意味着进步，当你迷茫找不到发展的目标时，可以 舍远求近，从自身的问题修补做起。实行红黑牌制度，可以让leader和下属都正视自己的进步轨迹，也可以避开繁琐的考核算分制度，因为65分和70分的区别实在不好区分 黑牌制度具有相当的灵活性，其不需要制定永久的实施标准，可以根据当前项目管理存在的问题或者当前项目管理的需要临时调整红黑牌的发放标准，只要在一个考核周期内保持红黑牌发放制度的一致性，就不影响考核数据的一致性和公平性,测试技术管理_团队建设,实行红黑牌制度可以解决绝对数据不能解

37、决的问题，比方说新增100和测试功能点和新增80隔测试功能点的区别，我们的处理原则是看待数字后面隐含的深度、广度，比方说测试列表的新增点可以从以下几方面考虑：相应的技术理解文档的质量（通过红黑牌去控制，没有红黑牌就代表合格），需求的覆盖度（评审后通过红黑牌去控制，没有红黑牌就代表合格），测试角度的合理利用（日后有更好的参考可以修改扩充，通过红黑牌去控制，没有红黑牌就代表合格）、测试用例的更新和采纳的设计角度、bug的数量和发现的角度及采用的技术、新技术的应用（体现在bug数据和测试用例更新）等 红黑牌的绝对数量只体现在某一个考核项目的比较当中，不会因为某一个项目给予的红牌数过多而影响全局的考核

38、，这样保证了在某一个局部项目的红牌激励或者黑牌刺激作用不会有副作用（影响公平性），如果局部红黑数量很多，可能会有特殊贡献意义，这时候可以单独给予红牌奖励 红黑牌只能在项目或者小组内 的员工来实施,测试技术管理_团队建设,Leader要具备007的素质，文档就是007手中的十八般武器 文档对考核的价值：文档是一面镜子，可以让大家看到你对知识的掌握程度、对知识理解的正确性，相对之前个人的进步和收获等，文档是最好的交流手段或者交流 平台之一，写文档不只是为了传授知识和储备知识，它也可以让大家来指出你文档当中透露出来 的问题，促进你改进，它也可以肯定你在文档当中体现出来的理解广度和深度，肯定你的工作成

39、果，保持正确的发展方向 测试leader如何去衡量下属的工作能力、技术水平呢？传统观念都是参考内部bug数据和外部bug数据，这只是最终结果，如果结果是好的，那么我们可以自豪的去享受成绩带来的荣誉和实惠，如果目标结果不能达成呢？能不能在结果没有出来之前，在执行没有开始或者执行过程当中就可以发现存在的风险或者肯定工作的进展顺利呢？可以通过执行者提交的技术文档、工作文档去衡量分析，因 为文档可以体现执行者的技术水平和工作思路，这些文档内容都不会太多，leader花不多的时间就可以了解全局形势，预测风险，找到问题，及时部署解决，保证目标的顺利达成,测试技术管理_团队建设,培训机制和评审机制的建立 测

40、试部内部必须要建立固定的培训机制 培训要区分普及性培训和专项培训，普及培训可以弱化考核指标，专项培训要明确效果考核指标 培训工作包括技术答辩、测试技术培训、产品技术培训、产品培训、测试工具培训、流程培训、工作方法培训、业务知识培训、素质提升培训等 培训要重质量，不要追求数量，不要陷入为了培训而培训的误区 培训效果要以对实际的测试工作带来的作用来衡量，比方说带来的测试用例数量的增加、测试角度的增加、bug发现思路的增加、工作深度、广度的增加等 培训要注意收集问题，效果要追踪，要和测试leader的考核相结合 培训内容要不断更新补充，贴合实战，对于补充和更新应该用考核激励 培训制度和评审机制是实现

41、团队技术共享、技术进步的重要实现方式，只有形成了固定的机制，团队成员就会通过培训和评审获得技术和知识 对于绝大部分公司来说，内部培训和评审往往可以很快的提高当前面团队的测试技术水平 也只有开展了内部的培训和评审，我们才会有对外需求培训和咨询的需求/渴望，从而使团队的水平往更高的境界迈进,测试技术管理_团队建设,续上 测试部必须要建立完善的评审制度 评审工作包括测试需求评审、测试策略评审、测试方案、测试用例评审、技术理解文档评审、测试报告评审、测试角度评审、测试计划评审、测试流程、规范评审等等 评审必须要重视评审前的准备工作 评审讲解人员必须要引导评审会议人员的思维进入评审议题当中 评审结束后，

42、必须要有评审既要，要列出评审的目标和评审效果的对比，列出评审过程当中提出的问题并解答 评审的效果必须要和实际的测试工作挂钩，要使用红黑牌考核方式来监督评审工作 评审的有效意见和意见在工作当中的采纳都要用绩效管理的方式跟踪 评审和培训很容易陷于形式，时间花了，但是没有达到效果，久而久之，就完全变成应付工作了 要避免官话：培训效果不错，其实要追究效果不错体现在那，对测试工作能带来什么好处，没有培训、评审之前的情况是怎么样，培训、评审后的情况有什么改善（从测试用例的增加数量、测试效率的提升等维度衡量），这样才能够确实保证培训和评审机制健康的生存发展,测试技术管理_团队建设,成立系统组（系统组的最终目

43、标：代表着测试部最高的技术水平和技术发展方向，系统组的工程师能够在公司拥有和开发架构师一样的地位 职责 团队的技术规划（测试技能列表规划、测试环境规划、测试手段规划、测试指标规划、自动化测试技术规划、集成测试技术规划、测试用例设计技术规划、静态测试技术规划、测试平台规划、测试工作规范的规划，寻求瞄准外部先进技术等） 承担团队建设工作的推动和监督、审核，承担测试部内部工作的质量qa的角色（评审工作、培训工作、新员工工作、内部文档库和交流平台工作、流程工作、考核工作、新技术推广应工作、各种内部规范工作等） 各种技术相关工作的成果鉴定，具有考核打分权 平衡测试各个team之间的技术问题和工作问题 新

44、技术攻关、测试技术难点攻关、故障攻关 辅助各测试team丰富完善各自的测试武器（如测试工具等），让测试人员的价值能够得到很好的体现，跃过随便点点键盘鼠标就发现bug的时代 系统组必须要把握好团队的技术路线，技术路线要和国际水平接轨（先追求国内顶尖再追求国际一流），要通过各种途径去获得行业内国际先进的测试水平的定义，定位自己的团队水平，规划好发展路线，一步一个脚印去追赶先进 长远的眼光会令当前的测试工作路线既务实，又具有前瞻性,测试技术管理_管理,测试leader管理什么，管理目标是什么 管理技术方向路线和应用效果，让技术驱动人的提升，人驱动团队的提升，团队的提升驱动工作的提升 手段：指导系统测

45、试组，用系统测试组驱动各个测试经理去落实 管理绩效考核，让绩效驱动人的思想和行为习惯并融入在工作当中 手段：绩效指标要同时针对工作的开展过程和结果 管理思想统一，管理行动统一，确保各项工作任务上下理解一致、执行策略一致、执行过程规范 手段：通过日志、计划和开展策略、结果衡量理解去保证 管理平台：建立和优化测试工作的软平台（风格、规范、制度、沟通渠道、考核激励等）和硬平台（设备资源、工具资源、人力资源、其他部门的配套支撑资源等） 手段：把工作当中遇到的各种问题都记录下来，找原因，然后归纳总结成规范，最好形成一个工作执行手册,测试技术管理_研发测试流程,研发测试流程的原则：要先分析当前研发体系的现

46、状和发展趋势，确定开发经理/开发老大的态度，确定具备开展条件的流程 建立规范的产品研发测试流程是我们的理想目标，但是受项目时间、研发资源、大环境等条件的影响，很多工作我们不能完全走正常流程，很多流程当中规定的产品、开发应该做的事情可能无法实现，只要不涉及降低产品测试质量的原则，测试leader必须要根据情况灵活处理 比方说没有开发文档或者开发文档内容不够细致，测试人员可以主动通过询问开发人员的方式了解开发实现的技术细节，因为我们如果不了解产品实现细节，我们的测试质量无法保证，版本质量风险很大 研发提交版本没有附带版本说明文档，我们无法拒绝版本测试，这样会延误项目周期，我们不了解版本说明测试重点

47、就无法掌握，那么我们就可以口头沟通开发经理/开发人员获得我们所需要的版本信息 有些紧急工作得到领导的口头审批可以先执行，后面再补相关手续,测试技术管理_ _研发测试流程,测试内部流程：测试计划评审、测试报告评审、测试方案内部评审、新员工培养计划评审、测试需求内部评审、测试用例内部评审、各种工作规范、制度评审、测试checklist评审、测试阶段总结评审等 开发测试流程：立项评审流程、版本接收流程、版本管理流程、测试计划评审、产品需求评审、研发设计文档评审、集成测试评审、单元测试评审、内部bug处理流程、外部故障处理流程、产品发布流程、测试流程、开发支持培训流程、开发审核测试技术文档流程、版本自

48、测流程/持续集成流程等 我接触过很多种管理流程，如ibm的npd流程，华为原先的管理流程、三一重工的管理流程、中软的管理流程等，这些流程都必须要结合他们各自公司特有的土壤条件才能发挥效果，流程最终是为了保证工作当中问题能够顺利解决，在当前的条件下，我们可以参考其他公司的管理流程，但是具体实施、执行细节肯定要根据公司的具体情况来制定，所以不要迷信大公司的管理流程，不要生搬硬套，测试leader要具备根据公司、研发体系实际的情况建立起适合测试工作顺利有效开展的内部流程和研发测试工作流程的能力 流程是解决问题、达成目标的，不是用来敬仰和复制的,测试技术管理_研发测试流程,续上 流程是为了规范工作，提

49、高工作效率，当出现意外情况或者不可抗拒的原因导致流程执行中断，测试leader应该主动想办法用另外一种方式令流程跳过中断的环节，继续走到下一环节，这样测试才能赢得主动，体现自身的素质和价值，获得更好的生存空间 比方说和开发约定周三提交版本，但是到了周三却一直没有提交版本，这时候测试不应该抱着不给版本是开发的错不是我的错，而是应该站在项目大局的角度及时的询问开发经理，了解情况，及时调整原定计划，规避风险，拥抱变化 测试人员应该多站在公司和项目的角度去看待工作，不能单纯从测试部的利益去开展工作，这样才能获得公司领导的认同，从而获得更大的发展空间和发展机遇,测试技术管理_组织架构,组织架构的划分原则

50、：根据产品线结构、开发团队的结构、测试部职能、测试人力结构来决定 组织架构在分工方面是固定的，但是各组之间要打破壁垒，加强技术互动交流，加强团队建设工作，做好技术储备 人员之间可以在一定周期内相互调配，既可以让员工多学知识，避开思维定式，也可以起到人才储备的作用，降低离职事件带来的影响 人员调配动作的前提是有完备的执行指导文档和各类支撑文档，调动人员都具备导师资格,测试技术管理_测试执行,关注测试执行案例数量和bug发现数量的对应关系（特别关注major级别以上的bug数量） 关注测试执行过程当中测试案例增加数量和亮点 关注测试执行过程当中测试案例修改数量和亮点 关注测试执行过程当中新增加的测

51、试角度、疑难bug分析 关注测试执行过程当中技术理解文档新增、修改内容 关注测试过程当中新增测试工具的应用 关注现有测试工具的使用拓展 关注对别人经验教训的引用 关注给其他部门提的技术建议（如评审意见） 关注其他兄弟部门的评价 版本测试的执行质量依赖于团队成员个体的执行质量，成员个体的执行质量体现在其执行过程当中的细节，而细节方面可以集中通过上面提及的各种数据去衡量 不要只从一个角度去衡量工作，角度越多，疏漏的机会也就越少 比方说版本质量本身很差，bug数量多并不能代表测试质量 同样版本质量很好，bug数量少也不能说明测试质量差,测试技术管理_测试执行,根据版本遗留问题和发布时间的关系，如果没有收敛或者存在发布延迟，要及早预警 关注最后一轮版本测试的版本控制 关注测试执行过程的版本提交数量及版本质量 关注发现bug的趋势曲线和解决趋势曲线（整体和个人都要兼顾） 关注致命bug、严重bug的分析 关注版本功能指标、性能指标、稳定性指标、兼容性指标、安全指标等重要指标的测试结果 关注需求变更 关注代码修改的影响范围 关注代码的debug实现点 系统组关注各个team在执行过程当中的经验和教训，及时推广到全体 系统组关注解决各个team的工作难题，统一调度资源解决,测试技术管理_体会收获,测试leader必须要为下属规划好