Meszaros：降低测试自动化成本需减少编码量

Jolt大奖图书作者 Gerard Meszaros（腾讯科技摄）

腾讯科技讯 10月26日消息，2012全球软件开发大会（杭州站）进入第二天议程，Jolt大奖图书作者Gerard Meszaros发表主题演讲，分享如何从自动化测试里面获得更多的价值。他认为，对软件进行自动化测试可以降低成本，简化测试流程，没必要做很多人工测试，同时还有利于帮助人们找到测试重点。他还表示，自动测试的安全性还可以提高软件开发者们的信心。

对于如何降低测试自动化成本，Gerard Meszaros指出，关键点是要减少编码量。他认为，降低测试自动化成本可以让产品可测试性更高。在做测试的时候，需要确保测试本身简化，测试文本很简单。如果在测试里面的细节描述太多的话，它更有可能出现重复。所以我们没有必要在测试编码里面包含这么多细节，它只会使我们测试变的更加冗长和反复。同时，要来减少运行测试成本的话，也必须去驱除所有手工做的步骤，我们的测试将是完全自动化，我们必须执行自动化设置，建立相应环境。

此外，Gerard Meszaros还强调测试的可维护性至关重要。他发现写一些软件特色时间花的越来越长。不仅如此，他还发现测试者们一般花很多时间解决以前测试里面所存在的问题，有80%、90%的时间都是花在维护以前的测试上面的。

今年有来自于腾讯、阿里巴巴、淘宝、盛大、天翼、百度、陌陌、支付宝等公司的一线技术专家，以及国外的Facebook、Tumblr、PayPal、RightScale的讲师等国内外技术专家出席了本次大会。

腾讯科技作为大会战略合作伙伴、官方指定微博平台，全程图文、微博直击大会盛况。

以下是Jolt大奖图书作者 Gerard Meszaros演讲实录：

Gerard Meszaros：大家早上好。欢迎大家来到今天早上的会议，今天上午我讨论的内容主要是关于自动化测试，如何从自动化测试里面获得更多的价值。首先我先想介绍一下自动化，自动化的测试方面的成本是什么样？能给我们当来什么好处？如何最大化它的价值？在今天演讲当中有一些案例介绍，就是如何让我们测试更加有效，而且让它的维护成本更低，可以获得更高的价值，让大家更容易理解。

这张图大家昨天都见过，我们之所以想把我们的测试一部分做成自动化，是因为我们想省一些时间，我们不想在这方面花太多时间。一般来说，在这个项目结束的时候，我们会把这个软件交给我们测试方，让他们去做一个测试，然后他们会做一个决定，看看这个软件到底能不能在实践中使用。具体来说，我在用之前，你一定要把这里面的缺陷帮我们解决好，比如说功能性、缺陷报告，缺陷补丁是不是已经打好了。有的时候会说我们现在时间不够，我们现在资金已经不够了，产品必须要上市了，在这个时候，大家觉得我们的软件就可以发出去了。

有的时候大家觉得这个时候我们还没有完全准备好，但是这个软件都已经出去了，我们有其他解决方案吗？在其他的一些生命周期之中，我们也讨论过，在开发的时候，下一步要测试一下它的功能性，它的质量也要特别注意。我们的测试者，他们的测试很多时候就是做一个形式，他们必须在发出去之前最后做一次测试。如果一般来说，这种情况没有什么问题，我们就可以直接把这个软件放到生产线上。当然，有的时候会有一些缺陷报告，那个时候我们会发现在这个软件里面需要增强更多的特色，这样反复几次，在这个过程之中，我们让产品质量有所提高。有的时候我们会说好，这个时候可以了，我们已经感觉不错了，我们这个产品有足够功能性，可以生产了，下面我们还会继续重复这样的流程，看看是否还需要更多功能性。之所以这样做非常重要，大家看到我们会发布很多不同版本的产品，有的时候我们并没有太多的时间做很长很完整的测试，有的时候我们会让这个产品更快上市，更快收到一些反馈信息，质量在第一天就要保证。

