web應用程序測試方法和測試技術詳述 - 程序開發(轉帖)

　　1.概述 隨着 web 應用的增多，新的模式解決方案中以 web 爲核心的應用也越來越多， 很多公司各種應用的架構都以 B/S 及 web 應用爲主，但是有關 WEB 測試方面的內容並沒有相應的總結，所以我在這裏對 web 的測試方法和採用的測試技術進行總結，便於內部交流。

　　測試方法儘量涵蓋 web 程序的各個方面，測試技術方面在繼承傳統測試技術的技術上結合 web 應用的特點。

　　2.測試方法

　　說明：測試方法的選擇取決你的測試策略。

　　一般的 web 測試和以往的應用程序的測試的側重點不完全相同，基本包括以下幾個方面。

　　當然圓滿的完成測試還要有好的團體和流程等的方方面面的支持，你同樣應該對這些方面進行注意。有些測試方法設計到了流程，哪些應該在你的測試團隊建設中建立。

　　2.1界面測試

　　現在一般人都有使用瀏覽器瀏覽網頁的經歷，用戶雖然不是專業人員但是對界面效果的印象是很重要的。如果你注重這方面的測試，那麼驗證應用程序是否易於使用就非常重要了。很多人認爲這是測試中最不重要的部分，但是恰恰相反界面對不懂技術的客戶來說那相當關鍵，慢慢體會你會明白的。

　　方法上可以根據設計文檔，如果夠專業的話可以專業美工人員，來確定整體風格頁面風格，然後根據這個可以頁面人員可以生成靜態的 HTML ， CSS 等甚至生成幾套不用的方案來討論，或者交給客戶評審，最後形成統一的風格的頁面 / 框架。注意不要靠程序員的美術素養形成你的 web 風格，那樣可能會很糟糕。

　　主要包括以下幾個方面的內容：

　　- 站點地圖和導航條 位置、是否合理、是否可以導航等內容佈局 佈局是否合理，滾動條等簡介說明 說明文字是否合理，位置，是否正確；

　　- 背景 / 色調 是否正確、美觀，是否符合用戶需求；

　　- 頁面在窗口中的顯示是否正確、美觀（在調整瀏覽器窗口大小時，屏幕刷新是否正確）表單樣式 大小，格式，是否對提交數據進行驗證（如果在頁面部分進行驗證的話）等；

　　- 連接 連接的形式，位置，是否易於理解等。

　　web測試的主要頁面元素

　　- 頁面元素的容錯性列表（如輸入框、時間列表或日曆）；

　　- 頁面元素清單（爲實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、複選框、列表框、超連接、輸入框等等）；

　　- 頁面元素的容錯性是否存在；

　　- 頁面元素的容錯性是否正確；

　　- 頁面元素基本功能是否實現（如文字特效、動畫特效、按鈕、超連接）；

　　- 頁面元素的外形、擺放位置（如按鈕、列表框、核選框、輸入框、超連接等）；

　　- 頁面元素是否顯示正確（主要針對文字、圖形、簽章）；

　　- 元素是否顯示（元素是否存在）；

　　- 頁面元素清單（爲實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、複選框、列表框、超連接、輸入框等等）。

　　測試技術

　　- 通過頁面走查，瀏覽確定使用的頁面是否符合需求。可以結合兼容性測試對不用分辨率下頁面顯示效果，如果有影響應該交給設計人員提出解決方案；

　　- 可以結合數據定義文檔查看錶單項的內容，長度等信息；

　　- 對於動態生成的頁面最好也能進行瀏覽查看。如 Servelet 部分可以結合編碼規範，進行代碼走查。是否支持中文，如果數據用 XML 封裝要做的工作會多一點等等。

　　2.1.l界面測試要素:

　　符合標準和規範 , 靈活性 , 正確性 , 直觀性 , 舒適性 , 實用性 , 一致性

　　2.1.l.1直觀性 :

