web常用模塊測試用例

 

一些常用模塊的測試用例
1、登錄　　2、添加　　3、查詢　　4、刪除
1、登錄
①用戶名和密碼都符合要求（格式上的要求）
②用戶名和密碼都不符合要求（格式上的要求）
③用戶名符合要求，密碼不符合要求（格式上的要求）
④密碼符合要求，用戶名不符合要求（格式上的要求）
⑤用戶名或密碼為空
⑥數據庫中不存在的用戶名，不存在的密碼
⑦數據庫中存在的用戶名，錯誤的密碼
⑧數據庫中不存在的用戶名，存在的密碼
⑨輸入的數據前存在空格
⑩輸入正確的用戶名密碼
以后按[enter]是否能登陸
2、添加
①要添加的數據項均合理，在界面保存成功后，檢查數據庫中是否添加了相應的數據：select查詢
②留出一個必填數據為空
③按照邊界值等價類設計測試用例的原則設計其他輸入項的測試用例：數據組合測試
④不符合要求的地方要有錯誤提示
⑤是否支持table鍵
⑥按enter是否能保存
⑦若提示不能保存，也要察看數據庫里是否多了一條數據
3、刪除
①刪除一個數據庫中存在的數據，然后查看數據庫中是否刪除（界面刪除一條數據，查看數據庫中是否刪除）
②[url=]刪除一個數據庫中並不存在的數據，看是否有錯誤提示，並且數據庫中沒有數據被刪除[/url]file:///C:/Users/ADMINI~1/AppData/Local/Temp/msohtmlclip1/01/clip_image005.gif
A.輸入條件的約束有以下4類：
① E約束（異）：a和b中至多有一個可能為1，即a和b不能同時為1。
② I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。
③ O約束（唯一）；a和b必須有一個，且僅有1個為1。
④ R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。
B.輸出條件約束類型
輸出條件的約束只有M約束（強制）：若結果a是1，則結果b強制為0。
5. 采用因果圖法設計測試用例的步驟：
1) 分析軟件規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予一個標識符。
2) 分析軟件規格說明描述中的語義，找出原因與結果之間, 原因與原因之間對應的關系，根據這些關系,畫出因果圖。
3) 由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不可能出現，為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件。
4) 把因果圖轉換為判定表。
5) 把判定表的每一列拿出來作為依據,設計測試用例。

網站測試的主要方面
1[url=]功能測試[/url]
對於網站的測試而言，每一個獨立的功能模塊需要單獨的[url=]測試用例[/url]的設計導出，主要依據為《需求規格說明書》及《詳細設計說明書》，對於應用程序模塊需要設計者提供基本路徑測試法的測試用例。
● 鏈接測試
鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面：
1）測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；
2）測試所鏈接的頁面是否存在；
3）保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之后進行鏈接測試。
Xenu------主要測試鏈接的正確性的工具
可惜的是對於動態生成的頁面的測試會出現一些錯誤。
●表單測試
當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
要測試這些程序，需要驗證服務器能正確保存這些數據，而且后台運行的程序能正確解釋和使用這些信息。
B/S結構實現的功能可能主要的就在這里，提交數據，處理數據等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復使用的腳本代碼，可以在測試、回歸測試時運行以便減輕測試人員工作量。
我們對UM子系統中各個功能模塊中的各項功能進行逐一的測試，主要[url=]測試方法[/url]為：邊界值測試、等價類測試，以及異常類測試。測試中要保證每種類型都有2個以上的典型數值的輸入，以確保測試輸入的全面性。
●Cookies測試
Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作而且對這些信息已經加密。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。
●設計語言測試
Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如[url=]Java[/url]、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
●數據庫測試
在Web應用技術中，數據庫起着重要的作用，數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。
在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
2性能測試
網站的性能測試對於網站的運行而言異常重要，但是目前對於網站的性能測試做的不夠，我們在進行系統設計時也沒有一個很好的基准可以參考，因而建立網站的性能測試的一整套的測試方案將是至關重要的。
網站的性能測試主要從三個方面進行：連接速度測試、負荷測試（Load）和壓力測試（Stress）.連接速度測試指的是打開網頁的響應速度測試。負荷測試指的是進行一些邊界數據的測試，壓力測試更像是惡意測試，壓力測試傾向應該是致使整個系統崩潰。
●連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鍾），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
●負載測試
負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？Web應用系統能否處理大量用戶對同一個頁面的請求？
●壓力測試
負載測試應該安排在Web系統發布以后，在實際的網絡環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什么情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
采用的[url=]測試工具[/url]：
性能測試可以采用相應的工具進行自動化測試，我們目前采用如下工具
ab -----Apache 的測試工具
OpenSTA—開發系統測試架構
3 接口測試
在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務器通訊，請求數據、驗證數據或提交訂單。
●服務器接口
第一個需要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，然后查看服務器記錄，並驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。
●外部接口

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

