昨天我参加了一个测试朋友的聚会，讨论“什么是有效的测试”。去之前我花20分钟时间草拟了一下自己的思路。到了那里，却也没有按照预定的想法去讲，而是和大家一起七嘴八舌畅谈起来。讨论中不乏一些好的问题、分析和案例，让我意识到自己之前的想法中不清晰和疏漏之处。所以今天将修正后的想法整理一下，以记录这次有意义的探讨。
虽然讨论的题目是“什么是有效的测试”，但除了“什么(What)”，大家更关注的是“怎么做(How)”，所以我们将这个命题的讨论分为两部分。
1 1 1. 什么是“有效的测试”
去聚会之前，我特意找了一个开发人员，询问他心目中的“有效的测试”是怎样的。毕竟，就象女人虽然比男人更多地在讨论“什么是好老婆”，但这个命题更多地要听服务的对象---老公是怎么看的。呵呵！同理，没准测试人员认为我做了有效的测试，而你服务的内部对象---开发人员不是这么衡量你的工作的呢！所以，听听开发人员是怎么想的吧！这个开发人员提供了两个很不错的观点：（1）测试人员的主要精力放在重要的或者常用的功能上；（2）测试人员报告的缺陷是业务上可能发生的情况，而不是逻辑上虽然可能但实际业务不太可能的情况。我想第一点更多的传递了这样的一个信息：开发人员也了解测试是无法穷尽的，所以他希望有限的时间内测试人员能够抓到要点（虽然这个要点是随着每次测试的范围、变更的性质、实施的特点等要灵活变化的，不一定是每次都是固定的那些常用的重要的功能）。而第二点则表达了在修复缺陷的阶段开发人员更愿意去做一些有业务价值的事情，而不一定是将系统做到完美。讨论伊始，我就介绍了这两个来自开发人员的观点。大家也基本对这两个观点认同，表示我们平时也大多是这么做的。
说到测试人员应该注重业务价值，有人补充了一个有趣的真实案例。某个版本中需求变更涉及两个模块，A模块主要是界面上的修改，B模块主要是接口的变化，测试时间又非常少。测试人员找到测试主管来沟通测试任务的安排。测试人员提出“先测试B,重点保证B，然后再测试A”。乍一听来挺有理的，因为接口的变化往往更复杂，更可能影响业务。但测试主管说“你应该先测试A。”大家可以想象一下背后的理由么？因为A模块是业务上80%利润的来源，它的一个页面错误可能都是非常严重的。B模块一天才有少量小的交易，错了马上修复也来得及。原来如此！
讨论中，还有人提出“所有测试都是有效的测试。因为你不能说我测试的这个功能不重要，我做的就不是有效的测试。”有趣的观点，但我可以想到工作中的一些反例来说明“某些测试是无效的”。比如，如果测试时走到了某段代码逻辑，但结果的异常并没有被察觉出来，这个类似monkey
testing的测试应该也不是有效的测试吧！又如，测试“修改日志纪录”这个功能，需求说页面上所有的字段的修改都要记录到日志中。穷尽所有字段，全部修改一遍然后查看日志记录固然是保险的做法，但若字段太多时间太少你无法穷尽所有字段怎么办？或者即使你有时间但你想做更高效的测试怎么办？选择其中几个测试一下？可以，但怎么选择呢？如果你随机选择几个字段测试一下，很有可能你就遗漏了一些缺陷，对这个功能的测试是无效的。比如，时间类型的字段要做时区的转换，它和其它类型的属性就不是一个等价类，如果你没有测试这个类型的数据就可能遗漏时区转换的缺陷。从此处我们可以知道，需求的等价类不一定是测试的等价类。在场的大多数测试经验丰富的测试人员也纷纷表示“虽然等价类的概念人人都懂，但工作中要将等价类划分正确并不简单。”
关于“什么是有效的测试”，除了注重业务价值以外，大家对于“有效的测试是基于风险的”也颇为认同。但因为时间所限，我们讨论的目的也是为了交换想法而非统一定义，所以大家一致同意转移到讨论“怎么做到有效的测试”的讨论中。
22。 2. 怎么做到“有效的测试”
现场讨论时，大家从“测试管理和测试技术”两个方面来展开“怎么做到有效的测试”的讨论。而我本来是准备从“快准狠”三个方面去分析的，角度不同，所以交叉不多。由于大家谈得比较发散，我记忆力有限，只能以我原始的观点为脉络穿插一些大家也谈到的点了。
2.1快
讨论中，有人提出“有效的(effective)测试”不同于“高效的(efficient)测试”，所以“测得快”不属于“有效的测试”。有道理！暂不讨论“快”的问题。
2.2准
为了能做“准”的测试，将箭射到靶子上，我从需求、设计、测试方法&技术&工具三个方面来分析。
(1) (1)需求
1) 充分理解需求，积累业务知识
也许对于互联网行业来说，很多需求是测试人员可以想像的，因为你就是客户。而对于其它更多的行业，如金融、医疗、通信等，离开了行业知识，测试就象折翼的天使飞不起来。所以，充分理解用户使用系统的业务场景，了解他们想要的是什么，是有效测试的基石。
2) 大胆质疑需求
需求有问题，我们的箭就可能射到旁边的靶子上，命中也也无用。所以测试人员作为用户的代言人，为了确保需求的准确，应该在充分理解需求的基础上大胆质疑需求。如:需求的假设是否经过确认和验证，万一出现某极端情况的补救措施是否可行等。
3) 补充需求
需求一般只讲我们要系统做什么，而不会明确提到不希望系统做什么。这类反面的测试用例就有待测试人员的补充。而有些异常情况、特殊数据的处理更需要测试人员提醒并明确是否是系统范围和如何处理。
4) 具化需求
就象object
diagram比class
diagram更能发现设计中可能的偏差，对于复杂或者抽象的系统逻辑，测试人员通常应该使用具体的测试数据去实例化需求，及早准确传达测试意图，避免误解了测试要点。
(2) (2)设计
1）测试人员应该从可测试性角度对设计提出要求。比如，接口测试时如果对方系统的环境长期无法保证稳定，我们设计上又没有提供mock等手段，莫说有效的测试，恐怕是测试都无法开展。
2）测试人员应该了解设计，从而在测试设计时明确如何测试才能测到点子上，如何才能正确划分等价类，如何才能实现完整的覆盖等；也能在测试执行前预测缺陷可能较多之处，从而更合理地分配测试时间。
(3) (3)测试方法、技术和工具
从我的角度，纯从测试而言，测试人员可以这样去尝试做到更有效的测试：
1）持续寻找当下最合适的测试方法、技术和工具，以期用最小的代价找到尽可能多的真正有价值的问题，不遗漏重要的问题
有效的测试是基于本次测试上下文的测试。上下文大至项目立项的意义，小至一个字段的长度验证，都需要具体情况具体分析，找到最能进行当前有效测试的方法、工具、测试集合。讨论中有人提出测试风险的评估、测试优先级的考量决不仅仅是测试管理需要考虑的，而是每个一线的测试人员都要在每天工作中不断考虑、不断调整的。于我心有戚戚焉！
2）快速重现问题，协助定位问题
有效的测试应该能准确描述缺陷发生的关键步骤和数据，帮助快速重现问题，和协助定位问题。在对缺陷把握准确度上，我们最容易看到有经验的测试人员和新手的差别。所以训练自己重现问题、定位问题的能力可以帮助我们做更有效的测试。
3）在验证缺陷修复时，阅读开发人员对于缺陷根本原因和代码修改范围的说明，从而做到对缺陷修复的更有效的测试
4）上线前利用测试覆盖率分析结果补充测试，上线后重视生产环境问题的反馈和真实业务数据纠偏测试，持续优化自己的测试
我们往往发现内部测试中一些低优先级的缺陷被迫带到了生产环境，而用户竟然很长时间也没有报告或者抱怨。遗憾的是，我们做了大版本发布后却总有不得不马上做一个hot fix来修复的紧急问题是内部测试遗漏的。所以，如何将有限的测试资源准确聚焦是一个值得持续探索的课题。讨论中，大家对这一点也颇为认同。我们目前采用的方法如上线前利用测试覆盖率分析结果来补充测试，上线后重视生产环境问题的反馈和真实业务数据来纠偏测试等。
2.3狠
有效的测试不仅仅脉要搭得准，下手也要狠。比如，探索式测试里提到的“问你的应用程序一个最难的问题”就是一个不错的有效测试手段。根据你的应用程序的具体情况，模拟极端的大数据、
多用户、 高并发的情况，考虑服务器、网络等异常情况，甚至乔装一个可能的破坏者进行攻击，都是比较“狠”但如果不狠便没有效果的测试手段。“狠”这个观点我没有拿出来讨论，在此要问问各位元芳怎么看。*_*
