自动化测试中基于色差分析的图片验证

本文将介绍一种基于色差分析的图片验证方法，与 Rational Functional Tester（RFT）提供的图片验证所不同，它在比对图片时，通过计算色差来模拟人眼对图片验证。使用该方法可以有效地减少因环境差异造成的不必要的图片验证失败，从而提高自动化测试中图片验证的效率。

图片验证在自动化测试中的应用

图片验证，简单地说，就是通过对比图片来确认测试结果。例如，在图形界面测试中，为实现验证某个视图中的多个按钮是否被正确显示的测试用例，并将其应用在以后的新版本测试中，测试人员会先基于已发布版本的产品，截取并保存正确显示的该视图作为基线。在测试新版本产品的该视图时，测试脚本会自动截取当前的视图并与保存的基线进行比较，以此验证新版本的正确性。如果新产品的视图设计发生了变化，比如增加了新的控件，则需要维护脚本，重新选择正确显示的新视图作为测试基线。

为什么会采用图片验证

在自动化测试中，需要多种验证手段来模拟手工测试对被测对象进行确认，从而达到测试目的。IBM 最近发布了新的自动化测试工具：Rational Functional Tester (RFT) 8.0，对于基于 Java 和 Eclipse 的界面元素，包括 Graphical Editor Framework（GEF）对象，都有很好的支持。使得测试人员既可以直接使用 RFT 提供的数据或者属性验证点，或利用 RFT 提供的 ObjectProxy 机制，调用被测对象的 API，来访问界面元素的数据及属性，从而对这些测试对象进行验证。IBM WebSphere Business Modeler (WBM) 是基于 eclipse 的图形化建模工具。在其自动化测试过程中，这些验证手段，尤其是后者被广泛采用。

但在对产品界面的自动化测试过程中，还要针对一些自定义或非标准的图形化编辑器和视图进行测试。以 WBM 的测试为例，图 1 所示的是 WBM 6.0 的一个核心视图：业务流程编辑视图。用户可以通过此视图显示或编辑各类业务流程。典型地，会要求测试人员验证编辑视图的右侧工具面板中各个按钮的显示和排列，以及流程图中的各种节点和连接是否能被正确排列和显示。

图 1. IBM WebSphere Business Modeler 的业务流程编辑视图

在实现该用例时，我们发现该视图是一种非标准的 GEF 视图，而当时的 RFT 的早期版本尚不能很好支持这种视图中的 GEF 元素，很难通过 RFT 的对象映射机制来获取其相关信息。类似地，为了提高界面的易用性和交互性，很多软件产品常会引入一些新的界面元素。而这些新的控件类型往往不能被当时的测试工具很好地支持。

另一方面，正如图 1 中显示的，WBM 流程视图中往往拥有众多的图形对象（工具面板中的按钮，流程中的节点和连接），为每个对象和元素增加验证点将是一件非常繁琐的工作，增加了自动化测试的开发成本。而从维护成本的角度考虑，一旦产品界面设计发生变化，这些验证点的维护对测试人员来说将是一场梦魇。事实上自 WBM 6.1.2 之后采用了 BPMN 规范来重新设计流程视图。如图 2 所示，新版的业务流程编辑视图使用了标准的 GEF 右侧工具面板，并对其中的按钮重新分组和排列，同时在视图顶部添加了新工具条。而流程中各种节点不仅在外观上做了修改，在具体实现上，其对应的 GEF 对象结构也发生了变化。对于基于前述的 RFT 验证方法，这意味着测试人员不得不维护每个界面元素的验证点，甚至重新分析或识别这些界面元素。

图 2. 新的 WBM 业务流程编辑视图

最终我们采用图片验证来实现此类测试：将整个流程视图拷贝下来存为图片，做为验证基线。然后每次测试时只要获取当前界面拷屏并与基线比对既可。这样测试人员可以不关心界面元素的具体实现。而当产品界面发生改变时，测试人员只需要把作为测试基线的图片更新为新界面。需要指出的是，从 RFT 7.0 开始，在数据或属性验证点之外，还提供了专门的图片验证点作为验证手段的补充，而无需测试人员自己编程实现，这在 RFT8.0 中得到了很好的继承。

图片验证的特点

从上述 WBM 的测试用例可以看出，图片验证简单直观，可以脱离图形界面的具体实现。不必为了定位界面控件或元素而了解其结构和类型。而在界面拷贝和相关图片存储和验证方面，有成熟和众多的 API 库支持。能大大节省脚本的开发和维护成本。然而在实际应用中，图片验证却又是经常为测试人员所诟病的一种验证手段。这是因为，与其他验证手段不同，图片验证还据有以下特点：

