测试用例的执行能被跟踪起来。

  在碰到严重错误的时候,日志的信息可以帮助找到引起问题的模块或代码。


  在一些模块接口计算的区域,日志文件包含的模块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的内容对于自动化测试脚本的影响。