@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

　　第三章 人是软件测试的中心  《转载》

　　简单的职业经历

　　蔡：请介绍一下你的职业经历。你是一直在华为工作？

　　邰：对，我的职业经历很简单。硕士研究生毕业后，在华为从事软件测试工作11年。

　　旁观者说：从职业发展的角度来说，长期在一家公司工作和服务于不同的公司各有好处。换多家公司，可以接触到不同的项目和不同团队，见多识广。长期在一家公司服务，有利于经验和人脉方面的积累，增加获得更高职位的可能性。

　　我本科和研究生的专业是机械电子，都是在天津大学上的。2001年3月，我研究生毕业，当年4月9日，我进入华为工作，到今年（2012年）的4月9日离开华为，整整11年。

　　蔡：真是不容易，在一家公司服务了11年。这11年是一段丰富的经历，给我们介绍一下吧。

　　邰：回过头来看，这11年可以分为两个阶段。2001年到2008年做具体产品的测试。在这个阶段里，从测试执行，到测试设计，再到团队管理，也是一个逐步提升的过程。

　　旁观者说：有一个问题，也简单，也残酷，就是回顾自己的职业经历，问自己：它是不是一个逐步提升的过程？如果没有了提升，可能就是处于停滞状态了。

　　从2008年开始，我的工作内容发生了转变：从"负责某个具体产品的测试"转变到"负责帮助其他测试人员更好地做好他们的测试工作"上来。

　　当时正好我所在的测试部（华为上海研究所）和来自华为瑞典研究所的高端测试专家有一个TPI（Test Process Improvement）合作项目，而我也希望自己能够从管理路线转到技术路线上来，希望自己在做了七、八年的软件测试之后，能够系统地、深入地思考一下怎样把测试工作做得更好。我很幸运地参与了这个合作项目，并自此开始了测试理论方面的研究。

　　TPI的工作就是对现有的测试工作做评估，并给出评估报告，然后各利益相关人再根据评估报告以及项目上下文开展具体的测试改进实施。说实话，在参与这个合作项目之前，没有想过要做测试理论方面的工作和研究，身边也没有这个氛围。和来自瑞典研究所的专家接触后，才意识到了测试理论与测试实践相结合的重要性。

　　TPI合作项目持续了一年多，我从中受益匪浅。TPI项目结束后，我选择了一个当时问题比较多的领域"测试设计领域"，继续开展更深入的调查和研究，提出了一套测试分析和测试设计的框架：MFQ&PPDCS ，该论文在葡萄牙的ICSEA2009会议上得到发表。基于这篇论文，我开发了相关的培训课程，在公司内部讲过十几次，让更多的同事了解了自己的主张。

　　旁观者说：职业发展的路都是一步一步走的，我相信，在公司内部的培训经历对于邰晓梅后来成为独立测试咨询顾问是有帮助的。

　　2008年，我代表部门参加了ISTQB -FL的培训，觉得它不错，把测试方面的知识做了系统化的梳理。参考ISTQB大纲，结合华为的工作经验，我开发出了"软件测试基础"这门课程。参加这门课程的人来自于各个产品线，而不仅仅局限于我所在的无线产品线。我从事测试工程领域的研究后，经常会收到来自不同部门不同地域的求助邮件或者咨询电话，有的时候可能都分不清楚对方来自哪里。但是，没有关系，我愿意给大家提供测试方面的咨询和服务。能够被人所信任、所依赖，是价值的体现。

　　旁观者说：有的人可能怕做多了，心想这又不是我的职责范围；有的人则愿意为别人提供服务，被别人需要。

　　2010年和2011年，我到美国参加了三次StarWest/StarEast会议，收获非常大。回来后我做了详细的总结，觉得光是把从大会上学到的技术分享给大家，并不充分，我希望更多的同事也能感受到参会的氛围，感受到测试工作的激情，于是就开始组织策划公司内部的软件测试会议，这样的会议共举办了两届，每年参加的人数大概有250人。

11年华为工作经历中印象深刻的事情

　　蔡：在一家公司能持续工作11年，挺不容易的。在这11年里，有哪些给你留下深刻印象的项目或者事情呢？

　　测试并不只是发现bug

　　邰：这方面的事情自然很多，我举个例子吧。大概在2005年的时候，我带一个测试组做一个小型产品的测试。这款产品的主要功能是配置和维护，功能并不算复杂，但是是新开发的产品，从零做起。我们测试组有十几个人，大家的干劲都比较高。这是我第一次独立带团队做测试，也是既兴奋又紧张。我很看重这个项目，从计划、人员配置到团队氛围等，我都处处留意。