1. 验证结果会受到测试环境的干扰。在分别将测试基线和结果保存为图片格式的过程中，由于环境的差异和图片格式的局限，对比的图片之间会有差异。
2. 图片验证算法不能区分各种差异。算法缺乏容错性，在验证过程中无法排除那些受测试环境变化干扰而产生的差异。
3. 仍然需要人工干预。当比对失败时，测试人员仍然需要通过人工比对图片，才能真正确认失败原因。这远不如其他验证方法那样能够让测试人员对失败原因一目了然。

在测试 WBM 流程视图的自动布局功能时，相关的脚本会在多个测试环境下运行。各测试环境不仅使用相同的测试脚本，也使用相同的界面截图作为测试基线，但在部分环境下的图片验证总是失败。虽然经手工确认，界面显示完全正确和一致。正因为上述这些特点，使得图片验证既是最直观和最容易实现的验证手段，但同时又被很多自动化测试人员视为可靠性不高，并极力避免使用的验证方法。

可以通过改进当图片比对失败时的反馈信息，来减少人工分析的成本。例如在上述测试用例的执行过程中，会在图片比对失败时，把期望的图片和实际得到图片拼合在一起，并记录在日志中，使得测试人员在分析日志时就能很方便地找出验证失败的原因。甚至像一些专业的图片比较工具那样显示出图片的差异来。但是这都不能从根本上解决图片验证的低可靠性的问题。因此分析为什么目前的图片验证结果会依赖于测试环境，从而改进图片验证，减少不必要的验证失败是目前条件下的唯一选择。

有的严格逐点比较的图片比对

在寻求如何改进现有的图片验证方法之前，我们先来分析现有图片比对方法，从而了解测试环境 ( 色彩深度 ) 的差异是如何影响图片验证的结果。

基于 RGB 色彩模型的图片比对

理论上，在进行图片验证时，只需要验证每个像素的颜色值或者各个 RGB 分量的值，即可达到验证的目的，这也是很多自动化测试中常用的比对方式。但在实际测试中，通过这样的图片比较方式会经常失败，即使是产品功能和界面没有任何变化。

首先我们需要了解色彩空间最常用的模型，RGB 模型。RGB 色彩模型基于物理三基色，为图像中每个象素规定了 RGB 三种颜色分量，每个分量可以取值 0-255。通常用 8bit 来存储每个分量，由于 RGB 模型是加法混色，所以 24bit 的颜色深度下，就会有 2^24 种颜色，而增加了透明通道的 32bit 颜色深度下则有 2^32 种颜色。这里需要指出的是，无论是否采用压缩格式存储图片，如果将 32bit 颜色转换为 24bit 颜色就会发生失真。此外，获取作为验证时基线的参照图片时的开发 / 测试环境与测试的实际执行环境常常会有差异，比如颜色深度分别为 24bit 和 32bit，在生成的图片或截屏中，同一位置的象素颜色值或 RGB 颜色向量值就就会有差异。

在我们以往的自动化测试中，很多图片验证的失败就是源于这种失真而造成比对的图片之间有了差异。一方面这种差异完全是由于测试环境的改变或者图片格式差异所造成，而非产品的缺陷。另一方面肉眼较难区分这样的差别，因而手工测试不会面临这样的问题。

RFT 的图片验证点

RFT8.0 中，有专门用于图形界面的图片验证的验证点（Verification Point）类型。用户可以很方便地利用 RFT 提供的工具选取图形界面元素，并截取屏幕作为图片比对的期望值。为了避免因为图片压缩造成的失真，RFT 的图片验证采用了无压缩的 PNG 格式，而不是通常适用的 JPG 格式来存储图像。同时用户还可以选择只比较图片的某一特点区域。

但是上述由于系统环境不同带来的颜色失真问题依然存在。为了克服上述问题带来的影响，最简单的方法是保持所有测试环境的完全一致性。但一方面这增加了测试的复杂性和测试人员的工作量，另一方面也降低了测试脚本的鲁棒性。相比较而言，通过改进图片比对算法来提高图片验证效率会更有效。

有关色差的原理和计算方法

为了解决基于 RGB 色彩模型的图片比对存在的上述问题，我们采用了基于色彩计算的新的图片验证方法。在开始介绍基于色差分析的图片比对方法之前，先介绍一下色差的相关原理。

色差的原理和发展历史

所谓色差，简单说来就是表示两种颜色的差异程度。说到色彩的量化和测量技术，就必须提到国际发光照明委员会 (CIE)。鉴于 RGB 色彩模型与设备相关性等问题，CIE 在 RGB 模型基础上，制定了一系列包括 CIE XYZ 基色系统和颜色空间等在内的新标准，试图建立一个新的色彩空间，使得工业界能够准确指定产品颜色。而后又针对 XYZ 色彩空间的不足，进一步制定了 LAB 色彩空间规范及有关色差计算公式。使得工业界可以用数值 deltaE 来表示两种色彩的差异程度，进而评估它们的近似度。目前 CIE1976LAB 规范已经被广泛应用，成为国际通用的色彩测量标准。需要指出的是，色差的计算公式并非只有 CIELAB 色差公式这一种。

