1. 概述
   隨著web應(yīng)用的增多，新的模式解決方案中以web為核心的應(yīng)用也越來越多， 很多公司各種應(yīng)用的架構(gòu)都以B/S及web應(yīng)用為主，但是有關(guān)WEB測試方面的內(nèi)容并沒有相應(yīng)的總結(jié)，所以我在這里對web的測試方法和采用的測試技術(shù)進(jìn)行總結(jié)，便于內(nèi)部交流。
   測試方法盡量涵蓋web程序的各個方面，測試技術(shù)方面在繼承傳統(tǒng)測試技術(shù)的技術(shù)上結(jié)合web應(yīng)用的特點(diǎn)。
   相關(guān)的測試和實(shí)現(xiàn)技術(shù)也有著很大的關(guān)系，由于本公司使用J2EE體系，也許例子中只有JAVA平臺可以使用，.NET平臺測試技術(shù)暫時不涉及，如果你有請與我聯(lián)系。
2. 測試方法
說明：測試方法的選擇取決你的測試策略。
   一般的web測試和以往的應(yīng)用程序的測試的側(cè)重點(diǎn)不完全相同，基本包括以下幾個方面。
   當(dāng)然圓滿的完成測試還要有好的團(tuán)體和流程等的方方面面的支持，你同樣應(yīng)該對這些方面進(jìn)行注意。
   有些測試方法設(shè)計到了流程，哪些應(yīng)該在你的測試團(tuán)隊建設(shè)中建立。

2.1 界面測試
   現(xiàn)在一般人都有使用瀏覽器瀏覽網(wǎng)頁的經(jīng)歷，用戶雖然不是專業(yè)人員但是對界面效果的印象是很重要的。如果你注重這方面的測試，那么驗證應(yīng)用程序是否易于使用就非常重要了。很多人認(rèn)為這是測試中最不重要的部分，但是恰恰相反界面對不懂技術(shù)的客戶來說那相當(dāng)關(guān)鍵，慢慢體會你會明白的。
   方法上可以根據(jù)設(shè)計文檔，如果夠?qū)I(yè)的話可以專業(yè)美工人員，來確定整體風(fēng)格頁面風(fēng)格，然后根據(jù)這個可以頁面人員可以生成靜態(tài)的HTML，CSS等甚至生成幾套不用的方案來討論，或者交給客戶評審，最后形成統(tǒng)一的風(fēng)格的頁面/框架。注意不要靠程序員的美術(shù)素養(yǎng)形成你的web風(fēng)格，那樣可能會很糟糕。
主要包括以下幾個方面的內(nèi)容：
站點(diǎn)地圖和導(dǎo)航條 位置、是否合理、是否可以導(dǎo)航等內(nèi)容布局 布局是否合理，滾動條等簡介說明 說明文字是否合理，位置，是否正確
背景/色調(diào) 是否正確、美觀，是否符合用戶需求；
頁面在窗口中的顯示是否正確、美觀（在調(diào)整瀏覽器窗口大小時，屏幕刷新是否正確）表單樣式 大小，格式，是否對提交數(shù)據(jù)進(jìn)行驗證（如果在頁面部分進(jìn)行驗證的話）等
連接 連接的形式，位置，是否易于理解等
   web測試的主要頁面元素
頁面元素的容錯性列表（如輸入框、時間列表或日歷）
頁面元素清單（為實(shí)現(xiàn)功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、復(fù)選框、列表框、超連接、輸入框等等）
頁面元素的容錯性是否存在
頁面元素的容錯性是否正確
頁面元素基本功能是否實(shí)現(xiàn)（如文字特效、動畫特效、按鈕、超連接）
頁面元素的外形、擺放位置（如按鈕、列表框、核選框、輸入框、超連接等）
頁面元素是否顯示正確（主要針對文字、圖形、簽章）
元素是否顯示（元素是否存在）
頁面元素清單（為實(shí)現(xiàn)功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、復(fù)選框、列表框、超連接、輸入框等等）
   測試技術(shù)
     通過頁面走查，瀏覽確定使用的頁面是否符合需求?？梢越Y(jié)合兼容性測試對不用分辨率下頁面顯示效果，如果有影響應(yīng)該交給設(shè)計人員提出解決方案。 
    可以結(jié)合數(shù)據(jù)定義文檔查看表單項的內(nèi)容，長度等信息。
    對于動態(tài)生成的頁面最好也能進(jìn)行瀏覽查看。如Servelet部分可以結(jié)合編碼規(guī)范，進(jìn)行代碼走查。是否支持中文，如果數(shù)據(jù)用XM  封裝要做的工作會多一點(diǎn)等等。

   界面測試要素:
