0.2.8 失败分析
当测试失败时分析原因可能会花费大量时间，对自动化测试失败的分析所花的时间要多于手动测试所花的时间。例如，手动测试时，在发现bug前你都知道做了些什么，所以在发现bug时就掌握了bug的上下文信息。然而，当自动化测试失败时，你可能仅仅知道测试的ID，而并不清楚这个测试到底是做什么、它所处的位置，以及发生了哪些其他的事情。在写bug的报告前需要重建bug的上下文信息，这需要一些时间。考虑到这种情况，自动化测试应该记录一些日志，这些额外的信息对需要检查测试失败的人是很有用的。失败分析在第20、23、27和29章中讨论。
0.2.9 自动化测试是否用来发现bug
0.1.1节提到过，发现bug对于测试来说是一个好的目标，然而对于自动化的回归测试来说，找到bug却不是一个好目标。然而，在一些示例中自动化确实可以发现新的bug。如果自动化能够允许运行一些测试，而这些测试不能通过其他手段运行（因为手动运行它们需要大量的时间而且不实用），那么自动化就能增加被测软件的测试覆盖率，而且还能发现那些其他方法找不到的bug。
基于模型的测试（model-based testing，参见第9、14、24、28和29章）不仅能够在执行测试时发现bug，还能在模型的开发过程中发现bug。
当自动化测试能够运行那些依靠手动几乎不可能执行的长序列的测试时，如猴子测试、可靠性测试和探索性自动化测试，就可以发现手动测试发现不了的bug。
如果想要记录哪些bug是通过自动化测试发现的，而不是通过其他方式发现的，第11章对bug跟踪系统提出了一些建议用来找到这些bug。第27章有一些有趣的统计数据，比较了自动化测试发现的bug数量（<10%）与手动脚本测试和探索性测试发现的数量。
0.2.10 工具和技术方面
0.1.9节从管理的角度讨论了工具，同时也必须考虑到这些工具的技术方面。如果要开发自己的工具，就可以用这些工具做你想要做的事情；理想情况下，你将会得到适用于需求的最好的工具。然而，开发工具需要进行大量的工作（通常比预计的更多），于是通常需要在期望得到的功能和可以利用的资源之间做出折中。
可以尝试的是使用多个工具来达成某个目标，而这个目标无法用单独的工具来完成。在采用这些工具时，要充分挖掘它们的用途。
那些和当前测试领域密切相关的工具能保证正确使用这些领域知识，而且使用起来更容易，也更少出错。
如果你在考虑测试件该使用什么编程语言，那么就挑选那些开发人员已经熟知的并且受欢迎的编程语言。这样就能更好地得到开发人员的帮助来解决测试件中出现的问题。
你也需要仔细注意测试的环境；测试发现的失败应该是真正发生的问题，而不是因为在环境中忘记了加入一些因素。很多环境因素的设置也能自动化地进行，这也有效地减少了人为错误。
还需要关注测试和软件的同步，尤其是当被测系统并没有限定只能使用标准的GUI控件时。虽然有很多工具对于同步提供很好的支持，并不是在所有的情况下工具都能很好地解决问题。而且有时无法充分地解决所有同步问题。这也就意味着软件中有些部分是不能应用自动化测试的，至少目前不行（或许未来会出现新的技术手段来解决这些问题）。
第7、8、14、17、18、19、24、26、27和29章讨论了这些问题。
0.3 总结
自动化测试不再是件奢侈品而成为系统的必需品；随着应用程序和系统变得越来越大、越来越复杂，仅仅依赖手动测试已经无法全面地测试系统。随着技术的进步，测试也必须进行调整——而且要快。
本书描述的自动化测试的实践包含了在21世纪第二个十年开始时测试自动化的情况。这些故事中既有痛楚也有荣耀，既有失败也有成功，既有卓越的想法也有难以置信的决定。倾听这些故事并且注意这些作者学习到了什么，这样你自己的测试自动化的实践便更有可能取得成功！
（未完待续...）
相关链接：