我们在看一下我们的成本和价值。我们所做的这些自动化测试能给我们带来什么好处？我们花这么多时间能带来什么好处？在成本这边，我们可以看到，首先你要建立这些测试，测试本身就是一些代码。你还需要解决测试缺陷，还要运行测试、检验结果，在此之后，你会发现有一些问题，会把这些缺陷修好，再进行测试，最后还需要做一些维护方面的测试。在一个常见系统之中，有的时候我们会发现其中有一半的代码都是测试代码，我们需要维护这些测试。我们在这方面付出什么努力，就可以得到什么好处，否则我们就会有一些问题，我们不仅是没有带来价值，我们是带来了成本，所以我们必须要考虑到成本方面的问题。我们做这样的测试能带来什么价值？首先我们可以省事，我们没必要做很多人工测试，还可以帮我们找出测试重点。而且它的一个安全性，可以提高我们的信心。还有可以给我们带来其他方面报告，每个部分我都会做详细介绍。

我们看成本方面内容，看看怎么可以降低成本，关键点是要减少编码量。我们在做测试自动化的话，一般传统的方式就是使用一些商业的测试工具，这个时候，你经常会重复的，大量重复的，非常不明智的编码，你去运作几次之后，它就会坍塌，你就要重新去做。使用商业工具测试非常不稳定，而且非常昂贵，并且会创造很多麻烦。所以我们必须考虑怎么样能够做好测试的工作在我们的测试编码里面做软件的工程，并且我们确保我们产品是可测试性的，可测试性很高，这也是为什么我们要去做测试自动化的模型。

我们来看看可以降低测试自动化成本的话，就是让我们的产品变的更可测试性，可测试性更高。我们做测试的时候，我们确保测试本身简化的，测试文本很简单，里面只有很简单的一些描述。而且在产生变化的时候，它的可变化也是简单的多。如果我们在测试里面的械劫描述太多的话，它更有可能出现重复。而且我们每一次发生变化的时候，我们都要到测试编码里面做相应改变。所以我们没有必要在测试编码里面包含这么多细节，它只会使我们测试变的更加冗长和反复。要来减少运行测试成本的话，我们也必须去驱除所有手工做的步骤，我们的测试将是完全自动化，我们必须执行自动化设置，建立相应环境。我们也可以检查测试结果，这过步骤也是自动化。我们希望把运行测试的成本是零，每一次运行成本都是自动化，从而可以降低成本。我们可以保证我们的编码的质量是很高的，在编码检查之后，我们还要进行自动化的进奏，所有这些都是自动化测试。测试的故障应该是一个例外，这是一个驱逐故障的工具，我们确保测试都在这个流程当中检测并且排除。整个测试构架一旦出现故障以后，会通知你说有问题，测试失灵的时候，你会得到相应的一些信息。我们得到太多的信息之后，这只是会给我们工作添加麻烦。我们要确保我们带运行测试的过程当中，它的成本几乎是零。我们出现测试故障时候，我们要让我们测试非常精细告诉我们，到底哪里出现故障了，所以我们必须有非常明晰的故障信息，来高知我们到底发生了什么，这样一来，我们知道发生什么，以及为什么会发生这样的实践，并且我们可以确保测试设计非常好，而且它可以一次一次去运行测试，而且所得的结果都是一样。我们不需要随机的、不稳定的内容，有的时候测试会有故障，这个时候我们会考虑为什么失败？这个时候就是非常不高效的，所以说我们的测试在这个方面一定要非常稳定。

我们在来看看价值方面的内容。显而易见的，如果价值很高的话，我们做所有的事情就是值得的。我们希望降低我们要去对于故障处理的时间精力，我们看有些人做TDD工作，他们在不同层次做TDD工作，在单位层面，在部件的侧面，在测试层面，他们会报告若他们会花很少时间排除故障，世界上都是这样子。如果说你想升值的话，你必须要降低你的排除故障工作。如果说要达到这一电，不要做TDD。如果你想花很长时间去鼓掌排除的话，你希望马上进入到下一步功能作的话，你必须要不断的从这些测试这边得到一些反馈，确保你在项目当前进。

