在Web工程過程中，基于Web系統(tǒng)的測試、確認和驗收是一項重要而富有挑戰(zhàn)性的工作。基于Web的系統(tǒng)測試與傳統(tǒng)的軟件測試不同，它不但需要檢查和驗證是否按照設(shè)計的要求運行，而且還要測試系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預(yù)見性使測試基于Web的系統(tǒng)變得困難。因此，我們必須為測試和評估復(fù)雜的基于Web的系統(tǒng)研究新的方法和技術(shù)。
本文將 web 測試分為 6 個部分：
1. 功能測試
2. 性能測試（包括負載/壓力測試）
3. 用戶界面測試
4. 兼容性測試
5. 安全測試
6. 接口測試
本文的目的是覆蓋 web 測試的各個方面，未就某一主題進行深入說明。
1 功能測試
1.1 鏈接測試
鏈接是Web應(yīng)用系統(tǒng)的一個主要特征，它是在頁面之間切換和指導(dǎo)用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證Web應(yīng)用系統(tǒng)上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
鏈接測試可以自動進行，現(xiàn)在已經(jīng)有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應(yīng)用系統(tǒng)的所有頁面開發(fā)完成之后進行鏈接測試。
采取措施：采用自動檢測網(wǎng)站鏈接的軟件來進行。
推薦軟件：
Xenu Link Sleuth 免費 綠色免安裝軟件
HTML Link Validator 共享（30天試用）
1.2 表單測試
當用戶通過表單提交信息的時候，都希望表單能正常工作。
如果使用表單來進行在線注冊，要確保提交按鈕能正常工作，當注冊完成后應(yīng)返回注冊成功的消息。如果使用表單收集配送信息，應(yīng)確保程序能夠正確處理這些數(shù)據(jù)，最后能讓顧客能讓客戶收到包裹。要測試這些程序，需要驗證服務(wù)器能正確保存這些數(shù)據(jù)，而且后臺運行的程序能正確解釋和使用這些信息。
當用戶使用表單進行用戶注冊、登陸、信息提交等操作時，我們必須測試提交操作的完整性，以校驗提交給服務(wù)器的信息的正確性。例如：用戶填寫的出生日期與職業(yè)是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗?zāi)J值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統(tǒng)是否會報錯。
1.3 數(shù)據(jù)校驗
如果系根據(jù)業(yè)務(wù)規(guī)則需要對用戶輸入進行校驗，需要保證這些校驗功能正常工作。例如，省份的字段可以用一個有效列表進行校驗。在這種情況下，需要驗證列表完整而且程序正確調(diào)用了該列表(例如在列表中添加一個測試值，確定系統(tǒng)能夠接受這個測試值)。
在測試表單時，該項測試和表單測試可能會有一些重復(fù)。
1.2和1.3的采取措施：第一個完整的版本采用手動檢查，同時形成WinRunner（QTP）腳本；回歸測試以及升級版本主要靠WinRunner（QTP）自動回放測試。
1.4 cookies測試
Cookies通常用來存儲用戶信息和用戶在某應(yīng)用系統(tǒng)的操作，當一個用戶使用Cookies訪問了某一個應(yīng)用系統(tǒng)時，Web服務(wù)器將發(fā)送關(guān)于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創(chuàng)建動態(tài)和自定義頁面或者存儲登陸等信息。
如果Web應(yīng)用系統(tǒng)使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內(nèi)容可包括Cookies是否起作用，是否按預(yù)定的時間進行保存，刷新對Cookies有什么影響等。如果在 cookies 中保存了注冊信息，請確認該 cookie能夠正常工作而且已對這些信息已經(jīng)加密。如果使用 cookie 來統(tǒng)計次數(shù)，需要驗證次數(shù)累計正確。
采取措施：
1 采用黑盒測試：采用上面提到的方法進行測試
2 采用查看cookies的軟件進行（初步的想法）
可以選擇采用的軟件
IECookiesView v1.50
Cookies Manager v1.1
1.5 數(shù)據(jù)庫測試
在Web應(yīng)用技術(shù)中，數(shù)據(jù)庫起著重要的作用，數(shù)據(jù)庫為Web應(yīng)用系統(tǒng)的管理、運行、查詢和實現(xiàn)用戶對數(shù)據(jù)存儲的請求等提供空間。在Web應(yīng)用中，最常用的數(shù)據(jù)庫類型是關(guān)系型數(shù)據(jù)庫，可以使用SQL對信息進行處理。
在使用了數(shù)據(jù)庫的Web應(yīng)用系統(tǒng)中，一般情況下，可能發(fā)生兩種錯誤，分別是數(shù)據(jù)一致性錯誤和輸出錯誤。數(shù)據(jù)一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網(wǎng)絡(luò)速度或程序設(shè)計問題等引起的，針對這兩種情況，可分別進行測試。
采取措施：暫時沒有更好的測試方法
考慮結(jié)合到1.2和1.3的測試中
1.6 應(yīng)用程序特定的功能需求
最重要的是，測試人員需要對應(yīng)用程序特定的功能需求進行驗證。嘗試用戶可能進行的所有操作：下訂單、更改訂單、取消訂單、核對訂單狀態(tài)、在貨物發(fā)送之前更改送貨信息、在線支付等等。這是用戶之所以使用網(wǎng)站的原因，一定要確認網(wǎng)站能像廣告宣傳的那樣神奇。
采取措施：深刻理解需求說明文檔
1.7 設(shè)計語言測試
Web設(shè)計語言版本的差異可以引起客戶端或服務(wù)器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環(huán)境中開發(fā)時，開發(fā)人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
暫時沒有方法測試，可以多參考一點討論組內(nèi)的更新信息
2 性能測試
2.1 連接速度測試
用戶連接到Web應(yīng)用系統(tǒng)的速度根據(jù)上網(wǎng)方式的變化而變化，他們或許是電話撥號，或是寬帶上網(wǎng)。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統(tǒng)響應(yīng)時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應(yīng)速度太慢，用戶可能還沒來得及瀏覽內(nèi)容，就需要重新登陸了。而且，連接速度太慢，還可能引起數(shù)據(jù)丟失，使用戶得不到真實的頁面。
2.2 負載測試
負載測試是為了測量Web系統(tǒng)在某一負載級別上的性能，以保證Web系統(tǒng)在需求范圍內(nèi)能正常工作。負載級別可以是某個時刻同時訪問Web系統(tǒng)的用戶數(shù)量，也可以是在線數(shù)據(jù)處理的數(shù)量。例如：Web應(yīng)用系統(tǒng)能允許多少個用戶同時在線？如果超過了這個數(shù)量，會出現(xiàn)什么現(xiàn)象？Web應(yīng)用系統(tǒng)能否處理大量用戶對同一個頁面的請求？
2.3 壓力測試
負載測試應(yīng)該安排在Web系統(tǒng)發(fā)布以后，在實際的網(wǎng)絡(luò)環(huán)境中進行測試。因為一個企業(yè)內(nèi)部員工，特別是項目組人員總是有限的，而一個Web系統(tǒng)能同時處理的請求數(shù)量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結(jié)果才是正確可信的。
進行壓力測試是指實際破壞一個Web應(yīng)用系統(tǒng)，測試系統(tǒng)的反映。壓力測試是測試系統(tǒng)的限制和故障恢復(fù)能力，也就是測試Web應(yīng)用系統(tǒng)會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數(shù)據(jù)負載，直到Web應(yīng)用系統(tǒng)崩潰，接著當系統(tǒng)重新啟動時獲得存取權(quán)。
壓力測試的區(qū)域包括表單、登陸和其他信息傳輸頁面等。
負載/壓力測試應(yīng)該關(guān)注什么
測試需要驗證系統(tǒng)能否在同一時間響應(yīng)大量的用戶，在用戶傳送大量數(shù)據(jù)的時候能否響應(yīng)，系統(tǒng)能否長時間運行。可訪問性對用戶來說是極其重要的。如果用戶得到“系統(tǒng)忙”的信息，他們可能放棄，并轉(zhuǎn)向競爭對手。系統(tǒng)檢測不僅要使用戶能夠正常訪問站點，在很多情況下，可能會有黑客試圖通過發(fā)送大量數(shù)據(jù)包來攻擊服務(wù)器。出于安全的原因，測試人員應(yīng)該知道當系統(tǒng)過載時，需要采取哪些措施，而不是簡單地提升系統(tǒng)性能。
瞬間訪問高峰
如果您的站點用于公布彩票的抽獎結(jié)果，最好使系統(tǒng)在中獎號碼公布后的一段時間內(nèi)能夠響應(yīng)上百萬的請求。負載測試工具能夠模擬 X 個用戶同時訪問測試站點。
每個用戶傳送大量數(shù)據(jù)
網(wǎng)上書店的多數(shù)用戶可能只訂購 1-5 書，但是大學(xué)書店可能會訂購 5000 本有關(guān)心理學(xué)介紹的課本? 或者一個祖母為她的 50 個兒孫購買圣誕禮物(當然每個孩子都有自己的郵件地址) 系統(tǒng)能處理單個用戶的大量數(shù)據(jù)嗎?
長時間的使用
如果站點用于處理鮮花訂單，那么至少希望它在母親節(jié)前的一周內(nèi)能持續(xù)運行。如果站點提供基于 web 的 email 服務(wù)，那么點最好能持續(xù)運行幾個月，甚至幾年。可能需要使用自動測試工具來完成這種類型的測試，因為很難通過手工完成這些測試。你可以想象組織100 個人同時點擊某個站點。但是同時組織 100000 個人呢。通常，測試工具在第二次使用的時候，它創(chuàng)造的效益，就足以支付成本。而且，測試工具安裝完成之后，再次使用的時候，只要點擊幾下。
采取措施：采用測試工具WAS、ACT協(xié)助進行測試
3 用戶界面測試
3.1 導(dǎo)航測試
導(dǎo)航描述了用戶在一個頁面內(nèi)操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應(yīng)用系統(tǒng)是否易于導(dǎo)航：導(dǎo)航是否直觀？Web系統(tǒng)的主要部分是否可通過主頁存取？Web系統(tǒng)是否需要站點地圖、搜索引擎或其他的導(dǎo)航幫助？
在一個頁面上放太多的信息往往起到與預(yù)期相反的效果。Web應(yīng)用系統(tǒng)的用戶趨向于目的驅(qū)動，很快地掃描一個Web應(yīng)用系統(tǒng)，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶愿意花時間去熟悉Web應(yīng)用系統(tǒng)的結(jié)構(gòu)，因此，Web應(yīng)用系統(tǒng)導(dǎo)航幫助要盡可能地準確。
導(dǎo)航的另一個重要方面是Web應(yīng)用系統(tǒng)的頁面結(jié)構(gòu)、導(dǎo)航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應(yīng)用系統(tǒng)里面是否還有內(nèi)容，內(nèi)容在什么地方。
Web應(yīng)用系統(tǒng)的層次一旦決定，就要著手測試用戶導(dǎo)航功能，讓最終用戶參與這種測試，效果將更加明顯。
3.2 圖形測試
在Web應(yīng)用系統(tǒng)中，適當?shù)膱D片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應(yīng)用系統(tǒng)的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內(nèi)容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應(yīng)用系統(tǒng)的圖片尺寸要盡量地小，并且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
（2）驗證所有頁面字體的風格是否一致。
（3）背景顏色應(yīng)該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質(zhì)量也是一個很重要的因素，一般采用JPG或GIF壓縮，最好能使圖片的大小減小到 30k 以下
（5）最后，需要驗證的是文字回繞是否正確。如果說明文字指向右邊的圖片，應(yīng)該確保該圖片出現(xiàn)在右邊。不要因為使用圖片而使窗口和段落排列古怪或者出現(xiàn)孤行。
通常來說，使用少許或盡量不使用背景是個不錯的選擇。如果您想用背景，那么最好使用單色的，和導(dǎo)航條一起放在頁面的左邊。另外，圖案和圖片可能會轉(zhuǎn)移用戶的注意力。
3.3內(nèi)容測試
內(nèi)容測試用來檢驗Web應(yīng)用系統(tǒng)提供信息的正確性、準確性和相關(guān)性。
信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導(dǎo)致法律糾紛；信息的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；信息的相關(guān)性是指是否在當前頁面可以找到與當前瀏覽信息相關(guān)的信息列表或入口，也就是一般Web站點中的所謂"相關(guān)文章列表"。
對于開發(fā)人員來說，可能先有功能然后才對這個功能進行描述。大家坐在一起討論一些新的功能，然后開始開發(fā)，在開發(fā)的時候，開發(fā)人員可能不注重文字表達，他們添加文字可能只是為了對齊頁面。不幸的是，這樣出來的產(chǎn)品可能產(chǎn)生嚴重的誤解。因此測試人員和公關(guān)部門一起檢查內(nèi)容的文字表達是否恰當。否則，公司可能陷入麻煩之中，也可能引起法律方面的問題。測試人員應(yīng)確保站點看起來更專業(yè)些。過分地使用粗體字、大字體和下劃線可能會讓用戶感到不舒服。在進行用戶可用性方面的測試時，最好先請圖形設(shè)計專家對站點進行評估。你可能不希望看到一篇到處是黑體字的文章，所以相信您也希望自己的站點能更專業(yè)一些。最后，需要確定是否列出了相關(guān)站點的鏈接。很多站點希望用戶將郵件發(fā)到一個特定的地址，或者從某個站點下載瀏覽器。但是如果用戶無法點擊這些地址，他們可能會覺得很迷惑。
3.4 表格測試
需要驗證表格是否設(shè)置正確。用戶是否需要向右滾動頁面才能看見產(chǎn)品的價格？把價格放在左邊，而把產(chǎn)品細節(jié)放在右邊是否更有效? 每一欄的寬度是否足夠?qū)挘砀窭锏奈淖质欠穸加姓坌校渴欠裼幸驗槟骋桓竦膬?nèi)容太多，而將整行的內(nèi)容拉長?
3.5 整體界面測試
整體界面是指整個Web應(yīng)用系統(tǒng)的頁面結(jié)構(gòu)設(shè)計，是給用戶的一個整體感。例如：當用戶瀏覽Web應(yīng)用系統(tǒng)時是否感到舒適，是否憑直覺就知道要找的信息在什么地方？整個Web應(yīng)用系統(tǒng)的設(shè)計風格是否一致？
對整體界面的測試過程，其實是一個對最終用戶進行調(diào)查的過程。一般Web應(yīng)用系統(tǒng)采取在主頁上做一個調(diào)查問卷的形式，來得到最終用戶的反饋信息。
對所有的用戶界面測試來說，都需要有外部人員（與Web應(yīng)用系統(tǒng)開發(fā)沒有聯(lián)系或聯(lián)系很少的人員）的參與，最好是最終用戶的參與。
采取措施：手動測試，參與人員最好有外部人員
4 兼容性測試
4.1 平臺測試
市場上有很多不同的操作系統(tǒng)類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應(yīng)用系統(tǒng)的最終用戶究竟使用哪一種操作系統(tǒng)，取決于用戶系統(tǒng)的配置。這樣，就可能會發(fā)生兼容性問題，同一個應(yīng)用可能在某些操作系統(tǒng)下能正常運行，但在另外的操作系統(tǒng)下可能會運行失敗。
因此，在Web系統(tǒng)發(fā)布之前，需要在各種操作系統(tǒng)下對Web系統(tǒng)進行兼容性測試。
4.2 瀏覽器測試
瀏覽器是Web客戶端最核心的構(gòu)件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規(guī)格有不同的支持。例如，ActiveX是Microsoft的產(chǎn)品，是為Internet Explorer而設(shè)計的，JavaScript是Netscape的產(chǎn)品，Java是Sun的產(chǎn)品等等。另外，框架和層次結(jié)構(gòu)風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設(shè)置也不一樣。
測試瀏覽器兼容性的一個方法是創(chuàng)建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構(gòu)件和設(shè)置的適應(yīng)性。
4.3 分辨率測試
頁面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否顯示正常? 字體是否太小以至于無法瀏覽? 或者是太大? 文本和圖片是否對齊?
4.4 Modem/連接速率
是否有這種情況，用戶使用 28.8 modem下載一個頁面需要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現(xiàn)。最后，需要確認圖片不會太大。
4.5 打印機
用戶可能會將網(wǎng)頁打印下來。因此網(wǎng)也在設(shè)計的時候要考慮到打印問題，注意節(jié)約紙張和油墨。有不少用戶喜歡閱讀而不是盯著屏幕，因此需要驗證網(wǎng)頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不一樣。測試人員至少需要驗證訂單確認頁面打印是正常的。
4.6 組合測試
最后需要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，但是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻無法使用 Lynx 來瀏覽。如果是內(nèi)部使用的 web 站點，測試可能會輕松一些。如果公司指定使用某個類型的瀏覽器，那么只需在該瀏覽器上進行測試。如果所有的人都使用 T1 專線，可能不需要測試下載施加。(但需要注意的是，可能會有員工從家里撥號進入系統(tǒng)) 有些內(nèi)部應(yīng)用程序，開發(fā)部門可能在系統(tǒng)需求中聲明不支持某些系統(tǒng)而只支持一些那些已設(shè)置的系統(tǒng)。但是，理想的情況是，系統(tǒng)能在所有機器上運行，這樣就不會限制將來的發(fā)展和變動。
采取措施：根據(jù)實際情況，采取等價劃分的方法，列出兼容性矩陣
5 安全測試
即使站點不接受信用卡支付，安全問題也是非常重要的。Web 站點收集的用戶資料只能在公司內(nèi)部使用。如果用戶信息被黑客泄露，客戶在進行交易時，就不會有安全感。
5.1 目錄設(shè)置
Web 安全的第一步就是正確設(shè)置目錄。每個目錄下應(yīng)該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的所有內(nèi)容。我服務(wù)的一個公司沒有執(zhí)行這條規(guī)則。我選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑"…com/objects/images"。然后在瀏覽器地址欄中手工輸入該路徑，發(fā)現(xiàn)該站點所有圖片的列表。這可能沒什么關(guān)系。我進入下一級目錄 "…com/objects" ，點擊 jackpot。在該目錄下有很多資料，其中引起我注意的是已過期頁面。該公司每個月都要更改產(chǎn)品價格，并且保存過期頁面。我翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們?yōu)榱藸幦∫粋€合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處于上風。
5.2 SSL
很多站點使用 SSL 進行安全傳送。你知道你進入一個 SSL 站點是因為瀏覽器出現(xiàn)了警告消息，而且在地址欄中的 HTTP 變成 HTTPS。如果開發(fā)部門使用了SSL，測試人員需要確定是否有相應(yīng)的替代頁面(適用于3.0 以下版本的瀏覽器，這些瀏覽器不支持SSL。當用戶進入或離開安全站點的時候，請確認有相應(yīng)的提示信息。是否有連接時間限制？超過限制時間后出現(xiàn)什么情況？
5.3 登錄
有些站點需要用戶進行登錄，以驗證他們的身份。這樣對用戶是方便的，他們不需要每次都輸入個人資料。你需要驗證系統(tǒng)阻止非法的用戶名/口令登錄，而能夠通過有效登錄。用戶登錄是否有次數(shù)限制? 是否限制從某些 IP 地址登錄? 如果允許登錄失敗的次數(shù)為3，你在第三次登錄的時候輸入正確的用戶名和口令，能通過驗證嗎? 口令選擇有規(guī)則限制嗎? 是否可以不登陸而直接瀏覽某個頁面？
Web應(yīng)用系統(tǒng)是否有超時的限制，也就是說，用戶登陸后在一定時間內(nèi)（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
5.4 日志文件
在后臺，要注意驗證服務(wù)器日志工作正常。日志是否記所有的事務(wù)處理? 是否記錄失敗的注冊企圖? 是否記錄被盜信用卡的使用? 是否在每次事務(wù)完成的時候都進行保存? 記錄IP 地址嗎? 記錄用戶名嗎?
5.5 腳本語言
腳本語言是常見的安全隱患。每種語言的細節(jié)有所不同。有些腳本允許訪問根目錄。其他只允許訪問郵件服務(wù)器，但是經(jīng)驗豐富的黑客可以將服務(wù)器用戶名和口令發(fā)送給他們自己。找出站點使用了哪些腳本語言，并研究該語言的缺陷。還要需要測試沒有經(jīng)過授權(quán)，就不能在服務(wù)器端放置和編輯腳本的問題。最好的辦法是訂閱一個討論站點使用的腳本語言安全性的新聞組?！?/font>
6 接口測試
在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務(wù)器通訊，請求數(shù)據(jù)、驗證數(shù)據(jù)或提交訂單。
6.1服務(wù)器接口
第一個需要測試的接口是瀏覽器與服務(wù)器的接口。測試人員提交事務(wù)，然后查看服務(wù)器記錄，并驗證在瀏覽器上看到的正好是服務(wù)器上發(fā)生的。測試人員還可以查詢數(shù)據(jù)庫，確認事務(wù)數(shù)據(jù)已正確保存。
這種測試可以歸到功能測試中的表單測試和數(shù)據(jù)校驗測試中
6.2 外部接口
有些 web 系統(tǒng)有外部接口。例如，網(wǎng)上商店可能要實時驗證信用卡數(shù)據(jù)以減少欺詐行為的發(fā)生。測試的時候，要使用 web 接口發(fā)送一些事務(wù)數(shù)據(jù)，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的數(shù)據(jù)。(簡單的客戶端腳本能夠在提交事務(wù)之前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，測試人員需要確認軟件能夠處理外部服務(wù)器返回的所有可能的消息。
這種情況在遠程抄表中可能會體現(xiàn)到
6.3 錯誤處理
最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統(tǒng)能夠處理所有錯誤，但卻無法預(yù)期系統(tǒng)所有可能的錯誤。嘗試在處理過程中中斷事務(wù)，看看會發(fā)生什么情況？訂單是否完成？嘗試中斷用戶到服務(wù)器的網(wǎng)絡(luò)連接。嘗試中斷 web 服務(wù)器到信用卡驗證服務(wù)器的連接。在這些情況下，系統(tǒng)能否正確處理這些錯誤？是否已對信用卡進行收費？如果用戶自己中斷事務(wù)處理，在訂單已保存而用戶沒有返回網(wǎng)站確認的時候，需要由客戶代表致電用戶進行訂單確認。
采取措施：在理解需求的基礎(chǔ)上，充分發(fā)揮想象力，盡量比較全面的列出各種異常情況。
7 結(jié)論
無論你在測試 internet、intranet 或者是 extranet 應(yīng)用程序，web 測試相對于非 web 測試來說都是更具挑戰(zhàn)性的工作。用戶對 web 頁面質(zhì)量有很高的期望。在很多情況下，就像業(yè)務(wù)功能一樣，頁面用于維護和發(fā)展公共關(guān)系，所以第一印象非常重要。
凡是有該標志的文章，都是該blog博主Caoer（草兒）原創(chuàng)，凡是索引、收藏
、轉(zhuǎn)載請注明來處和原文作者。非常感謝。