●錯誤處理
最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發生什么情況？訂單是否完成？嘗試中斷用戶到服務器的網絡連接。嘗試中斷 web 服務器到信用卡驗證服務器的連接。在這些情況下，系統能否正確處理這些錯誤？是否已對信用卡進行收費？如果用戶自己中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，需要由客戶代表致電用戶進行訂單確認。
4 可用性測試
可用性/易用性方面目前我們只能采用手工測試的方法進行評判，而且缺乏一個很好的評判基准進行，此一方面需要大家共同討論。
●導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜索引擎或其他的導航幫助？
在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要盡可能地准確。
導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統里面是否還有內容，內容在什么地方。
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
●圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
（2）驗證所有頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般采用JPG或GIF壓縮。
●內容測試
內容測試用來檢驗Web應用系統提供信息的正確性、准確性和相關性。
信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；信息的准確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用Microsoft Word的“拼音與語法檢查”功能；信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂“相關文章列表”。
●整體界面測試
整體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什么地方？整個Web應用系統的設計風格是否一致？
對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般Web應用系統采取在主頁上做一個調查問卷的形式，來得到最終用戶的反饋信息。
對所有的可用性測試來說，都需要有外部人員（與Web應用系統開發沒有聯系或聯系很少的人員）的參與，最好是最終用戶的參與。
5 兼容性測試
需要驗證應用程序可以在用戶使用的機器上運行。如果您用戶是全球范圍的，需要測試各種操作系統、瀏覽器、視頻設置和 modem 速度。最后，還要嘗試各種設置的組合。
●平台測試
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。
●瀏覽器測試

瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、ActiveX、 plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。

測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
采用測試工具：
通過白盒測試或者黑盒測試導出的測試用例，采用相應的工具進行測試，可以采用OpenSTA進行測試，此測試工具可以采用不同的瀏覽器進行測試。
●視頻測試
頁面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否顯示正常? 字體是否太小以至於無法瀏覽? 或者是太大? 文本和圖片是否對齊?
●Modem/連接速率測試
是否有這種情況，用戶使用 28.8 modem下載一個頁面需要 10 分鍾，但測試人員在測試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最后，需要確認圖片不會太大。
●打印機測試
用戶可能會將網頁打印下來。因此網頁在設計的時候要考慮到打印問題，注意節約紙張和油墨。有不少用戶喜歡閱讀而不是盯着屏幕，因此需要驗證網頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不一樣。測試人員至少需要驗證訂單確認頁面打印是正常的。
●組合測試
最后需要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，但是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻無法使用 Lynx 來瀏覽。如果是內部使用的 web 站點，測試可能會輕松一些。如果公司指定使用某個類型的瀏覽器，那么只需在該瀏覽器上進行測試。如果所有的人都使用 T1 專線，可能不需要測試下載施加。（但需要注意的是，可能會有員工從家里撥號進入系統） 有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。但是，理想的情況是，系統能在所有機器上運行，這樣就不會限制將來的發展和變動。
6 安全測試
Web應用系統的安全性測試區域主要有：
●目錄設置
Web 安全的第一步就是正確設置目錄。每個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的所有內容。如果沒有執行這條規則。那么選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑“…com/objects/images”。然后在瀏覽器地址欄中手工輸入該路徑，發現該站點所有圖片的列表。這可能沒什么關系。但是進入下一級目錄 “…com/objects” ，點擊 jackpot。在該目錄下有很多資料，其中有些都是已過期頁面。如果該公司每個月都要更改產品價格信息，並且保存過期頁面。那么只要翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們為了爭取一個合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處於上風。
●登錄
現在的Web應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
●Session
Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如15分鍾）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
●日志文件
為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。
●加密
當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
●安全漏洞
服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
目前網絡安全問題日益重要，特別對於有交互信息的網站及進行電子商務活動的網站尤其重要。目前我們的測試沒有涵蓋網站的安全性的測試，我們擬定采用工具來測定。
工具如下