如果说我们能够更常规的、更经常的去运作我们测试的话，我们就能更快的得到一些反馈。这样做也可以省掉我们很多精力，就是一直尝试解释哪些方面出现问题。事实上，我们也经常会去考虑在上一个小时里面，我到底做了哪些工作，才使这个新的问题产生。如果我每30秒运作一测试的话，我就记得住上30秒我做了什么工作，我就可以把上30秒工作重新做。所以说测试频率越高，效果越好。这就是为什么我们要这么自动化的测试，而且经常去做测试。另外，我们在一些稳定的固定的循环过程当中，把写自动化的测试可以减少我们很多精力。有一些工作我们可以看到，出现有问题的话，我们必须一次一次重做。一旦我们测试做完了之后我们必须重做。所以从这个角度来说，我们可以更好的管理，看哪些问题必须去纠正。我们也在这个故障上花很长时间找根源，看接下来一步在哪些方面做的更好。我们也花很长时间管理我们客户，所有这方面的工作量都可以减少，如果我们的测试能够变的自动化的话。

另外个这些测试如果可以自动循环的话，我们的工作也可以减少很多。我们看它到底来能做什么？我们可以剩很多精力做阅读编码，就是说你压知道编码应该做什么，你就要去读这个文本。这个编码怎么样去做，你要去读文本。但是你知道，它应该怎么去做，你要去读文本。你在读文本的时候，这个时候如果你的测试做的很好的话，你的阅读量可以减少。如果你能很容易去读你的测试的话，可以知道你的系统行为应该是什么样的话，就证明你的测试就写的很好了。

给大家看一下例子。看一下关注点，这是我们可以得到的一些测试。我们接受的测试是系统水平的测试，还有功能的测试是会给到开发团队的，会告诉开发团队下一步功能是什么。还有部件层面测试，这会帮助我们下一步我们将会执行哪个部件，或者说哪个情景，我们部件会支持，他会给我们更多任务清单。还有单位层面测试，这也是让我们更好的去理解一些逻辑，并且可以更好的执行下一步功能。所以说我们不会直接去做很多不必要的步骤，因为我们面前已经有很好的测试。对这个测试是不是要增加新的编码？有的时候并不需要，可能在未来需要这个功能，但是现在不需要这么做。因为目前我们这么做的话它不会给你回报，因为现在不需要，所以只要在需要的时候增加这一步。这也是测试的好处。

在很多的极限变成团队里，如果能把一个编码去除掉，而测试不会失效的话，这个时候你有要这么做。有的时候你问这些测试怎么办？这就是一坏消息，这就是我们为什么要确保测试在每一步都要被执行。我有一个朋友，在牙医那面看到上面有一个告示，上面有一个微笑的大猩猩，在这个海报上，我是不是要把所有牙齿刷一遍，下面有一句话说不，你只要刷那要保留的牙齿有就要好了。我们是不是把每个编码都测试？不是，那些你不像保留的编码不要对它测试，你甚至不用写这些编码出来。当然，这也是一个理由说为什么我们必须要去编写编码，因为它可以帮助我们捕获所有的错误，特别是回归性的测试。你也不希望把一些现存的编码取消，这个时候测试的功能就是变化的探测器，它会告诉我们过去是可行的，如果编码改变之后，还是可行，或者有变化，有一些变化是我们故意设置在那里的，我们希望它的行为里面有关这样的变化，所以我们看这个测试结果的时候，我们说是的，这是我们所期望的，这是一种没有记录下来的特点互动，但是我们希望看到这样的变化。有的时候我们看到这个变化不是我们所期望的，在这种情况下，我们就不会去对这个编码做太多的风险，说如果我们这样做会怎么样。有的时候我们只是去改变编码，看看未来会发生什么。通过这种手段，我们可以更好的去学习编码，通过测试之后，可以了解到会产生什么变化。你可以看到，我们有更多的信心，我们的压力也会减少，另外我们不用花太多的精力去应对这些的压力、这样一些偏执。我们只要当变化产生的时候，再去考虑怎么解决，所所以这些测试给我们更大的安全感。

还有一个价值是无形的，每次我们运行一个测试的时候，我们总能得到回报。作为一个开发商，如果我们工作几个小时，如果没有一点回报反馈的时候，我们会很担忧。如果你做了几个星期，没有反馈给你说你做的很好，这个时候，你的感觉就不一样了。 如果你写了很多编码之后，101次测试通过，他们都告诉你每天每分钟你都在进步，你都在做很多好的工作，这都是非常积极的反馈。