　　- 用戶界面是否潔淨, 不唐突, 不擁擠. 界面不應該爲用戶製造障礙 . 所需功能或者期待的響應應該明顯 , 並在預期出現的地方；

　　- 界面組織和佈局合理嗎? 是否允許用戶輕鬆地從一個功能轉到另一個功能? 下一步做什麼明顯嗎? 任何時刻都可以決定放棄或者退回, 退出嗎? 輸入得到承認了嗎? 菜單或者窗口是否深藏不露?

　　- 有多餘功能嗎? 軟件整體抑或局部是否做得太多? 是否有太多特性把工作複雜化了? 是否感到信息太龐雜?

　　- 如果其他所有努力失敗 , 幫助系統真能幫忙嗎?

　　2.1.l.2一致性

　　- 快速鍵和菜單選項 . 在 Windows 中按 F1 鍵總是得到幫助信息；

　　- 術語和命令. 整個軟.web應用程序測試方法和測試技術詳述 - 程序開發(轉帖) .件使用同樣的術語嗎? 特性命名一致嗎? 例如, Find 是否一直叫Find, 而不是有時叫Search?

　　- 軟件是否一直面向同一級別用戶? 帶有花哨用戶界面的趣味賀卡程序不應該顯示泄露技術機密的錯誤提示信息；

　　- 按鈕位置和等價的按鍵 . 大家是否注意到對話框有 OK 按鈕和 Cancle 按鈕時, OK 按鈕總是在上方或者左方,而 Cancle 按鈕總是在下方或右方? 同樣原因, Cancle 按鈕的等價按鍵通常是 Esc, 而選中按鈕的等價按鈕通常是 Enter. 保持一致。

　　2.1.l.3靈活性

　　狀態跳轉：靈活的軟件實現同一任務有多種選擇方式；

　　狀態終止和跳過：具有容錯處理能力；

　　數據輸入和輸出：用戶希望有多種方法輸入數據和查看結果 . 例如 , 在寫字板插入文字可用鍵盤輸入 , 粘貼,從 6 種文件格式讀入 , 作爲對象插入 , 或者用鼠標從其他程序拖動。

　　2.1.l.4舒適性

　　恰當：軟件外觀和感覺應該與所做的工作和使用者相符；

　　錯誤處理：程序應該在用戶執行嚴重錯誤的操作之前提出警告 , 並允許用戶恢復由於錯誤操作導致丟失的數據，如大家認爲 undo /redo 是當然的；

　　性能：快不見得是好事，要讓用戶看得清程序在做什麼，它是有反應的。

　　2.2功能測試

　　功能測試是測試中的重點，主要包括一下幾個方面的內容：

　　連接：這個連接和界面測試中的連接不同。那裏注重的是連接方式和位置，如是圖像還是文字放置的位置等，還是其他的方式；這裏的連接注重功能，如是否有連接，連接的是否是說明的位置等；

　　表單提交：應當模擬用戶提交，驗證是否完成功能，如註冊信息，要測試這些程序，需要驗證服務器能正確保存這些數據，而且後臺運行的程序能正確解釋和使用這些信息。還有數據正確性驗證，異常處理等，最好結合易用性要求等。 B/S 結構實現的功能可能主要的就在這裏，提交數據，處理數據等如果有固定的操作流程可以考慮自動化測試工具的錄製功能，編寫可重複使用的腳本代碼，可以在測試、迴歸測試時運行以便減輕測試人員工作量；

　　Cookies 驗證：如果系統使用了 cookie ，測試人員需要對它們進行檢測。如果在 cookies 中保存了註冊信息，請確認該 cookie 能夠正常工作而且已對這些信息已經加密。如果使用 cookie 來統計次數，需要驗證次數累計正確。關於 cookie 的使用可以參考瀏覽器的幫助信息。如果使用 B/S 結構 cookies 中存放的信息更多；

　　功能易用性測試 完成了功能測試可以對應用性進行了解，最好聽聽客戶的反映，在可以的情況下對程序進行改進是很有必要的，和客戶保持互動對系統滿意度也是很有幫助的。

