随着公司组织架构的调整，战略调整，产品的实现技术不断变化，现在的测试人员可以说是什么都可以干。

    有些人做产品，有些人做平台，有些人做工具......

    有些人有点象专职开发，有些人有点象专职运营......

      Facebook,google的一些敏捷测试理念中，测试人员应该致力于提出测试解决方案，研究各种测试工具为主，具体的测试执行工作，由coding的开发同学去做。

    变化后面也有很多不变的，测试手段无外呼白盒测试，黑盒测试，静态测试，动态测试，单元测试，集成测试，系统测试，安全测试，性能测试等等。那些奋斗在一线的测试工程师的工作内容实则没有什么大的变化，访谈的结果是大家觉得自己也没有成就感，工作很累。

    这一切都让我迷惑了，很多人象我一样也迷惑了，测试人员的核心价值到底是什么？

    测试人员的职业发展是什么？特别是focus在业务上的测试人员的核心价值是什么？在这里仅表达下我个人的观点，欢迎大家一起拍砖。

Ø  核心价值一：测试设计能力

最基本的也是最重要的价值就是测试设计。无论是采用白盒，黑盒，手工还是自动化等不同的方式，精华都在测试设计中。测试设计能力入门容易，做深难，需要耐得住寂寞，不断的学习积累，同时需要的知识面非常广。

下面几点可以提升测试设计能力：

1.对产品的熟知程度

2.对用户的了解程度

3.技术实现/依赖产品/中间件/DB设计/缓存机制/安全机制等技术的深入了解程度

4.产品运行环境（包括服务端，客户端，浏览器，系统并发量，吞吐量等）

5.bug回溯（定位/分析）

非常值得一提的是bug回溯，是一项非常有意义的活动。很多公司特别重视线上bug的预防，分析，却忽略了线下bug的回溯。而实际上，大家都有这样的印象，发现bug的不一定是你设计的TC，而是在执行TC时发散的其他测试场景。通过bug原因分析，可以更精准的帮助你识别易出问题的点。而且现在的技术，环境都是多样性的，总会出现一些你意想不到的bug，它的存在一定是有原因的。这些东西需要通过bug回溯不断的积累。

Bug回溯  与测试设计形成良性循环

Ø  核心价值二：制定测试策略

大家都知道测试是不能穷举的。在有限的人力、时间、资源情况下，如何更快，更全面的覆盖被测对象，是需要策略的。

我记得以前天彤说过，专家级的测试工程师可以对被测对象进行“精准爆破”，非常认同。对于象淘宝这么庞大复杂的系统来说，如果不能做到精确设计，精确测试，为了保障大用户量大数据量的并发下，想最大程度的规避可能出现的风险，让测试同学以眉毛胡子一起抓的方式进行测试就是在劳民伤财。

不同产品，不同的团队，产品成熟度，人员的成熟度，所采用技术的成熟度等等，都可能导致测试策略的不同。制定测试策略的过程，就是对当前的项目、团队进行量体裁衣。

影响测试策略的因素：

• 项目类型  如：新产品，完善功能，重构型的，底层升级，数据库升级，不同的项目类型，测试重点也不同，采用的测试工具和测试类型也不尽相同

• 产品成熟度    主要考虑产品的业务是否稳定，成熟。是属于创新型，试水产品，是否是成熟行业，需求明确稳定等等？

• 使用研发技术和研发平台    采用新的研发工具，新的研发技术，还是公司成熟的技术，工具，使用什么样的数据库设计，包括产品的设计思想，产品架构等

• 团队能力及默契度   稳定型团队？新团队？半新半旧，人员技术能力如何？人员特点如何？（特别需要说明的是，通过bug回溯可以发现团队开发或测试人员的技术能力，代码质量，业务掌握情况，逻辑清晰等这些个人特质，针对不同的人可以在测试时做不同的重点验证）

•  研发模式   采用什么研发模式，传统的瀑布，还是敏捷，迭代等。这种研发模式以往常出现的问题是什么？该模式在该团队的运行是否成熟，稳定？

• 产品线上运行环境    包括服务端和客户端的运行环境，负载机制，缓存机制，服务器分布等

• 产品线上并发量，吞吐量等指标    关注目前指标及增长趋势

• 产品使用用户   使用产品的用户人群众分布？目前的使用满意度如何？用户的计算机使用水平如何？用户反馈的最大问题是什么？用户的使用习惯是什么？竞争产品在用户中的优势是什么？

• 测试过程保障    上线前测试依赖的环境、数据、技术、平台、工具保障，有现成的，还是需要开发？

测试策略的方面

²  测试类型

²  各种测试类型的测试程度、测试通过/停止标准

²  使用测试技术

²  依赖平台、工具

在工作中，大家对一些事情存在一些误区：

1.编码能力   我们不盲目崇拜编码能力，而是随着测试手段不同，测试深入程度不同，需要我们有能力去识别代码中存在的风险，对产品的技术实现有更深入全面的掌握，才能更有针对性的进行测试，所以，我们必须具备编码能力。

2.创新     我们不能为了创新而创新，而是在工作过程中，技术结合业务，为解决实际的问题自然而然的生长出来的新东西。这个创新一定是解决我们工作中的问题或用户的问题的。

3.工具     工欲善其事，必先利其器，随着我们被测试对象的复杂化，多样化，使用技术的差异化，一些常规手段无法测试的内容，一些重复的劳动密集性的事务，需要让工具代替手工去做，自然而然的就会产生工具。所以，我们不是迷信工具，也不是崇拜工具，工具是为我们服务，带来价值的。如果这个工具不能给我们带来价值，就算做一个工具，没有人使用，又有什么意义呢？

在实现测试设计与测试策略制定过程中，我们为解决实际问题自然会生出一些工具，平台，我们要鼓励大家用创新的思维去思考和解决问题，这样的产出是非常有价值的。

软件测试价值观-SMBT新理念  《转载》

　近年来有不少软件测试同行不少有些困惑-软件测试人员的价值在哪里？我们怎么才能做好软件测试？怎么才能让自己的价值在团队中得到最佳的体现？在这里SMBT理念会给你答案，你所有的困惑将会迎刃而解。 

　　一、SMBT是什么？

　　SMBT是Shortest time、Most bug、Best bug、Track bug这几个单词的缩写，其含义就是“测试人员要在最短的时间内发现最多最有价值的Bug，并将Bug跟踪到底”，这就是我们测试人员追求的最高价值。其核心包括：一个宗旨、四个关键域。

附：SMBT图示

　　二、SMBT宗旨

　　以产品成败为出发点，站在整个项目团队的立场上思考问题、解决问题，而不是单一的从测试团队或者个人为出发点。

　 　在这点我想说明的是：在一些企业里面的某些产品团队因为或多或少的原因导致产品失败，最后影响整个产品团队的考核，这个时候必然会有一部分测试人员跳出 来说我们测试做的挺好的，产品失败和我们没什么关系，为什么给我们也考核得那么差。这时我想对那些测试人员或者主管测试的负责人说，你们真的错了，你们是 为整个产品团队服务的，虽然产品失败的因素可能会很多、可能和你没直接关系，试想一下难道真的和你一点关系都没有么？如果现在用SMBT的宗旨来看待这个 问题，你势必会找到你错在了哪里！我们不能有本位主义的思想来禁锢自己，我们一切要为整个产品团队出发，只有这样你才能在整个产品研发过程中充分发挥你的 才能为整个产品服务，而不是单单的测试活动，因为单单的测试活动是远远不够的，这是传统的测试理念和思维给我们带来的弊端，也是SMBT产生的根本。

　　三、SMBT关键域

　　1、Shortest time：最短时间、尽早、尽快

　　一方面Bug无限，时间有限，这个道理大家都知道，我们在测试工作中测试的时间是有限的，我们的每一项测试的时间都不可能很充足，随着互联网行 业的竞争越来越大，产品更新换代的周期日益缩小，企业稍微慢一步，整个产品就完全没有竞争优势，势必会被竞争对手抢占先机，即使你有创新的想法，但没有最 快的速度上市，也难得商机。不管是互联网行业还是其他行业，现在都是快鱼吃慢鱼的时代，在这种环境下，对我们的研发团队、我们的测试人员提出更高的要求， 那就是快-快-快，一点都不能慢。测试时间长了即使你产品的质量再好，因为时间关系错失商机、流失用户，我们所有的付出都将白费。

　　另一方面从研发模式来讲，现在很多企业都比较推崇敏捷研 发模式，这也是追求快速响应的一个途径，然而对于测试来讲，我们一定要尽早的发现Bug，让开发人员尽早的修改，或者让产品人员调整需求，而不是到了产品 最后某些本应该前期发现的Bug结果到了产品快上线的时候才发现，一旦这个时间出现比较严重的Bug，这将会对整个产品的研发进度造成严重的影响，同时因 为这个Bug的修复势必会对本来感觉已经稳定的系统带来重大的质量干扰，因为修复Bug在很大程度上必然会带来新的Bug，至于修复Bug的难度那就更不 用说了。特别是在产品研发的后期发现需求流程上的问题，这将是灾难性的后果！

　2、Most bug：最多Bug