当然，也很难去把所有的这方面的好处都告诉大家，但是却给你一个很高的工作满意度。如果你的员工有很高工作满意度的话，他也不会去离职。不然的话，你又要花很长时间培训员工。关键的价值就是说你很糟的运行，或者经常性云运行测试是有很多好处的。如果说你发现很难去编写测试的话，为什么很难编写测试？如果测试很难编写的话，我们就会延误测试的编写，我们就会说我不知道应该怎么写测试，所以我还是编写编码吧。如果我去编写编码的话，这个时候我们测试就更难写了，这就形成一个恶性循环。你可以看到，这是一个非常不好的恶性的循环，编码写的越多，测试就更难写，这样就不烟雾你写了四测试的时间。这里唯一能改变的是大家的思路，我们需要有一些关注。首先要改变我们的行为，我们在编写测试的时候，要尽量早一些，在这里面，我知道有的时候会有一个问题，大家觉得会写测试比较难，而她们比较复杂。就难以理解，难以维护。除了难以测试之外，我们发现测试本身的代价也是比较高，它的成本比较高，而且难以维护。所以它是一个两方面的问题，对于开发者来说，我们的关注尽快得到一些反馈意见，我们需要尽快进行测试，希望测试方给我们尽快提供反馈意见。这样，我们就不要给自己提出一个借口，让我们不能更早的来写好这些测试。

有的时候如果说我们节几个小时没有做好，后面可能要花很多时间把里面某些代码改好。如何让我们测试进行更迅速一些？我们要实现定义好一些子集，比如说事先制定好，这些子集需要做测试，同样，我们把这些测试集代码直制定好，这些都非常重要。定义字迹方面，所有网络服务器测试是多少，元件测试多少，以及我们一个服务器的可靠性，它的一个性能测试应该是什么样的。所以首先我们要先做一些测试才可以，我们把这些测试准备好，这样测试才可以进行比较高效迅速。在这里面，我们知道有很多的一些配制的数据，我们应该配制好，具体来说，对于数据库里面每一个互动来说，我们基本需要做十个步骤，实现把这些测试安排好。这些测试会需要很多时间来运行，有的时候我们会把内存里面一些数据库的数据对它们进行修改，这是同样的测试。我们在内存里面考虑它里面的内容，除此之外，还要考虑到真实数据库里面的内容。

可维护性为何如此重要？前面我也说过，应该是在1999年或者2000年初的时候，在那个时候，当时我们做很多单元测试，在项目进展之中，当时我也注意到一件事情，就是发现写一些软件特色时间花的越来越长，后面有一些不同的原因。所以当时我们也是花了几个小时，把软件的特色加进去，在接下来一个特征就是越来越长，越来越长。为什么？当时我就问这样一个问题？我问开发者，我说如果你写一个新的测试要花多长时间？写测试代码要多少时间？总体时间是多少？后来我发现他们所花的时间比新的代码、新的测试时间还要长。后来我们发现他们一般花很多时间解决以前测试里面所存在的问题，有80%、90%这样的时间都是花在维护以前的测试上面的。就是出现了这样一个问题，我就逐渐开始考虑这个问题，我认为首先测试代码要写好，我们在进一步看一下这个问题之后，我们会讲代码。如果这是我的一个项目，我应该怎么去做？我的生产代码怎么写。在这个基础上面，我会加一些测试自动化方面的工作，我们会发现中间会有一块突起，这个突起就是我们所花的功夫。也就是说，花的这个功夫就是与作为学习如何写出很好的测试代码。

在这条线下面，就是我们可以减少的一些功夫。在突起这块，我们可以看到，这是我们额外增加的成本和花费的力气，我们在写测试代码，有的时候是一个很好的测试，在这一期间，我们会看到这实际上就是我们在成本方面花费比较多，我们的回报率比较低的这块就是在这个地方。通常来说，我们如果说测试做好的话，我们这个节省的时间比我们花在学习上的时间还是要多的多。要确保我们这个软件测试各个方面可以很方便得到维护。如果说测试完全结果得不到的话，我们会发现我们得到的价值就会更好。而且到后面生生产期间测试成本会更高，而且你的老板会告诉你把这个工作停下来，他不会让你继续做下去。如果你这样作的话，会让你的成本有所增加。即使在这种情况下，提的质量变好了，但是他们还是会让你停下来。在这个方面，我们就要问一个问题，我们如何尽量减少曾是方面成本。我们就是让我们测试变的简单、间接、容易。同样的，我们测试的时候可以达到最高级测试，通过测试方面来验证我们所存在的问题。

