昨天我参加了一个测试朋友的聚会，讨论“什么是有效的测试”。去之前我花20分钟时间草拟了一下自己的思路。到了那里，却也没有按照预定的想法去讲，而是和大家一起七嘴八舌畅谈起来。讨论中不乏一些好的问题、分析和案例，让我意识到自己之前的想法中不清晰和疏漏之处。所以今天将修正后的想法整理一下，以记录这次有意义的探讨。

　　虽然讨论的题目是“什么是有效的测试”，但除了“什么（What）”，大家更关注的是“怎么做（How）”，所以我们将这个命题的讨论分为两部分。

　　1、什么是“有效的测试”

　　去聚会之前，我特意找了一个开发人员，询问他心目中的“有效的测试”是怎样的。毕竟，就象女人虽然比男人更多地在讨论“什么是好老婆”，但这个命题更多地要听服务的对象---老公是怎么看的。呵呵！同理，没准测试人员认为我做了有效的测试，而你服务的内部对象---开发人员不是这么衡量你的工作的呢！所以，听听开发人员是怎么想的吧！这个开发人员提供了两个很不错的观点：

　　（1）测试人员的主要精力放在重要的或者常用的功能上；

　　（2）测试人员报告的缺陷是业务上可能发生的情况，而不是逻辑上虽然可能但实际业务不太可能的情况。我想第一点更多的传递了这样的一个信息：开发人员也了解测试是无法穷尽的，所以他希望有限的时间内测试人员能够抓到要点（虽然这个要点是随着每次测试的范围、变更的性质、实施的特点等要灵活变化的，不一定是每次都是固定的那些常用的重要的功能）。而第二点则表达了在修复缺陷的阶段开发人员更愿意去做一些有业务价值的事情，而不一定是将系统做到完美。讨论伊始，我就介绍了这两个来自开发人员的观点。大家也基本对这两个观点认同，表示我们平时也大多是这么做的。

　　说到测试人员应该注重业务价值，有人补充了一个有趣的真实案例。某个版本中需求变更涉及两个模块，A模块主要是界面上的修改，B模块主要是接口的变化，测试时间又非常少。测试人员找到测试主管来沟通测试任务的安排。测试人员提出“先测试B，重点保证B，然后再测试A”。乍一听来挺有理的，因为接口的变化往往更复杂，更可能影响业务。但测试主管说“你应该先测试A。”大家可以想象一下背后的理由么？因为A模块是业务上80%利润的来源，它的一个页面错误可能都是非常严重的。B模块一天才有少量小的交易，错了马上修复也来得及。原来如此！

　　讨论中，还有人提出“所有测试都是有效的测试。因为你不能说我测试的这个功能不重要，我做的就不是有效的测试。”有趣的观点，但我可以想到工作中的一些反例来说明“某些测试是无效的”。比如，如果测试时走到了某段代码逻辑，但结果的异常并没有被察觉出来，这个类似monkey testing的测试应该也不是有效的测试吧！又如，测试“修改日志纪录”这个功能，需求说页面上所有的字段的修改都要记录到日志中。穷尽所有字段，全部修改一遍然后查看日志记录固然是保险的做法，但若字段太多时间太少你无法穷尽所有字段怎么办？或者即使你有时间但你想做更高效的测试怎么办？选择其中几个测试一下？可以，但怎么选择呢？如果你随机选择几个字段测试一下，很有可能你就遗漏了一些缺陷，对这个功能的测试是无效的。比如，时间类型的字段要做时区的转换，它和其它类型的属性就不是一个等价类，如果你没有测试这个类型的数据就可能遗漏时区转换的缺陷。从此处我们可以知道，需求的等价类不一定是测试的等价类。在场的大多数测试经验丰富的测试人员也纷纷表示“虽然等价类的概念人人都懂，但工作中要将等价类划分正确并不简单。”

　　关于“什么是有效的测试”，除了注重业务价值以外，大家对于“有效的测试是基于风险的”也颇为认同。但因为时间所限，我们讨论的目的也是为了交换想法而非统一定义，所以大家一致同意转移到讨论“怎么做到有效的测试”的讨论中。

　　2、怎么做到“有效的测试”

　　现场讨论时，大家从“测试管理和测试技术”两个方面来展开“怎么做到有效的测试”的讨论。而我本来是准备从“快准狠”三个方面去分析的，角度不同，所以交叉不多。由于大家谈得比较发散，我记忆力有限，只能以我原始的观点为脉络穿插一些大家也谈到的点了。

　　2.1 快

　　讨论中，有人提出“有效的（effective）测试”不同于“高效的（efficient）测试”，所以“测得快”不属于“有效的测试”。有道理！暂不讨论“快”的问题。

　　2.2 准

　　为了能做“准”的测试，将箭射到靶子上，我从需求、设计、测试方法&技术&工具三个方面来分析。

　　1）需求

　　（1）充分理解需求，积累业务知识

　　也许对于互联网行业来说，很多需求是测试人员可以想像的，因为你就是客户。而对于其它更多的行业，如金融、医疗、通信等，离开了行业知识，测试就象折翼的天使飞不起来。所以，充分理解用户使用系统的业务场景，了解他们想要的是什么，是有效测试的基石。