　　2. 2.1測試技術

　　功能測試的測試技術可是很多的，我們可以結合實際環境選擇使用。

　　白盒測試技術(White Box Testing)： 深入到代碼一級的測試，使用這種技術發現問題最早，效果也是最好的。該技術主要的特徵是測試對象進入了代碼內部，根據開發人員對代碼和對程序的熟悉程度，對有需要的部分進行在軟件編碼階段，開發人員根據自己對代碼的理解和接觸所進行的軟件測試叫做白盒測試。這一階段測試以軟件開發人員爲主，在 JAVA 平臺使用 Xunit 系列工具進行測試， Xunit 測試工具是類一級的測試工具對每一個類和該類的方法進行測試。

　　黑盒測試技術(Black Box Testing)：黑盒測試的內容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結合兼容，性能測試等方面進行，根據軟件需求，設計文檔，模擬客戶場景隨系統進行實際的測試，這種測試技術是使用最多的測試技術涵蓋了測試的方方面面，可以考慮以下方面

　　正確性 (Correctness) ：計算結果，命名等方面。

　　可用性 (Usability) ：是否可以滿足軟件的需求說明。 邊界條件 (Boundary Condition) ：輸入部分的邊界值，就是使用一般書中說的等價類劃分，試試最大最小和非法數據等等。

　　性能(Performance)： 正常使用的時間內系統完成一個任務需要的時間，多人同時使用的時候響應時間在可以接受範圍內。 J2EE 技術實現的系統在性能方面更是需要照顧的，一般原則是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影響易用性了。如果在測試過程中發現性能問題，修復起來是非常艱難的，因爲這常常意味着程序的算法不好，結構不好，或者設計有問題。因此在產品開發的開始階段，就要考慮到軟件的性能問題

　　壓力測試(Stress)： 多用戶情況可以考慮使用壓力測試工具，建議將壓力和性能測試結合起來進行。如果有負載平衡的話還要在服務器端打開監測工具 , 查看服務器 CPU 使用率，內存佔用情況，如果有必要可以模擬大量數據輸入，對硬盤的影響等等信息。如果有必要的話必須進行性能優化 ( 軟硬件都可以 ) 。這裏的壓力測試針對的是某幾項功能。

　　錯誤恢復(Error Recovery)：錯誤處理，頁面數據驗證，包括突然間斷電，輸入髒數據等。

　　安全性測試(Security)：這個領域正在研究中，防火牆、補丁包、殺毒軟件等的就不必說了，不過可以考慮。破壞性測試時任意看了一些資料後得知 , 這裏面設計到的知識 \ 內容可以寫本書了 , 不是一兩句可以說清的，特別是一些商務網站，或者跟錢有關，或者和公司祕密有關的 web 更是需要這方面的測試，在外國有一種專門幹這一行的人叫安全顧問，可以審覈代碼，提出安全建議，出現緊急事件時的處理辦法等，在國內沒有聽說哪裏有專門搞安全技術測試的內容。

　　兼容性(Compatibility)：不同瀏覽器，不同應用程序版本在實現功能時的表現不同的上網方式，如果你測試的是一個公共網站的話。

　　兼容性測試內容詳述：

　　- 硬件平臺

　　- 瀏覽器軟件和版本：瀏覽器插件，瀏覽器選項，視頻分辨率和色深，文字大小，調制解調器速率 .

　　軟件配置 (Configuration)：如 IE 瀏覽器的不用選項 - 安全設定最高，禁用腳本程序等等，你們的程序在各種不用的設置下表現如何。

　　2. 2.2單元測試技術 (Unit Test):

　　2. 2.2.1 下面是對白盒測試和單元測試的區別的論述 :