色差的计算和应用

虽然 RGB 色彩模型被广泛应用，但却不能直接通过 RGB 色彩模型计算出色差。我们必须先将色彩从 RGB 色彩空间转换到 XYZ 色彩空间，而后再转换到 LAB 色彩空间，最后根据总色差公式来计算色差。事实上 CIE 提供了多种理想的色彩模型和转换算法，这里我们只是选取其中的一种简单算法。

从 RGB 色彩模型转换为 XYZ 色彩模型：

x=(0.490r+0.310g+0.200b)/(0.667r+1.132g+1.200b)

y=(0.117r+0.812g+0.010b)/(0.667r+1.132g+1.200b)

z=(0.000r+0.010g+0.990b)/(0.667r+1.132g+1.200b)

需要指出的是，CIE 在多年前不仅制定了 XYZ 色彩空间模型，还通过一系列实验，为观察者和光源制定了标准。因此上述公式中的数值都是基于标准观察者 (2 度 ) 和标准光源下 (D65) 的经验值。这些数值都是通过实验经过推算得到的。

从 XYZ 色彩模型转换为 LAB 色彩模型：

L=116(Y/Y0)^(1/3)-16

A=500[(X/X0)^(1/3)-(Y/Y0)^(1/3)]

B=200[(Y/Y0)^(1/3)-(Z/Z0)^(1/3)]

相比之下，从 XYZ 模型到 LAB 模型的地转换要简单些。

通过 LAB 色彩模型计算色差。

在 LAB 色彩空间中，L 表示亮度，a 和 b 分别表示从红色至绿色的范围，以及从蓝色到黄色的范围。而由 LAB 色彩模型计算色差很简单，公式如下 :

明度差 : dL = L1-L2

色度差 : dA = A1-A2 dB=B1-B2

总色差 : dE=(dL^2 + dA^2 + dB^2)^0.5

其中明度差表示色彩深浅的差异，色度差表示色彩色相的差异，而总色差则表明在明亮度和色调的综合作用下，两种色彩的差异程度。

基于色差分析的图片比对方法

既然色差值可用来判断两种色彩的差异程度，那么也就可以通过计算色差值来模拟测试人员肉眼对两种颜色差异的感觉。逐点比对时，先将得到像素 RGB 颜色转换为 XYZ 空间的色彩，再转换到 LAB 色彩空间，最后计算两个像素的颜色的总色差。如果色差值小于或等于临界值，则判定两点颜色一致，反之则判定两点颜色不一致。测试人员应根据实际测试环境和经验选择合适的色差值，作为判定色彩是否一致的临界值。在 WBM 的实际测试中，一般都选定 6~10 作为临界值。

图片比对的代码实现

//Transform. RGB Color to XYZ Color //rgb is the integer value of pixel color. //r,g and b represent its Red, Green and Blue value. xyz.x = (0.490*r + 0.310*g + 0.200*b) / (0.667*r + 1.132*g + 1.200*b); xyz.y = (0.117*r + 0.812*g + 0.010*b) / (0.667*r + 1.132*g + 1.200*b); xyz.z = (0.000*r + 0.010*g + 0.990*b) / (0.667*r + 1.132*g + 1.200*b); //Treat RGB color BLACK(0,0,0) specifically. if (rgb == -16777216) { xyz.x = 0; xyz.y = 0; xyz.z = 0; } //Transform. XYZ color to LAB Color double x = xyz.x / 95.047; double y = xyz.y / 100.000; double z = xyz.z / 108.883; //Adjust the x, y and z value. (Optional) if (x>0.008856) x = Math.pow(x, 1.0/3.0); else x = (7.787*x) + (16/116); if (y>0.008856) y = Math.pow(y, 1.0/3.0); else y = (7.787*y) + (16/116); if (z>0.008856) z = Math.pow(z, 1.0/3.0); else z = (7.787*z) + (16/116); //Calculate l,a and b from x,y and z. lab.l = 116*Math.pow(y, 1.0/3.0) - 16; lab.a = 500*(Math.pow(x, 1.0/3.0) - Math.pow(y, 1.0/3.0)); lab.b = 200*(Math.pow(y, 1.0/3.0) - Math.pow(z, 1.0/3.0)); //Calculate chromatic aberration double deltaL = lab1.l - lab2.l; double deltaA = lab1.a - lab2.a; double deltaB = lab1.b - lab2.b; double deltaE = Math.pow((Math.pow(deltaL, 2) + Math.pow(deltaA, 2) + Math.pow(deltaB, 2)), 0.5); …… //Compare two pixels by their chromatic aberration. //If it is less than _MODELER_CHRABE, we think two pixels are same. //_MODELER_CHRABE is a customized and experienced value selected by testers. if (deltaE <= _MODELER_CHRABE) {//Two pixels have no difference. ……