　　量变到质变是事物的变化规律，测试也如此，只有Bug的量上去了，产品的质量才能有所改观，如果Bug在数量上上不去，这对测试活动有信心谈何 容易，一旦遇到这种情况测试经理们就头痛起来了，因为这必定是一个危险的信号，我们的信心将会荡然无存，除非系统质量足够的好，测试手段足够的高超，否则 我们将会面临产品上市后的最大危机。

　　3、Best bug：最有价值Bug

　　之前谈到我们尽早发现Bug、发现最多的Bug，难道这样就可以了么，很显然特别的片面，进一步的说我们还要发现有价值的Bug。那么什么样的 Bug才算有价值呢？直白一点就是最影响系统使用、对系统功能模块有严重影响或者破坏作用的Bug，最能决定研发周期的Bug，比如说如果事先能把需求类 的Bug在需求阶段提出来解决而不是等研发末期提出来，还有就是影响系统架构的Bug以及一些隐藏很深修复难度及波及面广的Bug，所有这些都是从量变到 质变的过程。

　　4、Track bug：跟踪Bug

　　经常会遇到一些项目在项目末期了才去关注以前提交的Bug，测试人员尽管很早就提出了很多严重的Bug，没有引起开发人员的注意或者测试人员跟 进不给力，在这个时候需求类Bug提交的早、也提交的多、并且也很有价值，甚至有些直到产品发布上线运营了有客户投诉或者在运营过程中再次暴露的时候才引 起关注，此类情况的发生直接说明前期所做的测试工作算是白做了，根本没有对产品质量做保证和提升嘛。也就是说我们测试人员缺乏明显的跟进，只发现Bug而 不跟进Bug修改这是测试人员最大的悲哀，反之如果测试人员做到了这点也是测试人员的最大价值体现，我们找到Bug不算什么，关键还是要让Bug得到解 决，这样才能对整个产品负责，也只有这样测试人员的价值才能得到真正的发挥和体现。

　　四、SMBT运用

　　1、领会SMBT的宗旨，建立良好的心态，做一个有责任心的测试人员，明确自己的工作不仅仅是测试工作，而是为整个产品团队服务的工作，当然这得根据自己的精力和能力来限定范围，不能什么都抓什么都做。

　　2、如何实现Shortest time

　　　　1）尽早介入到产品研发活动中，特别是产品需求阶段是很容易被忽略的，有问题尽早发现；

　　　　2）对测试活动及相关的安排进行合理的部署，测试策略、测试方法及测试工具的选择对测试效率的影响至关重要。

　　3、如何实现Most bug、Best bug

　　　　1）加强测试设计的能力，提升测试技术基础势在必行，剖析被测对象的内在，而不仅是表象。

　　　　2）站在产品用户的立场思考问题做好测试设计、深入挖掘用户行为和心理、深入理解系统运行机制及实现原理，这些都做到了，还做不到Most bug、Best bug真的很难。

　　　　3）不能单一的追求Most bug或Best bug，要两者兼顾，要在Most的基础上Best。

　　4、如何实现Track bug

　　　　1）以主人翁的心态对待每一个Bug，我们不仅负责测试出Bug，还要将这个Bug的修改情况负责跟踪到底，直到最终解决不再复现为此，也只有这样我们的测试工作才算完成。另外还要以积极的心态高效的跟进，不能有半点耽误和延迟。

　　　　2）不光要配合Bug修改，更重要的是要起到督促的作用，测试人员的行为要为整个项目负责。

　　领会SMBT宗旨，将SMBT四个关键域融会贯通、运用自如，此乃测试最高境界也！

　　PS：坦诚的讲，鄙人自知对SMBT的理解或许存在一些不完善的地方，在此也算是起到抛砖引玉的作用吧。希望测试界的广大同仁及读者能够对 SMBT进行完美的补充，让SMBT更加完善，理念更加深入透彻。也希望测试工作者能够灵活运用到企业中，更好的改进测试工作，提升测试价值，保持测试行 业的绝对竞争优势！

　　本文转载自：http://blog.csdn.net/vincetest/article/details/8330303

10种使测试人员陷入困境的行为趋势   《转载》

这篇文章的作者是著名软件与网络测试实验室Quardev的高级顾问，做过测试经理、测试承包商、为微软等公司做过顾问，并为很多杂志写过文章，且时常在各种测试大会中做演讲。在10年的时间中作者组织、管理了超过400次的测试岗位面试，这些面试都是以项目模拟的形式进行的，从对这些面试中面试者的表现，作者总结了限制测试人员发挥其测试技能的10种倾向，并提出了如何避免这些倾向的建议。

　　作者组织这些面试的目的是让面试者们暴露他们的优势与不足，从而决定他们是否适合在Quardev的工作。面试的流程如下：先是通过电话面试了解求职者的工作经历，然后通过邮件提供给求职者一个产品，并要求在20分钟之类对其进行测试写出至少一个bug。接下来，会邀请求职者去实验室，对他们的工作经历进行一次面对面的深入调查。项目模拟是最后一步，项目模拟的过程如下：

　　作者在白板前介绍测试任务，然后在白板上写下Bugs和Issues/Questions。

　　求职者在Bugs下记录他们发现的问题，每条记录必须少于20个单词。Issues和Bugs的区别在于，测试人员可能不是很确认这是否是一个bug，他们不确定是否原本就是这么设计的。比如"在主目录下没有setup.exe"，事实上可能是一个bug。这与求职者对于程序设计原理的了解程度和自信心等级有关。

　　如果求职者过于谨慎，在测试过程中没有在Bugs下有任何记录，或者过于自信，不认真考虑具体的实际情况，将自己发现的问题都记

　　录为bug，我都会特别关注。我希望在谨慎和自信直接找到一个平衡点。

　　作者告诉求职者，当他们发现一个问题的时候有三个选择：1）记录为一个bug；2）记录为一个issue；3）提一个问题。然后作者写下Test Ideas和Tests Run。Tests Ideas是由于执行时间过长而不当场执行的测试，Tests Run则是求职者当场执行的测试。

　　白板上的内容如下图：

　　然后作者给求职者一台笔记本电脑，上面有一个目录存放着被测软件，软件目录如下：

　　这是一个检查三角形类型的程序，输入用逗号隔开的3个数字，点击Check按钮后，会有5种可能的输出：“scalene” (three unequal sides), “equilateral” (three equal sides), “isosceles” (two equal sides), “invalid”, and “Not a Triangle.”。软件的UI如下：

作者让求职者开始进行测试，并在进行过程中接受求职者的提问。在项目模拟过程中，作者关注求职者的以下一些能力：

　　Questioning：他们是否通过提问来构建他们的测试，还是直接进行测试

　　Resourcing：他们是否索要项目相关的文档、用例、邮件的资源

　　Modeling：他们如何关注提供测试的目录？是否打开每一个文件夹？并对每一个进行提问，并围绕他们设计测试

　　Recording：测试过程中是否进行记录

　　Conjecturing：推断，如果他们没有向我进行提问，他们对产品的设想是如何的？并且如何进行测试？

　　作者在求职者的测试过程中寻找所谓的“The 3 C’s”：caution， critical thinking， and curiosity。

　　如果他们向我进行提问，我们会以开发、项目经理、测试lead、CEO等角色中的一个对他们进行回答。有时作者会给以善意但是误传消息的回答，有时回答又会自相矛盾，这些都是真实项目中会出现的情况。

　　作者的目标是观察求职者的技能，并使他们陷入作者自己或者身边的人曾经遇到过的困境。通过这些面试，作者总结了最常见的10种使测试人员陷入困境的行为趋势：

　　10、Stakeholder Trust

　　测试人员对利益相关者过分的信任，认为他们拥有所有必须的信息，并且所有他们提供的信息都是正确和中肯的。

　　如何避免：尽可能多的形式收集信息：阅读、提问、交谈、测试...

　　9、Compartmental Thinking

　　思维局限性，测试人员仅从自己的或者近似的视角出发考虑问题，而没有用其他的、对立的或者正交纬度的视角出发，这样会导致漏掉一些

　　系统级的bug，或者漏测某个完整的特性。

　　如何避免：尝试Brute Cause Analysis

　　8、Definition Faith

　　测试人员没有意识到诸如“回归测试”、"测试用例"、"功能"、"特性"等对不同的人来说意味着不同的事情。结果会导致，测试人员自认为测

　　试已经完整了，而实际上测试却还没开始。

　　如何避免：牢记相同的单词可能有不同的含义，使用与你作为测试人员所服务的合作伙伴角度出发最合适的定义来理解。

　　7、Inattentional Blindness

　　非注意盲视，和思维局限性有所不同，测试人员以自己的视角发现了某些事情，但是却没有处理这些信息，而是直接忽略了。

　　如何避免：全面获取信息，而不是指关注自己认为会引起问题的那部分。situational awareness态势感知，在大规模系统环境中，对能够引起系统态势发生变化的安全要素进行获取、理解、显示以及预测未来的发展趋势。

　　6、Dismissed Confusion

　　由于困惑而驳回自己的意见，测试人员不自信，认为开发软件的人员比自己更聪明，导致问题的不是软件本身的bug。

　　如何避免：增加自信，遇到困惑的时候提出问题或者记录下来

