我希望可以自动化实现尽可能多的测试。如果只跑一次测试会使我很不舒服。如果一个程序员改变了代码并引进了一个bug，怎么办？如果我没抓住那个缺陷，只是因为我在变化之后没有进行新的测试，怎么办？我将不感到可怕吗？所以我需要使用自动化测试工具来实现多次的重复测试工作。
恩，是这样的，当我使用了自动化测试后也没有觉得舒服。测试花费了很长的时间，最终发现是我过度的使用了自动化测试。在我定义的测试里其实只有少量的测试需要自动化测试来帮助完成。多余的自动化测试在运行时是不会发现任何有价值的bug的，毫无意义！
现在的问题是怎样做合理的自动化测试呢？当我从事测试这项工作，作为一个测试员我一般会为一些产品功能设计一系列的测试。对他们中的每个来说，我需要决定哪个测试应该使用自动化测试来进行。这篇文章描述了我在权衡测试中的看法。
设想
为了使我的论点清楚，我一定要避免一次去尝试描述所有可能的测试设想。如果我挑选一个很有用的设想，清楚的描述它，你作为一个读者会很好的了解。然后留下你把论点用于你具体的项目中。下面是我的设想：
1． 首先，你应该拥有一个固定的自动化的支持。即，自动化工具是可用的。你可以不是一位专家，但是你必须知道怎样使用他们。写好配置文件。我设想你使用已有的工具进行工作，不会去使用新的工具，将一些简单的功能放到配置文件中，或者了解更多的测试自动化。问题是：凭你现有的这些可以证明你的自动化测试一定是正确地吗？现在给你这个答案还为时过早。
在其他情况下，你可能赞同在一个工程后期增加自动化测试。在本文中没有对到好与不好做辩论，但通过上下文，你会知道自动化测试的价值所在。
2． 这里只有两种可能性：完全的自动化测试，没有一点的人为操作；全手工进行的自动化测试，使用一次测试后就该扔掉了。这是一个事务上的两个极端。你可以自动化测试那些组织起来很麻烦的部分，但是其余留下的部分做手工。你可能有足够用的很仔细的文献证明能容易再跑一次手动测试。当你深刻理解了从一个极端到另一个极端的时候，你将会清楚的认识到在一个连续的统一体上特殊的测试点应该在哪里。
3． 自动化测试和手工测试是似是而非的。当然也不是总是这种情况。例如，负载测试经常需要创造大量的使用者的同时操作的情况。如果需要300个测试员同时使用一个产品，很明显是很低效的。所以负载测试需要被自动化。
4． 通过外部接口所做的测试（“黑箱测试”）。相同的analysis applies在代码级测试——在文章的后面会给出一个简短的例子——但是我将不描述全部细节。
5． 没有必要必须什么情况都使用自动化测试。经验告诉我们在测试中需要把自动化测试和手工测试完美的结合。
6． 首先你需要设计好测试然后决定它是否需要被自动化执行。实际上，自动化的需要对设计的影响是很普遍的。这让人很伤心，因为有些时候测试会被减弱只是因为使用了自动化。但是，如果你理解了自动化测试并正确地使用它，它可以给程序带来无害的调整甚至改进。
7． 你有一定量时间完成你的测试。你应该尽力在规定时间内做更好的测试。在测试开始时，会在是否要测试不那么普通的情况和需要的时间上有一些争论。
Overview
我的解决过程用到了这些问题。
1. 如果自动化执行一次测试需要的时间多于其做简单的手工测试的时间，会多多少时间？
2. 一个自动化测试过程有一个生命周期，在其生存期它必须赔偿那额外的成本。迟早这次试验可能死吗？什么事件很可能结束它？
3. 在它的生存期内，它测试出额外bug的可能性（是否在测试的第一时间内发现了bug）？怎样平衡这些不可预测的问题和代价之间的关系？
如果这些问题没有被彻底的解决，其他小的问题就没有平衡可言。
第3个问题是必要的，这个我将在大多数细节里继续探索。令人遗憾，一个好的答案需要对一个产品有更好的理解，我将解释应该怎样去把握一个准确的理解。
(未完待续)
|