　　單元測試和白盒測試是不同的，雖然單元測試和白盒測試都是關注功能，他們都需要代碼支持，但是級別不同。白盒測試關注的是類中一個方法的功能，是更小的單位，但是完成一個單元測試可能需要 N 多類，所以說作單元測試需要寫驅動和穩定樁，比如查詢單元是一個查詢包，包括 N 多的測試類、測試數據，運行他需要提供數據的部分，輸入參數和發出命令的驅動等等，是比類大的一個整體進行的。

　　另一個明顯的區別是白盒測試不會關注類接口，但是單元測試主要的內容就是類接口測試。

　　不過很多時候是很少區分的，因爲這兩種技術實現起來有很多相互關聯的部分。不過要看你對質量的關注程度來決定。

　　2. 2.2.2 功能測試邊界測試 \ 越界測試技術詳述

　　邊界條件

　　邊界條件是指軟件計劃的操作界限所在的邊緣條件，如果軟件測試問題包含確定的邊界，那麼數據類型可能是：數值、速度、字符、地址、位置、尺寸、數量。同時，考慮這些類型的下述特徵：第一個 / 最後一個、最小值 / 最大值、開始 / 完成、超過 / 在內、空 / 滿、最短 / 最長、最慢 / 最快、最早 / 最遲、最大 / 最小、最高 / 最低、相鄰 / 最遠。

　　越界測試

　　通常是簡單加 1 或者很小的數 ( 對於最大值 ) 和減少 1 或者很小的數 ( 對於最小值 ) ，例如：第一個減 1/ 最後一個加 1 、開始減 1/ 完成加 1 、空了再減 / 滿了再加、慢上加慢 / 快上加快、最大數加 1/ 最小數減 1 、最小值減 1/ 最大值加 1 、剛好超過 / 剛好在內、短了再短 / 長了再長、早了更早 / 晚了更晚、最高加 1/ 最低減 1 。

　　另一些該注意的輸入：默認，空白，空值，零值和無；非法，錯誤，不正確和垃圾數據。

　　2. 2.2.3 狀態測試技術

　　- 軟件可能進入的每一種獨立狀態；

　　- 從一種狀態轉入另一種狀態所需的輸入和條件；

　　- 進入或退出某種狀態時的設置條件及輸入結果。

　　具體測試方法可以參考如下：

　　- 每種狀態至少訪問一次；

　　- 測試看起來最常見最普遍的狀態轉換；

　　- 測試狀態之間最不常用的分支；

　　- 測試所有錯誤狀態及其返回值；

　　- 測試隨機狀態轉換。

　　2. 2.2.4 競爭條件測試技術

　　競爭條件典型情形參考如下 :

　　- 兩個不同的程序同時保存或打開同一個文檔；

　　- 共享同一臺打印機 , 通信端口或者其他外圍設備；

　　- 當軟件處於讀取或者修改狀態時按鍵或者單擊鼠標；

　　- 同時關閉或者啓動軟件的多個實例；

　　- 同時使用不同的程序訪問一個共同數據庫。

　　2. 2.3負載 \壓力測試 (StressTest)

　　在這裏的負載 \ 壓力和功能測試中的不同，他是系統測試的內容，是基本功能已經通過後進行的。可以在集成測試階段，亦可以在系統測試階段進行。

　　使用負載測試工具進行，虛擬一定數量的用戶看一看系統的表現，是否滿足定義中的指標。

　　負載測試一般使用工具完成， loadrunner ， webload ， was ， ewl ， e-test 等，主要的內容都是編寫出測試腳本，腳本中一般包括用戶常用的功能，然後運行，得出報告。所以負載測試包括的主要內容就不介紹了。

　　負載測試技術在各種極限情況下對產品進行測試 ( 如很多人同時使用該軟件，或者反覆運行該軟件 ) ，以檢查產品的長期穩定性。例如，使用壓力測試工具對 web 服務器進行壓力測試。本項測試可以幫助找到一些大型的問題，如死機、崩損、內存泄漏等，因爲有些存在內存泄漏問題的程序，在運行一兩次時可能不會出現問題，但是如果運行了成千上萬次，內存泄漏得越來越多，就會導致系統崩滑。用 J2EE 實現的系統很少但是並不是沒有內存問題。