　　5、Performance Paralysis

　　面临选择的时候害怕犯错而迟疑不定。

　　如何避免：尝试P.I.Q.cycle：Plunge-In-and-Quit，从某处开始考虑一个问题，当思考的过于复杂或者抽象而让你头疼的时候，退出来休息下，然后回来以新的视角考虑这个问题

　　4、Function Fanaticism

　　功能狂热，只通过对UI判断，程序能做什么、不能做什么，以此来直接进行测试。而不考虑程序的构成、如何运行、如何被使用及有哪些依赖项。

　　如何避免：使用启发式思考或者checklist

　　3、Yourself， untested

　　测试人员没有从合作伙伴的角度评估自己的工作。给合作伙伴提供了不准确的信息：bug报告、测试说明等。

　　如何避免：test your testing，评估自己的测试技术、策略、计划、风险等

　　2、Bad Oracles

　　Oracles 指识别问题的原理和机制。这里相当于用例是否通过的标准。测试人员使用了错误的标准或者不知道使用什么标准来评判一个用例是否通过。

　　如何避免：听取其他合作伙伴的已经，以判断问题是否为bug。

　　1、 Premature Celebration

　　提前庆祝，发现问题后不深入寻找原因，而是提前抛出问题。

　　如何避免：遇到问题立即进行分析推断，而不是马上下定论。

　　如果你看到这篇文章了，你就有机会成为专业的了！

　　我写这篇文章并不是因为这个，其他无数的测试人员有比我更多的好东西拿来分享。总体而言，我的意思是在空闲时间阅读其他测试相关文章来提高自己的测试技能时，你也将是有志成为专业测试人员中的一分子。

　　寻找最佳理由

　　上周我在LinkedIn上看到有人讨论“为什么测试不是一份职业”，有很多答复包括说“因为大学没有专业授教”，但都是说“因为它是新兴的，人们并没有专业的进行学习”。但我没有找到有人反驳这个观点的人并说“因为大多数人工作的方式就不是专业的，才被觉得测试不是一份职业”。

　　我猜大家都注意到了给我们的责备而忙于自怜和抱怨受到的不公平。

　　寻找答案

　　坦白的讲，不管在哪我们不被当成专业人士都是因为我们并没有优先地专业化的开展工作。

　　基于我有限的工作经历，不管什么地方认真对待工作并尝试改进而给组织带来的价值的测试人员都会被尊重，并且会给予高度的评价和感谢。

　　现在切入正题，不能成为专业测试人员的10大理由：

　　1、你认为测试并不是一份技术性的职业，所以并不去尝试学习理解产品的编码

　　如果你从事的是软件开发，至少会理解一些软件工程的知识。而作为测试人员，你应该能够读懂代码来分析产品，来理解代码的变更和修复将会如何引入其他的bug.黑盒vs白盒的日子应该结束了。

　　如果你不想这样，即使不用写任何代码依然可以从事该工作。但是如果你不去读代码，将会失去对整个测试流程很重要的一项投入。

　　2、只有当开发人员告知开始测试时才真正介入到整个流程中

　　大家如实的回答，在整个开发流程中何时开展测试的？

　　理论上我们想在需求收集分析阶段就介入，和其他成员一起完成余下的，事实上我们很难投入进去，只有当开发人员想尽快得到反馈首次提交代码交付给我们时才能介入。

　　为什么要这样持续下去？大多数测试人员会说这种测试工作是开发流程中的最后一环，当其他人忙于计划时我们总是忙于测试。

　　但是实际上，如果不能每天抽两小时做测试设计就意味着你在管理时间上很差劲。而且还意味着，你不想提早介入到开发流程中的唯一原因是没有优先处理，或者换句话根本不想这么做。

　　3、只有在技术支持的同事要求重现bug时才与客户之间交流

　　测试人员一部分工作职责就是基于各种用户使用场景进行测试，一旦产品发布之后基于场景来寻找bug尤为重要。

　　但事实上（这里应该指的是外包项目中），在整个开发流程中你只是代表了客户而不是用户，根据客户的工作行为来计划测试及搭建测试环境，只是被期望基于他们的需求和限制来提供功能反馈。

　　如果真是这种情况，不了解真实的用户如何代表用户模拟他们的行为呢？最后一次访问用户如何使用产品是什么时候？工作中你能真正考虑到他们如何使用产品和工作环境有哪些限制吗？我猜答案一定是NO！

　　去拜访一些用户直到你理解他们，才不会一直做这样差劲的工作。

　4、只有在处理人寿保险时才进行风险管理

　　对于测试有一个简单的真理，也许是最微不足道的：测试人员没有足够的时间验证一切。这时，基本的风险管理派上用场了，帮助我们区分工作的优先级，哪些需要测试，哪些优先测试，可以假定哪些是基于其他测试结果上工作的。

　　但是如我所说，这只是风险管理基本的一面，更高级的是在分析跟测试压根一点关联都没有时候可以提供更大价值。

　　所有测试人员都知道产品中风险更大的区域是哪里，哪里有更多的bug，团队因为什么不定期和无计划的事务被推迟的。

　　作为测试人员我们应该意识这些区域并在项目不同的阶段实时提醒团队。这样，我们也能决定是否使用产品其他模块开发这些功能，或者考虑到这些意想不到的问题迟早都会出现，如果允许的话是否可以花更多的时间来保持系统的稳定。

　　你应该尽力尽早暴露这些影响产品的问题，不管是已知的还是潜在的，帮助团队设定靠谱的目标，在时间和预算上达成目标。

　　5、你没有任何计划来提高自己测试工作的价值

　　测试职业在许多方面都是未知的领域，有很多途径带入到测试行业，一旦进入到测试行业中，就有各种途径来改进测试专业技能。大部分测试技能提升来自于个人，而且将会由测试人员个人能力，当前工作环境的需要和限制，还有就是当前能获取的信息来源等因素决定的。

　　总之，并没有唯一的途径把自己培养成一名专业的测试人员，而且并不容易，成效并不快。所以除非你决定想真正改进开发流程，并且知道如何达到这些目的后才能够真正提高测试技能和提高能够贡献给团队的价值。

　　如何达成呢？

　　开始列出作为测试人员的强项和弱项，想想哪些方面你想改善，最终寻找可取的方法。有一件事很确定，如果你不把握机会或者跟别的测试人员的职业发展牵着一起，将永远不可能得到提高。

　　6、我们认为测试工作就是设计和运行预先定义好的测试用例

　　其实除了运行测试用例之外，还有更多的内容：

　　- 对产品设计上提供反馈；

　　- 分析当前项目计划的风险；

　　- 在不同的开发阶段提供非正式的反馈；

　　- 开发自动化框架，能帮助开发人员维持他们所开发的产品的稳定性；

　　- 运行脚本或用例，但不单单是之前预先设计好的；

　　- 分析测试结果以及能获取的所有信息，帮助我们了解产品的最新进展状况；

　　- 在流程中持续反馈

　　而且我们可以照这些步骤持续开展。

　　总之，如果只是单纯的运行用例并设置为PASS OR FAIL，那价值远远没有实现。

　7、自动化是一门高级学问，测试项目能在以后空闲时间里开展

　　请不要想出一大堆借口解释为什么不做自动化！

　　从另一个角度讲，这是一些测试人员技术弱点的另一面。

　　自动化不是灵丹妙药，并不能处理测试人员遇到的所有问题，但是通过使用脚本或工具仍然能够代替我们做一些重复的劳动，更高效，更省时。

　　问题是，一些测试人员到这里仍然感觉不够有技术含量，所以他们并不选择通过自动化或脚本改进测试。某种意义上讲，就好比使用钻木取火而拒绝用打火机并一边说这种方式很容易。

　　8、大多数时候非常自我自负的做测试

　　一个好的测试人员应该谦卑。我们需要知道如何提供反馈，更重要的是如何从其他组员或同行那获得反馈。

　　如果其他成员特别是开发人员对测试工作提供一些未经请求的反馈，或者他们查出bug遗漏或测试没有执行后，很多测试人员感到很沮丧。其实每次都有很好的理由来解释漏测，只需要冷静下来分享下这些信息，但是很多测试人员认为这是对工作失职的人身攻击，并且反驳说一些难听的话。

　　同时，我们需要知道如何提交bug，并为团队提供消极的反馈，并且需要知道如何从同行那获得建设性的批评。

　　没人期望你是完美的。但是他们期望你能认真对待失误并且同时从获得的反馈中学到经验教训。

　　9、并没有跟进需要改进提升的技能或领域

　　之前我其中一个最好的经理经常谈论我们个人的“虚拟工具箱”，好比我们所携带的技能在需要的时候随时可以使用。

　　在你的工具箱里都有哪些？

　　哪些工具需要改进或更新了？

　　哪些是你需要的，哪些是下一步想要获得的？

　　不容置疑，测试像是一门手艺，没有合适的工具不能创造需要的产品。

　　10、你的职业发展生涯就是成为管理人员或改行

　　有些人转行是因为他们觉得做测试是种很好的途径转做开发，还有部分人根本不知道测试是干什么的，甚至是因为觉得整体玩弄这些程序很好玩。毕竟，也难不到哪里去。