　　在我的带领下，我们测试组每天都能发现很多缺陷，开发改不过来了，因为新增的bug数量大于开发每天所能解决的数量，再加上开发团队还要做新功能，这样，就出现了测试压倒开发的"态势"。

　　旁观者说：测试压倒开发，与开发压倒测试一样，不是好的项目状态。二者应当势均力敌，互相制约，互相推动和促进，做出一个好的产品来。

　　整个项目进行期间，测试团队不可谓不努力，但是绩效却不好，也算不上快乐。这其中的原因是什么呢？当时百思不得其解。现在回过头来看，至少有两个方面是可以从中吸取教训的。

　　第一，当时的理念认为测试就是提问题单。现在很多人都知道，这是不对的，测试并不仅仅是发现bug，预防bug也非常重要。

　　第二，没有把开发和测试视作一个完整的团队，而是开发和测试分隔得太"开"。

　　在产品bug非常多的时候，我们没有想到去做缺陷分析，采取一些预防措施，没有问："这类缺陷怎么又出现了？我们能不能走到开发前期，去了解测试做哪些工作，可以帮助预防这类缺陷？甚至测试能不能帮助开发解决一些bug？因为未修复的bug已经堆积很多了"等这样的问题，不认为这些也是自己的工作职责。由于缺乏"预防测试（Preventive Testing）、完整团队（Whole Team）"的思想，测试只是一味地发现缺陷，而大量的缺陷意味着产品质量并不高，测试人员难免会有挫败感。

　　旁观者说：在实际的项目中，有的时候其实也能发现流程或者工作方法方面的一些问题，但是往往因为疲于应对工作，下不了决心来做改进。项目结束后的总结过程是很有必要的，让我们更加清晰地看到不足，制定出具体的改进办法。

　　更多的启发

　　如果深入思考，这个案例可以带给我们更多的启发。

　　第一，如果一个产品或项目有大量的bug暴露出来，作为项目管理者要注意了，这意味着项目本身有很大的改进空间，产品的质量不容乐观。

　　处理bug是很费时间的：测试提交一个bug，开发打回，说这不是bug；测试再打过去，证明这就是一个bug；开发修改后，不经过单元测试，就打给测试去验证；如果测试验证没有通过，还要打回给开发，开发重新修复，测试再重新验证……可以想象，成千上万个bug，如果每一个都要走这样的流程，单是解决掉这些bug就要耗费多么大的精力！每一个bug就是对系统的一次change，软件系统本身已经很复杂了，再加上成千上万次change，系统变得更加复杂，潜藏的缺陷有可能更多！

　　旁观者说：对于全新的功能，我在自己的团队有一个提法：剥笋子。软件的功能都是逐步完善的，在初期很容易发现这样、那样不对的地方，这个时候不要开过多的bug，而应该像剥笋一样一层一层来。先提交最主要的几个bug，开发修改了以后，测试人员得到新的build，再基于新的build提交另几个主要的bug。bug分清楚主次，提交的时间分先后，能够提高bug的有效性，也方便开发人员解决问题，提高研发效率。

　　第二，测试流程只起到辅助性的作用。

　　当时公司已经有了非常不错的测试流程，有很多测试工程方法可以使用，有很多测试文档模板可以选用，我认为只要认真遵守流程规范，就一定能做好测试。在某一个时间点，应该采用什么样的模板、出具什么样的测试文档、使用哪些测试工程方法、开展哪些测试活动、做哪些测试总结和缺陷分析等，我都一一照做，花了不少的时间。但是，遗憾的是，我虽然努力了，却没有抓住事情的本质，忘记了我们的第一目标是要得到一个可发布的高质量软件，而不是找到尽可能多的bug。

　　旁观者说：测试团队天生有想发现更多bug的倾向，有的时候绩效考核会起到推波助澜的作用。但是的确，按时发布质量达到标准的软件产品是任何"参战部队"的最重要的目标。

　　实际上，我现在认为，测试流程是一种启发式（Heuristics），遵守了流程，测试不一定就做得好；不遵守流程，测试也不一定就做不好。测试流程起到的更多的是一个辅助性的作用，而不是决定性的作用。所有的启发式都可以帮助我们思考。我们要学会应用（Apply）测试流程，而不是遵守（Follow）测试流程。

　旁观者说：让测试流程为我所用，而不是机械地遵循。

　　第三，做任何测试工作，首先要做的是Know Your Mission（知道你的任务所在）。

　　测试是一种服务，为我们的客户（包括其他各种角色和最终的客户）提供质量相关的信息。当我们接收到一个测试任务时，首先要做的就是了解客户是谁，客户期望得到什么价值，希望测试为其提供什么样的服务。有的朋友可能有这样的工作习惯，不管软件大小或者功能大小，一上来就动手测试，迫不及待地想提交bug。可是，如果不知道客户的期望是什么，则容易出现偏差。要了解客户在哪里，期望的价值在哪里。

