LOADRUNNER性能測試中的驗證碼問題

如今愈來愈多的網站爲了安全性或是防止Spam的侵害，採用了驗證碼的校驗技術。簡單地說，驗證碼就是在進

行登陸或是內容提交的時候，頁面上會隨機出現一我的工可識別，但機器不可識別的驗證字符串（通常是採用

背景、扭曲等方式產生的圖片），要求登陸或是提交內容時同時輸入這個驗證碼。

驗證碼能夠有效防止對口令的刺探和所謂的網絡推廣軟件帶來的大量的Spam內容，目前已經被許多Internet或

是Intranet應用接受爲標準的實現方式。但對性能測試來講，這種驗證碼又帶來了很大的問題。

最突出的問題是，性能測試工具自己是自動化工具，因爲這種驗證碼採用的是「防止自動化工具嘗試」的方法

，所以，在錄製了腳本以後會發現，很難對腳本進行調整，以使其適應驗證碼驗證的須要。已經不止一次有人

提到這個問題，並詢問有沒有較好的解決方案。

對這個問題，我我的的見解是，基本上能夠考慮從三個途徑來解決該問題：

一、第一種方法，也是最容易想到的，在被測系統中暫時屏蔽驗證功能，也就是說，臨時修改應用，不管用戶輸

入的是什麼驗證碼，都認爲是正確的。這種方法最容易實現，對測試結果也不會有太大的影響（固然，這種方

式去掉了「驗證驗證碼」這個環節，不過這個環節原本就很難成爲系統性能瓶頸）。但這種方法有一個致命的

問題：若是被測系統是一個實際已上線的系統，屏蔽驗證功能會對已經在運行的業務形成很是大的安全性的風

險，所以，對於已上線的系統來講，用這種方式就不合適了；

二、第二種方法，在第一種方法的基礎上稍微進行一些改進。第一種方法帶來了很大的安全性問題，那麼咱們可

以考慮，不取消驗證，但在其中留一個後門，咱們設定一個所謂的「萬能驗證碼」，只要用戶輸入這個「萬能

驗證碼」，咱們就驗證經過，不然，仍是按照原先的驗證方式進行驗證。這種方式仍然存在安全性的問題，但

因爲咱們能夠經過管理手段將「萬能驗證碼」控制在一個小的範圍內，並且只在性能測試期間保留這個小小的

後門，相對第一種方法來講，在安全性方面已經有較大的改進了；

三、若是安全性對應用來講真的是相當重要的，不允許有一絲一毫的閃失，那咱們還能夠用更進一步的方法來處

理這個問題。通常的性能測試工具（MI的LR、Seague的Silk performer等）都可以調用外部的DLL或是組件接口

，所以，能夠考慮得到「驗證碼驗證」部分的實現，寫一個驗證碼獲取的DLL，在測試腳本中進行調用便可。

除了這三種方法之外，可能還會有其餘的方法存在，也但願各位能提供一些其餘的思路。在個人實踐中，第二

種方法用得比較多，對未上線系統系統的內部性能測試，有時候也用第一種方法。但要提醒的是，若是針對的

是已上線系統，不管用哪一種方法，測試完成後，都必須馬上將應用恢復，並對系統進行一次安全審計，以避免在

測試期間被他人***。第三種方法用得比較少，並且具體上還依賴於驗證組件是否能提供這樣的接口。

在LR中，關聯的原理是將服務器返回的信息中的某些內容保存在一個變量中，而後，在後續的操做（譬如POST

）中用這個變量替代錄制時的內容。若是用關聯能夠解決驗證碼的問題，那就只有一個可能：請求頁面時返回

的內容中已經包含了驗證碼了，但若是真實狀況是這樣，驗證碼也就沒有任何做用了。根據個人理解，驗證碼

通常經過組件來產生，產生的驗證碼通常以「圖片」形式嵌入在頁面中，並且該圖片通常通過扭曲、背景、隨

機干擾等方式進行了處理，經過關聯這種方式是確定不能解決的。

最後，若是你還能找到描述用關聯方法解決驗證碼問題的文章，麻煩給我發一份，我也學習一下，謝謝。