　　一部分人最终成了很棒的测试人员，但是多数人最后失意收场，度日如年的盼着啥时候能结束测试生涯，可以做自己想做的工作，而另外的人并不欣赏测试所带来的挑战，他们觉得唯一获得进步的就是做管理。

　　没错，做管理的确也有挑战和收获。但是不做管理也是要克服无数的问题，这些也许能给予你更大的挑战和收获（绝对还没那么头疼）。

　　我的观点是，如果你一直在想做其他的而不能关注于做一名更好的测试人员，根本不可能做的更专业。所以想想是否入对了行或者可能应该简单地摸索点别的。

　　想成为专业？首先作一个专业的测试！

　　总结上面10点，贯穿始终的是如何改变我们对测试的认知。

　　第一步就是把测试当成你的职业！

　　当我们做到了第一步，第二步就是看看哪些我们遗漏了，哪些我们需要加强，我们要怎么开展工作以及如何与同事及客户处理好关系，以及为了提高我们的价值现在能做什么。

　　第三步是我们应该未雨绸缪，并且意识到作为一种职业在变成大师或专家之前有很多东西需要学习。

　　最重要的是要意识到这种改变要发自肺腑有实际行动，而不是从一些神赐予的法令而来，或者邮件所署名字旁边的标题来证明。

好的测试实践——软件测试的尽早介入  《转载》

　　测试的尽早介入，是软件测试提倡的一个基本原则。测试过程中实践测试的尽早介入原则，其主要的优点表现在：提高质量、降低成本、加快进度和过程改进等。

　　首先，我们将从缺陷的角度来看看测试尽早介入的表现。缺陷是我们测试人员的最主要输出之一，但是它的一些特征说明了测试尽早介入的必要性。

　　1）缺陷是什么时候引入的

图1 不同阶段缺陷引入的分布

　　2）缺陷在什么时候发现

图2 缺陷发现的阶段

　　3）缺陷的雪崩效应

图3 缺陷的雪崩效应

　　4）缺陷发现与修复的成本放大效应

图4 缺陷发现与修复的成本放大效应

　　图1缺陷是在什么时候引入的，说明大部分的缺陷都是在需求阶段引入的；而图2说明大部分的缺陷却是在系统测试阶段才被发现；图3说明前期阶段存在的缺陷，会随着开发阶段的开展而不断的放大；而图4说明发现和修复缺陷会随着开发阶段的演进而不断的放大。因此，从这些图表和数据中，我们可以看出测试尽早介入的必要性。尽早测试介入，尽早发现缺陷，开展良好的评审活动就是一个非常好的手段。

　　其次，我们从测试计划的角度，看看尽早介入的必要性。我们提倡尽早制定测试计划，其主要的目的是：

　　1）尽早识别测试风险，并采取合适的应对策略。其中风险包括了产品风险与项目风险。

　　（1）产品风险：可以帮助我们更好的分配测试工作量、选择测试技术、确定测试顺序和选择缺陷修复的优先级。

　　（2）项目风险：帮助我们计划和管理测试工作，例如：产品培训或者测试工具培训等。

　　2）尽早估算测试工作量，并以此为基础协调与沟通测试资源，例如：测试仪表、测试人员、测试工具等。

　　3）根据测试资源情况，尽早安排和搭建测试环境。

　　第三，测试人员尽早开展对开发工作产品的学习和研究，有助于测试用例的设计与执行，并更好的开展测试活动和完成测试任务

为功能测试正名，写给广大软件测试同行 《转载》

　首先，恭祝生日快乐，感谢您一直是所有软件测试人员成长的摇篮和精神支柱！

　　从刚刚接触软件测试工作，到现在已经有十年之久。

　　十年前，毕业后就进入了一家软件公司，经理分配的任务就是测试软件，发现有错的地方就告诉他。这是我对软件测试工作的第一印象，就是看系统是否报错，各个功能按钮是否能够正确响应。

　　两年后，由于公司经营不善，我被公司裁员。其理由是：技术总监认为没有必要设置软件测试工程师的岗位。因此，竞岗时，我无岗可竟。

　　恰巧，当时中国软件评测中心跟省科技厅联合培训，于是，我就第一次真正认识到什么是软件测试。同时，也知道了51testing和测试时代这些软件测试交流的专业平台。

　　之后，我就入职另一家软件公司。当时，入职的职务是测试员，但公司的测试基本上和我第一次接触软件测试工作时的水平差不多。于是，我就从最基础的缺陷管理、测试用例、测试流程、测试规范、测试标准等等，一步步的将公司的测试规范建立起来，而我也因此成为了公司的测试部门经理。从测试员到测试部门经理，在这短短的八个月的时间里，可以说我取得的每一次进步，掌握的每一种知识，均来源于51testing和QQ群。可以说，如果没有这些交流平台，就不可能有系统化学习的机会。

　　为了挑战质量要求更高的项目，我离开了家乡，加入了现在的团队。这是一支由150多名技术人员组成的团队，其中，测试人员有20人。我入职的职务是测试组长，两周后任质量经理，八个月后任测试总监。从各种测试标准的制定到测试规范的建立，再到测试体系的建立；从团队战略发展方向到团队梯队建设再到测试知识库的筹建；从技术培训到团队成员职业规划；三年来 ，我和这支团队一起成长。

　　从业近十年，参与的项目十余个，其中千万级以上的项目三个。项目涉及MIS、HIS、GIS、OA、三维应用、BI、SOA、应用系统集成等诸多方向，其测试类型包括：功能测试、性能测试、接口测试。

　　说了这么多，大家一定以为我写跑题了，其实不然。之所以描述自己的成长经历，是想告诉大家我的体会来源于我的经历。

　　无论是在各种测试论坛上，各个测试QQ群中，还是在招聘时的应聘人员。我经常会遇到这种问题，相信大多数同行们也都遇到过。

　　1、做功能测试有前途么？
　　2、做黑盒测试有前途么？
　　3、我现在只能做功能测试，但我今后一定要做自动化测试、性能测试！
　　4、你们公司上自动化了么？
　　5、我会QTP、LR。

　　广大测试同行在投简历时，也一定常见这种职位要求：要求熟练掌握LR、QTP、QC、TD、Bugzilla等工具之一。

　　咱们先说说后面这种情况。一个公司在选择测试人员时，竟然将这些测试工具作为选人标准之一。我想问这样招聘的公司几个问题：

　　1、贵公司的产品适合上自动化么？
　　2、贵公司的管理水平达到上自动化的要求了么？
　　3、LR能完全支撑贵公司产品的性能测试么？
　　4、贵公司一年能有多少项目需要做性能测试？
　　5、缺陷管理工具每个公司用的都不太一样，其缺陷管理流程是需要结合公司管理流程的，这种工具即便人家不会或没用过此类工具，你就不能培训么？很难么？

　　除非公司是在招聘对口的技术人才，否则，我只能认为这家公司的测试水平真的不咋的。甚至于写招聘要求的人，压根就不懂测试。

　　咱们再来说说关于同行们对功能测试的误解。好多人都认为功能测试门槛低，没技术含量，好像提起来做功能测试就低人一等似得。如果你有这种意识，我只能说：兄弟，多干几年吧。我承认功能测试的入门门槛是低，但我不认为功能测试没技术含量。我甚至认为一个能把功能测试做好的测试人员，才是一个合格的质量负责人！

　　大家先别拍我，让我们来谈一下什么是软件测试。既然大家都是同行，相信大家都认同：“通过测试手段，在用户使用前，发现缺陷。”以及“软件中不可能没有缺陷。”这两句话。不错，测试是不能被穷举的，因此，我们也不可能发现软件中所有的缺陷。因此，我们是不是能够换句话说：“软件测试是通过一系列的测试手段，证明软件具备一定的质量。”

　　如果你认同这一观点，那么我们再来谈谈功能测试的范围。

　　狭义的功能测试：这点点，那点点，看看能不能正确打开页面、程序会不会崩溃、功能是不是能够正确实现等等。这也就是大家之所以认为功能测试没技术含量的根本原因。因为这种测试也得叫它功能测试。

　　广义的功能测试：各种业务逻辑是否已正确实现？各种业务约束是否正确实现？各类特殊的数据是否能够正确处理？软件的容错机制如何？数据的完整性、唯一性、正确性是否已经通过测试？系统及数据的安全性是否已通过测试？软件的易用性是否满足用户的需要？等等等等。功能测试所包含的范围实在是太大。

　　我没有贬低其他测试专业的意思，但有几点是需要说明的。随着各行各业对信息化建设的需求日益提高，其软件的规模和复杂度正在翻倍的提高。而功能测试的难度也随软件的复杂度逐日提高。而相对来说，白盒测试依旧关注的是单个函数的代码逻辑以及异常的处理；自动化测试仅仅提高的是测试执行效率，测试质量依然是要靠功能测试用例来保障；性能测试其实关注的是业务发生的场景和如何生成负载和收集监控指标，其变化就是需要监控的对象更多，影响因素更为复杂。