　　無論什麼工具基本的技術都是利用線程技術模仿和虛擬用戶，在這裏主要的難點在與測試腳本的編寫，每種工具使用的腳本都不一樣，但是大多數工具都提供錄製功能就算是不會編碼的測試人員同樣可以測試。

　　對負載工具的延伸使用可以進行系統穩定性測試，系統極限測試，如使用 100 的 Load Size 連續使用 24 小時，微軟定義的通過準則是通過 72 小時測試的程序一般不會出現穩定性的問題。

　　2. 2.4迴歸測試 (Regression Test)

　　過一段時間以後，再回過頭來對以前修復過的 Bug 重新進行測試，看該 Bug 是否會重新出現。

　　迴歸測試技術可以在測試的各個階段出現，無論是單元測試還是集成測試還是系統測試。是對以前問題進行驗證的過程。

　　迴歸測試的目的就是保證以前已經修復的 Bug 不會再出現。實際上，許多 Bug 都是在迴歸測試時發現的，在此階段，我們首先要檢查以前找到的 Bug 是否已經更正了。值得注意的是，已經更正的 Bug 也可能又回來了，有的 Bug 經過修改之後可能又產生了新的 Bug 。所以，迴歸測試可保證已更正的 Bug 不再重現，不產生新的 Bug 。

　　2. 2.5 Alpha和 Beta測試 (Alpha and Beta Test):

　　在正式發佈產品之前往往要先發布一些測試版，讓用戶能夠反饋出相關信息，或者找到存在的 Bug ，以便在正式版中得到解決。

　　特別是在有客戶參加的情況下，對系統進行測試可能會出現一些我們沒有考慮的情況，還可以解決一些客戶實際關心的問題。

　　不同的測試技術區分

　　2.3覆蓋測試技術

　　說明 : 測試覆蓋率可以看出測試的完成度，在測試分析報告中可以作爲量化指標的依據，測試覆蓋率越高效果越好。

　　覆蓋測試可以是程序代碼的執行路徑覆蓋，亦可以是功能實現的步驟覆蓋（可以理解成流程圖的路徑覆蓋）。

　　該技術可以用在任何測試階段，包括單元測試、集成測試、系統測試。

　　使用該技術時可以使用以上的任何測試方法和測試技術。

　　2.4白盒測試和黑盒測試技術

　　白盒測試技術 (White Box Testing) ：該技術主要的特徵是測試對象進入了代碼內部，根據開發人員對代碼和對程序的熟悉程度，對有需要的部分進行測試。在軟件編碼階段，開發人員根據自己對代碼的理解和接觸所進行的軟件測試叫做白盒測試。這一階段測試以軟件開發人員爲主，使用 Xunit 系列工具進行測試，可以包括很多方面如功能性能等。

　　黑盒測試 (Black Box Testing) ：測試的主體部分，黑盒測試的內容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結合兼容，性能測試等方面進行，包括的不同測試類型請參考以上內容。 2.5手工測試和自動化測試

　　手工測試（ Manual Testing ）：即依靠人力來查找 Bug 。方法可以參考上邊的測試，也可以根據對實現技術及經驗等進行不同的測試。

　　自動測試（ Automation Testing ）：使用有針對工具實行。可以作出自動化測試的計劃，對可以進行自動化測試的部分編寫或者錄製相應的腳本，可以加入功能，容錯，表單提交等，可以參考 MI,Rational 或者其他類測試工具說明。

　　根據權威的軟件測試經驗，手工測試還是主要的測試方法，自動測試不夠靈活，在這裏不再詳述。微軟的測試過程 80 ％還是手工完成。

　　自動測試永遠也代替不了手工測試，但是手工測試的工作量很大是不爭的事實。

　　2.6根據RUP標準按階段區分測試