同样的要看到，举个例子，现在有很多的一些测试并不能很好的证明我们这个代码真正的意义。我们需要在测试的时候考虑到在某一个域里面使用同样的语言。比如说内部DSL，我们必须定义一个DSL，我们在里面用一些关键词，比如说你是用C，或者是用什么其他语言要定下来。你要做的工作，你每次测试只有一种测试状态，每一次就是你只关注一件事情，在里面，你需要考虑到一些术语。同样，你也要避免你不像测试的任何代码。除此之外，让你这个测试看起来非常清晰可见，要有很好命名法。在这里，我们可以看到是一些维护的测试代码。右边是经过一些清理之后的代码，怎么让左边变成右边？就好象一张发票一样，上面有客户的名字，有运输如其、地址。如果我们回到这个测试代码里面，如何把它简化，把任何不必要的内容去掉。我们先看这块，这块需要做一个验证，看一下它的结果如何。我前面给大家提到要关注GIVEN，这个测试起点在什么地方？就是它的数量，它所说的，我们看的并不是很清楚。这是WTF，你们知道什么意思吗？有的时候大家会问为什么在这里会出现这个代码，这是结果代码。我们可以看到这里面有很多内容，它到底代表什么意义？有的时候我们可以用逆向工程的方法找出它是怎么写出来的。

为什么在这里加入这个代码？为什么加入真和伪？这只是一个很好的例子。通过这个方法可以改进我们的代码。这些内容起什么作用？具体来说这就是可以看到我们这个发票方面的一些值。这跟行为有什么关系？如果我把这些做了改变，可能这个地方的数值就会发生变化，但是我们不像发生这种情况，这是一个非常脆弱的代码。我们可以把整个对象做一个比较，每个领域做一个比较看一下，所以在你做这个加入内容的时候，你会看一下，这样我们在这里就没必要把它们进行一次又一次重复。这里我们会创建出我们自己需要加入的内容。现在可以看到，把一些复杂性已经从我们的测试里面移出去了。这样可以做直接比较。

在我们测试里面，为什么要有条件性的测试逻辑？条件性测试什么意思？具体来说它们是两减不同的事情，我们一次只能做一件事情，为什么在这里我要加入一个条件性测试逻辑？如果不这么做的话，可以让我们代码里面加入没比较的复杂性。我们看一下我们有适合的横竖，这是一个无条件的逻辑。我们回到整个测试里面看一下里面的不同部分，现在在这里我们已经可以看到很清楚，在这里描述，WHNE只有一行就可以了。WTF代表什么？我们把这个代码放大，很多地方是可以删除，有很多人认为这些非常重要，这些清楚代码它的目的让大家可以更好的理解它们的作用是什么，所以最好把它们留下来。但是如果说这些删除没作用的话，其他部分也会失效。如果说是，在什么地方这块失效的话，到那个时候我们在做测试，也就会失效。实际上这就是我们一个测试数据的泄露。所以它一点也不可靠，而且对我们也没有帮助，所以要去除他。还有一个选择，把它做的可靠性高一点，但是这样是不行的。还有一种细分、拆分的方法，把它拆出到测试以外。现在所有编码再去俄运行，我们看这样做还是不行，我们还是要找到其他解决方法。更好的一个方法是这样一个测试，我们把这个数据库分贝，你可以看到在测试过程当中消失了，如果测试这个范围之外及我们可以不断追寻我们这些对象，找到真实的测试对象进行测试。这样我们就有了一些编码，就像这样一段一样。你要确保它运行非常合适，而且我们在测试里高复杂性又进一步减少了。