SAINT------- SecurityAdministrator’s Integrated Network Tool

此工具能夠測出網站系統的相應的安全問題，並且能夠給出安全漏洞的解決方案，不過是一些較為常見的漏洞解決方案。
7 代碼合法性測試
代碼合法性測試主要包括2個部分：程序代碼合法性檢查與顯示代碼合法性檢查。
●程序代碼合法性檢查
程序代碼合法性檢查主要標准為《intergrp小組編程規范》，目前采用由SCM管理員進行規范的檢查，未來期望能夠有相應的工具進行測試。
●顯示代碼合法性檢查

顯示代碼的合法性檢查，主要分為Html、JavaScript、Css代碼檢查，目前采用HTML代碼檢查------采用CSEHTML Validator進行測試JavaScript、Css也可以在網上下載相應的測試工具。

8 文檔測試
●產品說明書屬性檢查清單

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

2）准確.既定解決方案正確嗎？目標明確嗎？ 有沒有錯誤？

3）精確、不含糊、清晰.描述是否一清二楚？ 還是自說自話？容易看懂和理解嗎？
4）一致.產品功能能描述是否自相矛盾，與其他功能有沒有沖突

5）貼切.描述功能的陳述是否必要？有沒有多余信息？功能是否原來的客戶要求？

6）合理.在特定的預算和進度下，以現有人力，物力和資源能否實現？
7）代碼無關.是否堅持定義產品，而不是定義其所信賴的軟件設計，架構和代碼

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

●產品說明書用語檢查清單
1）說明。 對問題的描述通常表現為粉飾沒有仔細考慮的功能----可歸結於前文所述的屬性.從產品說明書上找出這樣的用語，仔細審視它們在文中是怎樣使用的.產品說明書可能會為其掩飾和開脫，也可能含糊其詞----無論是哪一種情況都可視為軟件缺陷.
2）總是，每一種，所有，沒有，從不.如果看到此類絕對或肯定的，切實認定的敘述，軟件測試員就可以着手設計針鋒相對的案例.
3）當然，因此，明顯，顯然，必然.這些話意圖誘使接受假定情況.不要中了圈套.
4）某些，有時，常常，通常，慣常，經常，大多，幾乎.這些話太過模糊.“有時”發生作用的功能無法測試.
5）等等，諸如此類，依此類推.以這樣的詞結束的功能清單無法測試.功能清單要絕對或者解釋明確，以免讓人迷惑，不知如何推論.
6）良好，迅速，廉價，高效，小，穩定.這些是不確定的說法，不可測試.如果在產品說明書中出現，就必須進一步指明含義.
7）已處理，已拒絕，已忽略，已消除.這些廉潔可能會隱藏大量需要說明的功能.
8）如果...那么...（沒有否則）.找出有“如果...那么...”而缺少配套的“否則”結構的陳述.想一想“如果”沒有發生會怎樣.
相關的測試工具

·        OpenSTA

主要做性能測試的負荷及壓力測試，使用比較方便，可以編寫測試腳本，也可以先行自動生成測試腳本，而后對於應用測試腳本進行測試。

·        SAINT

網站安全性測試，能夠對於指定網站進行安全性測試，並可以提供安全問題的解決方案。

·        CSE HTML Validator

一個有用的對於HTML代碼進行合法性檢查的工具

·        Ab（Apache Bench）

Apache自帶的對於性能測試方面的工具，功能不是很多，但是非常實用。

·        Crash-me

Mysql自帶的測試數據庫性能的工具，能夠測試多種數據庫的性能

