专访刘琛梅：如何全面提升测试效率和质量？

lsekfe

51Testing：1、作为我们网校的最受欢迎讲师之一，很荣幸今天能与您进行一次深入的交流，在开始之前，请您向大家介绍一下自己！
　　刘琛梅：大家好，我是刘琛梅。我有10年+的工作经验，但我的工作经历和涉及的领域都比较单纯：10多年的软件测试经验，涉及的产品领域都是网络安全产品。曾在华为（华赛）就职7年，担任测试架构师，测试经理，之后在绿盟科技就职，担任下一代防火墙测试代表。不过目前在职位上有个新挑战，我开始担任下一代防火墙的产品经理。但是对测试10余年全身心投入，测试已经深入我心，很高兴，职业的变化让自己有了新的挑战，也让测试变成我的爱好，让我可以站在新的角度去思考它，获得新的感悟。
　　技术上，对IPD、敏捷、测试策略、测试分析和设计，质量评估、自动化测试、性能测试、可靠性测试等都有一些涉及和研究，当然，还有网络安全方面的知识技术。
　　51Testing：2、您最近写了一本书，主要是讲测试策略的，您是怎么想到写这本书的？书中提到"对合适的用例做自动化，才有可能提高效率"，要如何才能做到"刚刚好"的测试，来提升测试效率？
　　刘琛梅：是的，我最近出了本书，叫《软件测试架构师修炼之道》，内容是围绕测试策略来展开的。这本书写得很辛苦，从开始策划到执笔，到出版，整整三年时间，其中初稿->推翻优化重写都经历了3次。
　　我们稍微搜索一下，就会发现目前在测试领域，几乎没有"测试策略"这个题材相关的书。我为什么要写这本书呢？源于我在工作中观察到的一些事情：
　　很多测试同学都非常关心各种测试方法和测试技术，发现一些新技术新方法后，都很热衷于把这些技术用到项目中。但实际效果，无论是自身在测试技术的提升方面还是对被测对象测试效果的提升上，都不是那么尽如人意。
　　遇到过一些有很长测试经验的同学，沟通时发现他们对当前的被测对象的业务很熟悉，或是对流程很熟悉，但是如果他们换一家公司，换一个产品，换一种业务，他们的经验就变得好像失效了。
　　很多测试同学都觉得手工功能测试很低级，想做自动化测试。努力做了自动化测试后，却发现自动化测试实际做起来问题很多，不仅很难从根本上解决之前的问题，反而又会引入新的问题。
　　这些事情引得我开始思考测试的核心能力是什么。是各种测试方法和测试技术么？是对业务的了解么？是自动化测试么？…..仔细思考后，我觉得这些都不是。对一个测试者来说，测试的核心能力其实特别简单直接，就是"有能力能够把产品测好"，有能力就是去做当前测试应该做的那些"正确的事情"，而不仅是"把事情做好"。如何去找出测试中应该做的 "正确的事情"呢？这就需要我们从整体上，系统的分析思考被测产品，根据产品当前的状况、特点去来确定测试内容、测试方法、测试技术，做"刚刚好"的测试。这就是测试策略。
　　只有想清楚了测试策略，才能从根本上提升测试效率和测试质量。否则投入越多，效果反而可能会适得其反。举几个我亲身经历的事情：
　　拿测试设计来说。我曾经仔细很认真的研习过各种测试设计的技术，然后在一个产品中，很规范的去运用这些技术，花了很多功夫，加了很多班，设计出来了我认为很完美的测试用例。但是最后这些我认为完美的测试用例，并没有发现太多的问题。
　　有个版本我负责了两个功能，有个功能看起来很简单，功能也很独立，所以我并没有花太多功夫去准备这个功能的测试。但当我实际测试的时候，却发现这个简单的功能问题太多了--这个功能是位新员工实现的，经验不足，往往是改一个问题，还会引出新的问题，直到产品快发布了，这个简单的功能还没有做好。
　　我曾经花了很多时间把很多简单的用例都自动化了，但执行时却苦不堪言--运行、确认结果并不是一件轻松的事。而且我发现很多自动化用例，好像没有必要要执行这么多次呢。
　　这些事情都是我亲身经历的事情。我是一个勤奋的测试者，我追求技术，并在项目中去运用他们。在我没有意识到测试策略的重要性之前，我大部分的付出，其实并没有对产品带来匹配的收益，有时候还会因为做了这些"提升"的事情，分散了精力，造成了测试遗漏，影响了产品的质量。当我们认识到测试策略的重要性之后，我才知道并不是所有的功能都需要按照统一的测试设计方法去设计--因为他们的优先级不同，测试的深度和广度是不一样的。我们不应该对每个功能都去追求完美的用例，而是应该追求在符合当前状况的最合适的用例。当我认识到测试策略的重要性之后，我才认识到，对测试重点的判断，不应该只是看实现的复杂度，还要看人，要多维度、更加全面的去识别、处理风险。当我认识到测试策略的重要性之后，我才发现我们常说的"用自动化来提高策略效率"这个观点是多么的肤浅，对合适的用例做自动化，才有可能提高效率，否则，干得越多，对效率反而是种拖累。当我认识到测试策略的重要性，我才认识到，测试并不应该总是做加法，看起来面面俱到的测试，实际上却是最无能为力的--测试根本就不可能穷尽所有的情况。敢做减法，才能把精力真正聚焦到最需要关注的地方，这才是一个好的测试真正应该修炼的能力--策略！
　　51Testing：3、有小伙伴反应他们现在项目面临的就是大家做的很累，但是项目每次还是延迟，质量还不好，十分影响测试效率，这个问题要如何解决？
　　刘琛梅：对这个问题，我的建议是把测试策略做起来。测试策略就是专门解决这个问题的。
　　51Testing：4、一个有效的测试策略包含哪些阶段，每个阶段又有什么不同点？要如何制定每个阶段的测试策略？
　　刘琛梅：事实上，很多团队其实都会在项目开始制定测试策略或者测试方案，然后…..真的就没有然后了--测试策略或者测试方案写完后，就没有人再去看这些内容了。这样的方案或者策略究竟能够在项目中起到多大的作用，不言而喻。所以测试策略要想起到作用，就要能够贯穿项目始终。在项目开始时，我们可以制定一个总体测试策略，来帮我们系统的分析测试的范围，测试的目标，测试的深度和广度，测试的重点和难点以及测试的先后顺序。在测试即将开始时，我们可以进一步把总体测试策略，根据测试分层，再细分为每个测试分层（或者说测试阶段）的测试策略，确定每个阶段要做的测试活动，要进入这个测试阶段要达到怎样的条件以及每个测试阶段完成时要达到的小目标。开始测试后，我们可以对每个版本都制定一个版本计划，把每个测试阶段要完成的小目标，再分解为每个测试版本需要达到怎样的目标，并在每个版本测试完成时，检查每个版本的测试目标是否达到了，如果目标没有达到，需要怎样调整测试策略。
　51Testing：5、您在华为和绿盟都有从事管理岗位，您能从管理的角度来来谈谈测试管理该如何进行？具体要怎么把控？
　　刘琛梅：这个问题我觉得是个特别大的问题。从管理的角度来说，主要包含下述这些内容：
　　商业目标、项目生命周期管理、项目组织模型、项目整体管理、价值管理、风险管理、范围管理、时间管理、质量管理、目标成本管理、财务管理、人力资源管理、采购管理和项目文化管理。
　　对测试管理来说，有些知识域是需要特别关注的，主要是价值管理、风险管理、范围管理、时间管理和质量管理，因为这些知识域和测试有直接关系。但了解其他的知识域也是很有必要的，最大的好处就是可以理解其他领域的主要工作，可以和其他领域的人员更顺畅的沟通交流。
　　如果测试管理者只是把自己定位于做事务性的管理，是远远不够的。不管你是基层管理者，还是中层、高层管理者，"关注人，让团队成长"，都是测试管理者最重要的事情。我认为一个测试管理者至少需要兼顾如下几个角色：
　　"教练"：引导者。
　　"牧羊犬"：督促者。
　　"守门员"：把关者。
　　测试管理者需要像"教练"一样指引团队去不断深入掌握新的测试技术和业务知识，不断提升和总结测试方法，提高测试效率和测试质量。这需要管理者有"提要求"的能力，能够把一个任务，最后要做成什么样子，才算是真正做好了讲清楚，根据结果来评定团队成员的贡献，而不是根据感觉或是苦劳，这点尤为重要。
　　此外，测试管理者还需要是一位"督促者"，需要在团队中制定一些"规范"或者"底线"，并将其形成团队独有的文化。
　　最后测试管理者还是一位"把关者"，测试管理者不一定要事必躬亲去做每一件事情，但他必须要有在关键时期能够接住任意活的能力。就像金星曾经说过的一样，她可以跳任意的位置。测试管理者也是一样，有能力在任何情况下，依然可以对产品质量负责，对产品进度和产品效率负责。
　　51Testing：6、现在有很多团队都尝试过自动化测试，但一般都是浅尝则止，很难坚持下去。您前面说到您也很擅长自动化测试，能我们说说自动化测试在实际测试中有多少占比？测试团队又要如何解决自动化测试开展困难的窘境？
　　刘琛梅：产品不同、团队自动化的成熟度不同、所处的自动化测试阶段不同，都会使得自动化测试在实际测试中的占比不同，所以这个问题很难有个统一的答案。
　　对第二个问题，我想，无论在哪个公司，自动化测试开展起来都是困难重重的。
　　很多人都会认为自动化测试只要有个好的自动化测试的工具或者平台，有几个会编码的人把脚本写起来，自动化测试就算开展起来了。但实际真没有这么简单：自动化测试工程师可能会发现，手工测试工程师给的测试用例写得不是看不懂，就是很不详细，或者用例有很多错误，没有更新，根本无法直接按照这些测试用例去自动化，于是自动化测试工程师就只好根据自己的理解去写脚本，但是这样一来，手工测试工程师又有疑问了，这些脚本到底能测试哪些东西，我这些个用例还需要再执行么？
　　但对自动化测试工程师来说，这些只是开始。确认自动化测试结果一直就是件烧脑的事情，要用很复杂的技巧才能勉强确认到。开发的接口或者UI又老是变化，脚本总是在改，天天忙得要死，脚本数量却不见涨。一眨眼这个项目就结束了，开发好的脚本却还没有跑两遍，而且下个版本也不大可能会直接用，还得再改。
　　很快我们就陷入了自动化测试的窘境之中。但造成窘境的根本原因却不是自动化测试，而是它的上下游，需求、设计、测试。
　　试想一下，如果团队一开始就充分考虑了自动化可测试性方面的需求，开发在编码是时能够遵循并实现这些内容，那么我们就可以大大减少那些需要使用复杂技巧才能编写的自动化脚本。如果手工测试者在写测试用例的时候，在用例的粒度、输入输出上都可以考虑自动化的特点，脚本编写的复杂度自然就会降低，可靠性自然也就提高了。如果需求，开发的接口或者UI都可以很快确定且不再频繁变化，自动化脚本的开发时间就会变得更充分，复用性也会大大加强。
　　所以我们不妨分析一下那些造成自动化测试项目窘境的根本原因，然后从根本上去解决这些问题，显然这些问题不一定就是自动化的问题，而需要整个产品团队一起来协调、支持和配合，自动化测试才能真正逐步走出这个困境，发挥应有的作用。
　　51Testing：7、如果普通的手工测试人员，没有过任何自动化测试的经验，想要变成一名自动化测试人员，您会给他什么建议？
　　刘琛梅：如果是没有自动化测试经验，又想在后面可以做一些自动化测试方面的事情，那可以从一些"半自动化"的事情开始，找找感觉。这时你可以想一下，你每天都有哪些例行的事情，比如发日报，每天需要跟踪的bug，每天要刷新的测试用例，定时升级被测系统等等，然后就想办法把这些事情一件件的自动化看看。有本书叫《Python编程快速上手-让繁琐工作自动化》可以参考。实现这些可能并不难，但确可以切切实实的提升工作效率，这种成就感能够帮你建立起自动化的感觉，或者说是种兴趣，在我看来，当你真正拥有自动化测试的兴趣，而不是强迫自己应该去做自动化，你就已经变成了一名自动化测试工程师。
　　但如果你做这些事情让你觉得痛苦，没有任何思路，提不起任何兴趣，我觉得可能你真的就不适合做自动化。事实上，我认识很多优秀的测试者，一点都不会做自动化测试，就做手工测试，但他们却可以对需求、场景有非常深入的理解，可以发现产品很多有价值的问题，也能获得产品团队的尊敬，也发展得很好。
　　所以我的建议是，尝试，然后自己去感受是否真的需要去变成自动化测试工程师，做不来也会很好。
　　51Testing：8、现在软件测试工具种类十分多，测试人员要如何选择合适地测试工具提升测试工作效率？
　　刘琛梅：测试工具很多，测试人员当然无需全部都会用，但是多掌握一些测试工具是必要的--我个人的经验是，每当我用了一个新工具，就一定可以发现产品新的问题。使用更多的工具可以大大提升测试人员的测试能力。
　　至于测试人员应该如何选择测试工具，我倒是没有特别的经验好分享。我自己喜欢找有相关测试经验的前辈推荐，多找几位，收集到的工具就够我研究一阵子了。另外我建议测试者有解决测试方法的能力--即在对一个测试点，找不到现成的测试工具的时候，可以自己开发实现。

自动化小白

看完感觉对我帮助挺大的，我就是在第7条的徘徊者。感觉对以后的发展很有帮助。