| 自动化测试专家Elfriede
Dustin在2008年10月的《Software Testing and Performance》杂志上发表文章，深入探讨了为什么如此多的自动化测试项目会最终失败。
1、IDT的自动化测试调查
IDT（Innovative Defense Technologies）在2007年进行了一次软件自动化测试的研究调查。调查研究表明：虽然很多公司都认为自动化测试是非常有用的，但是很少有公司真正成功地实施了自动化测试。在问及没有很好地开展自动化测试的原因时，大部分人回答是由于缺乏资源，例如：时间、预算、技术等，其中：
- 37%认为缺乏时间。
- 17%认为缺乏足够的预算。
- 11%认为缺乏合适的工具。
- 20%认为缺乏专家的技术指导。
研发领域的技术在过去20、30年间得到了高速的发展。然而我们对这些技术的测试能力并没有跟上发展的速度。现实告诉我们，测试变得越来越重要。IDT研究测试技术多年，发现一些有趣的东西：
（1）软件测试开始和软件开发一起驱动着业务。
以前，业务驱动着软件和测试的技术发展。现在，软件和测试技术逐渐对业务起着驱动作用。业务部门可以有很好的业务idea，但是如果软件开发和测试部门不能很好地交付产品，或者测试能力有所欠缺的话，业务的竞争力会很快地消失。抢占市场的先机很重要，但是应该给予产品开发和质量保证更多的关注。
（2）应该给予“感知质量”更多的测试
质量过程和标准往往过于关注数据，例如出现了多少个Bug、缺陷的密度等数据，而忽略了顾客的“感知质量”。例如，对于一个产品，频繁出现的10个缺陷，并且会影响到关键的功能运行，这往往会被顾客认为是一个低质量的产品，即使相对于整个项目而言，缺陷密度是非常低的。
相反地，如果发布的产品中有100个缺陷，但是不经常出现，而且几乎不影响正常的功能操作，顾客则会认为这是个高质量的产品，即便从数据看来，其缺陷率非常高。
到目前为止，并没有太多“基于使用的测试”的研究。“基于使用的测试”探索感知质量的内涵，追求高的感知质量，从而获得更高的顾客满意度。在Elfriede
Dustin看来，amazon.com相比起其他在线书店网站，拥有更高的顾客感知质量，因为amazon.com的用户体验非常友好。
我们的目标是提高产品的感知质量。提高的途径是：让测试专注在那些最常使用的功能上（确保正常工作，没有任何缺陷），专注于测试那些最常用功能的可用性、可靠性。
（3）测试人员总是会受到责备
Deadline临近，而在多种环境下的测试周期看起来是无止境的。测试人员通常会因为Deadline而受到责备，还会因为项目超出预算、没有覆盖产品的所有Bug、缺乏创新等，受到责备。
但是，通常造成这种结果的真正原因是因为缺乏系统工程的过程。例如，对于一个上百万行代码、包含大量功能模块的产品，仅仅依靠测试组的黑盒测试，费尽九牛二虎之力才找到一些Bug。
从另外一个角度来看，测试对项目进度拖延的真正原因是：不良的开发习惯导致充满Bug的代码，需要很长的、重复的修改周期。
还有一个原因是：缺乏单元测试。调查分析表明：单元测试越充分、越有效，则系统测试会开展得越顺利，系统测试的周期也会越短。
不能忽略的一个问题是产品构建。构建（Build）和发布（Release）的过程应该自动化。如果没有实现构建的自动化，那么软件构建的过程将会是非常浪费时间、并且容易出错的一件事情。
另外，如果Deadline本身设置得就不合理，那么导致失败的可能性就非常大。有些Deadline的设置没有考虑清楚究竟需要多长的时间来开发和测试软件。
（4）开发人员不做测试
虽然已经有不少的开发人员采用单元测试、测试驱动的开发方式，他们确实做得不错。但是开发人员仍然缺少集成和系统方面的测试。开发人员往往倾向于关注自己编写的功能模块的问题，缺乏对整个系统的全局观。
为什么开发人员不做一下系统测试呢？他们没有时间，他们不是专业的测试人员，他们缺少测试的技巧，他们忙着开发新的代码和功能，并且测试系统整合部分的代码不是他们的职责。
开发人员疲于应付新功能的开发，以便满足那些不合理的Deadline。毕竟，大部分人认为抢占市场是很关键的。然而，事实证明，我们不仅仅要关注R&D，还要关注R&D&T。
2、自动化测试的最佳实践
很自然地，大家希望借助于自动化测试来缩短系统测试的周期，缓解测试的压力。但是，如果在设计和代码开发的过程中缺乏对自动化测试的考虑，例如提高应用程序的可测试性，我们可能会掉入自动化测试的陷阱中去。
为了避免掉入自动化测试的陷阱，Elfriede Dustin总结了几个最佳实践，其中包括：
（1）提高应用程序的可测试性。
软件开发人员可以通过在程序中构建更多的可测试特性，来帮助测试人员开展自动化测试。可以有多种方式来提高可测试性，其中一种比较常见的方式是提供日志或跟踪机制，从而提供关于程序正在做什么的信息，包括正在操作的数据，以及关于应用程序状态、运行中的错误等方面的信息。测试工程师可以利用这些信息来判断错误是否发生，跟踪测试执行过程中的各种处理流程。
在应用程序执行过程中，所有模块都会写入关于方法、函数、当前处理对象等详细的日志信息。通常日志会写到文件或数据库中，并且按一定的格式写入，以便后期地分析和调试。
在某些复杂的C/S结构系统或Web系统中，日志文件可能会写到多个机器上，因此日志中应该包含足够的信息用于判断在机器之间执行的顺序和路径。但是也不能包含太多的信息，否则将影响后期的分析过程。每个日志信息应该尽可能简洁地包含一些关键的信息，例如：
- 类名和方法名。
- 机器名和进程ID。
- 时间戳（精确到毫秒级）。
- 执行信息或出错信息。
灰盒测试方式可以充分利用这些日志信息，跟踪到对象在测试执行过程中的各种信息。另外，还会带来如下好处：
- 测试用例的执行能被跟踪起来。
- 在碰到严重错误的时候，日志的信息可以帮助找到引起问题的模块或代码。
- 在一些模块接口计算的区域，日志文件包含的模块ID、数据可以帮助找出这些接口的错误。
在找到Bug之后，测试人员把Bug描述连同格式化的日志信息发给开发人员，有助于开发人员定位和调试问题发生的根源。例如下面的日志信息：
Function: main (main.cpp, line 100)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:54.721
Message: connecting to database [dbserver1, customer_db]
Function: main (main.cpp, line 125)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:56.153
Message: successfully connected to database
[dbserver1, customer_db]
Function: retrieveCustomer (customer.cpp line 20)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:56.568
Message: attempting to retrieve customer record for
customer ID [A1000723]
Function: retrieveCustomer (customer.cpp line 25)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:57.12
Message: ERROR: failed to retrieve customer record,
message [customer record for ID A1000723 not found]
从日志中可以看到，应用程序按照测试用例的执行过程，不能取到指定的顾客记录。
在这种情况下，测试员应该检查dbserver1数据库，使用SQL查询工具查询customer_db数据库中ID为A1000723的记录，来验证数据是否存在。确认是Bug之后，连同日志信息一起发送给开发人员，而不仅仅包含Bug的现象。这些日志信息对于开发人员定位问题的本质有重要的作用，可以减少问题分析和定位、调试的时间。
（2）GUI和接口测试的建议
录制回放型的测试工具通过脚本语言记录测试工程师在程序界面上的操作，然后通过回放来做一些基本的验证。由于需要与GUI打交道，任何GUI的细微变化都可能引起脚本回放的失败。因此，如果是基于位图的录制，则要注意下面几个方面：
- 控件的字体不要随便改动。
- 界面的颜色不要随便改动。
- 显示的设置需要保持不变。
- 如果可能，应该保持操作系统的标准设置。
开发人员在做界面层的修改之前，需要考虑到界面的修改对自动化测试脚本的影响，尤其是在界面基线已经建立起来之后，需要慎重考虑GUI的修改。
GUI测试工具通常是基于对象的属性来识别对象的，因此开发人员最好能知道GUI测试工具的工作原理，这样可以在修改GUI时尽量避免对自动化测试脚本造成的影响。
3、小结
为了避免掉入那些主要的自动化测试陷阱，R&D应该在开发过程中把测试这个“T”也考虑进去，而不仅仅考虑那些最新最酷的开发技术。如果发明并使用了最新最好的技术，但是不能被充分测试或者很难被测试到，那么我们如何知道它们的质量水平呢？！
测试自动化是个很关键的技术，在开发软件的过程中，程序员需要把测试效果和可测试性等因素考虑进去。并且，还应该明白修改GUI的内容对于自动化测试脚本的影响。 | 