色差分析的实际应用效果

下面通过一个 WBM 流程视图的测试用例来验证图片比对中使用色差分析的效果。如图 3 所示，需要验证某流程中各元素的排列和显示。测试人员通过 RFT 增加了一个图片验证点，选取流程编辑器的画面作为测试对象，并选取了图片验证的范围。此时测试人员的脚本开发环境的系统色彩深度是 16bit。

图 3. 通过图片验证来确认流程节点属性和布局的正确性

在测试环境中执行该脚本时，测试环境的系统色彩深度是 32bit。由于环境变化导致图片存储时的色彩失真，该图片验证点失败。在 RFT 中打开该失败的验证点会发现，比对的两幅图的基本属性完全一致 ( 如图 4)。

图 4. 在 RFT 图片验证点中的基本属性。

分析相关的日志目录中保存的两幅截图，发现两幅图片只有因为色彩失真造成的非常细微的差异，肉眼很难发现。通过分析比对，找出将 RGB 色彩值不同的像素对，然后计算该像素对的色差。同时把相关信息 ( 坐标，各自的 RGB 色彩值，以及对应的色差值 ) 输出。以下是输出的部分结果 :

x:0 y:359 RGB(Expected|Actual):(243，243，243)|(241，241，241) DeltaE: 0.0 x:2 y:359 RGB(Expected|Actual):(242，242，242)|(240，240，240) DeltaE: 0.0 x:3 y:359 RGB(Expected|Actual):(156，156，156)|(160，160，160) DeltaE: 0.0 x:4 y:359 RGB(Expected|Actual):(167，167，167)|(164，164，164) DeltaE: 1.4217791915866692E-14 x:5 y:359 RGB(Expected|Actual):(236，236，236)|(227，227，227) DeltaE: 0.0 x:6 y:359 RGB(Expected|Actual):(252，252，252)|(255，255，255) DeltaE: 0.0 x:7 y:359 RGB(Expected|Actual):(251，251，251)|(248，248，248) DeltaE: 1.5263043145882805E-14 ... ... ...

从中可以清楚地看出，虽然两图之间的有些像素的 RGB 不一致，但是其色差值远低于我们定义的临界值。这意味着测试人员肉眼很难看出这些像素的差异，因此两图中所有有差异的点都可以被视为无差别。

基于色差分析可以显著降低图片比对的失败率，但是不能解决所有的图片比对的问题。例如我们在测试中发现不同的测试环境中，其系统的缺省字体往往是不同的，尤其是不同语言版本的操作系统之间。以前文提到的 WBM 流程视图测试用例为例，本文所附的两张图片一张 (DifferentFont_base.png) 是截取自该测试脚本的开发环境，使用的是中文 WidnowsXP。另一张 (DifferentFont_fail.png) 则是取自该测试脚本的执行环境，使用英文 WindowsXP。

我们先采用基于 RGB 模型的逐点比较算法，并用绿色记录下两图之间的不同像素，得到了比较的差异图 ( 图 5)。对比图 3 可以看出，在两个环境下，流程中所有元素的颜色都被判定为不同。

图 5. 基于 RGB 模型的图片验证得到的比较差异

图 6 显示的是使用色差分析的图片比对发现有差异的像素。对比图 5 和图 3，可以看出，差异都是由流程中的文本信息造成，这主要是因为两个环境下使用的缺省字体不同所致。但从另一方面也可以看出使用基于色差分析的图片比对确实能够减少系统环境变化对测试结果的干扰，从而提高图片比较的效率。

图 6. 基于色差分析的图片验证得到的比较差异

在 WBM BVT 自动化测试中，原本受环境变化干扰而失败的图片验证点，在运用这种图片比对的方法后平均大约 74% 左右运行通过，余下的失败的图片验证点，除去界面变动和产品缺陷所导致的外，主要是因为操作系统缺省字体和系统界面主题的不同所致。最理想的解决办法是将图片中的文字单独析取出来进行比较。而利用光学字符识别（OCR）来识别图片中的字符，不失为一种解决办法，但这已经超出了本文的范畴。

结束语

基于色差分析的图片比对方法能够在很大程度上提高图片验证的效率，从而进一步提高自动化测试的开发效率和减少后期执行和维护的成本。这种图片比对方法能够很容易在 RFT 脚本中实现，可以做为 RFT 的图片验证点的补充。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780873/viewspace-582411/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14780873/viewspace-582411/