@import url(http://www.blogjava.net/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css); 勤奋是一条通往成功的路  《转载》

　　我的职业发展路径

　　蔡：谢谢文强接受我的采访。请相对详细地介绍一下你的个人经历。就我个人而言，我比较喜欢看人物传记。虽然我们不是什么大人物，但是每个人都是独特的，人生的经历都是宝贵的，其中或许有可以供其他朋友借鉴的地方。

　　按工号随机分配而进入软件测试行业

　　郑：我不是计算机相关专业毕业的，却阴差阳错地从事了与之相关的软件测试工作。1994年到1998年我在华东师范大学物理系上学，1998年到2001年接着在本校上了精密激光物理专业的研究生。因为大学与研究生专业都是理科，在整个7年学习期间基本没有上过计算机相关的专业课，因此IT基础很差，导致工作以后入门相对比较难。

　　2001年硕士毕业以后我应聘进入中兴通讯上海第一研究所。中兴通讯在上海有两个研究所：第一研究所和第二研究所，其中第一研究所的主要产品线是有线通讯。我在中兴通讯上海第一研究所的工作是软件测试，产品是园区宽带接入系统IPDSLAM，主要提供ADSL/VDSL的用户端接入。从时间上来说，在国内我算是做软件测试比较早的一批了。当时国内测试行业刚刚起步，测试工作并不受重视。说起来比较有意思，新入职一批新人，按工号排列，奇数的去做开发，偶数的去做测试（或者反过来，记得不是很清楚了），就是这么随机分配的。

　　努力学习软件测试

　　由于专业的原因，我的IT基础很差，甚至TCP/IP协议和IP地址/掩码等方面的知识都没有。不懂怎么办？我能做的只能是比其他同事更加勤奋努力。在工作之余，我拼命看书，同时多向其他同事学习。当时测试组加我只有三个人，两个做功能测试，一个做性能测试，我就是被分配做性能测试的那位。刚出校门，我对通信设备的功能都不了解，就要做性能测试，压力非常大。但是，没有别的路可以走，只能靠自己努力。当时所做的性能测试，主要是偏硬件的，要搭建大的测试环境，是个体力活，基本都是没有人愿意接手的工作。更苦的是，除了性能测试，还需要负责通信设备的EMC（电磁兼容性）测试，每次都是背着沉重的设备，乘公交车去其他公司的EMC实验室做测试，经常在外面奔波。

　　旁观者说：刚毕业后的第一份工作，不要挑工作内容。不管做什么，都是一种历练，像郑文强一样踏踏实实做下来。刚毕业的时候有冲劲，总想学习，没有家累，这些都是优势，能够弥补工作经验的不足。如果这也不愿做，那也不愿做，要享受老员工的"待遇"，等于在破坏自己的优势。一个人在公司总要有点优势。

　　就像前面说的，当时所谓的性能测试和EMC测试，都是最没有地位的工作，即使是在测试部门内部。为了使自己更多地了解产品功能和协议方面的知识，我在完成性能测试与EMC测试工作之后，就会拿一个本子，坐到做功能测试的同事边上，边看边记，不懂的就问。等他们中午吃饭和休息的时候，我就自己动手尝试操作，这个过程对自己掌握产品功能的测试帮助很大。

　　旁观者说：在这里，我看到了郑文强刻苦学习的精神。天道酬勤。

　　除了产品测试的任务之外，为了在公司内部引入一些自动化测试的内容，我开始尝试学习编程语言。没有一点编程的基础，怎么办？时间对每个人都是平等的，在不影响每天测试工作的前提下，我主动加班以获取更多的学习时间。那时候，每个月的加班时间都在40个小时以上。因此，很快熟悉了如何通过C++和TCL（Tool Command Language，一种通用的脚本语言，可以在各种平台上解释运行）进行测试脚本的编写。大概过了半年的时间，我不但在性能测试和EMC测试上是了解最多的，同时在产品功能测试方面也不逊色。因此，部门经理开始让我在技术上负责公司内IPDSLAM的总体测试任务和公司外OEM交换机的验收测试。

　　旁观者说：时间都是挤出来的。一个月加班40个小时，相当于给自己增加了一周。

　　旁观者说：机会来自能力，而能力来自于日常的学习和积累。

　　在2001年的时候，公司对测试并不大重视。当然这并不是单个公司的问题，整个国内的大环境就是这样，整个软件测试行业还是刚起步，流程上也不规范。项目计划主要是根据客户的要求来确定的，在项目进度与质量之间发生冲突的时候，往往先满足发布的时间要求，而牺牲产品质量。因此，对于测试人员，除了在公司内部有紧张的测试任务之外，还需要不断地去解决客户现场的问题，就是一个不断救火的过程。

　　在中兴通讯上海第一研究所的2年测试工作为我在产品知识领域打下了非常坚实的基础。这是合格的测试人员首先需要具备的一个技能--深入了解你的测试对象，它的架构、功能，以及客户是如何使用他们的业务知识的。

　　旁观者说：对软件产品了解到什么程度，测试才能做到什么程度。

　　学习好软件研发流程

　　2003年中，我第一次换工作，到上海贝尔-阿尔卡特继续从事测试工作。现在回过头来看，即使是在2003年，上海贝尔-阿尔卡特的项目管理、开发流程和测试流程都是做得相当好的。在上海贝尔-阿尔卡特公司内部，一个萝卜一个坑，不仅仅强调个人的能力，更注重团队的整体能力。上海贝尔-阿尔卡特的文档管理系统非常好，以前项目的所有文档你都能找得到，而且是正确的版本，同时针对各种测试工作产品，都会有相应的文档模板，以方便测试人员迅速了解每个文档中应该包括哪些内容。当时采用的开发模型是火车模型 ，即迭代增量的开发模型，针对产品有5年的长远计划，基本上是每隔半年会发布一个版本。

　　旁观者说：团队越大，项目越大，配置管理就越重要。

　　在上海贝尔-阿尔卡特，除了继续在产品知识和业务领域进行学习与实践之外，我将很大的精力花在了流程的学习上，包括PMP知识体系、开发模型、测试流程的主要活动、测试输入与输出文档等。在上海贝尔-阿尔卡特的几年工作经验，使得自己对整个研发流程都有了全局了解，也让自己可以更轻松地和不同的测试从业人员进行交流与分享。不同公司尽管其采用的开发模型和测试流程会有所不同，但是基本的测试知识体系都大同小异。

　　旁观者说：在一家公司工作，除了学到软件产品对应的技术外，不要忘了学习“软技能”，例如研发流程。
　去管人还是坚持做技术

　　在上海贝尔-阿尔卡特，我当时的目标是去做经理，简单地讲，就是去管人。周围的氛围大抵如此，大家基本都认为管人的经理有地位、有能力，当然也有面子。其间我曾经去UT-斯达康面试过，目标职位是项目经理。所有的面试流程都通过了，但是这个职位因为各种原因最终被取消了，我没有去成。这件事情让我深思，我问自己：自己真的喜欢做项目管理工作吗？自己真的适合做项目经理吗？是自己喜欢还是活在其他人的期望之中？深思和反省了一段时间之后，发觉自己并不是真的喜欢项目经理这样的职位，更多的是由于人家觉得这样是好的。经过这次反思，我给自己重新做了一个定位：发挥自己在测试领域的专长与经验，继续自己的软件测试技术之路。

　　旁观者说：做自己，而不是生活在别人的期望中。

　　上海贝尔-阿尔卡特是一家不错的公司，我在其中的几年最大的收获是：深入了解了软件开发流程、测试流程与项目管理方面的知识。这也是合格测试人员需要具备的技能。除了了解你的测试对象之外，你需要深入了解软件产品是如何开发出来的，开发与测试之间的关系是什么，主要的测试活动与测试任务，等等。

　　由于办公场所在浦东，离家太远，每天往返上下班需要2到3个小时。虽然公司有班车，但是每天在路上花费的时间太多。在2006年的时候，我犹豫、徘徊了很久，最终决定到离家更近的朗讯科技光网络有限公司，继续做我喜欢的软件测试工作。这样，我也可以更好地平衡工作与生活。

　　旁观者说：一个人最珍贵的资源是什么？时间。

　　在朗讯我做了2年多的测试管理职位，带领一个测试团队。在朗讯工作2年多后，也就是2008年年底，我主动向公司申请，转做测试技术岗位。我感觉自己的个人兴趣还是在技术上，我想专注在软件测试过程和测试能力改进等领域上，这样从管理岗位转到技术岗位有利于自己的发展，有更多的时间和精力去做自己想做的事情。

　　旁观者说：能够看清自己的兴趣在哪里，看清自己擅长的在什么地方，真是幸事。

　　研究测试技术和方法

　　在朗讯公司内部，完成测试任务之后，我将其他时间与精力放在了测试技术与方法的研究上面，提出了一些解决方案来不断提高团队内部的测试能力。例如，在测试用例设计与执行中引入了测试类型的概念；根据敏捷开发的特点，在测试团队中提出并引入了Pair Testing（结对测试 ）的概念；在测试用例设计中提出了"精简化的测试用例"的概念；在测试用例设计中提出了放射性思维，使得测试用例编写的工作量与测试人员创造性思维方面得到了很好的平衡。

　　旁观者说：提出新概念是一种创新，当然这不容易做到。

　　同时，我开始在公司内部更广泛地参与测试相关的活动。2011年和2012年分别参加了公司中国区第一届和第二届技术大会，并做了主题演讲。积极参与公司内部的软件测试社区建设，并在公司内部推广测试知识、测试技术与方法、测试管理等方面的培训与分享。现在非常明显地感觉到公司对软件测试的重视程度在不断提高。

　　到现在为止，我在朗讯的工作时间已经有7年了，在软件测试方面给我最大的体会是：不管多好的测试理念、测试技术与方法，我们都需要和实际测试工作结合起来，不断提高测试效率和有效性，不断提升测试质量。这是合格的测试人员需要具备的技能。

　　旁观者说：让理论经过实践的检验，落地，形成适合自己公司和团队的做法和经验。

　　我在测试行业工作已经超过11年了，我感觉是在更深入地了解测试的内涵，更愿意将当前的状态看做是超越自己的一个起点。坚持去做自己喜欢的工作，不断积累、总结和分享，相信每个人都可以成为领域内的专家。

　　旁观者说：11年的积累，仍然看做是一个新的起点，值得学习。

　　跳槽时要考虑自己的兴趣爱好

　　蔡：一个人跳槽的时候要有哪些方面的考虑呢？

　　郑：首先，从大的方向而言，我不鼓励经常跳槽，特别是在没有职业规划的情况下，仅仅因为待遇、人际关系等原因而匆匆下决定的跳槽。从个人的发展机会而言，在一个公司待的时间久了，可以获得更多的机会，俗话说"伟大是熬出来的"。当然行业也很重要，要注意自己知识和技能的持续积累。假如真的决定要跳槽，那么下面几个方面需要仔细考虑。

　　旁观者说：跳槽会有新的机会，同时也会付出代价。在做决定的时候，要看到两面。

　　第一，跳槽要考虑自己的兴趣爱好。做自己喜欢做的事情，尽管钱也很重要，但是为了涨一些钱就跳槽，甚至为此去做自己并不真正喜欢的工作，并不见得是一个明智的选择，同时很难一直坚持下去。我自己就是一个例子，在2005年准备换工作的时候，我心仪的职位是项目经理，感觉特有面子和地位。但在求职失败之后，我重新审视了自己：去做自己喜欢的，还是去做人家喜欢的？最终我选择了前者。从目前的结果看，感觉到自己在公司内部可以做的事情更多了，参与的活动也在增加。不管对公司还是对个人，体现的价值都是在不断增加的。

　　旁观者说：在公司里工作，我们难免会被安排，而不一定都遂人愿，但是在发展的大方向上，还是要自己定。

　　第二，如果兴趣爱好能和自己的优点结合起来，那么跳槽就会更加理性。认识自己的优缺点实际上是挺困难的一件事情，"当局者迷，旁观者清"。还是以我自己为例，我的优点是勤奋、专注于技术能力。因此我更适合有条理地工作，自己计划和控制时间完成每一件事情，而不太适合每天参与各种会议、讨论与协调工作。所以，从这个层面而言，我更适合去做测试技术方面的工作，而不是测试管理工作。假如你认定自己的性格并不适合做管理工作，那就不要强求，否则不仅自己痛苦，整个团队也痛苦。

　　旁观者说：去认识自己的优缺点。一个人要想认清自己其实并不容易。

　　第三，跳槽需要和自己的职业规划相一致，不要乱了方向。假如有了明确的职业规划，清楚实现职业发展需要具备哪些方面的技能，那么在跳槽的时候就会考虑如何更快地掌握这些技能。记得我在中兴通讯上海第一研究所的一位同事，原来是做测试工作的，但是其职业规划是做项目经理。项目经理不仅需要了解测试工作，而且需要了解整个软件开发流程和管理工作。因此，除了平时积极学习项目管理方面的知识外，他在第一次跳槽的时候，找到了一个软件开发的职位，目的就是为了获取软件开发的实际经验，待遇方面考虑得比较少。在软件开发方向工作3年以后，他再次跳槽，如愿以偿地得到了某个公司项目经理的职位。由于他不仅了解开发工作，而且了解测试，同时这一结果又符合自己的职业规划，因此目前他的工作状态是非常有激情，这对公司、对个人都是一个不错的结果。

　　旁观者说：目的非常明确的职业发展路线，值得学习。

　　第四，在考虑跳槽的时候，也需要考虑公司的企业文化、团队氛围、个人在公司内的发展空间等，例如，公司离家是否方便，公司是否经常加班，公司是否等级森严，公司是否鼓励员工个性化发展等。

 

印象深刻的从巴西到上海的项目转移

　　蔡：请谈一下让你印象深刻的项目。

　　郑：从事软件测试工作超过11年了，经历的大大小小的项目超过了几十个，有成功的，也有失败的。不管是成功的软件项目还是失败的，我从中都学到了很多经验和教训，其中印象最深的项目是2006年从巴西成功地将IPAFM/AFM项目转移到上海。该项目的主要功能是为电信运营商提供宽带接入系统，分别提供IP的上行链路和ATM的上行链路，客户端的主要接入手段有ADSL、ADSL2+、PSTN、100M电口/光口等。

　　公司从成本方面考虑，2006年的时候希望将该项目从巴西转移到上海，包括相关的资源、知识、工具等都转移过来。作为该项目的测试负责人，我面临多项挑战，例如，产品相关文档、知识、技能和资源如何有效地转移到上海研发中心，新团队对该产品功能缺乏经验，在有限的时间与资源下如何开展有效的回归测试，如何测试新的功能，等等。

　　面对面的沟通是重要的

　　为了提高产品转移的速度和效率，公司派了几个人到巴西出差，为期一个半月。面对面的沟通对于项目转移非常重要。我们积极参加巴西研发团队针对我们的各种培训和讨论，深入学习产品相关的功能与业务知识。我们尽量多地收集需求文档、开发文档和测试文档，包括原来测试团队在前面项目中测试的经验教训等，熟悉软件环境的搭建和配置，包括测试仪表的使用、测试环境的基本配置等。由于巴西测试团队的鼎力相助，整个测试知识和技能的转移非常顺利。

　　旁观者说：即使电话、QQ、微博等各种沟通方法很方便，也取代不了面对面的沟通。见到“真人”的感觉是不一样的。

　　毫无保留地做分享

　　回国以后，我们的任务是将学到的知识与技能在整个测试团队内共享。在共享过程中，我印象最深的是大家毫无保留地将自己学到的知识和技能分享给团队中的每个人。

　　只要是我懂的，我会主动在团队内进行分享。我会主动给每个成员讲解功能的工作原理，如何搭建测试环境，如何执行测试步骤，如何判断测试结果等。只有掌握了测试对象的业务和测试知识，他们才能顺利完成任务。而对于我来说，整个项目测试的管理与监控也会比较容易。同时，由于测试成员都能学到新的知识，也可以增加他们在团队内的凝聚力。

　　作为测试的负责人，不要期望自己在所有的方面都比其他人强，你的定位应该是为整个测试团队服务。如果你能在团队内带头分享自己的知识与经验，也一定能带动其他人分享，更好地做好测试团队的知识与技能的储备，有利于测试经理更好地分配测试工作，并做好备份工作。

　　旁观者说：管理者要成为团队的核心、精神领袖，并不是什么都要比别人强，更不能去压制别人的“强”。

　　有的人不愿意分享，是担心别人超过了自己。从实际来看，你今天分享了经验，同事仍然要花一段时间去消化，并不是说，你一说大家就都到了你的这个程度，还是需要实际操作和慢慢体会的。在这段时间里，你可能又学会了新的东西，所以不必过于担心。你经常做分享，大家也会因此而尊重你，这对于你在团队里立足是很有帮助的。

　　旁观者说：管理者要鼓励大家分享，甚至可以把分享算入绩效。

　　回归测试不能流于形式

　　测试的工作量主要集中在回归测试上面，因此，如何选择合适的测试用例是我在实施整个测试工作中的重点。我们考虑到的重点是：什么功能是客户最经常使用的；哪些功能对客户而言是最重要的；哪些功能在以前版本中发现的缺陷是最多的；针对新增加的功能或者升级，对原来的哪些功能和模块的影响是最大的。

　　回归测试不应该是流于形式的，应该制定严格的回归测试过程，包括软件变更分析、软件变更影响分析、定义回归测试策略、定义回归测试套件、执行回归测试套件，以及报告回归测试结果等。

　　旁观者说：常见的做回归测试的几条依据：按照功能的重要性来做；按照bug来做；按照新功能（即变化量）来做。这几条标准往往是同时运用的。

　　推动开发和测试的规范化

　　我们需要对每个增加的功能、升级修改的功能进行详尽的需求文档化，作为后续开发测试活动的参考和基线。这样，可以在后续的开发设计、测试设计等方面拥有共同的输入和参考点。这对于系统的研发非常重要，这个环节没有做好，项目的开发将一直处于混乱状态，例如，系统需求不明确、开发条目不清晰、测试输出预期没有标准等，无法保证项目产品的质量。所以，我们和开发一道，推动整个后续开发、测试的规范化，有助于整个测试的顺利完成。

　　简单而言，项目成功转移的关键点是：沟通、分享、合适的测试过程、开发与测试的紧密合作。

　　旁观者说：表面上开发和测试为了bug会有争执，其实两股力量的目标是一致的，都是想做出好产品，所以紧密合作是有可能的，也是应该的

 

成为优秀的测试工程师：勤奋、努力、坚持不懈

　　蔡：如何成为优秀的测试工程师呢？

　　郑：优秀的测试工程师，不仅需要时间的积累，也需要测试知识、技能和测试经验等的持续积累。要想成为优秀的测试工程师，至少需要从下面几个方面不断地充实自己。

　　第一，深入了解测试对象，即测试人员需要深入了解被测产品的架构、功能与业务知识。对于我自己，我一直从事的是宽带接入系统与交换功能，因此掌握ADSL、VDSL、以太网交换功能、L2协议标准、三层交换功能、OAM功能等是开展各种测试任务的基础。

　　第二，熟悉研发流程，即知道在什么时候应该做什么事情。测试人员需要了解每个开发阶段的输出是什么，测试的主要活动与任务有哪些，只有对测试过程中的各种活动与任务了然于心，测试人员才能主动去完成任务，而不是每次被动地等着测试经理给你分配任务。另外，了解每个阶段可能存在的问题，可以提前制订应对计划。

　　第三，除了知道测试过程中我们需要做什么之外，测试人员需要掌握如何有效地去做，因此需要测试人员深入了解各种软件测试技术与方法，例如：测试用例设计技术与方法、测试估算方法、测试风险识别与评估方法等。

　　第四，培养各种软技能，例如沟通与合作。现在更强调整体团队运作过程，测试人员不仅需要和开发人员沟通与合作，也需要和客户紧密合作。另外，测试人员还需要培养专业的怀疑态度、严密的分析能力、处理冲突的能力、严谨的工作态度与创新能力等方面的技能。

　　想成为优秀的测试工程师，勤奋、努力和坚持不懈是非常重要的。

　　猜数字游戏和探索性测试

　　蔡：什么是探索性测试？

　　郑：探索性测试（Exploratory Testing，ET）是Cem Kaner在1983年提出的，是软件测试的一种方式。与脚本化测试（Scripted Testing，ST）相比，探索性测试将更高的认知水平放在了测试执行上面，同时更加强调测试人员学习、设计、执行与结果分析等测试活动的并行、相互反馈与相互支持。

　　很多人都玩过猜数字游戏：我预先在心里想好一个1到100之间的数字，你来猜。你可以问任何问题，而我只有两种回答"是"或"不是"。然后通过你的不断提问与我的不断回答，最终猜到我心中想的数字。在猜对的情况下，问的问题越少得分越高。这就是一个典型的探索性测试的例子。测试人员需要根据前面问题的答案分析和设计下一个问题。第一个问题可能不靠谱，但是根据前面问题的不断反馈和结果分析，你设计的问题将会越来越靠近问题的答案。假如参与者了解二分法，那么最多7次就可以猜中数字。假如不了解二分法，你也可以猜到数字，但是尝试的次数可能远多于7次。你的策略、技术与方法，直接决定了你完成任务的速度与质量。

　　探索性测试的过程与猜数字游戏的过程是类似的。游戏中你要猜的数字，就是你要寻找的缺陷或者其他质量信息；你要问的问题，是你分析和设计的测试用例；每个问题的答案，则是测试过程中测试对象的输出。测试人员面对一个被测试的功能，首先对它有个模糊的概念与范围，然后不断地分析、设计和执行测试用例，观察测试对象的输出和反应，并以此为基础判断下一步的测试用例，获取缺陷或者其他质量信息。

　　由于探索性测试的不断探索、不断分析、不断反馈的特点，它可以较好地解决脚本化测试中的一些问题，例如，脚本化测试强调尽早的测试设计，但是测试设计越早，测试人员对测试对象的了解越少，对风险的了解越少。测试人员对测试对象的了解是一个逐步的过程，脚本化测试需要更多的工作量以应对这个过程（需求的细化和变更等）。

　　与脚本化测试相比，探索性测试更强调测试人员的思维自由度与主观能动性。然而，探索性的自由，并不代表它是不做准备的，它也不是随机的。好的探索性测试依赖于测试人员综合应用测试策略、测试技术与方法的能力，例如，获取测试数据，掌握测试设计技术，建立失效模式，创建测试模型等。口号式的探索性测试并不能帮助测试人员成功。探索性测试如下象棋，规则不多。但是我们在欣赏象棋比赛的时候，关注的是在这些规则下选手选择下一步如何走的技巧与技能，它的技术含量也不在其规则，而在选手的技巧与技能。规则简单，技巧复杂。

　　旁观者说：探索性测试的基础是对测试对象的熟悉。

　　尽管探索性测试可以解决脚本化测试中的一些问题，但我并不认为探索性测试优于脚本化测试，或者将来会谁取代谁的问题。它们之间各有所长，作为测试人员，我们应该做的是根据测试对象特点、组织特点、资源特点等具体情况，如何更好地发挥两者的各自优点，弥补两者的不足。

天猫 软件自动化测试开发