符合標(biāo)準(zhǔn)和規(guī)范,靈活性,正確性,直觀性,舒適性,實(shí)用性,一致性
   1.直觀性:
   用戶界面是否潔凈,不唐突,不擁擠.界面不應(yīng)該為用戶制造障礙.所需功能或者期待的響應(yīng)應(yīng)該明顯,并在預(yù)期出現(xiàn)的地方.
   界面組織和布局合理嗎  是否允許用戶輕松地從一個功能轉(zhuǎn)到另一個功能  下一步做什么明顯嗎  任何時刻都可以決定放棄或者退回,退出嗎  輸入得到承認(rèn)了嗎  菜單或者窗口是否深藏不露   
   有多余功能嗎  軟件整體抑或局部是否做得太多  是否有太多特性把工作復(fù)雜化了  是否感到信息太龐雜   
   如果其他所有努力失敗,幫助系統(tǒng)真能幫忙嗎   

   2.一致性
   快速鍵和菜單選項.在Windows 中按F1鍵總是得到幫助信息
   術(shù)語和命令.整個軟件使用同樣的術(shù)語嗎  特性命名一致嗎  例如,Find是否一直叫Find,而不是有時叫Search   
   軟件是否一直面向同一級別用戶  帶有花哨用戶界面的趣味賀卡程序不應(yīng)該顯示泄露技術(shù)機(jī)密的錯誤提示信息.
   按鈕位置和等價的按鍵.大家是否注意到對話框有OK按鈕和Canc  e按鈕時,OK按鈕總是在上方或者左方,而Canc  e按鈕總是在下方或右方  同樣原因,Canc  e按鈕的等價按鍵通常是Esc,而選中按鈕的等價按鈕通常是Enter.保持一致.

   3.靈活性
   狀態(tài)跳轉(zhuǎn).靈活的軟件實(shí)現(xiàn)同一任務(wù)有多種選擇方式.
   狀態(tài)終止和跳過,具有容錯處理能力.
   數(shù)據(jù)輸入和輸出.用戶希望有多種方法輸入數(shù)據(jù)和查看結(jié)果.例如,在寫字板插入文字可用鍵盤輸入,粘貼,從6種文件格式讀入,作為對象插入,或者用鼠標(biāo)從其他程序拖動.
   4.舒適性
   恰當(dāng).軟件外觀和感覺應(yīng)該與所做的工作和使用者相符.
   錯誤處理.程序應(yīng)該在用戶執(zhí)行嚴(yán)重錯誤的操作之前提出警告,并允許用戶恢復(fù)由于錯誤操作導(dǎo)致丟失的數(shù)據(jù).如大家認(rèn)為undo /redo是當(dāng)然的.
   性能.快不見得是好事.要讓用戶看得清程序在做什么,它是有反應(yīng)的.

2.2 功能測試
   對功能測試是測試中的重點(diǎn)