再回到我们整体测试。你可以看到这样的测试就简化多了。我们可以去看到这个测试里面的复杂性最大的一块就是在于GIVEN，就是如果怎么样。我们看看这段测试，里面包括很多的一些数据，我们会自己先问自己一个问题，就是所有的这些价值，它是不是会去影响测试应该产生什么行为？我们回到刚才一段话，就是如果这个信息在测试里是不需要，或者并不是很重要的话，我们一定要把它去除掉。为什么？因为这就是我们的测试的构架所需，我一定要简化。当然，并不是在所有测试里面每一细节都要这么做，我们要把这些编码去除，替换掉。因为它们只会生成一些随机的价值。有的时候一些价值我们多次使用，这个时候我们只是零时用一些这个测试，并不是把这个测试循环进行使用，这样一来使测试出现一些问题。我不想看到这样的测试，所的这些可以看到，都是无关的内容。我们必须把所有的内容都去除到，都看不见，都搬出到测试之外。还有一个方法，就是提取法，提取法是我们的好朋友，它可以帮助我们大大提高编码质量，包括产品的编码。这就是提取法的好处。我们要把重要内容提取出来，在这里，我们把测试的对象提取出来，并且创造一个命名的地址，就是说我不在乎这个人，我需要这个信息，但是我不介意它的一些价值，这些对我都是无关的。

你可以看到，这是一些编码，我们这里有两个地址，我们创建的是一个客户，它有两个地址。我们创建一款产品，我们的发票。另外，我们在提升质量，你可看到这样一来，我们测试可以挤到一页当中，这就足够清晰了吗？我想说还不够，我们还要问这个客户的地址是不是会影响量的行为？如果说它会影响的话，我们就会看它的影响是什么，如果不影响的话，我们要把这部分内容去掉，因为这部分内容只是客户要求的，但是它没有任何影响，它是无关的，所以我们再把它去除掉。我们就是一系列的去问很多问题，在我们测试编码里面看这部分内容是不是需要？为什么我需要？我为什么需要客户？客户会不会对我们增加的项有影响？去问这些问题。有的时候可能这个客户是一个比较高级的客户，他们每次买产品的时候，都能得到折扣。这个时候，这一项的价值不一样。在我们测试里面，它只是一个简单添加的测试，所以这一段是是无关的。所以可以看到，慢慢我们的测试越来越短，所以底部的编码我不想上他在这里，我自己问它是什么功能？我能不能解释清楚这段编码？我们写的测试并不是为了电脑而写，我们是为了要去阅读这个测试的人而写的，而他们每一次你写一条测试，他在未来就要读十次。所以要尽量简化，让测试非常简便。

这段话讲什么？我们怎么用简单的英文、中文、法文去描述？这就是我们要思考的问题。其实这底部的编码就是一个意思，就是我们只是需要一个项，在发票上只有有一个项目就足够了。所以我们把它简化了，这是我们现在这个测试的母羊。你看到我们有五派可执行的编码，这个大大简化了。所有整个测试就做完了，我很喜欢这样的流程，有的时候我们可以比这个做的更好。

如果说有一个空发票的时候，这个时候会增加一排，这个时候就说我能不能把测试条件阅读清楚？我们再回去仔细读，看能不能做到。我们在这个方面可以做进一步改进？怎么改进？怎么把我的域的语言变的更加精简。我们可以把这个测试重命名，包括时间还有产品价值都是我们的项，在最后一排里，我们怎么描述所期待的项，已经在我的方法里定义出来了。我们有一系列方法清单，我们可以在里面看到我们所覆盖的测试条件到底是什么。我们有GIVNE这些条款都包含进去了。我们可以在最后两排里，把这些条款精简到一条，把它写成一句成词。我们可能把它写成无关的命名，甚至我可以把它写成如果说有任何产品，有任何空的发票的话，就是说这段话都是如果含义里面的一段内容。

这就是一个例子，我们怎么样能够去精简清理非常繁复罗嗦的编码，使它更容易管理。我们来看看那种字体更喜欢写？是喜欢写25行、还是4行？当然，你也可以从一个4行测试这里更容易去复制一个新的测试出来。如果说我们要做一个复制产品的话，我们该怎么做？我们要复制前一个测试，这个时候，我们要把这里做一些改变。我会说我这里要放两个量，第一个和第二个，结果就是我们最后只有一个QUANTITY。我写下一个测试的时候，我要花更长的时间去描述。如果说有一个空的发票的话，在不同产品当中用Q两次的话，会得到这样一个结果。