黑盒測試用例設計
黑盒測試（Black-box Testing，又稱為功能測試或數據驅動測試）是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。
采用黑盒技術設計測試用例的方法有：等價類划分、邊界值分析、錯誤推測、因果圖和綜合策略。
黑盒測試注重於測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執行程序所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他類型的錯誤。
黑盒測試試圖發現以下類型的錯誤：
1）功能錯誤或遺漏；
2）界面錯誤；
3）數據結構或外部數據庫訪問錯誤；
4）性能錯誤；
5）初始化和終止錯誤。
一、黑盒測試的測試用例設計方法
· 等價類划分方法
· 邊界值分析方法
· 錯誤推測方法
· 因果圖方法
· 判定表驅動分析方法
· 正交實驗設計方法
· 功能圖分析方法
等價類划分：
是把所有可能的輸入數據，即程序的輸入域划分成若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。該方法是一種重要的，常用的黑盒測試用例設計方法。
1） 划分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的。並合理地假定：測試某等價類的代表值就等於對這一類其它值的測試。因此，可以把全部輸入數據合理划分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據。取得較好的測試結果。等價類划分可有兩種不同的情況：有效等價類和無效等價類。
有效等價類：是指對於程序的規格說明來說是合理的，有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
無效等價類：與有效等價類的定義恰巧相反。
設計測試用例時，要同時考慮這兩種等價類。因為，軟件不僅要能接收合理的數據，也要能經受意外的考驗。這樣的測試才能確保軟件具有更高的可靠性。
2）划分等價類的方法：下面給出六條確定等價類的原則。
① 在輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。
② 在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類。
③ 在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。
④ 在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。
⑤ 在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。
⑥ 在確知已划分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步的划分為更小的等價類。
3）設計測試用例：在確立了等價類后，可建立等價類表，列出所有划分出的等價類：
輸入條件 有效等價類 無效等價類
然后從划分出的等價類中按以下三個原則設計測試用例：
① 為每一個等價類規定一個唯一的編號。
② 設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋地有效等價類，重復這一步。直到所有的有效等價類都被覆蓋為止。
③ 設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步。直到所有的無效等價類都被覆蓋為止。
邊界值分析法
邊界值分析方法是對等價類划分方法的補充。
（1）邊界值分析方法的考慮：
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應着重測試的邊界情況。應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。
（2）基於邊界值分析方法選擇測試用例的原則：
1）如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數據。
2）如果輸入條件規定了值的個數，則用最大個數，最小個數，比最小個數少一，比最大個數多一的數作為測試數據。
3）根據規格說明的每個輸出條件，使用前面的原則1）。
4）根據規格說明的每個輸出條件，應用前面的原則2）。
5）如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。
6）如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。
7）分析規格說明，找出其它可能的邊界條件。
錯誤推測法
錯誤推測法： 基於經驗和直覺推測程序中所有可能存在的各種錯誤， 從而有針對性的設計測試用例的方法。

錯誤推測方法的基本思想： 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。例如， 在單元測試時曾列出的許多在模塊中常見的錯誤。 以前產品測試中曾經發現的錯誤等， 這些就是經驗的總結。 還有， 輸入數據和輸出數據為0的情況。 輸入表格為空格或輸入表格只有一行。 這些都是容易發生錯誤的情況。 可選擇這些情況下的例子作為測試用例。

因果圖方法

前面介紹的等價類划分方法和邊界值分析方法，都是着重考慮輸入條件，但未考慮輸入條件之間的聯系， 相互組合等。考慮輸入條件之間的相互組合，可能會產生一些新的情況。 但要檢查輸入條件的組合不是一件容易的事情， 即使把所有輸入條件划分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種適合於描述對於多種條件的組合，相應產生多個動作的形式來考慮設計測試用例。 這就需要利用因果圖（邏輯模型）。

因果圖方法最終生成的就是判定表。 它適合於檢查程序輸入條件的各種組合情況。
利用因果圖生成測試用例的基本步驟：

（1） 分析軟件規格說明描述中， 那些是原因（即輸入條件或輸入條件的等價類），那些是結果（即輸出條件），並給每個原因和結果賦予一個標識符。

（2） 分析軟件規格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關系。 根據這些關系，畫出因果圖。

（3） 由於語法或環境限制， 有些原因與原因之間，原因與結果之間的組合情況不不可能出現。為表明這些特殊情況， 在因果圖上用一些記號表明約束或限制條件。

