梅子：测试策略才是测试的核心

2017年3月1日晚8点半，《测试架构师修炼之道》的作者梅子，一位拥有10年网络安全产品测试经验的新任产品经理，为大家带来主题为“为什么我说测试策略才是测试的核心”的分享。以下是主持人刘静对精华内容做的实录整理。

问：我现在是开发，但是目前团队开发质量问题深陷泥潭。开发需求不断增加，上线时间不断被压缩。同时又因为忽略了质量问题，研发又不断的现网的问题所报复。研发队伍苦不堪言，但领导要的只是非理性deadline。我在尝试建立研发部门的自动化测试流程，以求让兄弟们日子好过一点。但毕竟是研发出身，不断忐忑于“这么做有效没”的疑问当中，请问您有什么好的建议？

答：我的团队也有这样类似的问题，就是产品的质量不高，领导埋怨测试人员的能力不好，没有很好的发现产品的问题，给测试的评价非常低。测试人员在这种环境下更是畏首畏尾，连问题都不敢提。

我到这个团队的时候，领导对我有两个期望，希望我可以提高测试团队的测试质量和工作效率，比如让测试人员去学习一下代码，做一下自动化。这是问题的背景，我想说的是，首先要做的是找一下当前测试团队问题的根本原因。根本原因真的是测试的能力问题吗？真的是自动化或者是看代码可以解决的吗？

这时我分析了用户反馈的bug，发现这些bug其实蛮低级。为什么这么低级的bug测试团队发现不到，测试团真的那么差吗？

我认真观察测试团队在版本测试时做的事情，发现测试团队在版本测试的时候并没有完全投入在测试上，而是在和开发确认讨论需求。

是的，在讨论和确认需求，本来该测试的时间用在讨论需求。然后开发又去修改设计，到了版本发布时间，就发布了。这时就会发现问题的根本在需求。所以当时我们花了一些力气去做需求。就一个版本，立马就看到了效果，测试的发现的问题，测试的方法都有了改善。

我举这个例子，是想建议这位提问的同学，可以深入分析一下问题的根本原因，想办法从根本上去决解问题。

问：请问文章中提到的这套策略是否在工具平台上做了定制？如果没有，您对于引导整个敏捷项目团队在工具使用和测试方面有什么好建议？

答：这套方法目前并没有在工具平台上做定制。我个人觉得这套方法就是一个测试思路，并不太适合用工具。

举个例子，测试策略和军队中的战术战略很像。军队是高度流程化的，但是对战术，军队不可能将其流程化，因为战术战略是动态的。

测试策略也是一样。我认为即使是同一个功能，在不同版本下的测试深度、测试广度都可能会不一样。

对于引导整个敏捷项目的工具，我觉得敏捷的项目管理用好看板就可以了。敏捷下的用例管理和非敏捷的用例管理也不会有什么差别，只是敏捷下可能用例的输出要求会更快，调整也会更频繁。可能在我的认知里，觉得工具没有那么重要。我自己用的要么是公司开发的，要么就是开源免费的，很通用的工具。

问：文章中提到的质量评估模型中最后的缺陷统计分析，它有没有进一步的用途？比如用于指导后续软件开发，或者用于评估团队or个人开发能力，又或者用于评估组织软件开发能力成熟度。能不能做到缺陷预防？我接触过缺陷预防，感觉有点虚……

答：我认为缺陷分析对测试来说是一项非常重要的技能，不过很可惜，好多测试都不是很了解缺陷分析。

为什么说缺陷分析很重要，是因为缺陷反应的是项目的实际状况。专家、大神对项目分析得再多，说得再好，在我看来都不如缺陷分析来得实在。

常见的缺陷分析技术，有缺陷密度分析、缺陷修复分析、缺陷趋势分析、缺陷年龄分析和缺陷触发因素分析。这些技术我们可能都听过，但是你可能会觉得没用，或者说觉得虚。原因是缺陷分析的方法不能单独用，要组合起来用才有效。

这几种方法分别是从某一些角度来对产品的质量来进行评估的。缺陷密度代表的是系统的缺陷是否发现得足够多符合预期，缺陷修复是发现的缺陷是否都解决了，缺陷趋势是是否可以再发现曲线，缺陷年龄是是否发现的是现在希望发现的问题，最后缺陷触发因素是测试发现缺陷的方法是否足够充分。

单独看某一项，根本不能说明问题，但你只要把这几项组合起来就非常容易发现项目的实际问题。

限于时间和工具，我可以在结束的时候提供这套缺陷分析方法和实例，大家可以参考，在项目中试用。

然后就是除了对当前项目的分析，对开发等组织的作用。其实缺陷分析恰恰是最能反应组织当前的技术水平的。比如前面提到的缺陷触发因素分析，说简单点就是分析测试发现问题的方法。如果从缺陷分析中测试发现的bug多，这说明测试掌握的方法多，这个团队的测试能力还是比较强的。如果方法单一，bug都是点点点的问题。这说明这个测试团队可能掌握的方法还不够，思路还不够开拓。

对开发也是一样，你可以从bug分析出一些共性的问题，比如开发bug会有很多fix on fix的情况，这可能是一个团队的问题，也可能是某个开发的问题。