我们带单位测试已经完成，还有一些部件的测试也是按同样的方法去撰写。还有更多技术测试，我们也是通过这些编码清理。我们很多部件测试里面也包含很多的工作流的内容。我们怎么样完成整个金字塔构架自动化测试？我们希望用过提取方式进行，我们单位测试是最底层做的，它的水平是很低的，但是里面包含的细节非常多。还有一个高层面，就是工作层，它包含范围是非常广泛的，所有测试都在高层级进行这些高层级细节不会包含很多，还有中层级测试，这些测试层级并不是很高也不是很低，所以你可以看到，范围和包含的测试细节是成反比的。如果说一个测试包含又是层级高，又是细节太多的话，就很难管理和维护。

我们来看一个例子，给大家看银行系统测试严案例。在这些测试里面，客户可以自己去布置，在什么时候交易，满足什么条件下，客户会被通知。其中包括交易金额多少，贷方还是借方等等，所以这些都是原则。最底下黑合资进行测试，我们要做很多测试工作。这里有一个例子，我们的客户所接触到的工作，在这里，我们列举出来他的帐户，我们在当户这里增加一行，加入一些帐户细节，关键点就是我们这里没有用户的界面，但是我们希望更好的不去使用这个用户界面进行测试。这是一个测试工作流的例子。大家看到客户登陆了，系统会列出这个客户可以启用的三个帐户。其中有支票帐户、存款帐户、信用帐户，他的通知都没有启动。客户对所有场地所有交易的疑问，必须要去通知，达到这个条件以后，客户就要被通知。我们要确保通知真的是能够执行，我们确认这个帐户看到877为宗旨的帐户被启动了，金额达到的话，是不是会发邮件。对于任何地点任何帐户超过1万美金的，都会通知到客户。这就是一个建立的测试，这是我们希望系统去做到的一系列工作。

这边是我们处理的交易，我们有一系列交易在进行。在这些帐目上，有不同的金额，不同种类的交易。在底部可以看到，如果说出现这个事情，我们将怎么做。这里面有一些左，有通知，不是所有这些情况都会通知，如果系统运行好的话，低于1万美金的交易是不需要通知的，如果看到这个测试的话，看它有很多步骤。你可以看到这个原则和哪些交易要去通知之间的关系并不是在这个阶段里面，你一定爱很仔细的删查这个数据。这就是我们通过用户界面写测试出现的问题。如果把是放在API里面，我们就是测试整个系统，我们在测试整个黑匣子，这样一来很难去写让人容易理解的测试。我们怎么做？我们想去改变我们怎么样测试归责原则的方法。我们来回到不同的层级的提取，我们希望从左手边测试的地方搬到另外一个地方，我们要写的测试是更精简的。首先我们把这个工作流的测试里面细节去除掉，搬到偶上角。

在此之后会到不同方向看一下范围，看里面的规则是什么样。这里我们写的同一个措施，这里面细节已经减少，如果需要通知，它的一个法值是1问美元，在这个值上面，我们需要发出通知。在这里，我们把它的范围给缩小了，我们不希望这里有太多的数据让大家难以理解。我们会看到一个比较低的数量，它不会发出警报。我们测试的是工作流，而不是规则。我们可以减少相关的细节。我们看到这两者之间的关系，除此之外，我们可以通过其他测试工具来做。我们减少范围，这里我们是把商业规则进行配制，是客户、帐号、标签，在这里使帐号的法值，都是一万美元。在下面是1000美元，我们可以看到，这里是抑制的条件，这这个值的情况下，我们是否通知客户？答案就是NO。我觉得这是按照规则可以做出比较完整的测试，可以完全约过我们前面所说的工作流。在这里，对于工作流的测试，它的时间比较长，所以在通过这种方法，我们测试的速度可以提高两到三个数量级。在这里可以设置不同的标准规则，甚至会有数十个，甚至数百个不同测试。在这个层级上面来进行表达，我们觉得容易的多。我们这样测试的话，我们首先要有我们的通知组件，把它们加入到后面的内容，这个具体来说就是我们的通知规则里面，我们是否应该发出通知？在接下来交易里面户做出一个答案。