　　面对规模庞大，业务逻辑愈来愈复杂的系统，保障其软件质量，就需要广大功能测试人员具备更强的逻辑分析、设计能力；掌握更多的业务知识及技术。同时，由于当前国内绝大多数企业对测试工作的认知程度不足，大多数测试工作都是在时间紧、任务重的条件下完成的。那么，在有限的条件下，如何能够提高软件产品的质量，即：如何证明软件具备了一定的质量。将是所有软件质量负责人首先考虑的问题。

　　在这种前提下，我认为，一个好的功能测试工程师应具备丰富的行业知识（专家级），极强的逻辑分析能力，精于业务架构、测试架构、数据库、测试用例的设计。公司的产品质量，取决于测试负责人的组织能力及团队成员的技术能力，因此，功能测试工程师在测试团队中不可或缺。

　　无论是白盒测试、自动化测试、性能测试，都是不同的测试手段，但功能测试却是产品质量的根本保障！ 请广大正在从事功能测试的同行们，正视自己的工作，认真对待，不要气馁或轻视自己的工作。将自己手头上的事做好，人生的每一段经历都将是你的财富！

　【背景介绍】

　　NB公司的面试流程步骤多，严谨，正常情况下一个顺利的面试流程需经5个面试官的考核，真所谓过五关斩六将，能闯到最后一关者，绝非易事。----某公司的过来人如是说。

　　求职者：王小姐，毕业后一直从事软件测试，工作4年。

　　面试官：共5位，其中前3位为技术面，后2位为综合素质面。

　　【故事内容：面试回顾】

　　话说王小姐的面试还是比较顺利，用的是周六的时间，不用请假。虽早上7点多就开始准备，直到下午4点才面试完，但能在国内知名的NB公司面试，并闯入最后环节，当王小姐走出NB公司的大门，还是自我欣慰了一番，并自信的笑了笑。心想：NB公司的面试官确实个个都有不同的一面，问的问题有些还比较尖锐。说实在的，测试技术也就是那些，面试官非要纠缠一些细节。我只好……，这个策略也叫“兵来将挡，水来土掩”吧。

　　也就在王小姐离开公司的一会儿，按惯例，HR组织几个面试官碰在一起交流下彼此对王小姐的评价。

　　面试官1评价：沟通能力不错，整个过程没有不顺畅的地方。技术上没有发现明显的优势与劣势，但总觉得她的话不太符合逻辑。

　　下面是面试官1的经典回顾。

　　面试官1问：“工作过程中，是否曾主动总结过什么东西与他人分享？”

　　王小姐说：“有的。”

　　面试官1问：“是否有什么案例具体说说。”

　　王小姐说：“我安装配置过给公司内部使用的XX软件，由于配置复杂，当时写了一份总结，并上传到网上我的博客空间了。”

　　面试官1问：“是什么网站。”

　　王小姐说：“不记得了。”

　　面试官1心想，上传了博文，有不知道是什么网站的吗？一般情况下建立博客空间是要注册的。不太靠谱吧。

　　下面是面试官2对王小姐的面试评价：

　　1、工作主动，有一定的过程总结能力。例如：她从自带的旅行包里取出一份测试报告展示给我看，报告内容详细、清晰，并提出某某图表是她主动做的。

　　2、有点过于自信，或自我认识不足。问及做了几年测试后，有没有遇到什么技术上的困难，或哪些方面觉得还有待于提高，回答各方面都做得很好，没有遇到什么困难。我表示怀疑。

　　下面是面试官2的经典回顾。

　　面试官2问：“你认为做好软件测试工作，哪个环节的工作做好最重要？”

　　王小姐回答说：“每一个都很重要，每一个环节我都做过，包括测试计划，测试方案、用例设计，测试总结与报告等。”

　　面试官2心想，既然都做得好，于是继续问：“在多年的测试过程中是否有遇到偶发的Bug，是如何回归偶发Bug的”。

　　王小姐说：“可能运气好，真没遇到，发现的问题无偶发的并且开发都解决了。”

　面试官2心想，这位王小姐，是神马，还是浮云，这显然不符合正常情况的软件研发过程逻辑。

　　轮到面试官3发表意见了，他略有所思，回忆了当时的面试场景。下面是他的经典回顾。

　　面试官3问道：“从事测试4年多来，是否有感到自己哪些方面比较欠缺的。”

　　王小姐说：“暂无感到有什么不足或缺点，工作上都挺顺利的。”

　　面试官3心想这个王小姐，心有顾虑，不太诚恳。于是现场出一个题目来考考她，拿出一张白纸，并在纸上画出一个日常常用到的软件界面，在明确需求的基础上，要她讲述测试的分析思路。

　　王小姐看了几眼，基本没作思考，便随口说了几个她所认为的测试思路。

　　面试官3心想，都是表面的几个测试点。从这点上来看，觉得她很一般，没有突出的特点。

　　面试官3继续问：“听你说，在公司各项工作开展都挺顺利的，也觉得自己没什么欠缺的，为什么还离职呢。”

　　王小姐回答说：“公司业绩不好，没有奖金发，一年了也未加过薪，这是重点。其次是看不到什么发展空间。”

　　对于王小姐回答的第1点，面试官3觉得可以理解，对于第2点有点好奇，于是追问道：“是什么原因使你认为看不到发展空间呢？”

　　王小姐回答说：“我的老板，即我的上司，是在公司工作了7-8年的老员工，在业务与技术上，自己明显是比不上的，他们老员工也比较稳，一般情况不会离职。而公司目前的发展未有其他管理岗位可提供。公司的测试部门还有另一个平台组，主要负责公共模块的测试，测试工具的开发，偏向测试开发，而自己这方面的技术水平又达不到。”

　　面试官3听了后，恍然大悟。

　　心里评价道：“工作不踏实，自命清高。回答问题不诚恳，自作聪明。”

　　【思路点拔】

　　三国时期的历史典故，杨修的鸡肋事件，本无其事，最后引火烧身，与本处的“聪明反被聪明误”案例，似有相似之处。抑或是杨修之死，还是本处的案例，告诉我们：

　　1、诚实。面试过程，是相互建立信任的过程，不少面试者为了掩盖自己的不足，往往会说一些谎言。当然作某些善意的谎言，只要不影响本质，面试官也不是不能接受的。

　　2、逻辑清晰。说话表达注意逻辑，问A问题，不能答B内容。软件测试是技术性工作，思路清晰，有逻辑的封闭性，这是基本的素质。例如本案例中提到的求职者主动上传了博文，却不知道博文位于何网站。

　　本故事面试场景中的一些地方，可能你也似曾相识，觉得那些地方求职者或面试官可以做得更好呢

　　我的职业发展路径

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

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

　　郑：我不是计算机相关专业毕业的，却阴差阳错地从事了与之相关的软件测试工作。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次。你的策略、技术与方法，直接决定了你完成任务的速度与质量。

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

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

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

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

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

　　蔡：如何把握软件产品的质量？

　　郑：不管软件产品规模是大还是小，结构是简单还是复杂，对它们质量的评估都不是一件容易的事情。尽管很难，但是产品质量的评估仍然是必需的，因为它也涉及软件版本是否能够发布。

　　软件发布之前做评估

　　根据我和公司内的实践经验，可以从下面两个方面进行评估。

　　第一，软件产品发布之前的质量评估，具体的度量指标包括：

　　缺陷，包括发现的总的缺陷分布趋势、缺陷在不同功能模块中的分布等。例如，总的缺陷分布趋势图。

　　测试通过率，主要包括计划的测试用例执行进度、通过的测试用例数目、失败的测试用例数目、被阻塞的测试用例数目等。我们项目中定义的测试通过率是95%。

　　测试覆盖率，包括测试对系统需求的覆盖率、对测试类型的覆盖率。例如，我们项目中定义的需求覆盖率必须达到100%，测试类型覆盖率也必须达到100%。

　　信心，负责这个模块的测试人员对质量的主观感受。可能有的人觉得很奇怪，怎么主观感受也可以作为产品质量的评估？因为负责功能模块测试的工程师是最了解他们的测试对象的。

　　旁观者说：可以设计一个信心指数，例如1～10，然后通过各种数据来支持这个指数。

　　软件发布之后做评估

　　第二，软件产品发布之后的质量评估。我们目前采用的度量指标是缺陷检测百分比DDP（Defect Detected Percentage），其计算公式如下：

　　客户现场发现的缺陷数 /（发布前测试团队发现的缺陷数 + 客户现场发现的缺陷数）* 100%

　　我们一般统计产品发布之后6个月内在客户现场发现的缺陷数。不同的公司与项目，采用的统计时间范围会有所不同。

　　旁观者说：统计客户发现的bug是有意义的，一是可以据此对客户做一些分析，例如，经常使用的功能、满意度等；二是可以用于反思之前的测试活动，以求改进。

　　测试团队为软件发布提供质量信息

　　还有一个问题是测试团队非常关心的：谁来决定软件产品的发布？从我的角度而言，我认为由测试团队决定软件产品是否发布是不合适的。

　　软件产品是否可以发布，需要有不同角色的成员参与进来，根据公司定义的判定准则进行评估，同时平衡产品质量、市场机会、产品战略以及成本等多个因素。测试团队在这个过程中主要的作用是尽量多地提供软件产品的质量信息、风险信息等，以帮助管理层做出是否发布的决定。任何一个单方面做决定都可能是不全面的。例如，测试人员觉得质量还不够好，发布有风险；但是市场机会要求我们发布，如果再等一段时间就会减弱市场机会，甚至丧失机会，这个时候就需要考虑哪个因素有更高的优先级。

