现在越来越多的网站为了安全性或是防止Spam的侵害，采用了验证码的校验技术。简单地说，验证码就是在进
行登录或是内容提交的时候，页面上会随机出现一个人工可识别，但机器不可识别的验证字符串（一般是采用
背景、扭曲等方式产生的图片），要求登录或是提交内容时同时输入这个验证码。
验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或
是Intranet应用接受为标准的实现方式。但对性能测试来说，这种验证码又带来了很大的问题。
最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是“防止自动化工具尝试”的方法
，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。已经不止一次有人
提到这个问题，并询问有没有较好的解决方案。
对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题：
1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输
入的是什么验证码，都认为是正确的。这种方法最容易实现，对测试结果也不会有太大的影响（当然，这种方
式去掉了“验证验证码”这个环节，不过这个环节本来就很难成为系统性能瓶颈）。但这种方法有一个致命的
问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风
险，因此，对于已上线的系统来说，用这种方式就不合适了；
2、第二种方法，在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题，那么我们可
以考虑，不取消验证，但在其中留一个后门，我们设定一个所谓的“万能验证码”，只要用户输入这个“万能
验证码”，我们就验证通过，否则，还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题，但
由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在性能测试期间保留这个小小的
后门，相对第一种方法来说，在安全性方面已经有较大的改进了；
3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处
理这个问题。一般的性能测试工具（MI的LR、Seague的Silk performer等）都能够调用外部的DLL或是组件接口
，因此，可以考虑获得“验证码验证”部分的实现，写一个验证码获取的DLL，在测试脚本中进行调用即可。
除了这三种方法以外，可能还会有其他的方法存在，也希望各位能提供一些其他的思路。在我的实践中，第二
种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的
是已上线系统，无论用哪种方法，测试完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在
测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样的接口。
在LR中，关联的原理是将服务器返回的信息中的某些内容保存在一个变量中，然后，在后续的操作（譬如POST
）中用这个变量替代录制时的内容。如果用关联可以解决验证码的问题，那就只有一个可能：请求页面时返回
的内容中已经包含了验证码了，但如果真实情况是这样，验证码也就没有任何作用了。根据我的理解，验证码
一般通过组件来产生，产生的验证码一般以“图片”形式嵌入在页面中，而且该图片一般经过扭曲、背景、随
机干扰等方式进行了处理，通过关联这种方式是肯定不能解决的。
最后，如果你还能找到描述用关联方法解决验证码问题的文章，麻烦给我发一份，我也学习一下，谢谢。