　　旁观者说：我很赞同测试是服务的提法。记得几年前在一家企业做演讲，当我提出测试是一种服务的时候，就有朋友表示不理解，认为服务人员的地位太低了，这么说是看低了软件测试。

　　在社会生活中，从事服务的人员没有得到足够的尊重。其实每一个人都是平等的，只是从事的职业不一样而已。说测试是一种服务，并不意味着测试低人一等。在大的研发体系中，软件测试这支力量扮演的是服务的角色，为提高研发效率和提高产品质量而奋斗。

　　对测试认识的三个阶段

　　蔡：谢谢你的分享。虽然你的工作经历比较单纯，但我相信你在华为工作的11年当中，对软件测试的认识应该是变化和逐步提高的。

　　以bug、流程、人为中心

　　邰：是，我对软件测试的认识是有变化的。

　　在2008年之前，虽然我也一直在做测试工作，但是我的确思考不多。现在回过头来看，如果在成长的道路上有人时不时地指点一下，那真是一件值得庆幸的事，会进步很快。从2008年开始，我会经常浏览测试类的博客、网站，参加各种会议，多做交流，对测试的认识有明显上升。

　　旁观者说：找到自己的导师，虚心请教。有的时候经验丰富的人一句话，就能让自己少折腾几个月。

　　到现在为止，我对测试的认识可以大体划分为三个阶段。

　　第一阶段，以bug为中心。认为测试就是找bug，bug越多越好。这可称为原始阶段。在这个阶段里，一般都是拿到软件就开测，流程不一定规范，也没有想到要规范，只是找bug。

　　第二阶段，以流程为中心。在测试工作中，认为应该先定义各种测试流程和规范，认为只要follow这些流程和规范，就可以更有效、更高效地找bug，就可以做好测试。

　　第三阶段，以人为中心。认为测试是以人为中心。我现在也还在这个阶段。不再以流程为中心，把流程、模板放到边上，而把人放在中心的位置上。把测试工程师的能力和潜能发挥出来，这是比流程更重要的事情。

　　旁观者说：团队的核心就是人，团队管理者的主要工作始终是调动和保持员工的工作积极性。

　　注意：这三个阶段对于我个人而言是个顺序认知的过程，但不意味着每个组织都要串行依次经历这三个阶段，也就是说，不一定要先建立测试流程，才谈测试以人为中心的事情。

　　软件测试在没有规范的时候也能做，也能找到一些问题，有了规范之后你的测试看起来就会正式一些，但如果想把测试做好，就应该以人为中心。最近国内开始流行的探索性测试，就是以人为中心，充分发挥人的各项技能。

　　研究软件测试思维

　　认识到测试以人为中心后，我开始研究"软件测试思维"相关课题，这是一个很大的课题，不仅涉及测试领域的知识，还可以从心理学、社会学、人类学等很多领域获得启发，这个课题的研究我也是刚刚起步，目前开发了"认识你的测试思维"这门课程，旨在帮助学员认识自己的测试思维，以实现改进和提高。

　　我通过和不同的测试人员开展结对测试发现，在外部条件都相近的情况下，例如，在相同的时间内，相同的测试对象和测试环境，甚至相同的测试用例，不同的人却得到不同的测试结果。在测试工作当中，测试思维扮演着重要的角色。但是，对于大多数人来说，测试思维--你测试时是如何思考的--是在潜意识下发生，很难用语言表达的，所以为了提高测试思维，首先得认识当前的测试思维。

　测试深度图

　　为了把看不见的东西可视化地表现出来，我提出了"测试深度图（Test Depth Graph）"的概念。通过这张图，可以展现出学员测试思维的特点，例如，是擅长深入思考（Focused Thinking）还是擅长广度思考（Defocused Thinking）等。在观察的过程中，我会告诉学员，哪些地方他（她）做得很好，这样他（她）就会得到激励，对测试工作更有信心。对于不足，我也会提起，这样他（她）在下次遇到类似场景时就会有意识地提醒自己，去做改进。这样的事情反复几次，一个人在测试思维方面就会得到提高。

　　旁观者说：表扬就是一种正面的引导。

　　蔡：对这三个阶段的认识的跨越你都是在一家公司，你的职业生涯比较顺利。

　　邰：是，我比较幸运，相对还是比较顺利的。刚进华为时，我告诉自己，两年后我就离开。过了两年，我发现有很多东西要去学习。就这样，年复一年，不断地觉得有新的值得去学习的东西，我也在一路不断成长。当你一直在学习一直有收获的时候，就会感觉很充实。我喜欢这种充实的感觉。