　　單元測試：在上邊有詳細的敘述，還有針對單元測試和集成測試的論述，請參考。

　　集成測試：分爲功能集成測試和系統集成測試，相互有調用的功能集成，在系統環境下功能相互調用的影響等，使用方法可以任意選用上面的內容。注重功能方面。

　　系統測試：在功能實現的基礎上，可以加入兼容性，易用性，性能等等。

　　驗收測試：可以包括 Alpha 和 Beta 測試，在這裏就不再詳述。

　　3.存在風險及解決方法

　　說明：測試不能找出所有的問題，只是儘量在開發階段解決大多數的問題而已。

　　測試風險如下：

　　軟硬件的測試環境提供上也對測試結果有很大的影響；

　　測試團隊的水平，經驗，合作效果等；

　　整個開發流程對測試的重視程度，測試的進入時間等；

　　由於測試環境操作系統，網絡環境，帶寬等情況可能產生的測試結果可能不同這是就需要經驗以及對測試環境的保護等方面下一些功夫。

　　4.軟件缺陷的原則

　　軟件缺陷區別於軟件 bug, 它是在測試過程中出現的對系統有影響的，但是在設計中沒有的或者對修改後的 bug 測試和開發人員有不同意見等。

　　- 軟件未達到產品說明書標明的功能；

　　- 軟件出現了產品說明書指明不會出現的錯誤；

　　- 軟件功能超出產品說明書指明範圍；

　　- 軟件未達到產品說明書雖未指出但應達到的目標；

　　- 軟件測試員認爲軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認爲不好。

　　5.文檔測試

　　產品說明書屬性檢查清單

　　完整：是否有遺漏和丟失？完全嗎？單獨使用是否包含全部內容？

　　準確：既定解決方案正確嗎？目標明確嗎？有沒有錯誤？

　　精確：不含糊，清晰。描述是否一清二楚？還是自說自話？容易看懂和理解嗎？

　　一致：產品功能描述是否自相矛盾？與其他功能有沒有衝突 ?

　　貼切：描述功能的陳述是否必要 ? 有沒有多餘信息 ? 功能是否滿足的客戶要求 ?

　　合理：在特定的預算和進度下，以現有人力，物力和資源能否實現 ?

　　代碼無關：是否堅持定義產品，而不是定義其所信賴的軟件設計，架構和代碼 ?

　　可測試性：特性能否測試 ? 測試員建立驗證操作的測試程序是否提供足夠的信息 ?

　　產品說明書用語檢查清單

　　說明：對問題的描述通常表現爲粉飾沒有仔細考慮的功能 ---- 可歸結於前文所述的屬性。從產品說明書上找出這樣的用語，仔細審視它們在文中是怎樣使用的。產品說明書可能會爲其掩飾和開脫 , 也可能含糊其詞 ---- 無論是哪一種情況都可視爲軟件缺陷。

　　- 總是，每一種，所有，沒有，從不。如果看到此類絕對或肯定的，切實認定的敘述，軟件測試員就可以着手設計針鋒相對的案例。

　　- 當然，因此，明顯，顯然，必然。這些話意圖誘使接受假定情況，不要中了圈套。

　　- 某些，有時，常常，通常，慣常，經常，大多，幾乎。這些話太過模糊， " 有時 " 發生作用的功能無法測試。

　　等等，諸如此類，依此類推。以這樣的詞結束的功能清單無法測試，功能清單要絕對或者解釋明確，以免讓人迷惑，不知如何推論。

　　- 良好，迅速，廉價，高效，小，穩定。這些是不確定的說法，不可測試。如果在產品說明書中出現，就必須進一步指明含義。

　　- 已處理，已拒絕，已忽略，已消除。這些廉潔可能會隱藏大量需要說明的功能。

　　- 如果 ... 那麼 ...( 沒有否則 ) 。找出有 " 如果 ... 那麼 ..." 而缺少配套的 " 否則 " 結構的陳述，想一想 " 如果 " 沒有發生會怎樣。