我如何设置这些规则？因为这些测试它们想通过这些规则，然后它们可以进入这些组件，这样我们可以进入数据库，来进入这些数据让它们进行互动。让这个设计的确可以做到可测试，我们需要把规则测试作用整个交易一部分，通过这个方法，我们做测试的时候，让它们留在本地测试之中，没有必要进入后来的数据库。在数据库里面知道真实的一个交易流程可以从数据库来到一个通知组件，这样他可以进入我们当地接口里面，通过这种方法，它的测试性能特征已经做了改变，我每秒可以做数千的测试。这是一个小的变化，可以产生很大的影响。通过这个方法可以很简单的做测试，比如说24小时之内可以得到一个回馈信息，所以你需要问自己的一个问题就是在定义这些测试的时候，是否还有其他的一些组件，它是依赖于其他组件的？有的时候有一些规则的组织器，就是数据苦，所以在这个地方，你需要在里面加一个组件，在规则的数据库里面加一些内容，做一些配制。或者把它通过界面给移过去，在这里面有不同方法去做。总之都可以做到，我们是否需要花格外的努力？基本上来说是零。我们在写这些测试的时候，我们要做改进，在这个方面，可以说这样带来的价值是非常高的。

我再给大家距最后一个例子，前面看到所关注的商业规则以及细节，以及非常寨的范围。可能在这个两者中间需要在交易层级做一个测试。在这里我们可以制定客户之间的互动，我们可以用用户的界面来进行配制。这样它可以发出通知，这是所有的一些测试。这些测试它们都是集中在一个交易上面，在这里并没有非常详细的细节，跟这个规则测试里面详细的细节是不一样的。所以在这里，我们是需要找到合适层级的一个测试，这样它可以符合你的系统，有的时候复杂情况需要四级，不同的层级可以包括你所想描述不同的行为，你想从高级开始，把它给缩小。比如说如何在这种情况下减少范围？如果你需要更多的细节，你可以把它进行放大。在这种情况下，会对这个配制元件进行互动，这就是我们把它们通知用户界面来进行测试。总之，我的目的就是要通过自动化的测试来增加价值，减少成本。我们需要减少成本，首先需要把测试加在里面，要写测试，确保这个代码是可以测试的。里面包括不太多的细节，还有里面不要有太多虫，我们要做比较小的，简单的测试。我们需要减少测试的成本，要见谅自动化去做。因为人在做一方面事情，机器可以做自动化测试。测试应该得出我们需要看到的结果，通过这个方法，它的检测成本是零。同样，我们测试要可以得到很好的修理或者维护，除此之外，自动化测试让我们可以关注重点，在我们写测试的时候，我们要特别关注它的可维护性。我们应该增加价值，可以通过写测试的时候加入我们关注的重点，这样可以减少成本。下一步需要做什么？同样我们要确保我们测试像安全网一样，这就好象是我们测试之中的一个步骤。我们也应该增加价值，就是说减少我们的工作量，减少调试的数量，同时减少积累下来没有处理的工作，比如说减少测试故障的次数。同样我们可以来增加它的一个功能性，有的时候可以通过代码做分析，除此之外，还可以测量我们进展情况。

我再总结一下，我们应该有意义考虑我们如何进行测试，如果最大化价值。

现场提问：对于一个已有的遗留的大型活动，这个活动年龄很长，可测试性很差，以前从事没有做过自动化测试，对于这样大型系统，怎么样做自动化测试？第一个步骤是什么？投资回报最高的测试工作有哪些？

Gerard Meszaros：比如说一个大的系统如何做测试？我们做什么样的测试可以得到最好的回报？首先要问自己一下，你这个系统哪一部分需要做改变，先问自己。如果一个逻辑需要改变的话，这个地方就是你的工作重点。有一些方法可以去做，但是一般结果都是测试起来非常困难，效率比较低。有可能你可以作为一个最低层级的安全网的作用去做测试，但是你并不会得到一个非常好的测试结果，你真正需要做的就是需要考虑一下。有的时候就是说你做测试的时候，你关注你要改的地方，就是这个意思。把改的东西放在盘子上面，把老的代码放在新的测试里面，我们系统里面不会做改变，写一些测试，比如说加入新的功能性以后会怎么样。实际上这个麦克写过一本书，就是关于老的遗留系统怎么做测试。你在里面可以把一些老的代码抽取出来，做一些测试。如果你一直这样去做的话，你看一下你到底需要改变哪些代码可以得到新的特性，看一下什么地方做的改变最多。比如说这个地方是您老的代码里面有很多漏洞，这块因为你改变的不多，你可能没法做很多的测试。你要看一下可以测试的一些新的元件，新的组件是什么样的。

作用已有的老的系统，是否能达到这样的目的，很难说。