（4） 把因果圖轉換為判定表。
（5） 把判定表的每一列拿出來作為依據，設計測試用例。
從因果圖生成的測試用例（局部，組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增加而線性地增加。

前面因果圖方法中已經用到了判定表。判定表（DECisionTable）是分析和表達多邏輯條件下執行不同操作的情況下的工具。在程序設計發展的初期，判定表就已被當作編寫程序的輔助工具了。由於它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確。

判定表驅動分析方法 
判定表通常由四個部分組成。
條件樁（ConDItion STub）：列出了問題得所有條件。通常認為列出得條件的次序無關緊要。
動作樁（Action Stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。
條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。
動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
規則：任何一個條件組合的特定取值及其相應要執行的操作。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。
判定表的建立步驟：（根據軟件規格說明）

① 確定規則的個數。假如有n個條件。每個條件有兩個取值（0，1），故有種規則。

② 列出所有的條件樁和動作樁。
③ 填入條件項。
④ 填入動作項。等到初始判定表。
⑤ 簡化、合並相似規則（相同動作）。
B.Beizer 指出了適合使用判定表設計測試用例的條件：
① 規格說明以判定表形式給出，或很容易轉換成判定表。
② 條件的排列順序不會也不影響執行哪些操作。
③ 規則的排列順序不會也不影響執行哪些操作。
④ 每當某一規則的條件已經滿足，並確定要執行的操作后，不必檢驗別的規則。
⑤ 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。
黑盒測試的優點
1、基本上不用人管着，如果程序停止運行了一般就是被測試程序CRASh了
2、設計完測試例之后，下來的工作就是爽了，當然更苦悶的是確定crash原因
黑盒測試的缺點
1、結果取決於測試例的設計，測試例的設計部分來勢來源於經驗，OUSPG的東西很值得借鑒
2、沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來作
3、就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的tEStcase造成的問題。這些在堆的問題中表現的更為突出。
黑盒測試（功能測試）工具的選擇
那么，如何高效地完成功能測試？選擇一款合適的功能測試工具並培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不采用任何功能測試工具，從事功能測試外包項目的軟件服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟件服務企業取代。
目前，用於功能測試的工具軟件有很多，針對不同架構軟件的工具也不斷推陳出新。這里重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。
WinRunner是一種用於檢驗應用程序能否如期運行的企業級軟件功能測試工具。通過自動捕獲、檢測和模擬用戶交互操作，WinRunner能識別出絕大多數軟件功能缺陷，從而確保那些跨越了多個功能點和數據庫的應用程序在發布時盡量不出現功能性故障。

WinRunner的特點在於： 與傳統的手工測試相比，它能快速、批量地完成功能點測試；能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差； 此外，它還能重復執行相同動作，測試工作中最枯燥的部分可交由機器完成； 它支持程序風格的測試腳本，一個高素質的測試工程師能借助它完成流程極為復雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用；它針對於大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基於Windows平台的應用程序實施功能測試而言帶來了極大的便利。

WinRunner的工作流程大致可以分為以下六個步驟：
1．識別應用程序的GUI
在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別后，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式： Global GUI Map File和GUI Map File per Test。其最大區別是后者對每個測試腳本產生一個GUI文件，它能自動建立、存儲、加載，推薦初學者選用這種模式。但是，這種模式不易於描述對象的改變，其效率比較低，因此對於一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。
2．建立測試腳本
在建立測試腳本時，一般先進行錄制，然后在錄制形成的腳本中手工加入需要的TSL（與C語言類似的測試腳本語言）。錄制腳本有兩種模式： Context Sensitive和Analog，選擇依據主要在於是否對鼠標軌跡進行模擬，在需要回放時一般選用Analog。在錄制過程中這兩種模式可以通過F2鍵相互切換。
只要看看現代軟件的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點鼠標就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟件的能力驗證、能力規划、性能調優、缺陷修復等方面都發揮着重要作用。
3．對測試腳本除錯（debug）
在WinRunner中有專門一個Debug TOOlbar用於測試腳本除錯。可以使用step、pause、breakpoint等來控制和跟蹤測試腳本和查看各種變量值。
4．在新版應用程序執行測試腳本
當應用程序有新版本發布時，我們會對應用程序的各種功能包括新增功能進行測試，這時當然不可能再來重新錄制和編寫所有的測試腳本。我們可以使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工作。可以使用一個call命令來加載各測試腳本。還可在call命令中加各種TSL腳本來增加批量能力。
5．分析測試結果
分析測試結果在整個測試過程中最重要，通過分析可以發現應用程序的各種功能性缺陷。當運行完某個測試腳本后，會產生一個測試報告，從這個測試報告中我們能發現應用程序的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話框等。
6．回報缺陷（defect）
在分析完測試報告后，按照測試流程要回報應用程序的各種缺陷，然后將這些缺陷發給指定人，以便進行修改和維護。
常用的功能測試方法
功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下：
1、頁面鏈接檢查：每一個鏈接是否都有對應的頁面，並且頁面之間切換正確。
2、相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。