　　旁观者说：赞同。软件发布与否应当综合各种因素来考虑，而不仅仅是某个角色说了算。

　　新人如何学习软件测试

　　蔡：对于软件测试的新手，包括刚进入这个行业的，也包括正在学习、准备进入的，你有什么建议和经验分享？

　　郑：对于软件测试的新手，假如希望在测试行业有所发展，根据我的经验可以从下面几个方面入手。

　　1、了解你的测试对象。你首先要知道软件产品是干什么的，其实现的主要功能是什么，其工作的基本原理和流程等。比如，我一直从事通信产品，除了产品本身的需求资料外，还花了大量的时间学习和钻研各种通信产品相关的国际标准和行业标准，例如路由协议、IPv6等。

　　2、多向有经验的人学习。在刚刚入门测试行业的时候，我们应该抱着向各位前辈学习的态度，通过各种形式向有经验的人员学习，例如，参加培训、个人交流等。根据测试的特点，学习主要从两个方面入手。

　　（1）我们应该积极参加项目团队中的领域知识培训和交流，也可以直接向系统人员和开发人员询问产品是如何工作的，具体如何实现等问题，以更快地熟悉和掌握产品知识

去管人还是坚持做技术

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

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

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

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

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

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

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

　　研究测试技术和方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3、多实践，不要怕失败。不管是测试领域的知识，还是测试技能，或者是测试思想和方法，测试新人都需要勇敢地去实践，许多经验、思想和收获来自于失败的经验教训。

　　旁观者说：如果真是要丢脸的话，越早越好，越晚越被动。

　　4、勤奋。在我的经验中，勤奋总是占有非常重要的地位。只要你设定的方向是正确的，想要达到目标，勤奋将是不可或缺的基础。特别是觉得自己在某方面基础不好，勤奋可以弥补这方面的不足，我当时入门软件测试就是这么走过来的。你看到有的人很牛，测试经验丰富，各方面都懂，那是表象，其实他（她）在背后花了很多时间，你在玩游戏、看电视的时候，他（她）在看书、总结、写文章。如果我们能够坚持，每天坚持，这样一段时间后你就会发现自己与以前大不相同了。

　　旁观者说：我很相信一句话：天道酬勤。

　　如何面对职业发展的迷茫

　　蔡：你对在软件测试行业工作了三五年的朋友有什么建议吗？有的朋友对我说，他觉得有些迷茫。

　　问自己三个问题

　　郑：在软件测试行业工作几年之后，免不了会产生各种不同的迷茫：软件测试有前途吗？软件测试有技术含量吗？将来是做技术还是做管理？我自己在2005年准备换工作的时候，就对是做技术呢，还是去找测试管理的职位有过迷茫。尽管现在已经选择技术方向很多年了，有时候还是会迷茫：测试技术真的能顺利走下去吗？

　　在面对这些迷茫的时候，我就会问自己：

　　（1）你喜欢做技术还是做管理？我喜欢做技术。

　　（2）你的目标是什么？我希望将来成为测试专家。

　　（3）目前的工作和活动能帮助你达成这个目标吗？是的。

　　旁观者说：简单直接的三个问题，就像程咬金的三板斧，蛮有威力的，你可以试试。

　　基于这些问题的内心回答，我会不断给自己加油，并鼓励自己继续往前走。我几乎每天都会反省自己当天的工作，有了哪些收获，有了什么总结，多少时间又被浪费了等。通过这样的形式，不断提升自己的信心，提高学习的效率和有效性。

　　旁观者说：能够做到每天反省和总结，不简单，值得学习。孔子说，吾三省吾身。或许可以这样说，无论做什么事情，比如锻炼、减肥、写日记、练字、学习等，如果能够坚持每天做，都了不起。

　　分享周围几个朋友在职业发展方面的例子

　　我与大家分享一下我对下面几个迷茫问题的建议。

　　1、到底是做技术还是做管理工作？希望读者可以从我前面的工作经历中得到一些启发：做自己喜欢做的事情，勤奋加坚持，你会发现你可以逐步走向成功，不管是做技术还是做管理。

　　2、软件测试有前途吗？这个问题应该是每个测试从业人员所关心的话题。假如大家因为这个问题而觉得迷茫，我和大家分享我周围几个朋友的例子，测试同样可以成就你的未来。

　　（1）以前公司的某个测试部门经理，现在是某公司重庆研究所的所长。测试的职业发展也可以是有高度的，而不是说测试经理就是测试人员的终极目标。

　　（2）以前公司的某位测试工程师，在2005年换工作的时候，找到的职位是产品经理。测试人员的优势是对软件产品的工作原理、工作环境与客户最关注什么等有充分的了解，因此产品经理是你可以努力的一个方向。

　　（3）以前公司的某位测试工程师，首先从事测试工作，在换工作的时候应聘了软件开发的工作，在第二次跳槽的时候选择了项目经理的职位。由于有明确的职业规划，在对测试与开发有了深入了解之后，再加上项目管理的知识、技能与经验，测试人员成为项目经理是可以的。

　　（4）另外，在我们周围有不少独立的测试专家、咨询师等，他们不断出书、写文章，参加各种大会做报告，受邀为公司开展企业咨询工作等，这同样是你可以选择的一条路。

　　旁观者说：他山之石，可以攻玉。上面几个例子虽然简单，但是仍有可借鉴的地方。

　　3、软件测试有技术含量吗？很多人都认为软件开发有技术含量，而软件测试就是点点鼠标，按照需求检查工作产品，所以没有什么技术含量。实际情况是这样吗？这让我想起了一个故事：某公司的发电机出现了故障，请了一位经验丰富的工程师进行维修，他在机器上东敲敲、西敲敲，在某个地方画了一个圈，将其中的一个线圈换掉后发电机就正常工作了。收取了1000美元的费用。公司老总觉得费用太贵，不就是换了一个线圈吗？维修工程师回答说：“换个线圈只要1美元，找到哪里的线圈更换需要999美元。”很多人只是看到了表象，测试人员坐在那里点点鼠标，提交了一个缺陷。但是技术含量不是测试人员点点鼠标，而是测试人员为什么点鼠标，鼠标点在哪里，要点几次，即测试人员是如何思考的、如何分析的。这才是人与人之间的最大不同，也是测试人员真正的价值所在。优秀的测试人员与平庸的测试人员之间的最大区别在于前者更懂得如何思考和分析。

　　旁观者说：努力成为专家型的人才，符合个人利益，也符合公司利益，双赢。

　　如何做好测试用例的设计

　　蔡：如何做好测试用例的设计呢？

　　郑：测试用例设计是每个测试从业人员最主要的测试活动之一。为了做好测试用例的设计，我们必须考虑下面几个因素。

　　明确参考输入

　　第一，做好测试用例设计，需要首先明确它有哪些参考输入。以我为例，我是做系统测试的，因此测试对象的需求规格说明是最主要的测试设计参考。但是实际面临的问题是需求常常不完善，因此纯粹依赖于需求规格说明肯定是不全面的。根据我的经验，下面的这些输入也应该经常考虑：用户需求、开发文档、标准与规范、测试经验知识库等。

　　测试经验知识库是测试人员以前做类似项目的测试经验、收集与分析的缺陷类型分类等，都是开展测试用例设计的基础。例如，我们的测试用例模板中的测试类型定义，除了参考ISO 9126质量模型 ，其中的重要输入就是以前项目的测试经验和缺陷分类分析。

　　旁观者说：有多少公司收集和存储了项目的历史数据？又是否做了分析和利用？

　　关注功能之间的交互

　　第二，做好测试用例设计，除了考虑被测对象功能之外，也需要关注被测功能与其他功能模块之间的交互。由于每个测试人员负责各自的功能模块，往往会导致整个测试对象不同功能模块之间的接口、相互作用和耦合等分析不够充分，而这些是影响测试对象质量的重要因素。例如，在我们当前的项目中，通用的交互测试点有主备倒换、内存使用、内存泄漏、CPU使用、数据备份/恢复、版本升级、系统重启等。

　　旁观者说：相对于开发人员来说，功能交互是测试人员的优势，我们要在这方面好好发挥。

　　采用合适的设计技术与方法

　　第三，有了测试用例设计的输入与交互分析之后，采用合适的测试用例设计技术与方法，有助于做好测试用例的分析。根据《软件测试设计》中提出的“问题驱动的软件测试设计”观点，可以从下面四个方面考虑进行测试设计，以解决测试设计中面临的问题。

　　1、挑战1：被测对象的逻辑组合和输入数据的组合是非常庞大的，而穷尽测试是不可能的。经典测试设计中的一些技术与方法，在保证测试覆盖率与质量的情况下，对减少测试用例的数目是非常有效的。例如，在项目测试中引入了“组合测试”技术。

　　2、挑战2：软件产品的不同利益相关者对产品的质量要求是不一样的，如何满足他们各自的质量要求？基于质量特性的测试设计有助于我们选择合适的质量特性。测试设计中要求100%的测试类型覆盖率，可以更好地满足不同利益相关者对质量的不同要求。