主要包括一下幾個方面的內(nèi)容
   連接這個連接和界面測試中的連接不同那里注重的是連接方式和位置，如是圖像還是文字放置的位置等，還是其他的方式。這里的連接注重功能。如是否有連接，連接的是否是說明的位置等。
   表單提交應(yīng)當(dāng)模擬用戶提交，驗證是否完成功能，如注冊信息，要測試這些程序，需要驗證服務(wù)器能正確保存這些數(shù)據(jù)，而且后臺運(yùn)行的程序能正確解釋和使用這些信息。還有數(shù)據(jù)正確性驗證，異常處理等，最好結(jié)合易用性要求等。B/S結(jié)構(gòu)實(shí)現(xiàn)的功能可能主要的就在這里，提交數(shù)據(jù)，處理數(shù)據(jù)等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復(fù)使用的腳本代碼，可以在測試、回歸測試時運(yùn)行以便減輕測試人員工作量。
   Cookies 驗證 如果系統(tǒng)使用了cookie，測試人員需要對它們進(jìn)行檢測。如果在 cookies 中保存了注冊信息，請確認(rèn)該 cookie能夠正常工作而且已對這些信息已經(jīng)加密。如果使用 cookie 來統(tǒng)計次數(shù)，需要驗證次數(shù)累計正確。關(guān)于cookie的使用可以參考瀏覽器的幫助信息。如果使用B/S結(jié)構(gòu)cookies中存放的信息更多。功能易用性測試 完成了功能測試可以對應(yīng)用性進(jìn)行了解，最好聽聽客戶的反映，在可以的情況下對程序進(jìn)行改進(jìn)是很有必要的，和客戶保持互動對系統(tǒng)滿意度也是很有幫助的。
   測試技術(shù)功能測試的測試技術(shù)可是很多的，我們可以結(jié)合實(shí)際環(huán)境選擇使用
   白盒測試技術(shù)(White Box Testing) 深入到代碼一級的測試，使用這種技術(shù)發(fā)現(xiàn)問題最早，效果也是最好的。該技術(shù)主要的特征是測試對象進(jìn)入了代碼內(nèi)部,根據(jù)開發(fā)人員對代碼和對程序的熟悉程度,對有需要的部分進(jìn)行在軟件編碼階段，開發(fā)人員根據(jù)自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主，在JAVA平臺使用Xunit系列工具進(jìn)行測試，Xunit測試工具是類一級的測試工具對每一個類和該類的方法進(jìn)行測試。
   黑盒測試技術(shù)（Black Box Testing）黑盒測試的內(nèi)容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結(jié)合兼容，性能測試等方面進(jìn)行，根據(jù)軟件需求，設(shè)計文檔，模擬客戶場景隨系統(tǒng)進(jìn)行實(shí)際的測試，這種測試技術(shù)是使用最多的測試技術(shù)涵蓋了測試的方方面面，可以考慮以下方面
     正確性 (Correctness)：計算結(jié)果，命名等方面
     可用性 (Usability)：是否可以滿足軟件的需求說明。
     邊界條件 (Boundary Condition)輸入部分的邊界值,就是使用一般書中說的等價類劃分,試試最大最小和非法數(shù)據(jù)等等.
     性能 (Performance) 正常使用的時間內(nèi)系統(tǒng)完成一個任務(wù)需要的時間,多人同時使用的時候響應(yīng)時間,在可以接受范圍內(nèi).J2EE技術(shù)實(shí)現(xiàn)的系統(tǒng)在性能方面更是需要照顧的,一般原則是3秒以下接受,3-5秒可以接受,5秒以上就影響易用性了. 如果在測試過程中發(fā)現(xiàn)性能問題，修復(fù)起來是非常艱難的，因為這常常意味著
程序的算法不好，結(jié)構(gòu)不好，或者設(shè)計有問題。因此在產(chǎn)品開發(fā)的開始階段，就要考慮到軟件的性能問題
     壓力測試 (Stress) 多用戶情況 可以考慮使用壓力測試工具,建議將壓力和性能測試結(jié)合起來進(jìn)行.如果有負(fù)載平衡的話還要在服務(wù)器端打開監(jiān)測工具,查看服務(wù)器CPU使用率,內(nèi)存占用情況,如果有必要可以模擬大量數(shù)據(jù)輸入,對硬盤的影響等等信息.如果有必要的話必須進(jìn)行性能優(yōu)化(軟硬件都可以).這里的壓力測試針對的是某幾項功能,.
     錯誤恢復(fù) (Error Recovery) 錯誤處理，頁面數(shù)據(jù)驗證,包括突然間斷電,輸入臟數(shù)據(jù)等.
