基于c/s非标准控件的自动化尝试和testcomplete介绍

第一部分 探索
 

1.1 自动化测试的原理
  自动化测试的原理就是无人值守的情况下开展对目标软件的测试，关键在于两点：对软件的行为进行控制、检查软件的预期结果来判断软件运行是否正常。

 

1.2 当前的测试软件和技术
  UI级别的测试工具：这类软件通过识别软件的界面原色和记录用户的鼠标键盘操作来达到控制应用程序的目的。对于结果比较也是通过识别用户界面中的元素的状态来判断操作的结果。这些方法对于标准的windows控件是通用的，这种方法实现了一种黑盒式的自动化测试，所作的一切都是在模拟用户的操作。这种方法是建立在对软件的UI元素能自动识别的基础上的。

  当前的难点：对于非标准的windows控件，现有的工具无法自动识别，导致无法通过自动的方式驱动软件运行。要想对这样的软件进行自动化的测试，必须寻找一些其他的方法。

在不修改应用程序源代码的基础上，尝试了以下几种技术：

 

1.2.1 MSAA
   MSAA即Microsoft Active Accessibility，为在应用程序和帮助技术之间交换信息提供标准的、一致的机制。例如，MSAA允许程序把所有对象的类型、名称、位置、当前状态暴露给屏幕读者并通知屏幕读者任何windows事件导致的用户接口改变，这原本是微软为有视力障碍人士开发一些接口，但是后来发现这些接口也可以用于对GUI元素的控制从而实现自动化测试。Active Accessibility 的主要思想是提供一种以程序方式访问UI元素信息或操作这些UI元素的功能。支持这种功能的 UI(User Interface) 元素是可访问的。在大多数情况下，这意味着一个UI元素支持 IAccessible 接口。你也可以说在 Active Accessibility 的世界里，一个可访问的UI元素可表示为 IAccessible 接口。MSAA的核心功能由 OLEACC.DLL 提供的。每次当你调用一个函数来返回一个 IAccessible 接口指针，其与一个UI元素相对应，OLEACC.DLL就检查此元素是否内在支持 IAccessible。内在的支持意思是该元素的 IAccessible 是用程序实现的。
    当一个UI元素不能内在的支持 IAccessible 时，OLEACC.DLL 检查该元素的Windows 类名。如果该类是一个 USER 或者 COMCTL32 支持的类，OLEACC.DLL 就创建一个代理为 UI 元素实现 IAccessible 接口。标准控件默认都是支持IAccessible接口，自定义的一些控件，如果没有实现，是不能正确支持的。

   在不改变程序而想通过MSAA接口来实现GUI的自动化测试，是行不通的。

 

1.2.2 Automation UI测试框架
  其实Automation UI是对MSAA的扩展，是WPF的一部分，对.net平台下的程序支持很好，可是很容易实现自动化，但是同样，对于传统的win32程序，在不修改被测程序的情况下，是不适用的。

  但是Automation UI提出了一个自动化测试的框架，这个框架基本上可以分为三部分：用例执行接口，测试控制接口、被测程序，其中测试控制模块位于被测程序和测试用例之间，用于在被测程序和测试用例之间传递控制消息和数据。这样就可以实现测试用例和被测程序的分离，易于被扩展。

 

1.2.3 windows API
  通过windows API，如FindWindow,EnumWindow等函数，可以找到窗口handle，我曾经在QQMusic的界面上试过，大部分的window都能找到，但是一些自绘的区域，如播放按钮，切换的tab按钮等，是不能枚举出来的，但是可以找到这些按钮的父窗口，这样通过SendMessage函数并指定鼠标的position，还是可以模拟点击事件的。但是对于点击的结果没有很好的方法判断。

 

1.2.4 进程注入，HOOK API
  想法是这样的：如果能hook住每个功能所对应的windows调用函数序列，就可以记录软件的运行方式，然后通过这些记录的信息完成自动化的操作。这种方法实现的关键点有两个：如何hook所有的函数调用以及如果进行结果比较。对于dll中的导出函数，通过一些特殊的技术，可以跟踪这些函数的执行，如可以跟踪kernel.dll中的window API,来监视应用程序的资源分配、内存分配等信息。但是对于一些非dll导出函数，如自定义的一些类中的函数，无法获取信息。而仅仅是标准的windows API函数是不能满足测试需求的。还有一个就是结果比较，如果无法知晓程序内部数据的获取方式和内部数据的数据结果，也是无法进行运行结果的判断的。

 

 

