摆脱验证码

本文章转载于搜狗测试

说到验证码，这里主要介绍关键的3大功能有关的分块：生成、展示、验证。至于数据保存的方式、展示的形式、图片的机器图像识别程度不在此做讨论，纬度太多。

这里讨论2种最常见的验证码逻辑：

实时生成验证码，即生成和显示在同一步操作，当用户访问验证码时，服务器则立即生成验证码图片，并在服务器上保存答案，将答案保存于session或者将对应的key返回给客户端作为标记，在之后的验证中使用。

批量提前生成验证码，其实就是前一种方式的改良，因为越是复杂的图片，消耗的CPU资源越是大，如果需要在瞬间生成大量的图片，那么将需要非常多的服务器资源来支撑，而提前生成即可最大利用服务器的空闲时间，缺点只是一定要连带图片一起保存，会消耗一定量的存储空间。

这里统一下验证码的需求，省去没必要的条件争论：

主要也就是每个验证码只能使用一次，验证后界面需要自动变更验证码，也提供手动更换验证码的功能。具体细节就不在这里阐述了。

然而很多人觉得验证码的测试是如此的简单，就好比这样：

输入正确验证码，通过

输入错误验证码，失败

输入上一次用的验证码，失败

换个验证码并用上一次的，失败

当然造成这样简单测试的原因有很大一部分是因为对程序的结构、逻辑细节不了解，说更直接点就是没有办法再想别的测试方式了。

我的观点

下面就简单介绍下可能存在一些怎么样的问题：

显示验证码时，没将答案存在服务器，而是将答案一起返回到了客户端，如放在cookie或隐藏在页面中等位置，这样只要在客户端也可以验证对错，手机端较多，基本也就是忽悠用户的，根本起不到任何作用

显示验证码时，仍然返回客户端，但做了加密，然后在验证时服务器解密这个数据并和答案对比，但因为图的答案与加密数据是匹配的，可一直绑定使用，自然变向成了万能验证码

再来，这次在服务器上保存了，但是可能因为开发手误，把答案保存位置对应的key写了个固定的，那么问题来了，所有人的答案都存在一个位置，互相覆盖……要是测试中没有多人使用，每个人都是单独用并没问题，但是上线用户多了就……

保存服务器上了，比如session，而没有经过客户端，客户端只暴露了答案对应的key，比如sessionid，万万没想到在环境的差异上出了问题，测试环境1台服务器，而生产环境多台服务器负载均衡，显示访问了A，而验证访问了B，又跪了

验证码验证错误后，没限制验证次数，导致可无限次尝试。虽然很多人会说我试过了，但是却没有想过，自己把验证码换掉的，因为是自动的，但如果阻止了不变呢？

验证码验证成功后，并没有即时清除答案，导致可再次利用上一次的key和答案，又一次变向成了万能验证码

验证码没有在该出现的时间里出现，比如秒杀等业务提前通过请求调出验证码，那么准点即可提交，哪怕别人验证码速度再快，也不会比提早准备好的快了

验证码有效期太长，在一些特定情况下也会存在问题

验证码太简单，容易被OCR之类的组件直接识别，图像识别高概率正确

如果验证码系统是公共独立的，那么必须在自身系统出错时有合理的处理方式，如常规逻辑异常视为错误，但如果是系统崩溃，为防止影响其他系统应放过，否则影响就是灾难性的

如果验证码是批量提前生成，就特别要注意验证码当前状态，如待使用、使用中、已验证等等，防止上面类似的情况发生

这里只是提到一些常规的情况，也有一些特殊情况可能没有包含在此。至于如何能做到详尽的测试，篇幅较大，就不在这里阐述了。小小验证码，居然有这么多内容，你有想过吗？