3、檢查按鈕的功能是否正確：如update， cancel，delete， SAve等功能是否正確。

4、字符串長度檢查： 輸入超出需求所說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯。

5、字符類型檢查： 在應該輸入指定類型的內容的地方輸入其他類型的內容（如在應該輸入整型的地方輸入其他字符類型），看系統是否檢查字符類型，會否報錯。
6、標點符號檢查： 輸入內容包括各種標點符號，特別是空格，各種引號，回車鍵。看系統處理是否正確。
7、中文字符處理： 在可以輸入中文的系統輸入中文，看會否出現亂碼或出錯。
8、檢查帶出信息的完整性： 在查看信息和update信息時，查看所填寫的信息是不是全部帶出。，帶出信息和添加的是否一致
9、信息重復： 在一些需要命名，且名字應該唯一的信息輸入重復的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前后輸入空格，系統是否作出正確處理。
10、檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按”delete”，看系統如何處理，會否出錯；然后選擇一個和多個信息，進行刪除，看是否正確處理。
11、檢查添加和修改是否一致： 檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定為整型的項，修改也必須為整型。
12、檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯。同時，也要注意，會不會報和自己重名的錯。
13、重復提交表單：一條已經成功提交的紀錄，back后再提交，看看系統是否做了處理。
14、檢查多次使用back鍵的情況： 在有back的地方，back，回到原來頁面，再back，重復多次，看會否出錯。

15、search檢查：在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確。如果可以輸入多個search條件，可以同時添加合理和不合理的條件，看系統處理是否正確。

16、輸入信息位置： 注意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方。
17、上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否能夠做到。
18、必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*
19、快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不允許輸入信息的字段，如選人，選日期對快捷方式是否也做了限制。
20、回車鍵檢查： 在輸入結束后直接按回車鍵，看系統處理如何，會否報錯。