通过以上的尝试，可以得出一个结论：对于基于非标准windows控件的应用程序来说，开展自动化测似需要得到应用软件的额外支持，即：应用软件需要在设计的时候就考虑到对测试的支持、测试是软件研发的一部分。

 

对于非标准控件，如何实现自动化测试？

 

  来看看自动化测试的一个典型的流程：编写测试用例——执行测试用例——驱动被测软件并记录被测软件的状态——生成测试报告。由此可以看出需要三个典型的模块来支持自动化测试：用例编写管理模块、测试驱动执行模块、测试报告生成模块(输出测试结果)。其核心是驱动执行模块，驱动执行的主要功能就是控制被测软件的运行并得到程序运行时的一些内部程序的状态。如果要实现这个功能，需要在被测软件的内部植入一个测试代理用来获取程序的控制权和内部数据。具体可以针对被测软件设定一些测试点，针对这些测试点在程序内部编写测试使用的API，通过调用这些测试使用的API就可以开展自动化测试。

 

 

 

 

第二部分 一些思考
   2.1 理想与现实
理想的目标是尽可能多地把测试任务自动化。我们认为无人值守的测试执行才是理想的测试，因此我们编写测试脚本实现那些复杂的手工测试用例。然而，有些测试用例是很难实现可靠的自动化的，不值得花费大量的精力去实现。很多时候，我们的脚本会漏掉一些BUG，因为在编写测试脚本时不会想到那些情况，并且有些测试用例对于人工执行而言是很容易的事情，但是对于计算机而言则很容易出错。

  2.2 观察、研究、自动化
  测试人员不但要熟悉业务的流程，还要熟悉业务所使用的技术，在测试的过程中分析哪些东西可以自动化，哪些不适合自动化。这些东西都不是靠一个测试工具就能够实现的。

  2.3 一半是人，一半是机器
  不同的测试工具，适应不同的测试环境，我们磨利了我们的工具之后，工具才能让我们变得更强大。在平时要注意收集一些有空的测试工具也提高测试的效率，如利用perlclip可以轻松产生任意长度的字符串。

 

 

第三部分  介绍一个自动化测试工具 TestComplete
3.1 什么是testcomplete
  TestComplete是一个可以运行针对win32,.net,WPF等程序的自动化测试环境。并且还集成了对网页、web服务器、web services的测试。支持对用vc、vb、delphi、C++Builde、java、等语言编写的应用程序。

 

3.2 TestComplete对GUI自动化的支持
  TestComplete支持录制回放机制的GUI测试。经过使用对比，发现TestComplete的录制级别相当于QTP的lower level级别，即鼠标键盘级别的录制。相对于QTP来说少了一层抽象机制，在对象管理方面不够方便。

 

3.3 TestComplete对白盒测试的支持
  对于像QTP等测试工具来说，自动化只限于“表面”，即应用程序的UI层，但不能深入到应用程序的内部，也即对应用程序的测试是黑盒的。TestComplete增加了深入到程序内部的能力，即使用TestComplete可以直接调用应用程序的代码，实现一种白盒方式的自动化测试。在此，TestComplete提出了两个概念，open Application、Connected Application

 

3.3.1 Open Application
  默认的，对于标准的vc、vb控件，基于.net、java等平台的程序，通过在编译的时候增加一些选项，TestComplete提供了一种可以 “看到程序”内部的方式。实现依靠的技术点是MFC，ATL等标准库的包装类(wrapper),编译过程中的debug信息，.net和java平台的reflection机制。

  通过这种机制，可以实现一些标准程序的自动化白盒测试

 

3.3.2 Connected Application
  一个应用程序可以通过编译选项是程序内部的一部分数据对外开放，但是对于很多自定义的对象，仍然对外是不可见的，即对于自动化的工具来说，是不可测的。鉴于此，TestComplete提出了Connected Application的概念，类似于普通的打桩、代理，具体做法为：在程序的内部，为自动一的对象生成一个包装，然后以注册到TestComplete中，就可以在TestComplete的脚本中调用这些对象进行测试。TestComplete用COM的方式实现这个过程

 

 

3.4 其他
   TestComplete还可以对应用程序进行单元测试等其他类型的测试。没有QTP容易上手，但是比QTP更能深入到应用程序的内部