中国软件测试专家访谈录（1）
中国软件测试专家访谈录（2）
中国软件测试专家访谈录（3）
中国软件测试专家访谈录（4）
如何把握软件质量
蔡：如何把握一个软件的质量呢？
邰：软件测试的目的是什么？不仅是找bug，而是要随时提供质量相关的信息。质量是什么？我比较喜欢的一个定义是RST课程里给出的：Quality is the value to someone who matters。做测试，首先要找到这个someone是谁，以及这个someone重视的value是什么。
问题里提到的"把握"软件产品的质量，我觉得这个词用得很好，测试就像一把尺子，我们可以通过测试衡量一个产品的质量，但不能"改变"一个产品的质量。也许测试间接地提升了产品的质量，但那不是测试本身最主要的目的。
如何把握一个产品的质量？对这个问题，我们仍然可以应用Know Your Mission的思路来回答。
第一，找到这个问题的客户是谁。是开发团队？运维团队？最终的用户？还是其他项目管理者？
第二，明白客户在意的价值是什么，明白客户希望测试提供什么样的信息。
第三，制定测试策略，考虑如何开展测试以便尽可能提供实时准确的质量相关信息给客户。
如果不思考这些问题，一上来就开始测试，例如，测试了100个用例，这能说明什么？说明被测系统的质量如何？我们知道，测试域是无穷尽的，这个数据只是part（部分），而不是整体，意义并不大。测试工程师要具有全局的视角，首先找到客户关心的value，然后据此开展测试。当你知道要开展哪些测试活动后，如果此时发现测试时间不够，没有关系，你可以按照风险的大小程度开展测试，先测试风险高的。这样，测试人员不仅可以告诉别人已经测了什么，还可以告诉别人哪些还没有测，哪些缺陷还没有修复，哪些地方还存在潜在风险。这种信息对于决策者更为重要，要想把握一个产品的质量，一定要有全局的视角。
旁观者说：对于测试人员来说，不但要尝试着站在客户的立场去使用软件，而且要了解客户在意的是什么，了解什么对于客户完成他（她）的工作是重要的，这些都是测试的重点。否则，在软件测试中平均用力，事倍功半。
质量度量过程中的数据分析
蔡：我同意你的观点，在把握软件质量的时候的确是要有全局的观点。那么，在具体做的时候，需不需要定义一些度量指标呢？
邰：需要的。定义度量指标有很多种方法，比如头脑风暴（Broadband Delphi）、GQM（Goal-Question-Metric）等。大家可以到网上找一些，然后选择一些符合自己要求的度量指标。在选择度量指标的时候，大家要明确自己的目标。你关心的是什么？是bug相关的指标，还是人员相关的指标，抑或是流程相关的指标？不要拿来就用，要多思考。
我这里倒是想要就度量过程中的数据分析谈一谈。大家知道，决定了度量方法后，就要开始收集数据。作为一个测试管理者，在面对度量结果，对这些统计数据进行分析的时候，"要更像一名测试人员"--我的意思是，管理者此时要充分发挥自己作为一名测试工程师的长处，要挑剔地思考（Critical Thinking），多疑多问，去挖掘这些数字背后的真实现象，而不仅仅是凭表面的一些数字就下结论，这种做法和Rick Craig提到的"Meta-Measure"这个词的含义很像，也就是说，去度量你的度量项。
旁观者说：不满足于已经得到的，多问几个为什么。
当我们看到产品的bug数连续很多天下降时，不要光顾着高兴。在高兴之前，多问几个问题，有哪些原因可能导致缺陷趋势下降了：是产品变好了？还是测试工作受到什么方面的阻碍导致有些地方没有办法测试？抑或是测试用例的有效性变低了？有没有测试人员积极性下降的因素在里面？等等。
无论对于测试管理者还是普通的测试人员，都要学会多问问题，挑剔地思考，逆向地思考，问各种各样的问题。James Bach在"Critical Thinking For Testers"这门课程里讲了一个简单易用的三步法，当你需要挑剔地思考时，只要问自己三个问题：
第一步，Huh？（嗯？）就是问：你说什么？你是说你执行了100个用例而且全部pass？在得到数据时要做一个确认，确保自己听到的是对方所要表达的意思。这一步可以避免交流中的误会和传递错误信息。
第二步，Really？（真的吗？）反问对方，这是不是真的？这个过程可以去伪存真。
第三步，So？（接下来怎么做？也许事实比你认为的还要严重。）和对方一起分析，基于这条信息，接下去我们需要做些什么。
旁观者说：简单实用的三步，做好确认，展开深入的思考。
所以，总结下来，测试度量要做，测试数据要收集，但当我们面对这些度量统计数据时，把它们当做Heuristics，我们不会完全Follow这些数据，而是试图去Apply这些数据，再加上我们挑剔地思考，做正确的数据分析，让这些数据为我所用。
做一个好的协调者
蔡：如何做一个优秀的测试管理者呢？
邰：这个问题很大，我没有全面地想过这个问题，这里我只想谈一点：一个好的测试管理者一定是一个非常好的协调者。他（她）对内协调测试团队，对外代表测试团队做各种沟通。
你知道，测试行业的特殊性之一就是总会有一些测试人员对自己的职业有困惑，有职业危机感，没有信心。团队的管理者应当在团队里建立积极向上的氛围，宣扬和培养正面的职业认识。软件测试是一个非常有挑战性、富有激情、充满乐趣的职业，值得为之奋斗，这是对内协调很重要的一个方面。
旁观者说：团队的管理者应当是团队的核心，成为团队的精神领袖。
对外协调就更难了，因为在测试团队之外，有不少人并不了解测试。测试团队怎么做测试他们并不关心，但是产品一旦出了问题，就会来指责测试。测试管理者应当做好对外协调，让测试团队之外的人了解和理解测试，进而理解测试团队，这会方便测试工作的开展。
比如，测试的基本原则之一"穷尽测试是不可能的"。但是，有的测试之外的管理者并不是这么认为的，而是认为测试应该抓住所有的bug。测试管理者应当通过各种方法让他们对测试有正确的期待。我讲课的时候，如果有测试之外的人来听，例如开发经理、一线的开发人员等，我会很欢迎他们，因为这会帮助他们更多地了解测试。
旁观者说：对于测试团队之外的人对测试的误解，管理者要做好解释工作。如果有的人很没有礼貌，轻视测试人员，这个时候测试团队管理者强势一些也是好事。对于虚心想来了解测试工作的，则给予耐心和友好的帮助与解释。
当然，我们不能坐等别人改变想法，而是应当积极地去与他们密切合作，在合作中增进相互了解。其实，测试外部的角色都是"测试的客户"，我们为他们提供测试服务。像敏捷里提倡的，"与客户合作胜过合同谈判"，测试管理者要想办法让这些"测试的客户"参与到测试工作中来，与他们紧密合作。实际上，我们别无选择，测试必须与其他角色紧密合作。大家知道，穷尽测试是不可能的，我们必须基于风险来开展测试。但是，谁更了解风险信息呢？我们应该看到，测试外部的人可能更了解客户，更了解需求，更了解风险所在，例如做需求设计的人，做开发的人，做售前、售后支持的人，销售人员，经验丰富的项目经理等，我们应该向他们学习，邀请他们和我们一起做产品的风险分析，帮助我们决策哪里可以测试得更深入一些，哪里可以测试得浅一些，让"测试的客户"参与到测试中来。
旁观者说：利用一切可以利用的力量，做好测试工作，就像统战工作。
如何提高测试分析能力
蔡：你刚才也提到了，你是很看重测试设计的，我也认为测试设计能力是测试工程师的核心能力之一。那么，一位测试工程师应该如何提高自己的测试设计能力呢？
邰：简单点说，其实不是如何去提高测试设计能力，而是如何去提高他们的分析能力。拿到需求后，如何得到有效的测试用例？这中间有个很重要的步骤就是分析。我们需要使用某种方法或手段去分析被测对象，真正了解被测对象，不仅能了解需求文档中描述的内容，还能挖掘出文档中没有提到的或者写错的内容，这都需要很强的分析能力。经过分析，你就会清楚，针对这样的一个被测对象，应该从哪些方面对其开展测试会比较好，这样你就明确了这次测试任务的测试目标，确定了测试点。接下来，你如何达成这个测试目标，如何测试这些测试点，就是测试设计的工作了。
测试工程师具备了分析能力，测试就会做到有的放矢。如果什么都是拍脑袋，临时决定，这样做缺乏全局观，看到的是部分，而不是整体。得到的结果也是部分，不是整体。
蔡：那么，具体如何提高分析能力呢？
邰：你知道，分析能力不是知识，而是一种skill（技能）。知识的提高可以通过看书、参加培训来实现，技能的提高只能靠多实践。我建议大家多拿一些需求来练习。例如，如果是学习Model Based Testing（基于模型的测试），就拿需求来多练习建模，甚至针对同一个需求用多种模型建模，去比较这之间的差异。如果可能的话，多个人一起学习，可以拿自己的model和别人的做比较，当然，如果能得到有经验的人从旁指点就更好了。这样的练习做多了，就会形成自己的分析型思维。
旁观者说：学习既要个人独自的努力，也要公开讨论，二者各有好处。
招聘测试工程师时的要求
蔡：你负责招聘的时候，对于测试工程师有什么要求？
邰：回想过去招聘的时候，我觉得有的时候没有招对人。如果我现在做招聘的话，我会重点考察面试者是否具备测试人员必备的一些测试技能。
比如，给面试者一个小程序去测试，或者给他一个小游戏去玩，或者问他一些问题，观察他的反应，这个过程可以体现面试者的测试思维。再比如，观察面试者的问问题的能力、逻辑思考的能力、逆向思考的能力、观察是否细致等。
还可以给面试者一个有些挑战性的任务，观察候选人的学习能力、分析能力、解决问题的能力，以及是否有面对挑战的激情。如果一遇到问题，就不知道怎么做，或者没有兴趣去解决问题，原地待命，等待领导，这样的人不适合做测试。
有一点需要分清楚的是，有测试经验并不等于具备测试思维，因为二者是两回事。
旁观者说：我在面试中比较看重发散思维能力。
在面试中，我不会问“什么是等价类”之类的直白的理论问题，因为没有意义。候选人即使不会，也会很快学会。
敏捷让测试如鱼得水
蔡：现在敏捷已经流行开来，很多公司采用了这种软件研发方法。你对软件测试如何适应敏捷有什么建议？
邰：对于这个问题，我觉得可能换一种问法更好，并不是“软件测试如何适应敏捷”，而是“软件测试如何适应瀑布模型的？”
我在了解了敏捷之后，觉得这才是软件测试应该处于其中的开发模式。敏捷中的很多理念把测试的本质充分发挥出来。
“个体和交互胜过流程和工具”强调的是以人为中心，而不是以流程和工具为中心。测试中以人为中心，强调的就是通过个人技能的发挥、通过与其他角色有效的沟通获得有价值的信息，做高效的测试，这比一味地遵守流程和规范重要得多。
“可以工作的软件胜过面面俱到的文档”，这当然是测试想要做到的。以前测试没有办法在项目早期就拿到可以工作的软件开展测试，敏捷以后，测试不用等那么久了，我们可以尽早开展测试了。
“与客户合作胜过合同谈判”，这也是测试人员一直希望做到的。以前我们想找到客户，想了解客户到底在意哪些方面，我们希望站在客户角度测试，可是很难做到，测试和客户的距离太远，我们只能把自己假象成客户去测试。现在客户和我们紧密合作，我们有很多机会和客户接触，了解客户真实的需求，我们可以开展更有针对性的测试。
“响应变化胜过遵循计划”，这也是测试提倡的。测试要基于风险，而风险是一直在变化的，我们必须拥抱变化、响应变化，而不是只知道遵循一个事先制订好的测试计划，我们的被测对象一直处于变化中，我们要找的bug也不是按照计划出现的，我们必须基于风险、调整测试，准备随时、随地发现各种类型的bug。
在我看来，敏捷让软件测试如鱼得水。所以，倒是以前在瀑布模型的时候测试需要去“适应”。
旁观者说：敏捷的好处前面邰晓梅已经说得比较细了，我这里再来补充几点个人的认知，尝试让读者朋友们得到一个全面的认识。
（1）敏捷中仍然需要编写和保留一定的重要的文档，例如主要功能的设计。有的团队在实施敏捷的时候打着敏捷的旗号不写文档了，项目信息都存在组员的脑袋里。这样做的风险是，每个人对于应该做成什么样子可能有不同的理解，而且当有员工流动的时候会有比较大的挑战。
（2）客户的参与在国内是双刃剑。有的客户做事并不专业，认为自己是甲方就随便更改需求，直接给研发团队下指令，导致研发团队疲于奔命。最好是既让客户参与，又让客户与研发团队保持适当距离，避免干扰。
（3）是响应变化，还是遵循计划，需要单独分析，看优先级。
开发和测试会融合吗
蔡：根据经典的敏捷理论，在敏捷中就不再区分开发和测试了，你觉得这两个角色在将来会融合吗？
邰：这要看情况。有的公司开发人员很强，他们去做测试也能做得很好，有的公司则不是这样。所以我想，不需要把开发和测试在角色上鲜明地分开，说开发人员和测试人员，这不是问题的关键，而是可以把它们从工作上分开：有开发类的工作和测试类的工作。从这个角度看，测试类的工作一定会存在，至于是谁去做，就要看实际情况和能力了，这在ISTQB里称为测试的独立性（Independence of Testing），可以是开发人员做测试，他们可以把测试做得很好；也可以是专业的测试人员去做测试；还可以是独立的第三方测试团队去做。
不管谁来做测试，都要保持一定的测试独立性，毕竟测试有其特有的思维方式。这里的独立性指的是精神上的独立，而不是物理上的独立（测试人员属于专门的测试团队，有自己单独的办公区域等）。
旁观者说：保持测试力量的独立的确重要，这有利于测试人员做出质量方面的判断。至于是否保持独立的测试团队，可根据测试团队的成熟程度而定。一般来说，我推荐成立独立的测试小组，让测试工程师有归属感。
对于软件测试行业前景的看法
蔡：对于测试行业的前景你怎么看？
邰：我认为测试从业人员面临的挑战会越来越大。现在测试环境越来越复杂，例如云计算环境、复杂的网络环境，被测对象也越来越复杂，bug也隐藏得越来越深，测试人员要充分了解测试环境和测试对象。
不管是测试新人还是有多年经验的测试工程师，都有必要认识自己的测试思维，不断有意识地提升自己的测试技能。
书籍推荐
1、《Secrets of A Buccaneer Scholar》，作者James Bach，中文版书名为《学习要像加勒比海盗》。这是一本关于自我教育的书，也是James本人最满意的一本著作，书虽然很薄，但James花了二、三十年时间才终于写成，书中每一篇都是精华，记录了James对自我教育、自我学习方面的认识和经验，测试即学习，相信本书能让很多爱学习的人深受启发。
2、《Lessons Learned in Software Testing》，作者Cem Kaner， James Bach， Bret Pettichord， 中文版书名为《软件测试的经验与教训》。本书堪称软件测试的“红宝书”，书中以293条经验教训的形式阐述了上下文驱动测试学派（Context-Driven School）的各种启发式（Heuristics）的观点，内容涵盖了测试认知、测试技术、测试管理、测试职业等方方面面，本书可以作为测试人员的参考宝典，随时翻阅。
3、《Essential Software Test Design》，作者Torbjorn Ryber。这是一本关于测试设计的书，书中以测试分析设计4步法的方式讲述了常用的十几种测试设计技术的应用，并辅以实例。
4、《XUnit Test Patterns：Refactoring Test Code》，作者Gerard Meszaros，中文版书名为《XUnit测试模式：测试代码重构》。对于从事单元测试的人来说，这是一本难得的好书，书中谈到了很多测试代码的坏味道，以及大量已经被证明的好的测试模式，使得测试代码更易编写和维护。
小结
邰晓梅在这次采访中和我们分享了很多宝贵的经验，总结如下：
1、能够被人所信任、所依赖，是价值的体现。
2、测试并不仅仅是发现bug，预防bug也非常重要。
3、开发和测试是一个完整的团队，不要把开发和测试分隔得太“开”。
4、如果一个产品或项目有大量的bug暴露出来，作为项目管理者要注意了，这意味着项目本身有很大的改进空间，产品的质量不容乐观。
5、测试团队的第一目标是要得到一个可发布的高质量软件，而不是找到尽可能多的bug。
6、我们要学会应用（Apply）测试流程，而不是遵守（Follow）测试流程。
7、做任何测试工作，首先要做的是Know Your Mission（知道你的任务所在）。
8、如果不知道客户的期望是什么，则容易出现偏差。要了解客户在哪里，期望的价值在哪里。
9、测试要以人为中心。不再以流程为中心，把流程、模板放到边上，而把人放在中心的位置上。把测试工程师的能力和潜能发挥出来，这是比流程更重要的事情。
10、年复一年，不断地觉得有新的值得去学习的东西，我也在一路不断成长。当你一直在学习一直有收获的时候，就会感觉很充实。我喜欢这种充实的感觉。
11、对于培养测试新手而言，我的观点是，并不一定一开始就要学习系统的软件测试知识，或者去学习测试新技术，而应当是多实践并且多思考。给他们一个测试任务，让他们去做。这对于新手来说肯定是个挑战，但是在这种情况下他们也会发挥自己的各项能力去做。当然，指导者也不是撒手不管，可以和他们一起结对测试，发现他们的不足，指导他们去做测试。通过实践，新人对软件测试的认识和兴趣都会得到提高，然后再去教他们测试理论知识，例如等价类边界值等，效果会更好。
12、人与人之间传递信息最有效的方式就是面对面的交流，比看文档、读书、参加培训效果更好。
13、如何成为测试牛人：① 描述你的目标；② 如果要实现这些目标，要掌握哪些技能和知识？③ 如何掌握这些技能和知识？
14、软件测试的目的是什么？不仅是找bug，而是要随时提供质量相关的信息。质量是什么？我比较喜欢的一个定义是RST课程里给出的：Quality is the value to someone who matters。做测试，首先要找到这个someone是谁，以及这个someone重视的value是什么。
15、作为一个测试管理者，在面对度量结果，对这些统计数据进行分析的时候，“要更像一名测试人员”--我的意思是，管理者此时要充分发挥自己作为一名测试工程师的长处，要挑剔地思考（Critical Thinking），多疑多问，去挖掘这些数字背后的真实现象。
16、测试度量要做，测试数据要收集，但当我们面对这些度量统计数据时，把它们当做Heuristics，我们不会完全Follow这些数据，而是试图去Apply这些数据，再加上我们挑剔地思考，做正确的数据分析，让这些数据为我所用。
17、一个好的测试管理者一定是一个非常好的协调者。他（她）对内协调测试团队，对外代表测试团队做各种沟通。
18、经过分析，你就会清楚，针对这样的一个被测对象，应该从哪些方面对其开展测试会比较好，这样你就明确了这次测试任务的测试目标，确定了测试点。接下来，你如何达成这个测试目标，如何测试这些测试点，就是测试设计的工作了。
19、分析能力不是知识，而是一种skill（技能）。知识的提高可以通过看书、参加培训来实现，技能的提高只能靠多实践。
20、在我看来，敏捷让软件测试如鱼得水。
21、不需要把开发和测试在角色上鲜明地分开，说开发人员和测试人员，这不是问题的关键，而是可以把它们从工作上分开：有开发类的工作和测试类的工作。从这个角度看，测试类的工作一定会存在，至于是谁去做，就要看实际情况和能力了。
22、不管谁来做测试，都要保持一定的测试独立性，毕竟测试有其特有的思维方式。这里的独立性指的是精神上的独立，而不是物理上的独立。
（连载完）