Web測試中的界面測試用例設計
一、文本框、按鈕等控件測試
　　1、文本框的測試
　　如何對文本框進行測試：
　　a、輸入正常的字母或數字;
　　b、輸入已存在的文件的名稱;
　　c、輸入超長字符。例如在“名稱”框中輸入超過允許邊界個數的字符，假設最多255個字符，嘗試輸入256個字符，檢查程序能否正確處理;
　　d、輸入默認值，空白，空格;
　　e、若只允許輸入字母，嘗試輸入數字;反之，嘗試輸入字母;
　　f、利用復制，粘貼等操作強制輸入程序不允許的輸入數據;
　　g、輸入特殊字符集，例如，NUL及\n等;
　　h、輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示;
　　i、輸入不符合格式的數據，檢查程序是否正常校驗，如程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示。
　　在測試過程中所用到的測試方法：
　　a、輸入非法數據;
　　b、輸入默認值;
　　c、輸入特殊字符集;
　　d、輸入使緩沖區溢出的數據;
　　e、輸入相同的文件名;
　　2、命令按鈕控件的測試
　　測試方法：
　　a、點擊按鈕正確響應操作。如單擊確定，正確執行操作;單擊取消，退出窗口;
　　b、對非法的輸入或操作給出足夠的提示說明，如輸入月工作天數為32時，單擊“確定”后系統應提示：天數不能大於31;
　　c、對可能造成數據無法恢復的操作必須給出確認信息，給用戶放棄選擇的機會;
　　3、單選按鈕控件的測試
　　測試方法：
　　a、一組單選按鈕不能同時選中，只能選中一個;
　　b、逐一執行每個單選按鈕的功能。分別選擇了“男”、“女”后，保存到數據庫的數據應該相應的分別為“男”、“女”;
　　c、一組執行同一功能的單選按鈕在初始狀態時必須有一個被默認選中，不能同時為空。
　　4、up-down控件文本框的測試
　　測試方法：
　　a、直接輸入數字或用上下箭頭控制，如在“數目”中直接輸入10，或者單擊向上的箭頭，使數目變為10;
　　b、利用上下箭頭控制數字的自動循環，如當最多數字為253時，單擊向上箭頭，數目自動變為1;反之亦適用;
　　c、直接輸入超邊界值，系統應該提示重新輸入;
　　d、輸入默認值，空白。如“插入”數目為默認值，點擊“確定”;或刪除默認值，使內容為空，單擊“確定”進行測試;
　　e、輸入字符。此時系統應提示輸入有誤。
　　5、組合列表框的測試
　　測試方法：
　　a、條目內容正確，其詳細條目內容可以根據需求說明確定;
　　b、逐一執行列表框中每個條目的功能;
　　c、檢查能否向組合列表框輸入數據。
　　6、復選框的測試
　　測試方法：
　　a、多個復選框可以被同時選中;
　　b、多個復選框可以被部分選中;
　　c、多個復選框可以都不被選中;
　　d、逐一執行每個復選框的功能。
　　7、列表框控件的測試
　　測試方法：
　　a、條目內容正確：同組合列表框類似，根據需求說明書確定列表的各項內容正確，沒有丟失或錯誤;
　　b、列表框的內容較多時要使用滾動條;
　　c、列表框允許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的情況;
　　8、滾動條控件的測試
　　要注意一下幾點：
　　a、滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利於用戶了解顯示信息的位置和百分比，如word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處於中間;
　　b、拖動滾動條，檢查屏幕刷新情況，並查看是否有亂碼;
　　c、單擊滾動條;
　　d、用滾輪控制滾動條;
　　e、滾動條的上下按鈕。
　　9、各種控件在窗體中混和使用時的測試
　　a、控件間的相互作用;
　　b、tab鍵的順序，一般是從上到下，從左到右;
　　c、熱鍵的使用，逐一測試;
　　d、enter鍵和esc鍵的使用。
　　在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現無誤后，再進行多個控件的的功能組合的測試。
　　ps：密碼輸入框測試時要特別注意進行字母大寫輸入的測試。
二、查找替換操作
　　案例演示：打開word中的“替換”對話框。
　　測試本功能有通過測試和失敗測試兩種情況：
　　通過測試：
　　a、輸入內容直接查找、或查找全部;
　　b、在組合框中尋找已經查找過的內容、再次查找並確認文檔的內容正確，如已經查找過“測試用例”、再次進入不用重新輸入查找內容、直接在文檔中搜尋就可以。
　　失敗測試：
　　a、輸入過長或過短的查詢字符串。如假設查詢的字符串長度為1到255，那么，輸入0、1、2、256、255和254進行測試;
　　b、輸入特殊字符集。如在word中^g代表圖片、^代表分欄符、可以輸入這類特殊字符測試;替換測試大體相同。
　　關於編輯操作窗口的功能測試的用例：
　　a、關閉查找替換窗口。不執行任何操作、直接退出;
　　b、附件和選項測試。假如設定“精確搜尋”、“向后”搜索等附件選項等等來測試;
　　c、控件間的相互作用。如搜尋內容為空時、按鈕“搜尋全部”、“搜尋”、“全部替換”、“替換”都為灰色。
　　d、熱鍵、Tab鍵。回車鍵的使用。
　　插入操作
　　1、插入文件
　　測試的情況：
　　a、插入文件;
　　b、插入圖像;
　　c、在文檔中插入文檔本身;
　　d、移除插入的源文件;
　　e、更換插入的源文件的內容。
　　2、鏈接文件
　　測試方法：
　　a、插入鏈接文件;
　　b、在文檔中鏈接文檔本身;
　　c、移除插入的源文件：
　　d、更換插入的源文件的內容。
　　3、插入對象
　　要測試的內容：
　　a、插入程序允許的對象、如在word中插入excel工作表;
　　b、修改所插入對象的內容。插入的對象仍能正確顯示;
　　c、卸載生成插入對象的程序、如在word中插入excel工作表后卸載excel、工作表仍正常使用。
　　編輯操作
　　編輯操作包括剪切、復制、粘貼操作。
　　測試剪切操作的方法
　　a、對文本、文本框、圖文框進行剪切;
　　b、剪切圖像;
　　c、文本圖像混合剪切。
　　復制操作方法與剪切類似。
　　測試時，主要是對粘貼操作的測試方法是：
　　a、粘貼剪切的文本、文本框及圖文框;
　　b、粘貼所剪切的圖像;
　　c、剪切后，在不同的程序中粘貼;
　　d、多次粘貼同一內容，如剪切后，在程序中連續粘貼3次;
　　e、利用粘貼操作強制輸入程序所不允許輸入的數據。
三、界面測試用例的設計方法
　　1、窗體
　　測試窗體的方法：
　　a、窗體大小，大小要合適，控件布局合理;
　　b、移動窗體。快速或慢速移動窗體，背景及窗體本身刷新必須正確;
　　c、縮放窗體，窗體上的控件應隨窗體的大小變化而變化;
　　d、顯示分辨率。必須在不同的分辨率的情況下測試程序的顯示是否正常。
　　進行測試時還要注意狀態欄是否顯示正確，工具欄的圖標執行操作是否有效，是否與菜單懶中圖標顯示一致;錯誤信息內容是否正確、無錯別字且明確等等。
　　2、控件
　　測試方法：
　　a、窗體或控件的字體和大小要一致;
　　b、注意全角、半角混合;
　　c、無中英文混合。
　　四、菜單
　　進行測試時要注意：
　　a、選擇菜單是否可以正常工作、並與實際執行內容一致;
　　b、是否有錯別字;
　　c、快捷鍵是否重復;
　　d、熱鍵是否重復;
　　e、快捷鍵與熱鍵操作是否有效;
　　f、是否存在中英文混合;
　　g、菜單要與語境相關、如、不同權限的用戶登陸一個應用程序、不同級別的用戶可以看到不同級別的菜單並使用不同級別的功能;
　　h、鼠標右鍵快捷菜單。
　　特殊屬性
　　a、安裝界面應有公司介紹或產品介紹、有公司的圖標;
　　b、主界面及大多數界面最好有公司圖標;
　　c、選擇“幫助”->“關於”命令、應看見相關版權和產品信息。

