WEB自动化测试中针对验证码的解决方案 (三)
4 自动测试中WEB验证码处理的方法
验证码给自动测试带来了很大的问题，但也并不是完全不能解决。结合我们在上文讨论的验证码实现的方法，图4给出了验证码实现的大致原理图。
从图4中可以看到，从技术的角度来看，至少设计两种不同的方法来实现自动测试工具对验证码的处理：
1、 完全从客户端角度考虑，靠模式识别的方法识别出验证码图片对应的字符串；
2、 从服务端角度考虑，如果自动测试工具可以获取Session中存储的随机数，也就能正确处理验证码了。
这两种方法是解决自动化测试中验证码问题的主要方法，我们分别称其为识别法和服务端插入法。这两种方法在实现方法上侧重点不同，适用的场合也不同。
识别法完全不用考虑服务端应用的实现，通过各种技术方法对显示的验证码图片进行“破译”，这样，即使完全不能接触到服务端代码，也能让自动化测试在有验证码的情况下进行下去；但这种方法当然也有其致命的缺点：只能对简单的验证码进行识别，对复杂的验证码，根本就无法识别。
而服务端插入法则从服务端入手，通过提供一个额外的客户端接口，向客户端只需要知道该接口的调用方法，就能通过该接口来获取该页面的验证码图片对应的实际数据，并使用该数据继续测试。
另一方面，除了技术角度解决问题的方法以外，还可以通过一些非技术的方法来解决验证码问题。
4.1 识别法的实现
识别法适用于不能获得和改变服务器端代码的情况下，在这种情况下，由于服务端代码本身不可获得，或是不能对其进行修改，测试者只能完全从客户端的角度想办法解决验证码的问题。
识别法的核心是对验证码图片的模式识别算法，该算法的可实现性基本取决于图片本身的复杂程度。以本文前面列举的验证码示例来说，类似Gmail和Hotmail的验证码基本上是无法通过程序来识别的。而最简单的验证码实现，例如ASP下用xbm技术生成的图片，就可以很容易地通过算法来识别；在PHP、dotNET等平台上完全使用图形库函数生成的图片，同样可以通过对某个区域内的图片分析，识别出图片对应的实际数字或是字母。
下面以处理xbm格式的验证码为例，介绍对其进行识别的算法。
本文的2.1节对xbm文件格式进行了深入的探讨，用xbm实现验证码的方法在ASP和dotNET平台上非常常见，由于xbm文件格式的规则性，因此很容易通过程序对其进行识别。一般的识别过程如下：
- 多次访问带有验证码的页面，分析每次获得的xbm文件和显示的图片之间的对应关系，获得验证码中所有符号对应的十六进制串；
- 编写识别验证码的代码，识别代码根据获得的xbm文件，将其按照编码方式分组，然后与上一步骤中获得的对应的十六进制串进行比较，这样就可以识别出该xbm文件对应的验证码的实际数据。
下面这段代码是用于将xbm图片文件识别为相应的验证码内容的C语言代码：
{
const char orgdig[10][10] = {
{0x3c,0x66,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0x66,0x7e}, //0
{0x18,0x1c,0x18,0x18,0x18,0x18,0x18,0x18,0x18,0x00}, //1
{0x3c,0x66,0x60,0x60,0x30,0x18,0x0c,0x06,0x06,0x7e}, //2
{0x3c,0x66,0xc0,0x60,0x1c,0x60,0xc0,0xc0,0x66,0x38}, //3
{0x38,0x3c,0x36,0x33,0x33,0x33,0xff,0x30,0x30,0xfe}, //4
{0xfe,0xfe,0x06,0x06,0x3e,0x60,0xc0,0xc3,0x66,0x3c}, //5
{0x60,0x30,0x18,0x0c,0x3e,0x63,0xc3,0xc3,0x66,0x3c}, //6
{0xff,0xc0,0x60,0x30,0x18,0x18,0x18,0x18,0x18,0x18}, //7
{0x3c,0x66,0xc3,0x66,0x3c,0x66,0xc3,0xc3,0x66,0x3c}, //8
{0x3c,0x66,0xc3,0xc3,0x66,0x3c,0x18,0x0c,0x06,0x03} //9
};
int i=0, j=0;
int ret = 1;
for(i=0; i<10; i++)
{
ret = 1;
for(j=0; j<10; j++)
{
if(orgdig[i][j]!= dig[j])
{
ret = 0;
break;
}
}
if(ret)
return i;
}
return -1;
}
主函数：
char picc[500], t[40], od[10];
char separators[] = ",";
char *token, *endstr;
int i=0, j=0;
//获取需要识别的图片中的数据描述部分，内容为
//0x3c, 0x3c, 0x18, 0x3c, 0x66 …
//将其存放在字符串picc中
…………
//分解获得的串
token = (char *)strtok(picc, separators); /* Get the first token */
if(!token)
{
return( -1 );
}
while( token != NULL )
{
if(!strcmp(token , "")) //处理为“空”的内容，将其替换成0x00
t[i] = 0x00;
else
t[i] = strtol(token, &endstr, 16);
i++;
token = (char *)strtok(NULL, separators);
}
for(i=0; i<4; i++) //一共4个数字，分别调用getDigital函数进行处理
{
for(j=0; j<10; j++)
{
od[j] = t[j*4+i];
}
lr_output_message("%d", getDigital(od));
}
其他通过服务器代码绘图方式实现的识别码识别相对麻烦一些，但原理上都差不多，无非是将获取到的图片进行分析，通过识别方法判断其对应的符号。
1.2 服务端插入法
如果可以控制和修改服务端代码，就可以使用服务端插入法。该方法在服务端提供一个可被客户端使用的接口，只要客户端传递过来自己的SessionID，该接口就返回此时正确的Session，这种方法就可以很容易地让自动测试工具直接获取到正确的应该提交的验证码内容。从测试的角度来说，这种方法就等于是在系统上增加了一个测试接口，从而提高了系统的可测试性。
服务端插入法的实现并不复杂，在任何一个平台上都能很容易实现，在此就不再赘述了。服务端插入法可以针对任何类型的应用使用，但这种方法也有明显的不足：
1、 如果是已经上线的应用，网站不太可能会允许保留一个这样的接口，因此，该方法一般用于还未上线的WEB系统，如果要在已上线的WEB系统上使用该方法，则必须通过管理上的方法提高该方面的安全性；
2、 采用这种方法，在性能测试时，由于该方法需要额外请求一次才能获得实际的验证码，相对于实际的用户操作来说，访问带有验证码页面的请求会多一次，因此在获得的测试结果上会有些许的差异。
1.3 解决自动测试中验证码问题的非技术方法
其实，测试并不只是单单的技术问题，除了上面给出的识别法和服务端插入法，其实，通过非技术的方式也能让自动化测试在具有验证码的系统上成功应用。当然，这些非技术方法应用的前提是，测试团队必须具有足够的能力和机会影响系统的实现。如果完全没有方法接触到服务端代码或是完全不能修改服务端代码，以下的方法就都不能应用了。
下面，让我们跳出技术的范围，换个角度来看看如何解决验证码的问题：
1、
屏蔽法
屏蔽法是最容易想到的一种方法，方法的核心就是：在被测系统中暂时屏蔽验证功能。这种方法最容易实现，对测试结果也不会有太大的影响（当然，这种方式去掉了“验证验证码”这个环节，如果该环节本身存在功能上的问题，或是本身就是性能的瓶颈，那就一定会对测试结果造成影响了）。但这种方法也有一个问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不合适了。
2、
后门法
后门法不屏蔽验证码，但在其中留一个后门，在代码中设定一个所谓的“万能验证码”，只要用户输入这个“万能验证码”，就能通过验证，否则，还是按照正常的验证方式进行验证。这种方式仍然存在安全性的问题，但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面有了较大的提高。
1.4 各种方法的比较
本文提供了多种用于解决具有验证码的WEB系统在自动测试时遇到问题的方法，这些方法既包含技术性的方法，也包含非技术性的方法。但由于每种方法的出发点不同，因此这些方法也就具有各自不同的优缺点和适用场合。本节我们对本文提到的各种方法进行比较，分别给出其优缺点和适用的场合。
|
|
技术性方法 |
非技术性方法 |
||
|
|
识别法 |
服务端插入法 |
屏蔽法 |
后门法 |
|
优点 |
不需要修改代码，也不需要在代码中增加额外的接口和后门，在服务端代码不可接触到的情况下，是唯一的选择 |
理论上来说可以解决任何验证码的问题，而且不需要修改已有的服务端代码 |
简单修改现有代码就能让自动测试顺利进行，开销小 |
实现方式不复杂，对现有代码改动小，安全性相对有保证 |
|
缺点 |
存在技术限制，只能对相对简单的验证码图片进行分析识别，对复杂的图片无法进行识别 |
存在一定的安全隐患，如果被攻击者获知测试接口，验证码就会失去作用 |
存在很大的安全问题，对于未上线应用还可应用，对于已上线的实际应用，该方法不可行；况且，由于该方法需要对代码修改的内容太多，导致发布时可能发生某些验证码被不正确屏蔽的情况 |
如果被攻击者探测得到万能验证码，则验证码会失去作用 |
|
适用场合 |
1、 服务端代码不可接触到或是不可进行任何修改 2、 验证码采用xbm等较简单的方式实现 |
未上线系统，或是在测试条件下安全性要求不是特别高的系统； |
开发阶段，未实际上线的系统 |
可在实际应用系统上应用 |
|
应用建议 |
纯粹的客户端识别解决方案成本较高，建议主要采用服务端方式实现 |
在管理上需要增加对测试接口的管理，系统在发布时需要保证去掉测试接口 |
在发布管理时，一定要有合理的方案保证发布时所有被屏蔽的验证码能够得到恢复 |
为了保证上线系统的安全，该方法一般需要结合密码管理方法使用，通过定期更换万能验证码、控制其知晓范围等手段保证安全 |
2 小结
针对WEB系统的验证码对自动化测试带来的挑战，本文详细分析了WEB验证码常见的实现方法，并根据分析提出了几种不同的解决方案：识别法、服务端插入法、屏蔽法和后门法。这几种方法各有其优缺点和适用场合，因此本文也给出了这几种方法之间的对比，并给出了各种方法的应用建议。
当然，本文的重点是介绍解决WEB系统的验证码对自动化测试带来问题的方法，在实际的自动化测试过程中，除了需要了解本文所介绍的方法外，还需要了解相应的自动化测试工具的具体应用方法，虽然不同的测试工具在提供的功能上大同小异，但在具体的使用层面上，不同的工具还是有较大差异性的，请读者自行查阅相应的测试工具文档，从工具的文档中获取相应信息。
(全文完)
