0.2.4　测试结果和报告

　　评估测试的结果是测试所做的最基本的事情：如果不关心结果是什么，那么它就不是一个测试！然而对自动化测试的结果进行检查并不是一件显而易见的事情，尤其是当检查结果是以屏幕截图的位图存储时（要尽可能避免），对结果进行自动化检查就更加困难。

　　工具不会告诉你一个测试通过还是失败；它仅仅能告诉你测试结果和你期望的结果是否匹配。如果期望结果就是错误的，那么工具可能很“高兴地”认为所有的测试都通过，即使它正在做错误的事情！

　　有时，自动化测试可能愚弄你，让你认为它们正在检查一些东西，而实际上没有——通过的测试通常不会有人进行检查，然而这有时会带来严重的问题，正如第15、19和29章所讨论的（第15章称这些测试为“僵尸测试”）。

　　对于测试结果的报告应该让收到报告的人能够理解这些测试；为此可能需要做一些额外的工作来过滤以及解释原始的测试结果，但是这些工作很值得，因为这能让各类人员对这些测试有着更好的交流。这些主题在第3、5、13和20章中讨论。

　　有时通过使用部分的预言（oracle），自动化测试仅仅能够检查测试结果的一部分而不是所有。例如，探索性的自动化测试（第28章和第29章）、猴子测试（第24章）和可靠性测试（第13章），可能会检查系统是否还在运行而不是检查系统的结果是否正确。当能够自动地生成大量测试时，仅仅检查系统是否能存活下来也是很有价值的。

　　更多的关于测试结果和报告的讨论见第3、5、10、13、14、17、19、20和29章。

　　0.2.5　对测试进行测试：审阅、静态分析、对测试件进行测试

　　自动化代码（包括脚本）也是软件，正如所有的软件一样，它们也会有bug，并且必须对其进行测试。对自动化测试件进行审阅，甚至检查，也能帮助找到在测试件本身中的bug和问题，并且保证自动化测试与它的目标是一致的。这还能够有助于团队内沟通知识，让团队人员更好地了解测试件的细节。不需要审阅所有的事情——选择一个具有代表性的测试方案，并且与利益相关者对其进行审阅是一种很有效的方式，有助于确定正在进行的工作是否正常。

　　正如第15章所述，另一个来自软件开发的技术，是对测试脚本的静态分析。静态分析工具能够发现代码（包括自动化代码）中的bug，这些bug在评审过程中以及测试中可能发现不到。虽然静态分析不能找到所有的bug，但其发现bug的速度很快而且成本很低。

　　这些主题在第1、5、7、10、15、17、21和29章中讨论。

　　0.2.6　对哪些测试进行自动化

　　第2章和第12章证明了对那些没有价值的测试进行自动化是没有意义的——首先，保证将进行自动化的测试是值得自动化的；其次仅仅自动化那些重复使用的测试。

　　首先应该对哪些测试进行自动化？那些对测试人员来说执行起来很无聊的、那些普通的并且重复的、或者那些非常复杂的测试，都是开始自动化的最佳候选测试，但是也要根据当前最需要解决的问题来进行选择，总的来说，要对那些能够为测试带来价值的测试进行自动化。

　　第25章给出了一个用于决定是否对某个测试进行自动化的检查列表。知道不要对什么进行自动化以及应该对什么进行自动化是很重要的。过多地进行自动化也会影响自动化的结果，因为这可能使你难于获得一些“快速的回报”（quick win），虽然这些回报能更有效地证明自动化的价值。

　　这些主题在第2、8、19、20、22、25和29章中讨论。

　　0.2.7　自动化测试不仅仅是执行测试

　　大多数人认为测试执行工具仅仅是用来执行测试的工具。然而，要达到好的自动化，仅仅对一项活动有着工具支持是远远不够的。书中很多案例研究都讲到，创造性地思考通过工具能支持自动化过程中的哪些活动——不论是通过使用传统商业工具还有内部实用工具、脚本、宏等，都能给项目带来惊人的收益。第19章主要关注这个主题，除此之外，第3、4、5、14、21、22、24、25和29章还包含了一些有用的小窍门和主意。

　　在自动化测试过程中经常被忽略的一个领域就是，将手动测试引入到自动化过程中是很有用的。第21章讲述的例子很有趣，它在改进自动化的同时也加入了对手动测试的支持，在第1、8、12和19章也讨论了这个主题。

　　另一个常被忽略的领域是对于预处理和后续处理任务的自动化。如果不能对这些任务进行自动化，那么自动化测试就不得不加入手动过程——这在很大程度上违背了自动化的目标！关于这个主题的更多讨论请参见第2、10、11、18和22章。