Web測試方法(5)

　　5.3 登錄

　　有些站點需要用戶進行登錄，以驗證他們的身份。這樣對用戶是方便的，他們不需要每次都輸入個人資料。你需要驗證系統阻止非法的用戶名/口令登錄，而能夠通過有效登錄。用戶登錄是否有次數限制? 是否限制從某些 IP 地址登錄? 如果允許登錄失敗的次數為3，你在第三次登錄的時候輸入正確的用戶名和口令，能通過驗證嗎? 口令選擇有規則限制嗎? 是否可以不登陸而直接瀏覽某個頁面?

　　Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內(例如15分鐘)沒有點擊任何頁面，是否需要重新登陸才能正常使用。

　　5.4 日志文件

　　在后臺，要注意驗證服務器日志工作正常。日志是否記所有的事務處理? 是否記錄失敗的注冊企圖? 是否記錄被盜信用卡的使用? 是否在每次事務完成的時候都進行保存? 記錄IP 地址嗎? 記錄用戶名嗎?

　　5.5 腳本語言

　　腳本語言是常見的安全隱患。每種語言的細節有所不同。有些腳本允許訪問根目錄。其他只允許訪問郵件服務器，但是經驗豐富的黑客可以將服務器用戶名和口令發送給他們自己。找出站點使用了哪些腳本語言，并研究該語言的缺陷。還要需要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。最好的辦法是訂閱一個討論站點使用的腳本語言安全性的新聞組。

　　6 接口測試

　　在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務器通訊，請求數據、驗證數據或提交訂單。

　　6.1服務器接口

　　第一個需要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，然后查看服務器記錄，并驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。

　　這種測試可以歸到功能測試中的表單測試和數據校驗測試中

　　6.2 外部接口

　　有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減少欺詐行為的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的數據。(簡單的客戶端腳本能夠在提交事務之前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，測試人員需要確認軟件能夠處理外部服務器返回的所有可能的消息。

　　這種情況在遠程抄表中可能會體現到

　　6.3 錯誤處理

　　最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發生什么情況?訂單是否完成?嘗試中斷用戶到服務器的網絡連接。嘗試中斷 web 服務器到信用卡驗證服務器的連接。在這些情況下，系統能否正確處理這些錯誤?是否已對信用卡進行收費?如果用戶自己中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，需要由客戶代表致電用戶進行訂單確認。

　　采取措施：在理解需求的基礎上，充分發揮想象力，盡量比較全面的列出各種異常情況。

　　7 結論

　　無論你在測試 internet、intranet 或者是 extranet 應用程序，web 測試相對于非 web 測試來說都是更具挑戰性的工作。用戶對 web 頁面質量有很高的期望。在很多情況下，就像業務功能一樣，頁面用于維護和發展公共關系，所以第一印象非常重要。

原文轉自：http://www.uml.org.cn/Test/200704021.asp