代替測試用例的檢查表
2004年底在大連出差的時候，幫一個項目做測試，順便寫下這個檢查表，這個檢查表對測試的初學者積累經驗比較有用，實際對於有經驗的測試人員尤其對於測試業務管理信息系統，基本上大量的測試不需要再編寫測試用例，當然對業務流程、復雜邏輯還是要設計詳細的測試用例的。如果你測試的系統是有大量人機交互的業務管理信息系統，而且你又比較懶惰，那就可以使用這個檢查表檢查了。
因此我總結了這類系統中常用的測試的檢查項，供當時項目組的測試人員使用，現在再次整理出來發於博客。
1 針對測試組長或測試經理
1.1測試管理工作檢查表：
1. 檢查每輪測試開始時測試環境是否准備好（包括軟件硬件、測試基本數據等）；
2. 確保測試環境（數據和程序）與開發分離，除了測試組之外其他人不能更新測試環境的數據和程序；
3. 每輪測試根據上一輪的情況和總體測試計划做分工調整；
4. 檢查case庫的填報情況，抽查執行過的case；
5. 檢查BUG提交情況，抽查提交的BUG是否規范；
6. 每天晚上統計BUG情況，填寫每天的BUG報告；
7. 根據每天的測試情況，決定是否開發組要發布新的BUILD；
8. 每輪測試結束后填寫測試總結。
2  下面是針對測試執行人員的：
2.1輸入、編輯功能的驗證檢查點：
1. 必輸項是否有紅星標記，如果不輸入提示是否跟相應的Label對應，提示的順序是否跟Form輸入域的排列次序一致；
2. 輸入的特殊字符是否能正確處理：`~!@#$%^&*()_+-={}[]|\:;”’<>,./?；