|
使用自动化测试会失去什么？
通常创造一个自动化测试往往要比手工的进行一次测试所要花费的时间多。（注释一）而费用上的微小的变化取决于这个产品和它的自动化设计。
l 如果产品需要经过一个GUI(图形用户接口)被测试，那么你的自动化测试计划手稿中就需要准备驱动GUI接口的部分（本质上要有简单的计划），在很多时候一个自动化测试其花费会和手工测试差不多。
l 如果你使用GUI capture/replay工具来记录产品内部接口间的交互并通过这些构建一个脚本的话，自动化测试相对来说是便宜的。但是，当因为错误导致需要重头安排自动化测试的时候，当需要组织整理测试的一些文档记录的时候，当测试进程陷入到bug中并且不断恶化的时候，等等这些，自动化测试就不像人工测试那样的廉宜。这些小细节下引起的成本的追加往往会不容易使人们注意它。
l 如果你现在正在对一个编译器进行测试，那么使用自动化测试的成本就会比使用手工的要多一些，应为大部分的时间会为编译器写测试计划，来使编译器根据计划进行编译。这些计划无论会不会被重复使用都的编写。而往往这些计划都不会被重复使用。
如果你的测试环境对使用自动化测试非常适合，而使用自动化测试的花费只比手工测试多的10%的话。（我认为这种情况很罕见。）这意味着，一旦你自动化实行了十次测试，做一次手工测试——对产品做一次独特的测试——这在用户提出要求前是不可能实行的。如果自动化测试的花费是更大的，那十个自动化测试可以替代运行十个、二十个或者更多的手工测试的话，应该如何掌握和处理呢，我们会发现什么？
所以，我们第一个测试自动化的问题应该是这样的：
如果我对它进行自动化测试,我会失去手工测试中的什么?我会丢掉多少bug,自动化测试的严格性？
依赖于你的设计，其答案是会变化的。假设你是一个电信系统的测试人员，在这里对其质量要求是很高的而且测试的预算会是非常充足的。你的答案可能是“如果我用自动化执行这个测试，我将或许会失去三个手工测试点。但是，我做好了非常漂亮的完整的测试设计工作，我清楚的认识到那些额外的测试只会对现有的测试产生一些价值不高的变化。严格的说，他们应该分别的执行，因为我真的怀疑他们也许会发现新的严重的bug。”对你来说，自动化测试的价值是很低的。
或者你正在测试一个产品需求和代码在最近几个月内在不停变化的工程的1.0版本。你的答案可能是“嘿！我没有时间去尝试为每一个明显的变化都重新做一次测试。这种情况下，我将会使用自动化来进行测试，同时我要保证其发现新的严重的bug的机会降到最低。”对你来说，自动化测试的价值是很高的。
这是我衡量自动化测试价值的标准——可以第一时间或预先发现bug——这看上去似乎有些古怪。人们通常是用做这项工作所花费的时间来衡量自动化测试的代价的。我之所以使用这样一个衡量标准是因为自动化测试的目的是在下一次运行中能够发现更多的bug。发现bug的数目体现了自动化测试的价值，因此衡量自动化测试价值的标准也因该统一到这个上面来。（注释2）
________________________________________________________________________________________
（注释1：有一些例外。例如，或许测试可以被制成模板。用一个工具可以通过处理这些模板中的表单来驱动产品的测试。而向模版表格中填入数据做自动化测试要比做手工测试快的多。看看[Pettichord96]和[Kaner97]的风格，如果用手工测试的花费会很大，我们就不会去牵扯它。但是需要小心：人们往往会低估自动化测试的花费。举个例子来说，将需要输入的数据填写到表单中会是一件非常easy的事，但是自动化测试的结果的验证却会是一件花费很大的事情。感谢Dave Gelperin在这个问题上给我的提示。）
（注释2：在我和Cem Kaner的谈话中，第一次让我感到应该这样衡量自动化测试的价值。Noel Nyman指出这是约翰 Daly规则的一个特别的情形，就像你总是问题：“我在做测试的时候还有哪些bug没有发现？”）
在预算上需要注意的地方
我想让你尽可能的准确估计在你的自动化测试中平均会出现的bug数是多少，并将结果告诉我。你的答案不应该是“0.25”或是“0.25±0.024”。你的答案应该象这样“我会努力减少bug数的出现”或者“我的bug决不会再次出现”。
稍后，你会被要求估计一个测试的生命周期（生存时间）。这个答案应该是这个样子的："不会超过软件的发布时间" 或者 "a long time" than "34.6 weeks".
然后，你会被要求估计在测试生命周期内可以找到多少个bug？答案依然是模糊的。
最后，你会被要求对自动化测试和手工测试模糊估计的结果做一个比较并做一个结论。
这样做有用吗？
回答是肯定的。当你考虑选择谁的时候，需要做出这样的比较——也许不是在表面上做的——尽管是一些少的比较模糊的数据。我的经验是快速的回答这些问题希望可以引导一次优秀的测试，不去管答案是否精确。我在这里倾向于不需要精确的去回答这些问题，但是有用的问题和容易被误解的问题必须要做精确的回答，不要给别人带来误导。
How Long Do Automated Tests Survive?（一次自动化测试的生命期会有多久？）
当代码做了改动之后，自动化测试显示出它的价值所在。除了一些极少数类型的测试以外，在代码未作任何改动之前去做重复测试是一个浪费时间而且没有任何效果的做法：它会找出一些bug，但和你第一次做测试所发现的是一样的。（例外，像所用时间测试和压力测试可以概略的用同一中方式来分析。因为简单我忽略了它们。（I omit them for simplicity.））
但是一个测试不会永远的持续下去。一些观点指出，产品上所做的变动很可能破坏一个测试。这个被破坏的测试将不得不做出修改或是被丢弃。我有一个很合理的近似值是这样的，我们去做一个测试的修改和抛弃已有的测试而重新编写一个新的测试的价值是同样的（注释3）。但是无论在变化后你做什么补救，如果修改和重新编写都不能达到要求的话，我认为放弃它而使用手工测试会比较好一些。
简而言之，测试的有用寿命看起来像是这一样:
当决定是否做自动化测试的时候，你必须估计出存在多少会影响测试的代码。如果你的答案是“不多”，那么自动化测试在发现bug上的表现会特别的出色。
你需要一些背景知识来估计一个测试的寿命。你还需要了解一些代码影响测试的途径。在这里我们从一个特别简单的图表开始：
________________________________________________________________________________________
（注释3：如果你使用录制工具能够将一次测试重放，那样的价值将会比在开始测试时记录其预期结果要有价值的多。花一些时间和精力在这个上面是在一次测试中是很有必要的。如果你要修改测试脚本，你需要正确地理解这个脚本，修改它测试它，确定你没有可能揭露的所有问题。你会发现新的测试脚本不可能完成老脚本能做的所有功能，所以可以将一个修改测试保留新旧两个测试脚本。如果你的testing effort已经确定下来，那么去修改一个测试要比从头开始写一个测试要好的多。这些将会不影响你在纸上做的工作；那样做会减少自动化测试所需要的花费。这一切的前提是你要清楚的认识和把握一次修复所需要的代价，人们往往会把代价估计不足。）
(未完待续)
|