　　3、挑战3：测试时间与资源总是非常有限的，如何平衡测试时间、成本与质量之间的关系是每个测试人员都需要考虑的。基于风险的测试设计可以帮助我们有效地解决这个问题。例如，先给模块确定测试优先级，然后分析每个模块存在的主要风险，并按照不同风险级别开展测试设计活动，以尽快尽早发现严重程度高的缺陷。

　　4、挑战4：测试人员面对的需求经常是不完善的、经常变更的。除了前面提到的完善测试用例设计的参考输入之外，基于经验的测试设计也可以帮助测试人员在这种情况下做得更好。例如，根据以前发现的缺陷和用户现场反馈的缺陷，进行缺陷分类分析和评估。另一个策略是更多地采用探索性测试，更好地发挥测试人员的主观能动性与分析能力

　　第四，在测试用例设计过程中，发挥团队的力量分析和评审测试点，其得到的效率和有效性会更好。例如，通过在测试分析与设计过程中应用思维导图 工具，帮助我们拓宽测试思路，增加测试条目。测试团队的放射性思维可以很好地帮助我们提升测试用例设计的效率和有效性。

　　测试用例的颗粒度没有严格的标准，我的观点是只要它们满足测试目的，符合产品特点、开发特点和测试过程等要求，有助于我们更好地发现缺陷和开展测试活动，测试用例的颗粒度就是合适的。

　　如何做好测试用例的评审

　　蔡：测试用例的评审一直是个问题。如何做好评审呢？

　　郑：测试用例是测试人员最重要的输出之一，也是后续开展测试执行与评估的基础。评审应该是开发过程中比较有争议的关键域，现实中存在矛盾：不做评审，这又是一个强制活动；开展评审吧，效果很一般，甚至得不到有用的评审建议，浪费时间。

　　结合我自己在评审方面的经验教训，做好测试用例的评审，下面是我的几个建议。

　　合适的评审团人选

　　第一，选择合适的人参与测试用例评审。例如，我们在做测试用例评审的时候，强制参与的评审人员有该功能的系统人员（他定义具体的需求）、开发人员以及测试架构师等。每个人参与测试用例评审的关注点是不一样的，例如，测试架构师关注测试类型的覆盖率方面，而开发人员和系统人员关注测试用例是否覆盖业务场景与不同功能模块之间的交互等。另外，语法、拼写、排版等方面的问题应该关注，但不应该是评审的重点。

　　管理层的支持

　　第二，管理层的支持。有效的评审是需要时间与资源的。例如，在我们公司的火车开发模型下，针对测试用例的评审是强制的，而且定义了评审的入口准则与出口准则；而且在做项目计划的时候，测试用例评审作为一个重要的活动，也相应地进行了工作量的估算和时间进度安排，这些都需要管理层的支持。

　　做好准备

　　第三，评审人员的准备，这是有效评审的关键所在。例如，我们针对测试用例的评审，定义了评审检查表，包括：测试类型覆盖、系统需求覆盖、测试用例模板符合程度检查等，这有助于有效开展测试用例的评审，也可以集中评审的重点。

　　旁观者说：即使我们要求不了别人，至少可以要求自己，评审前做些准备。

　　宣传评审的价值

　　第四，让更多的人明白测试尽早介入（评审）的意义。很多时候，大家不愿意积极参与评审，除了时间和资源方面的原因，主要是大家对评审的优点没有直观的感觉和定量的数据。例如，提高质量、降低成本、加快进度与过程改进等。只有认可了这些优点，大家参与评审才能更加自觉、有效。

　　我举一个写作的例子。我与马均飞在写作《软件测试管理》与《软件测试设计》过程中，对书稿进行交叉评审。评审过程中的讨论与交流，不仅使得我们对写作内容有更多的理解并达成一致，而且可以使内容更加全面、完善。评审取得成功的主要因素包括：选择合适的评审人员、每个人准备充分、时间与资源有保证，特别是认识到评审对作品（产品）的重要意义！

　　蔡：如何评估测试用例的质量？

　　郑：测试用例质量的评估，我主要考虑下面三个方面。

　　1、根据测试用例的形式评估其质量，主要包括：

　　（1）测试用例与需求规格说明中需求条目的可追溯性。例如，每个需求条目至少有1个测试用例与之对应。

　　（2）测试用例有无明确的期望结果。

　　（3）是否满足公司内部定义的测试用例模板。

　　2、根据测试用例覆盖率评估其质量，主要包括：

　　（1）需求的覆盖率。例如，我们主要负责系统测试级别，因此测试用例的需求覆盖率要求必须达到100%。

　　（2）质量特性的覆盖率。例如，我们在测试用例模板中采用测试类型的概念，要求每个功能的测试用例必须100%覆盖所有的测试类型。

　　（3）测试平台的覆盖率。例如，针对我们目前的通信产品，每个功能都需要在不同平台上运行；再如，不同的网元类型、接口类型、业务类型等。测试用例对这些平台的覆盖率也要求达到100%。

　　3、根据测试用例的有效性评估其质量，主要包括：

　　（1）测试用例的缺陷发现率。我们采用的计算方法是，系统测试发现的缺陷数目除以执行的测试用例数目（百分比）。

　　（2）脚本化测试的缺陷发现率。我们采用的计算方法是，根据测试用例步骤发现的缺陷数目除以总发现的缺陷数目（百分比）。如果这个百分比很低，则说明设计的测试用例的有效性方面比较差，不少bug是通过探索性测试发现的。

　　（3）遗漏到用户现场的缺陷率。我们采用的计算方法是，6个月内用户现场反馈的缺陷数目，除以系统测试级别发现的缺陷数目与6个月内用户现场反馈的缺陷数目之和（百分比）。

　　每个公司和测试团队在评估测试用例质量方面都会存在不同的度量指标，我们的要求是这些度量指标要简单容易收集，并且有利于改进测试过程和测试团队的测试能力，但切记不会做针对测试人员个人的能力与绩效的评估。

　　旁观者说：从不同的侧面去做度量，是一个更好的办法。这种办法可以在工作的很多方面得到应用。

　　成为测试牛人的三个步骤

　　蔡：有网友提到一个问题，如何成为测试牛人？

　　郑：不管是测试管理方向还是测试技术方向，都是可以成为测试牛人的。要成为测试牛人，你要有成为测试牛人的强烈要求。根据我的经验，下面的步骤有助于你成为某个领域内的专家。

　　第一步，制订目标：你希望成为哪个领域的测试牛人？例如，测试技术方面的牛人、测试自动化方面的牛人。

　　第二步，技能要求：要达到所制订的目标，你需要具备哪些方面的技能？以我自己为例，希望自己成为测试技术专家，我主要从下面几个方面不断积累经验与技能。

　　（1）深入了解测试对象的背景知识与业务功能。例如，我是做宽带接入产品的，除了测试对象的功能之外，我利用空闲的时间学习了VPN、MPLS、IPv6、IP路由交换协议等。

　　（2）深入了解我公司所采用的开发模型与测试流程，即需要清楚地知道在测试生命周期中，什么阶段需要做什么事情，有哪些输入与输出。

　　（3）测试人员要深入了解各种软件测试技术与方法。例如，我们采用敏捷开发，在面向业务的测试过程中，探索性测试与测试人员的结对测试是我们经常采用的测试方式，不仅可以有效发挥测试团队的主观能动性与及时分析反馈能力，而且可以更好地分配资源与加强测试团队内部的技能共享。

（4）培养测试人员的各种软技能，例如，沟通与合作。对我而言，在业余时间喜欢看各种类型的书籍，例如，沟通、管理、心理学、演讲、理解与记忆、经济学、思维等。广泛涉猎各种知识，可以帮助我更好地提高软技能。

　　第三步，立即行动。

　　“千里之行，始于足下”，坚实走出每一步，坚持走出每一步，成功就在前面等你。

　　旁观者说：没有行动，再好的目标也仅仅是纸上的目标。

　　面试中的考量

　　蔡：你的测试经验很丰富，肯定参加和主持过不少的测试职位的面试。你在面试中看重什么？

　　郑：在面试过程中，我主要会从下面几个方面进行考量。

　　第一，会详细了解职位候选人在测试对象的产品背景知识与业务知识方面是否满足职位的要求。

　　第二，考察应聘者在测试流程、测试技术与方法等方面是否有所了解，结合测试项目和产品的特点，判断他所掌握的这些技能是否有助于测试团队的测试能力改进。例如，我们一直做的是系统测试工作，时间与资源经常非常紧张，除了基本功能的验证之外，测试中很多的精力放在用户业务的考察上，因此应聘者了解基于场景的测试、基于风险的测试等技能是受欢迎的。

　　第三，考察候选人在性格特征、为人处世等方面是否符合企业文化和团队氛围。

　　同时，员工的上进心与学习能力也很重要。例如，两个候选人，一个有一年工作经验，另一个有三年工作经验。只要有上进心，有一年工作经验的那位候选人在半年后就能做与有三年工作经验的那位朋友一样的事情，甚至做得更好。

　　旁观者说：这里也揭示了一个残酷的事实：如果没有高人一等的技能，年资有的时候会在找工作的时候帮倒忙（暂且称为年资拐点）。我们要尽可能延迟年资拐点的出现。