安全性測試(Security)這個領(lǐng)域正在研究中,不過防火墻,補(bǔ)丁包.殺毒軟件等的就不必說了,不過可以考慮破壞性測試時任意.看了一些資料后得知,這里面設(shè)計到的知識\內(nèi)容可以寫本書了,不是一兩句可以說清的,特別是一些商務(wù)網(wǎng)站,或者跟錢有關(guān),或者和公司秘密有關(guān)的web更是,需要這方面的測試,在外國有一種專門干這一行的人叫安全顧問,可以審核代碼,提出安全建議,出現(xiàn)緊急事件是的處理辦法等,在國內(nèi)沒有聽說哪里有專門搞安全技術(shù)測試的內(nèi)容.
     兼容性 (Compatibility) 不同瀏覽器，不同應(yīng)用程序版本在實(shí)現(xiàn)功能時的表現(xiàn),不同的上網(wǎng)方式,如果你測試的是一個公共網(wǎng)站的話.
   兼容性測試內(nèi)容詳述
   硬件平臺
   瀏覽器軟件和版本:瀏覽器插件,瀏覽器選項,視頻分辨率和色深.文字大小,調(diào)制解調(diào)器速率.
     軟件配置 (Configuration) 如IE瀏覽器的不用選項-安全設(shè)定最高,禁用腳本程序,等等,你們的程序在各種不用的設(shè)置下表現(xiàn)如何.

單元測試技術(shù)(Unit Test):
2.2.1 下面是對白盒測試和單元測試的區(qū)別的論述:
   單元測試和白盒測試是不同的,雖然單元測試和白盒測試都是關(guān)注功能雖然他們都需要代碼支持,但是級別不同,白盒測試關(guān)注的是類中一個方法的功能是更小的單位,但是完成一個單元測試可能需要N多類,所以說作單元測試需要什么寫驅(qū)動和穩(wěn)定樁,比如查詢單元是一個查詢包包N多的測試類,測試數(shù)據(jù),運(yùn)行他需要提供數(shù)據(jù)的部分,輸入?yún)?shù)和發(fā)出命令的驅(qū)動等等.是比類大的一個整體進(jìn)行的.
   另一個明顯的區(qū)別是白盒測試不會關(guān)注類接口,但是單元測試主要的內(nèi)容就是類接口測試.
   不過很多時候是很少區(qū)分的,因為這兩種技術(shù)實(shí)現(xiàn)起來有很多相互關(guān)聯(lián)的部分.不過要看你對質(zhì)量的關(guān)注程度來決定.
2.2.2 功能測試邊界測試\越界測試技術(shù)詳述
   邊界條件
邊界條件是指軟件計劃的操作界限所在的邊緣條件.
如果軟件測試問題包含確定的邊界,那么數(shù)據(jù)類型可能是:
數(shù)值 速度 字符 地址 位置 尺寸 數(shù)量
同時,考慮這些類型的下述特征:
第一個/最后一個 最小值/最大值
開始/完成 超過/在內(nèi)
空/滿 最短/最長
最慢/最快 最早/最遲
最大/最小 最高/最低
相鄰/最遠(yuǎn)
   越界測試
通常是簡單加1或者很小的數(shù)(對于最大值)和減少1或者很小的數(shù)(對于最小值),例如:
第一個減1/最后一個加1
開始減1/完成加1
空了再減/滿了再加
慢上加慢/快上加快
最大數(shù)加1/最小數(shù)減1
最小值減1/最大值加1
剛好超過/剛好在內(nèi)
短了再短/長了再長
早了更早/晚了更晚
最高加1/最低減1
   另一些該注意的輸入:默認(rèn),空白,空值,零值和無;非法,錯誤,不正確和垃圾數(shù)據(jù).