bug的规律还可以帮助测试在开发方案评审的时候做缺陷预防。哪个地方从经验来看bug比较多，评审的时候可以多在这些地方问问题，这就是缺陷预防了，很实在，每个人都做得到。

问：在测试策略提到自动化测试如果不能发现缺陷，那么实现的收益并不是想象的那么大。而之前理解的自动化测试是为了对原有功能进行回归测试 并不是为了发现缺陷而开发，那么如何确定这个两者之间的平衡点 或者说自动化测试的通常是用来发现缺陷还是回归测试？

答：第一，不管我们是团队中的什么角色，测试也好，开发也好，SE也好，产品经理也好，成本和收益都是我们需要考虑的。

我们做自动化的目的，不是为了自动化而自动化，而是想切切实实的提高团队的效率，提高质量。

可以自动化的内容很多，选择哪个部分去做自动化，选择的标准就是自动化后真的可以提高团队的效率，而不是别人说的XXX地方需要自动化。

我们说自动化更多的用于回归测试，这个说法肯定没有错，但是有没有关注过这个说法的上下文，这句话是谁说的，他是在怎么样的场景下对什么产品下给出的这样的经验呢？

如果我们的产品特点是，回归测试发现的问题不多，我们当然可以不回归，而把自动化用在对产品来说更需要的地方。

第二，很多人会说自动化一般是用于证实，实际上现在的自动化技术也是可以用于证伪的。安全测试里面最常用的fuzzing，就是用的证伪的自动化测试方式，还有很多基于数据驱动的自动化技术，都可以证伪。所以，做自动化是用来发现缺陷还是确认正常修复，主要还是看产品的具体情况，不应该把自动化限制在某种目的上。

至于证实和证伪的比例，我觉得没有什么比例。我是这样操作的，我给产品制定好整体的测试策略后，我会确定哪些地方可以自动化，整体分析一遍投入产出比，从最高的入手，遇到的这项是证实就证实，是证伪就证伪。

问：对于10来人的伪敏捷app开发，三周迭代，在研发没有成熟的单元测试和代码走读体系下，目前状况是进行更多的手工测试。不过最近应领导要求需要进行自动化测试...请问领导的决策是否正确？如果不正确需要何种理由给领导拍回去；如果正确，开展自动化测试需要怎样的自动化测试策略？有没有比较成熟的方案？

答：第一，领导的决策一定是对的，如果有不认同，也要边举手边执行。

第二，如何确定自动化测试的方案，这个网上有大把的工具，可以根据产品类型、编程语言、团队能力等几方面来做选择。

其实这个问题可能更多的是说，这个测试团队对自己的定位的问题。

问：对于目前很多开发人员来说（包含测试），他们并没有真正理解或者吃透所需开发的需求。无论是对是错，不加思考的去做，回头测试找回来，说文档就这样，你要想改找产品提需求。开发/测试人员没有怀疑精神，所谓文档就那么写的，原本就是这样。对于这样的大环境，如何改进？

答：我的建议是这样的，我们要明白，任何改变、变革都非常的困难，特别是自下而上的变革。如果你是比较高层的，可能还好一些，如果你是基层的，一定要找一个能够说上话的人支持你。接下来是必要的等待，引导，一定要“顺势而为”。

我想分享一个我自己的例子，和你这个有点类似。也许对你有点启发。

我刚到一个团队的时候，我很看不惯团队里面的一些做法，我就想改变团队。这样的话，自然会把手升得很长，而且我又是新人，自然团队很多人对我不满。我就向总监抱怨，也给总监讲了当前团队的问题和我的解决思路。总监说，他同意我的观点（找到了支持），但是我应该“顺势而为”（其实总监在辅导我）。我就闭嘴了，我不说话了，自然团队对我也没有那么敌意，我也可以更好的和团队的其他同学沟通了。后来事实证明，确实也出了我说的那些问题，很多同学开始认可我了，我就可以开始逐渐做一些事情了。没有直接回答你的问题，但是希望对你有点帮助。

问：作为一开发转测试的新人，公司以测试系统工程师标准来进行高要求，面对这么大的压力，怎么淡定面对，并快速提升测试能力，制定好的学习策略。

答：开发转测试应该会上手比较快，所以不要太大的压力。

关于快速提高测试能力：

你可以分析一下你觉得还不错的测试人员发现的bug，分析一下他们的测试思路。 多看一些书，具体哪方面的书，你可以根据产品特点来选择。

问：对于团队领导那种技术能力较差，靠说话和时机走上项目管理领导岗位的人，经常对测试提的需求就是测一下，对开放的需求就是赶紧提测，目的是想让这个流程快点走过去，对提测质量不关心，对实际质量不关系，只关心bug数量，如何从测试的角度提高团队交付的质量？

答：如果有可能，建议多和领导进行一些沟通和交流，和领导建立连接。

另外，我想说一句话你可能会感到失望，bug数量确实可以从一定层面反应产品的质量，特别是产品质量水平不是那么高的情况，抓bug是一种领导策略，我们可以试着去理解一下。

从测试的角度如何来提高团队的交付质量，从问题的描述，我觉得，在现阶段，测试可以想办法多去发现那些更有价值的bug，想办法提早发现bug，想办法增加发现bug的手段。我们看看我们把bug这部分提高了，领导的风格会不会有变化。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文：《梅子：测试策略才是测试的核心》）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF92F2D0000162B8D4A017CB1438