　　当然，面试中获取每个候选人真实的信息并不是一件容易的事情，我自己会从候选人的日常时间安排、个人兴趣爱好和业余时间计划等方面收集与分析信息。

　　基于我面试的经验，下面是我给测试职位应聘者的两条建议。

　　1、面试前做好充足的准备工作。

　　2、面试过程中，应聘者诚实很重要。面试过程中有些问题不会，可以直接回答不懂或者没有经验，切记不要不懂装懂。没有一个人是完人，面试官可以接受存在不足的候选人，但不会接受明显撒谎的人。

　　旁观者说：对，坦诚其实是面试中最好的态度。

　　软件测试行业的发展前景

　　蔡：对软件测试行业的发展前景，你怎么看？

　　郑：我是2001年开始从事软件测试工作的，从我个人的整个从业经历来说，软件测试行业一直在往专业化、系统化、正规化方向发展，因此软件测试应该是一直在往上走的趋势。针对软件测试行业的发展，可以从行业本身与测试从业人员两个方面进行分析

　　首先，我国的软件测试行业相对欧美国家，现在还是处于很年轻的阶段。借鉴美国等软件测试的历史发展经验，测试行业发展的前景还是乐观的。在欧美国家，软件测试行业中经常可以看到有30年甚至40年测试经验的从业人员；而在国内，像我这样有11年软件测试经验的人都算是“很老的”测试人了。因此，欧美国家中30/40年的软件测试经验，可以说明这个行业能够提供机会，让他们一直做下去，而且做得不错。我相信这个现象同样适用于我国的软件测试行业。

　　旁观者说：有的朋友说，咱们国家的IT公司不养年纪大的人，你看身边哪有年纪大的？对于这一点不必悲观。之所以现在IT公司里没有年纪大的员工，主要是因为我们的IT行业太年轻。只要IT行业持续发展，公司规模增大，慢慢就会出现白发斑斑的IT工程师。

　　其次，客户对软件产品的质量要求越来越高。尽管说软件产品的质量是构建进去的，而不是测试出来的，但是软件测试对提高产品质量是建设性的，因此测试在研发中的不可或缺性将会不断得到提升。这对软件测试行业而言是利好消息。

　　旁观者说：社会对软件的依赖和对软件质量要求的提高，是软件测试行业发展的基础。从这个方面来说，测试从业人员可以去培育和引导社会对软件质量的要求。

　　第三，2012年的软件测试很热闹，除了在上海成功举行了中国第一届软件测试大会之外，在北京、上海等地轮番上阵了ISTQB测试沙龙、测试专题讨论、软件测试俱乐部沙龙等民间测试活动，并且参与的测试从业人员都是几百人的量级。这样的现象在前几年是不可想象的，这从另一个侧面反映了测试行业的蓬勃发展。

　　测试人员要提升自己的技能水平和价值

　　蔡：测试工程师将来会遇到哪些挑战呢？

　　郑：测试行业前景看好并不代表每个测试从业人员都有好的前景，这依赖于测试人员如何提升自己的测试技能与提供的测试价值。今后一段时间测试业界内的热点是：

　　1、自动化测试与手工测试之争。随着软件测试成熟度的提高，加强自动化测试将是一个合理的趋势，这对于测试从业人员而言是一个发展方向。但是自动化测试并不能代替手工测试，因为自动化测试的基础来自于测试人员的思维与设计，测试从业人员应该将自动化测试作为一个提高测试效率的手段，而不应该是最终的目标。自动化测试工具并不能保证项目的成功，但是可以帮助优秀的测试人员更加出色地工作。

　　2、探索性测试与脚本化测试之争。测试从脚本化测试的关注过程，到探索性测试更关注测试人员的思维与主观能动性，并不能说明两者之间谁好谁坏，或者谁替代谁的问题。测试人员需要做的是如何平衡两者之间的关系，如何更好地发挥两者各自的优势，弥补各自的不足。

　　3、敏捷开发模式下的敏捷测试。敏捷测试更强调整体团队运作，强调将质量构建进产品而不是在生产出来之后再进行测试，强调自动化测试，以及同时强调面向技术的测试与面向业务的测试。敏捷测试要求测试人员掌握熟悉范围之外的新技能，例如，测试驱动开发、持续集成。

　　软件测试行业将持续往前发展，而测试从业人员能否在这个平台中同步前进，这依赖于测试人员自己的不断积累、不断实践与不断交流。要发展，测试人员同样需要走出去，了解当前的测试热点、测试发展趋势、测试理念与思想的趋势等。

　　旁观者说：博取各家所长，兼容并蓄。

　　书籍推荐

　　1、《软件测试艺术》：软件测试的经典著作，展示了测试大师Glenford Myers多年的软件测试思想和技术。书中探讨了代码检查、走查与审查、测试用例的设计、单元测试、系统测试、极限测试等主题，是测试人员入门的一本优秀教材。

　　2、《软件测试经验与教训》：本书分享了3位作者多年的测试经验，知道成功的测试需要什么。书中汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可以将这些经验用于自己的测试工作中，避免一些容易犯的错误，提高测试效率与有效性。

　　3、《A Practitioners Guide to Software Test Design》：关注测试用例设计的一本著作，其中包括了白盒测试技术、黑盒测试技术与基于经验的测试技术。每个测试技术本身都结合了技术原理、案例分析和优缺点分析，是每个测试人员了解和应用测试用例设计的一本好书。

　　4、《赢在测试：软件测试先行者之道》：蔡为东写的这本书，汇集了多名测试行业的测试精英，其中描述了他们是如何认识测试，发展测试，规划测试，以及如何在测试行业中取得成功的，为测试从业人员的职业发展提供了参考方向。这本书为处于迷茫阶段的测试人员规划自己的测试职业发展，提供了许多现实可行的方向。

　　5、《思维导图：大脑使用说明书》：要想在测试领域有所建树，测试人员持续不断地学习与积累是非常重要的，而如何有效地阅读与学习将是决定成败的一个关键。思维导图是一个简单易学的革命性思维工具，它可以帮助你提高记忆力和理解力，激发想象力，更好地制订生活和工作计划。

　　在这次采访中，郑文强和大家分享了很多宝贵的经验，摘要如下：

　　1、勤奋学习能够弥补基础的不足。

　　2、在决定发展方向的时候，不要生活在别人的期望中，而是要知道自己想做什么，擅长做什么。

　　3、去做自己喜欢的，还是去做人家喜欢的？最终我选择了前者。从目前的结果看，感觉到自己在公司内部可以做的事情更多了，参与的活动也在增加。不管对公司还是对个人，体现的价值都是在不断增加的。

　　4、把好的测试理论、测试思想与工作实践结合起来。

　　5、坚持去做自己喜欢的工作，不断积累、总结和分享。

　　6、认清楚自己，明确自己的优点和不足。

　　7、让跳槽符合自己的发展方向。

　　8、分享并不会导致“教会了徒弟，饿死了师傅”，因为学习是一个过程。另一方面，同事会因为你的分享而感谢和尊重你。

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

　　10、与脚本化测试相比，探索性测试更强调测试人员的思维自由度与主观能动性。然而，探索性的自由，并不代表它是不做准备的，它也不是随机的。好的探索性测试依赖于测试人员综合应用测试策略、测试技术与方法的能力，例如，获取测试数据，掌握测试设计技术，建立失效模式，创建测试模型等。口号式的探索性测试并不能帮助测试人员成功。

　　11、我几乎每天都会反省自己当天的工作，有了哪些收获，有了什么总结，多少时间又被浪费了等。通过这样的形式，不断提升自己的信心，提高学习的效率和有效性。

　　12、软件发布与否应当综合多个方面的因素来考虑，而不仅仅是测试的意见。

　　13、要想获得成功，勤奋是不可或缺的。

　　14、多实践，不要怕失败。不管是测试领域的知识，还是测试技能，或者是测试思想和方法，测试新人都需要勇敢地去实践，许多的经验、思想和收获来自于失败的经验教训。

　　15、面对职业发展迷茫的时候问自己喜欢做什么，目标是什么，当前的工作和活动是否能帮助自己达成这个目标。

　　16、从形式、覆盖率和有效性方面来评估测试用例的质量。

　　17、成为测试牛人的三个步骤：制订目标，明确技能目标，立即行动。

　　18、在参见面试前做好准备，并在面试过程中保持坦诚。

　　19、软件测试行业的发展前景乐观，同时测试工程师会面对不少的挑战。测试人员要提高自己的技能水平和价值。

　　20、软件测试行业将持续往前发展，而测试从业人员能否在这个平台中同步前进，这依赖于测试人员自己的不断积累、不断实践与不断交流。要发展，测试人员同样需要走出去，了解当前的测试热点、测试发展趋势、测试理念与思想的趋势等。

　　简单的职业经历

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

　　邰：对，我的职业经历很简单。硕士研究生毕业后，在华为从事软件测试工作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比较多、风险比较高，从而把测试做得很好。一个人要想成为测试高手，需要具备很强的学习能力。如果只是资历高，但学习能力差，会很麻烦的。

　　（未完待续）