2.2.3 狀態(tài)測試技術(shù)

   軟件可能進(jìn)入的每一種獨(dú)立狀態(tài);
   從一種狀態(tài)轉(zhuǎn)入另一種狀態(tài)所需的輸入和條件;
   進(jìn)入或退出某種狀態(tài)時的設(shè)置條件及輸入結(jié)果.

   具體測試方法可以參考如下:
   每種狀態(tài)至少訪問一次;
   測試看起來最常見最普遍的狀態(tài)轉(zhuǎn)換;
   測試狀態(tài)之間最不常用的分支
   測試所有錯誤狀態(tài)及其返回值
   測試隨機(jī)狀態(tài)轉(zhuǎn)換
2.2.4 競爭條件測試技術(shù)
   競爭條件典型情形參考如下:
   兩個不同的程序同時保存或打開同一個文檔
   共享同一臺打印機(jī),通信端口或者其他外圍設(shè)備
   當(dāng)軟件處于讀取或者修改狀態(tài)時按鍵或者單擊鼠標(biāo)
   同時關(guān)閉或者啟動軟件的多個實(shí)例
   同時使用不同的程序訪問一個共同數(shù)據(jù)庫

2.3 負(fù)載\壓力測試(StressTest)
   在這里的負(fù)載\壓力和功能測試中的不同,他是系統(tǒng)測試的內(nèi)容,是基本功能已經(jīng)通過后進(jìn)行的.可以在集成測試階段,亦可以在系統(tǒng)測試階段進(jìn)行.
   使用負(fù)載測試工具進(jìn)行,虛擬一定數(shù)量的用戶看一看系統(tǒng)的表現(xiàn),是否滿足定義中的指標(biāo).
   負(fù)載測試一般使用工具完成，  oadrunner，web  oad，was，ew  ，e-test等，主要的內(nèi)容都是編寫出測試腳本，腳本中一般包括用戶一般常用的功能，然后運(yùn)行，得出報告。所以負(fù)載測試包括的主要內(nèi)容就不介紹了。
   負(fù)載測試技術(shù)在各種極限情況下對產(chǎn)品進(jìn)行測試 (如很多人同時使用該軟件，或者反復(fù)運(yùn)行該軟件)，以檢查產(chǎn)品的長期穩(wěn)定性。例如，使用壓力測試工具對web服務(wù)器進(jìn)行壓力測試. 本項測試可以幫助找到一些大型的問題，如死機(jī)、崩損、內(nèi)存泄漏等，因為有些存在內(nèi)存泄漏問題的程序，在運(yùn)行一兩次時可能不會出現(xiàn)問題，但是如果運(yùn)行了成千上萬次，內(nèi)存泄漏得越來越多，就會導(dǎo)致系統(tǒng)崩滑。用J2EE實(shí)現(xiàn)的系統(tǒng)很少但是并不是沒有內(nèi)存問題.
   無論什么工具基本的技術(shù)都是利用線程技術(shù)模仿和虛擬用戶，在這里主要的難點(diǎn)在與測試腳本的編寫，每種工具使用的腳本都不一樣，但是大多數(shù)工具都提供錄制功能就算是不會編碼的測試人員同樣可以測試。
   對負(fù)載工具的延伸使用可以進(jìn)行系統(tǒng)穩(wěn)定性測試，系統(tǒng)極限測試，如使用100的  oad Size連續(xù)使用24小時，微軟定義的通過準(zhǔn)則是通過72小時測試的程序一般不會出現(xiàn)穩(wěn)定性的問題。

