web經常使用模塊測試用例

一些經常使用模塊的測試用例 1、登陸　　二、添加　　三、查詢　　四、刪除 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、黑盒測試的測試用例設計方法 · 等價類劃分方法 · 邊界值分析方法 · 錯誤推測方法 · 因果圖方法 · 斷定表驅動分析方法 · 正交實驗設計方法 · 功能圖分析方法 等價類劃分： 是把全部可能的輸入數據，即程序的輸入域劃分紅若干部分（子集），而後從每個子集中選取少數具備表明性的數據做爲測試用例。該方法是一種重要的，經常使用的黑盒測試用例設計方法。 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 指出了適合使用斷定表設計測試用例的條件： ① 規格說明以斷定表形式給出，或很容易轉換成斷定表。 ② 條件的排列順序不會也不影響執行哪些操做。 ③ 規則的排列順序不會也不影響執行哪些操做。 ④ 每當某一規則的條件已經知足，並肯定要執行的操做後，沒必要檢驗別的規則。 ⑤ 若是某一規則獲得知足要執行多個操做，這些操做的執行順序可有可無。 黑盒測試的優勢 一、基本上不用人管着，若是程序中止運行了通常就是被測試程序CRASh了 二、設計完測試例以後，下來的工做就是爽了，固然更苦悶的是肯定crash緣由 黑盒測試的缺點 一、結果取決於測試例的設計，測試例的設計部分來勢來源於經驗，OUSPG的東西很值得借鑑 二、沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來作的，還作不到針對被測試程序的狀態轉換來做 三、就沒有狀態概念的測試來講，尋找和肯定形成程序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） 在分析完測試報告後，按照測試流程要回報應用程序的各類缺陷，而後將這些缺陷發給指定人，以便進行修改和維護。 經常使用的功能測試方法 功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。經常使用的測試方法以下： 一、頁面連接檢查：每個連接是否都有對應的頁面，而且頁面之間切換正確。 二、相關性檢查：刪除/增長一項會不會對其餘項產生影響，若是產生影響，這些影響是否都正確。 三、檢查按鈕的功能是否正確：如update， cancel，delete， SAve等功能是否正確。 四、字符串長度檢查： 輸入超出需求所說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯。 五、字符類型檢查： 在應該輸入指定類型的內容的地方輸入其餘類型的內容（如在應該輸入整型的地方輸入其餘字符類型），看系統是否檢查字符類型，會否報錯。 六、標點符號檢查： 輸入內容包括各類標點符號，特別是空格，各類引號，回車鍵。看系統處理是否正確。 七、中文字符處理： 在能夠輸入中文的系統輸入中文，看會否出現亂碼或出錯。 八、檢查帶出信息的完整性： 在查看信息和update信息時，查看所填寫的信息是否是所有帶出。，帶出信息和添加的是否一致 九、信息重複： 在一些須要命名，且名字應該惟一的信息輸入重複的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的先後輸入空格，系統是否做出正確處理。 十、檢查刪除功能：在一些能夠一次刪除多個信息的地方，不選擇任何信息，按」delete」，看系統如何處理，會否出錯；而後選擇一個和多個信息，進行刪除，看是否正確處理。 十一、檢查添加和修改是否一致： 檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定爲整型的項，修改也必須爲整型。 十二、檢查修改重名：修改時把不能重名的項改成已存在的內容，看會否處理，報錯。同時，也要注意，會不會報和本身重名的錯。 1三、重複提交表單：一條已經成功提交的紀錄，back後再提交，看看系統是否作了處理。 1四、檢查屢次使用back鍵的狀況： 在有back的地方，back，回到原來頁面，再back，重複屢次，看會否出錯。 1五、search檢查：在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確。若是能夠輸入多個search條件，能夠同時添加合理和不合理的條件，看系統處理是否正確。 1六、輸入信息位置： 注意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方。 1七、上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否可以作到。 1八、必填項檢查：應該填寫的項沒有填寫時系統是否都作了處理，對必填項是否有提示信息，如在必填項前加* 1九、快捷鍵檢查：是否支持經常使用快捷鍵，如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、輸入相同的文件名; 　　二、命令按鈕控件的測試 　　測試方法： 　　a、點擊按鈕正確響應操做。如單擊肯定，正確執行操做;單擊取消，退出窗口; 　　b、對非法的輸入或操做給出足夠的提示說明，如輸入月工做天數爲32時，單擊「肯定」後系統應提示：天數不能大於31; 　　c、對可能形成數據沒法恢復的操做必須給出確認信息，給用戶放棄選擇的機會; 　　三、單選按鈕控件的測試 　　測試方法： 　　a、一組單選按鈕不能同時選中，只能選中一個; 　　b、逐一執行每一個單選按鈕的功能。分別選擇了「男」、「女」後，保存到數據庫的數據應該相應的分別爲「男」、「女」; 　　c、一組執行同一功能的單選按鈕在初始狀態時必須有一個被默認選中，不能同時爲空。 　　四、up-down控件文本框的測試 　　測試方法： 　　a、直接輸入數字或用上下箭頭控制，如在「數目」中直接輸入10，或者單擊向上的箭頭，使數目變爲10; 　　b、利用上下箭頭控制數字的自動循環，如當最多數字爲253時，單擊向上箭頭，數目自動變爲1;反之亦適用; 　　c、直接輸入超邊界值，系統應該提示從新輸入; 　　d、輸入默認值，空白。如「插入」數目爲默認值，點擊「肯定」;或刪除默認值，使內容爲空，單擊「肯定」進行測試; 　　e、輸入字符。此時系統應提示輸入有誤。 　　五、組合列表框的測試 　　測試方法： 　　a、條目內容正確，其詳細條目內容能夠根據需求說明肯定; 　　b、逐一執行列表框中每一個條目的功能; 　　c、檢查可否向組合列表框輸入數據。 　　六、複選框的測試 　　測試方法： 　　a、多個複選框能夠被同時選中; 　　b、多個複選框能夠被部分選中; 　　c、多個複選框能夠都不被選中; 　　d、逐一執行每一個複選框的功能。 　　七、列表框控件的測試 　　測試方法： 　　a、條目內容正確：同組合列表框相似，根據需求說明書肯定列表的各項內容正確，沒有丟失或錯誤; 　　b、列表框的內容較多時要使用滾動條; 　　c、列表框容許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的狀況; 　　八、滾動條控件的測試 　　要注意一下幾點： 　　a、滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利於用戶瞭解顯示信息的位置和百分比，如word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處於中間; 　　b、拖動滾動條，檢查屏幕刷新狀況，並查看是否有亂碼; 　　c、單擊滾動條; 　　d、用滾輪控制滾動條; 　　e、滾動條的上下按鈕。 　　九、各類控件在窗體中混和使用時的測試 　　a、控件間的相互做用; 　　b、tab鍵的順序，通常是從上到下，從左到右; 　　c、熱鍵的使用，逐一測試; 　　d、enter鍵和esc鍵的使用。 　　在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現無誤後，再進行多個控件的的功能組合的測試。 　　ps：密碼輸入框測試時要特別注意進行字母大寫輸入的測試。 2、查找替換操做 　　案例演示：打開word中的「替換」對話框。 　　測試本功能有經過測試和失敗測試兩種狀況： 　　經過測試： 　　a、輸入內容直接查找、或查找所有; 　　b、在組合框中尋找已經查找過的內容、再次查找並確認文檔的內容正確，如已經查找過「測試用例」、再次進入不用從新輸入查找內容、直接在文檔中搜尋就能夠。 　　失敗測試： 　　a、輸入過長或太短的查詢字符串。如假設查詢的字符串長度爲1到255，那麼，輸入0、一、二、25六、255和254進行測試; 　　b、輸入特殊字符集。如在word中^g表明圖片、^表明分欄符、能夠輸入這類特殊字符測試;替換測試大致相同。 　　關於編輯操做窗口的功能測試的用例： 　　a、關閉查找替換窗口。不執行任何操做、直接退出; 　　b、附件和選項測試。假如設定「精確搜尋」、「向後」搜索等附件選項等等來測試; 　　c、控件間的相互做用。如搜尋內容爲空時、按鈕「搜尋所有」、「搜尋」、「所有替換」、「替換」都爲灰色。 　　d、熱鍵、Tab鍵。回車鍵的使用。 　　插入操做 　　一、插入文件 　　測試的狀況： 　　a、插入文件; 　　b、插入圖像; 　　c、在文檔中插入文檔自己; 　　d、移除插入的源文件; 　　e、更換插入的源文件的內容。 　　二、連接文件 　　測試方法： 　　a、插入連接文件; 　　b、在文檔中連接文檔自己; 　　c、移除插入的源文件： 　　d、更換插入的源文件的內容。 　　三、插入對象 　　要測試的內容： 　　a、插入程序容許的對象、如在word中插入excel工做表; 　　b、修改所插入對象的內容。插入的對象仍能正確顯示; 　　c、卸載生成插入對象的程序、如在word中插入excel工做表後卸載excel、工做表仍正常使用。 　　編輯操做 　　編輯操做包括剪切、複製、粘貼操做。 　　測試剪切操做的方法 　　a、對文本、文本框、圖文框進行剪切; 　　b、剪切圖像; 　　c、文本圖像混合剪切。 　　複製操做方法與剪切相似。 　　測試時，主要是對粘貼操做的測試方法是： 　　a、粘貼剪切的文本、文本框及圖文框; 　　b、粘貼所剪切的圖像; 　　c、剪切後，在不一樣的程序中粘貼; 　　d、屢次粘貼同一內容，如剪切後，在程序中連續粘貼3次; 　　e、利用粘貼操做強制輸入程序所不容許輸入的數據。 3、界面測試用例的設計方法 　　一、窗體 　　測試窗體的方法： 　　a、窗體大小，大小要合適，控件佈局合理; 　　b、移動窗體。快速或慢速移動窗體，背景及窗體自己刷新必須正確; 　　c、縮放窗體，窗體上的控件應隨窗體的大小變化而變化; 　　d、顯示分辨率。必須在不一樣的分辨率的狀況下測試程序的顯示是否正常。 　　進行測試時還要注意狀態欄是否顯示正確，工具欄的圖標執行操做是否有效，是否與菜單懶中圖標顯示一致;錯誤信息內容是否正確、無錯別字且明確等等。 　　二、控件 　　測試方法： 　　a、窗體或控件的字體和大小要一致; 　　b、注意全角、半角混合; 　　c、無中英文混合。 　　4、菜單 　　進行測試時要注意： 　　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. 輸入的特殊字符是否能正確處理：`~!@#$%^&*()_+-={}[]|\:;」’<>,./?；