　　重点测试技术

　　蔡：请你给大家介绍一下你认为重要的测试方面的技术，或者新技术。

　　邰： 所谓的新技术，是有context（上下文）的。例如ReqBT（Requirements Based Testing，基于需求的测试），我邀请了Richard Bender在ChinaTest 2012上做了介绍，有的朋友可能会认为这是测试新技术，其实作者提出来已经30多年了。新与不新，是个相对的概念，有的人感觉比较新，有的人则早就接触过了。

　　不同的公司也有不同的情况。对于有些公司来说，在时间、资源等很有限的情况下，ReqBT这样偏"重"型的方法可能就不适合，他们可能更需要类似于RST（Rapid Software Testing，快速软件测试）这样偏"轻"型的方法，RST是James Bach和Michael Bolton讲述的一门课程，侧重于如何在测试进度紧张、测试资源有限等条件下快速而有效地开展测试工作。所以，技术的应用或者重要与否取决于项目上下文。

　　人也是有上下文的。不同资历的人，看法会不一样。当然，如果只是年资的增长但是见识没有增长，这是自己要认真思考的问题。对于培养测试新手而言，我的观点是，并不一定一开始就要学习系统的软件测试知识，或者去学习测试新技术，而应当是多实践并且多思考。给他们一个测试任务，让他们去做。这对于新手来说肯定是个挑战，但是在这种情况下他们也会发挥自己的各项能力去做。当然，指导者也不是撒手不管，可以和他们一起结对测试，发现他们的不足，指导他们去做测试。通过实践，新人对软件测试的认识和兴趣都会得到提高，然后再去教他们测试理论知识，例如等价类边界值等，效果会更好。

　　旁观者说：邰晓梅这里提出来一个新的观点：对于软件测试，可以走先实践、后理论的学习路子。这里有新意，值得参考。对于公司内部转岗的情况，可以尝试一下这种做法，先直接做测试，然后慢慢回过头来学习理论。对于刚毕业的大学生朋友，因为需要找一份测试工作，先学习测试理论会有利于通过面试。

　　如何学习软件测试

　　蔡：你对于正在学习软件测试的朋友有哪些建议？

　　多实践，多思考

　　邰：我强调的是，不管你是在学校里，还是在公司里，要多交流，多实践。如果条件允许，最好找一个导师，项目里的最好，可以面对面交流，这对成长有很大的帮助。从我个人的体会来说，人与人之间传递信息最有效的方式就是面对面的交流，比看文档、读书、参加培训效果更好。

　　旁观者说：寻找导师，向周围的人学习。如果真能找到一位师傅，建立一种或密切或松散的师徒关系，收获往往很大。除了技术方面，思维方式和做事风格都是对人有很大影响的几个方面。

　　找导师往往很难，因为这是要双方愿意的事情。每个人对自己的师傅有一定的期望，有的时候你看准了一位师傅对方也不一定愿意来指点你。虚心请教，有利于学习和找到导师。

　　多实践，多思考。如果工作了七、八年，在软件测试方面的进步却并不明显，这是值得反思的：是不是自己思考不多？

　　三步法

　　如果你想学习软件测试，甚至成为测试的牛人，我们可以应用前面提到的Know Your Mission的方法思考这个问题。

　　第一步，请你描述自己的目标，你想成为什么样的人？是想写软件测试方面的著作，还是要得到公司的认可？目标要定下来。

　　第二步，如果想要实现这些目标，需要具备哪些技能和知识？也许你需要了解测试设计技术，也许你需要在某个方面很强，比如测试自动化、安全性测试、性能测试等。

　　第三步，如何掌握这些知识和技能？也许你要去学习一些相关的测试课程，浏览相关的网站，阅读一些测试书籍，思考总结自己的测试经验等。

　　归纳起来，这是一个What'What'What（目标是什么-需要什么技能和知识-做些什么以获取这些知识和技能）的过程。这3个What是一个迭代的过程，刚开始的时候对每一个What的认知少一点没有关系，循环执行这个过程，就会一步步贴近你的目标。

　　旁观者说：定一个目标何其容易，愿意一步一步、一天一天去实现它又何其难啊！

　　测试就是学习

　　我主张的一个观点是，Testing is learning（测试即学习）。谁的学习能力强，谁就可以快速地了解被测对象，快速地了解哪些区域bug比较多、风险比较高，从而把测试做得很好。一个人要想成为测试高手，需要具备很强的学习能力。如果只是资历高，但学习能力差，会很麻烦的。

　　（未完待续）

天猫 软件自动化测试开发