2.4 回歸測試 (Regression Test)
   過一段時間以后，再回過頭來對以前修復(fù)過的Bug重新進(jìn)行測試，看該Bug 是否會重新出現(xiàn)。
   回歸測試技術(shù)可以在測試的各個階段出現(xiàn)，無論是單元測試還是集成測試還是系統(tǒng)測試。是對以前問題進(jìn)行驗證的過程。
   回歸測試的目的就是保證以前已經(jīng)修復(fù)的Bug不會再出現(xiàn)。實(shí)際上，許多Bug都是在回歸測試時發(fā)現(xiàn)的，在此階段，我們首先要檢查以前找到的Bug 是否已經(jīng)更正了。值得注意的是，已經(jīng)更正的Bug 也可能又回來了，有的Bug 經(jīng)過修改之后可能又產(chǎn)生了新的Bug。所以，回歸測試可保證已更正的Bug不再重現(xiàn)，不產(chǎn)生新的Bug。
2.5 A  pha 和Beta 測試 (A  pha and Beta Test):
   在正式發(fā)布產(chǎn)品之前往往要先發(fā)布一些測試版，讓用戶能夠反饋出相關(guān)信息，或者找到存在的Bug，以便在正式版中得到解決。
   特別是在有客戶參加的情況下，對系統(tǒng)進(jìn)行測試可能會出現(xiàn)一些我們沒有考慮的情況，還可以解決一些客戶實(shí)際關(guān)心的問題

不同的測試技術(shù)區(qū)分
3.1 覆蓋測試技術(shù)
說明:測試覆蓋率可以看出測試的完成度,在測試分析報告中可以作為量化指標(biāo)的依據(jù)，測試覆蓋率越高效果越好。
   覆蓋測試可以是程序代碼的執(zhí)行路徑覆蓋，亦可以是功能實(shí)現(xiàn)的步驟覆蓋（可以理解成流程圖的路徑覆蓋）。
   該技術(shù)可以用在任何測試階段，包括單元測壞死、集成測試、系統(tǒng)測試。
   使用該技術(shù)時可以使用以上的任何測試方法和測試技術(shù)。
3.2 白盒測試和黑盒測試技術(shù)
   白盒測試技術(shù) (White Box Testing)該技術(shù)主要的特征是測試對象進(jìn)入了代碼內(nèi)部,根據(jù)開發(fā)人員對代碼和對程序的熟悉程度,對有需要的部分進(jìn)行在軟件編碼階段，開發(fā)人員根據(jù)自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主，使用Xunit系列工具進(jìn)行測試，可以包括很多方面如功能性能等。
   黑盒測試 (Black Box Testing)測試的主體部分黑盒測試的內(nèi)容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結(jié)合兼容，性能測試等方面進(jìn)行,包括的不同測試類型請參考以上內(nèi)容。
3.3 手工測試和自動化測試
   手工測試（Manual  Testing）：即依靠人力來查找Bug。方法可以參考上邊的測試，也可以根據(jù)對實(shí)現(xiàn)技術(shù)及經(jīng)驗等進(jìn)行不同的測試。
   自動測試（Automation Testing）使用有針對工具實(shí)行。可以作出自動化測試的計劃,對可以進(jìn)行自動化測試的部分編寫或者錄制相應(yīng)的腳本,可以加入功能,容錯,表單提交等,可以參考MI,Rationa  或者其他類測試工具說明.
   根據(jù)權(quán)威的軟件測試經(jīng)驗，手工測試還是主要的測試方法，自動測試不夠靈活，在這里不再詳述。微軟的測試過程80％還是手工完成。
   自動測試永遠(yuǎn)也代替不了手工測試，但是手工測試的工作量很大是不爭的事實(shí)。
3.4 根據(jù)RUP標(biāo)準(zhǔn)按階段區(qū)分測試
   單元測試在上邊有詳細(xì)的敘述，還有針對單元測試和集成測試的論述，請參考。
   集成測試分為功能集成測試和系統(tǒng)集成測試，相互有調(diào)用的功能集成，在系統(tǒng)環(huán)境下功能相互調(diào)用的影響等，使用方法可以任意選用上面的內(nèi)容。注重功能方面。
   系統(tǒng)測試在功能實(shí)現(xiàn)的基礎(chǔ)上，可以加入兼容性，易用性，性能等等
   驗收測試可以包括Alpha和Beta測試，在這里就不再詳述。

4. 存在風(fēng)險及解決方法
說明：測試不能找出所有的問題，只是盡量將問題在開發(fā)階段解決大多數(shù)的問題而已。
測試風(fēng)險如下：
   軟硬件的測試環(huán)境提供上也對測試結(jié)果有很大的影響。
   測試團(tuán)隊的水平，經(jīng)驗，合作效果等
   整個開發(fā)流程對測試的重視程度，測試的進(jìn)入時間等
   由于測試環(huán)境操作系統(tǒng)，網(wǎng)絡(luò)環(huán)境，帶寬等情況可能產(chǎn)生的測試結(jié)果可能不同這是就需要經(jīng)驗以及對測試環(huán)境的保護(hù)等方面下一些功夫。
5. 軟件缺陷的原則
   軟件缺陷區(qū)別于軟件bug,它是在測試過程中出現(xiàn)的對系統(tǒng)有影響的,但是在設(shè)計中沒有的或者對修改后的bug測試和開發(fā)人員有不同意見等
   軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能。
   軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤。
   軟件功能超出產(chǎn)品說明書指明范圍。
   軟件未達(dá)到產(chǎn)品說明書雖未指出但應(yīng)達(dá)到的目標(biāo)。
   軟件測試員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢，或者最終用戶認(rèn)為不好。

6. 文檔測試
   產(chǎn)品說明書屬性檢查清單
   完整.是否有遺漏和丟失  完全嗎  單獨(dú)使用是否包含全部內(nèi)容   
   準(zhǔn)確.既定解決方案正確嗎  目標(biāo)明確嗎  有沒有錯誤   
   精確,不含糊,清晰.描述是否一清二楚  還是自說自話  容易看懂和理解嗎   
   一致.產(chǎn)品功能能描述是否自相矛盾,與其他功能有沒有沖突   
   貼切.描述功能的陳述是否必要  有沒有多余信息  功能是否原來的客戶要求   
   合理.在特定的預(yù)算和進(jìn)度下,以現(xiàn)有人力,物力和資源能否實(shí)現(xiàn)   
   代碼無關(guān).是否堅持定義產(chǎn)品,而不是定義其所信賴的軟件設(shè)計,架構(gòu)和代碼   
   可測試性.特性能否測試  測試員建立驗證操作的測試程序是否提供足夠的信息   

   產(chǎn)品說明書用語檢查清單
說明 對問題的描述通常表現(xiàn)為粉飾沒有仔細(xì)考慮的功能----可歸結(jié)于前文所述的屬性.從產(chǎn)品說明書上找出這樣的用語,仔細(xì)審視它們在文中是怎樣使用的.產(chǎn)品說明書可能會為其掩飾和開脫,也可能含糊其詞----無論是哪一種情況都可視為軟件缺陷.
   總是,每一種,所有,沒有,從不.如果看到此類絕對或肯定的,切實(shí)認(rèn)定的敘述,軟件測試員就可以著手設(shè)計針鋒相對的案例.
   當(dāng)然,因此,明顯,顯然,必然.這些話意圖誘使接受假定情況.不要中了圈套.
   某些,有時,常常,通常,慣常,經(jīng)常,大多,幾乎.這些話太過模糊."有時"發(fā)生作用的功能無法測試.
   等等,諸如此類,依此類推.以這樣的詞結(jié)束的功能清單無法測試.功能清單要絕對或者解釋明確,以免讓人迷惑,不知如何推論.
   良好,迅速,廉價,高效,小,穩(wěn)定.這些是不確定的說法,不可測試.如果在產(chǎn)品說明書中出現(xiàn),就必須進(jìn)一步指明含義.
   已處理,已拒絕,已忽略,已消除.這些廉潔可能會隱藏大量需要說明的功能.
   如果...那么...(沒有否則).找出有"如果...那么..."而缺少配套的"否則"結(jié)構(gòu)的陳述.想一想"如果"沒有發(fā)生會怎樣.