web應用程序測試方法和測試技術(shù)詳述
1. 概述
隨著(zhù)web應用的增多，新的模式解決方案中以web為核心的應用也越來(lái)越多， 很多公司各種應用的架構都以B/S及web應用為主，但是有關(guān)WEB測試方面的內容并沒(méi)有相應的總結，所以我在這里對web的測試方法和采用的測試技術(shù)進(jìn)行總結，便于內部交流。
測試方法盡量涵蓋web程序的各個(gè)方面，測試技術(shù)方面在繼承傳統測試技術(shù)的技術(shù)上結合web應用的特點(diǎn)。
l 相關(guān)的測試和實(shí)現技術(shù)也有著(zhù)很大的關(guān)系，由于本公司使用J2EE體系，也許例子中只有JAVA平臺可以使用，.NET平臺測試技術(shù)暫時(shí)不涉及，如果你有請與我聯(lián)系。
2. 測試方法
說(shuō)明：測試方法的選擇取決你的測試策略。
一般的web測試和以往的應用程序的測試的側重點(diǎn)不完全相同，基本包括以下幾個(gè)方面。
當然圓滿(mǎn)的完成測試還要有好的團體和流程等的方方面面的支持，你同樣應該對這些方面進(jìn)行注意。
有些測試方法設計到了流程，哪些應該在你的測試團隊建設中建立。
2.1 界面測試
現在一般人都有使用瀏覽器瀏覽網(wǎng)頁(yè)的經(jīng)歷，用戶(hù)雖然不是專(zhuān)業(yè)人員但是對界面效果的印象是很重要的。如果你注重這方面的測試，那么驗證應用程序是否易于使用就非常重要了。很多人認為這是測試中最不重要的部分，但是恰恰相反界面對不懂技術(shù)的客戶(hù)來(lái)說(shuō)那相當關(guān)鍵，慢慢體會(huì )你會(huì )明白的。
方法上可以根據設計文檔，如果夠專(zhuān)業(yè)的話(huà)可以專(zhuān)業(yè)美工人員，來(lái)確定整體風(fēng)格頁(yè)面風(fēng)格，然后根據這個(gè)可以頁(yè)面人員可以生成靜態(tài)的HTML，CSS等甚至生成幾套不用的方案來(lái)討論，或者交給客戶(hù)評審，最后形成統一的風(fēng)格的頁(yè)面/框架。注意不要靠程序員的美術(shù)素養形成你的web風(fēng)格，那樣可能會(huì )很糟糕。
主要包括以下幾個(gè)方面的內容：
Ø 站點(diǎn)地圖和導航條 位置、是否合理、是否可以導航等內容布局 布局是否合理，滾動(dòng)條等簡(jiǎn)介說(shuō)明 說(shuō)明文字是否合理，位置，是否正確；
Ø 背景/色調 是否正確、美觀(guān)，是否符合用戶(hù)需求；
Ø 頁(yè)面在窗口中的顯示是否正確、美觀(guān)（在調整瀏覽器窗口大小時(shí)，屏幕刷新是否正確）表單樣式 大小，格式，是否對提交數據進(jìn)行驗證（如果在頁(yè)面部分進(jìn)行驗證的話(huà)）等；
Ø 連接 連接的形式，位置，是否易于理解等。
web測試的主要頁(yè)面元素
Ø 頁(yè)面元素的容錯性列表（如輸入框、時(shí)間列表或日歷）；
Ø 頁(yè)面元素清單（為實(shí)現功能，是否將所需要的元素全部都列出來(lái)了，如按鈕、單選框、復選框、列表框、超連接、輸入框等等）；
Ø 頁(yè)面元素的容錯性是否存在；
Ø 頁(yè)面元素的容錯性是否正確；
Ø 頁(yè)面元素基本功能是否實(shí)現（如文字特效、動(dòng)畫(huà)特效、按鈕、超連接）；
Ø 頁(yè)面元素的外形、擺放位置（如按鈕、列表框、核選框、輸入框、超連接等）；
Ø 頁(yè)面元素是否顯示正確（主要針對文字、圖形、簽章）；
Ø 元素是否顯示（元素是否存在）；
Ø 頁(yè)面元素清單（為實(shí)現功能，是否將所需要的元素全部都列出來(lái)了，如按鈕、單選框、復選框、列表框、超連接、輸入框等等）。
測試技術(shù)
Ø 通過(guò)頁(yè)面走查，瀏覽確定使用的頁(yè)面是否符合需求?？梢越Y合兼容性測試對不用分辨率下頁(yè)面顯示效果，如果有影響應該交給設計人員提出解決方案；
Ø 可以結合數據定義文檔查看表單項的內容，長(cháng)度等信息；
Ø 對于動(dòng)態(tài)生成的頁(yè)面最好也能進(jìn)行瀏覽查看。如Servelet部分可以結合編碼規范，進(jìn)行代碼走查。是否支持中文，如果數據用XML封裝要做的工作會(huì )多一點(diǎn)等等。
2.1.l 界面測試要素:
符合標準和規范,靈活性,正確性,直觀(guān)性,舒適性,實(shí)用性,一致性
2.1.l.1 直觀(guān)性:
Ø 用戶(hù)界面是否潔凈,不唐突,不擁擠.界面不應該為用戶(hù)制造障礙.所需功能或者期待的響應應該明顯,并在預期出現的地方；
Ø 界面組織和布局合理嗎是否允許用戶(hù)輕松地從一個(gè)功能轉到另一個(gè)功能下一步做什么明顯嗎任何時(shí)刻都可以決定放棄或者退回,退出嗎輸入得到承認了嗎菜單或者窗口是否深藏不露
Ø 有多余功能嗎軟件整體抑或局部是否做得太多是否有太多特性把工作復雜化了是否感到信息太龐雜
Ø 如果其他所有努力失敗,幫助系統真能幫忙嗎
2.1.l.2 一致性
Ø 快速鍵和菜單選項.在Windows 中按F1鍵總是得到幫助信息；
Ø 術(shù)語(yǔ)和命令.整個(gè)軟件使用同樣的術(shù)語(yǔ)嗎特性命名一致嗎例如,Find是否一直叫Find,而不是有時(shí)叫Search?
Ø 軟件是否一直面向同一級別用戶(hù)帶有花哨用戶(hù)界面的趣味賀卡程序不應該顯示泄露技術(shù)機密的錯誤提示信息；
Ø 按鈕位置和等價(jià)的按鍵.大家是否注意到對話(huà)框有OK按鈕和Cancle按鈕時(shí),OK按鈕總是在上方或者左方,而Cancle按鈕總是在下方或右方同樣原因,Cancle按鈕的等價(jià)按鍵通常是Esc,而選中按鈕的等價(jià)按鈕通常是Enter.保持一致。
2.1.l.3 靈活性
Ø 狀態(tài)跳轉：靈活的軟件實(shí)現同一任務(wù)有多種選擇方式；
Ø 狀態(tài)終止和跳過(guò)：具有容錯處理能力；
Ø 數據輸入和輸出：用戶(hù)希望有多種方法輸入數據和查看結果.例如,在寫(xiě)字板插入文字可用鍵盤(pán)輸入,粘貼,從6種文件格式讀入,作為對象插入,或者用鼠標從其他程序拖動(dòng)。
2.1.l.4 舒適性
Ø 恰當：軟件外觀(guān)和感覺(jué)應該與所做的工作和使用者相符；
Ø 錯誤處理：程序應該在用戶(hù)執行嚴重錯誤的操作之前提出警告,并允許用戶(hù)恢復由于錯誤操作導致丟失的數據，如大家認為undo /redo是當然的；
Ø 性能：快不見(jiàn)得是好事，要讓用戶(hù)看得清程序在做什么，它是有反應的。
2.2 功能測試
功能測試是測試中的重點(diǎn)，主要包括一下幾個(gè)方面的內容：
Ø 連接：這個(gè)連接和界面測試中的連接不同。那里注重的是連接方式和位置，如是圖像還是文字放置的位置等，還是其他的方式；這里的連接注重功能，如是否有連接，連接的是否是說(shuō)明的位置等；
Ø 表單提交：應當模擬用戶(hù)提交，驗證是否完成功能，如注冊信息，要測試這些程序，需要驗證服務(wù)器能正確保存這些數據，而且后臺運行的程序能正確解釋和使用這些信息。還有數據正確性驗證，異常處理等，最好結合易用性要求等。B/S結構實(shí)現的功能可能主要的就在這里，提交數據，處理數據等如果有固定的操作流程可以考慮自動(dòng)化測試工具的錄制功能，編寫(xiě)可重復使用的腳本代碼，可以在測試、回歸測試時(shí)運行以便減輕測試人員工作量；
Ø Cookies 驗證：如果系統使用了cookie，測試人員需要對它們進(jìn)行檢測。如果在 cookies 中保存了注冊信息，請確認該 cookie能夠正常工作而且已對這些信息已經(jīng)加密。如果使用 cookie 來(lái)統計次數，需要驗證次數累計正確。關(guān)于cookie的使用可以參考瀏覽器的幫助信息。如果使用B/S結構cookies中存放的信息更多；
Ø 功能易用性測試 完成了功能測試可以對應用性進(jìn)行了解，最好聽(tīng)聽(tīng)客戶(hù)的反映，在可以的情況下對程序進(jìn)行改進(jìn)是很有必要的，和客戶(hù)保持互動(dòng)對系統滿(mǎn)意度也是很有幫助的。
功能測試的測試技術(shù)可是很多的，我們可以結合實(shí)際環(huán)境選擇使用。
Ø 白盒測試技術(shù)(White Box Testing)： 深入到代碼一級的測試，使用這種技術(shù)發(fā)現問(wèn)題最早，效果也是最好的。該技術(shù)主要的特征是測試對象進(jìn)入了代碼內部，根據開(kāi)發(fā)人員對代碼和對程序的熟悉程度，對有需要的部分進(jìn)行在軟件編碼階段，開(kāi)發(fā)人員根據自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開(kāi)發(fā)人員為主，在JAVA平臺使用Xunit系列工具進(jìn)行測試，Xunit測試工具是類(lèi)一級的測試工具對每一個(gè)類(lèi)和該類(lèi)的方法進(jìn)行測試。
Ø 黑盒測試技術(shù)（Black Box Testing）：黑盒測試的內容主要有以下幾個(gè)方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結合兼容，性能測試等方面進(jìn)行，根據軟件需求，設計文檔，模擬客戶(hù)場(chǎng)景隨系統進(jìn)行實(shí)際的測試，這種測試技術(shù)是使用最多的測試技術(shù)涵蓋了測試的方方面面，可以考慮以下方面
正確性 (Correctness)：計算結果，命名等方面。
可用性 (Usability)：是否可以滿(mǎn)足軟件的需求說(shuō)明。
邊界條件 (Boundary Condition)：輸入部分的邊界值，就是使用一般書(shū)中說(shuō)的等價(jià)類(lèi)劃分，試試最大最小和非法數據等等。
性能 (Performance)： 正常使用的時(shí)間內系統完成一個(gè)任務(wù)需要的時(shí)間，多人同時(shí)使用的時(shí)候響應時(shí)間在可以接受范圍內。J2EE技術(shù)實(shí)現的系統在性能方面更是需要照顧的，一般原則是3秒以下接受，3-5秒可以接受，5秒以上就影響易用性了。如果在測試過(guò)程中發(fā)現性能問(wèn)題，修復起來(lái)是非常艱難的，因為這常常意味著(zhù)程序的算法不好，結構不好，或者設計有問(wèn)題。因此在產(chǎn)品開(kāi)發(fā)的開(kāi)始階段，就要考慮到軟件的性能問(wèn)題
壓力測試 (Stress)： 多用戶(hù)情況可以考慮使用壓力測試工具，建議將壓力和性能測試結合起來(lái)進(jìn)行。如果有負載平衡的話(huà)還要在服務(wù)器端打開(kāi)監測工具,查看服務(wù)器CPU使用率，內存占用情況，如果有必要可以模擬大量數據輸入，對硬盤(pán)的影響等等信息。如果有必要的話(huà)必須進(jìn)行性能優(yōu)化(軟硬件都可以)。這里的壓力測試針對的是某幾項功能。
錯誤恢復 (Error Recovery)：錯誤處理，頁(yè)面數據驗證，包括突然間斷電，輸入臟數據等。
安全性測試(Security)：這個(gè)領(lǐng)域正在研究中，防火墻、補丁包、殺毒軟件等的就不必說(shuō)了，不過(guò)可以考慮。破壞性測試時(shí)任意看了一些資料后得知,這里面設計到的知識\內容可以寫(xiě)本書(shū)了,不是一兩句可以說(shuō)清的，特別是一些商務(wù)網(wǎng)站，或者跟錢(qián)有關(guān)，或者和公司秘密有關(guān)的web更是需要這方面的測試，在外國有一種專(zhuān)門(mén)干這一行的人叫安全顧問(wèn)，可以審核代碼，提出安全建議，出現緊急事件時(shí)的處理辦法等，在國內沒(méi)有聽(tīng)說(shuō)哪里有專(zhuān)門(mén)搞安全技術(shù)測試的內容。
兼容性 (Compatibility)：不同瀏覽器，不同應用程序版本在實(shí)現功能時(shí)的表現不同的上網(wǎng)方式，如果你測試的是一個(gè)公共網(wǎng)站的話(huà)。
兼容性測試內容詳述：
Ø 硬件平臺
Ø 瀏覽器軟件和版本：瀏覽器插件，瀏覽器選項，視頻分辨率和色深，文字大小，調制解調器速率.
軟件配置 (Configuration)：如IE瀏覽器的不用選項-安全設定最高，禁用腳本程序等等，你們的程序在各種不用的設置下表現如何。
單元測試和白盒測試是不同的，雖然單元測試和白盒測試都是關(guān)注功能，他們都需要代碼支持，但是級別不同。白盒測試關(guān)注的是類(lèi)中一個(gè)方法的功能，是更小的單位，但是完成一個(gè)單元測試可能需要N多類(lèi)，所以說(shuō)作單元測試需要寫(xiě)驅動(dòng)和穩定樁，比如查詢(xún)單元是一個(gè)查詢(xún)包，包括N多的測試類(lèi)、測試數據，運行他需要提供數據的部分，輸入參數和發(fā)出命令的驅動(dòng)等等，是比類(lèi)大的一個(gè)整體進(jìn)行的。
另一個(gè)明顯的區別是白盒測試不會(huì )關(guān)注類(lèi)接口，但是單元測試主要的內容就是類(lèi)接口測試。
不過(guò)很多時(shí)候是很少區分的，因為這兩種技術(shù)實(shí)現起來(lái)有很多相互關(guān)聯(lián)的部分。不過(guò)要看你對質(zhì)量的關(guān)注程度來(lái)決定。
Ø 邊界條件
邊界條件是指軟件計劃的操作界限所在的邊緣條件，如果軟件測試問(wèn)題包含確定的邊界，那么數據類(lèi)型可能是：數值、速度、字符、地址、位置、尺寸、數量。同時(shí)，考慮這些類(lèi)型的下述特征：第一個(gè)/最后一個(gè)、最小值/最大值、開(kāi)始/完成、超過(guò)/在內、空/滿(mǎn)、最短/最長(cháng)、最慢/最快、最早/最遲、最大/最小、最高/最低、相鄰/最遠。
Ø 越界測試
通常是簡(jiǎn)單加1或者很小的數(對于最大值)和減少1或者很小的數(對于最小值)，例如：第一個(gè)減1/最后一個(gè)加1、開(kāi)始減1/完成加1、空了再減/滿(mǎn)了再加、慢上加慢/快上加快、最大數加1/最小數減1、最小值減1/最大值加1、剛好超過(guò)/剛好在內、短了再短/長(cháng)了再長(cháng)、早了更早/晚了更晚、最高加1/最低減1。
另一些該注意的輸入：默認，空白，空值，零值和無(wú)；非法，錯誤，不正確和垃圾數據。
Ø 軟件可能進(jìn)入的每一種獨立狀態(tài)；
Ø 從一種狀態(tài)轉入另一種狀態(tài)所需的輸入和條件；
Ø 進(jìn)入或退出某種狀態(tài)時(shí)的設置條件及輸入結果。
具體測試方法可以參考如下：
Ø 每種狀態(tài)至少訪(fǎng)問(wèn)一次；
Ø 測試看起來(lái)最常見(jiàn)最普遍的狀態(tài)轉換；
Ø 測試狀態(tài)之間最不常用的分支；
Ø 測試所有錯誤狀態(tài)及其返回值；
Ø 測試隨機狀態(tài)轉換。
競爭條件典型情形參考如下:
Ø 兩個(gè)不同的程序同時(shí)保存或打開(kāi)同一個(gè)文檔；
Ø 共享同一臺打印機,通信端口或者其他外圍設備；
Ø 當軟件處于讀取或者修改狀態(tài)時(shí)按鍵或者單擊鼠標；
Ø 同時(shí)關(guān)閉或者啟動(dòng)軟件的多個(gè)實(shí)例；
Ø 同時(shí)使用不同的程序訪(fǎng)問(wèn)一個(gè)共同數據庫。
在這里的負載\壓力和功能測試中的不同，他是系統測試的內容，是基本功能已經(jīng)通過(guò)后進(jìn)行的?？梢栽诩蓽y試階段，亦可以在系統測試階段進(jìn)行。
使用負載測試工具進(jìn)行，虛擬一定數量的用戶(hù)看一看系統的表現，是否滿(mǎn)足定義中的指標。
負載測試一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的內容都是編寫(xiě)出測試腳本，腳本中一般包括用戶(hù)常用的功能，然后運行，得出報告。所以負載測試包括的主要內容就不介紹了。
負載測試技術(shù)在各種極限情況下對產(chǎn)品進(jìn)行測試 (如很多人同時(shí)使用該軟件，或者反復運行該軟件)，以檢查產(chǎn)品的長(cháng)期穩定性。例如，使用壓力測試工具對web服務(wù)器進(jìn)行壓力測試。本項測試可以幫助找到一些大型的問(wèn)題，如死機、崩損、內存泄漏等，因為有些存在內存泄漏問(wèn)題的程序，在運行一兩次時(shí)可能不會(huì )出現問(wèn)題，但是如果運行了成千上萬(wàn)次，內存泄漏得越來(lái)越多，就會(huì )導致系統崩滑。用J2EE實(shí)現的系統很少但是并不是沒(méi)有內存問(wèn)題。
Ø 無(wú)論什么工具基本的技術(shù)都是利用線(xiàn)程技術(shù)模仿和虛擬用戶(hù)，在這里主要的難點(diǎn)在與測試腳本的編寫(xiě)，每種工具使用的腳本都不一樣，但是大多數工具都提供錄制功能就算是不會(huì )編碼的測試人員同樣可以測試。
Ø 對負載工具的延伸使用可以進(jìn)行系統穩定性測試，系統極限測試，如使用100的Load Size連續使用24小時(shí)，微軟定義的通過(guò)準則是通過(guò)72小時(shí)測試的程序一般不會(huì )出現穩定性的問(wèn)題。
過(guò)一段時(shí)間以后，再回過(guò)頭來(lái)對以前修復過(guò)的Bug重新進(jìn)行測試，看該Bug 是否會(huì )重新出現。
Ø 回歸測試技術(shù)可以在測試的各個(gè)階段出現，無(wú)論是單元測試還是集成測試還是系統測試。是對以前問(wèn)題進(jìn)行驗證的過(guò)程。
Ø 回歸測試的目的就是保證以前已經(jīng)修復的Bug不會(huì )再出現。實(shí)際上，許多Bug都是在回歸測試時(shí)發(fā)現的，在此階段，我們首先要檢查以前找到的Bug 是否已經(jīng)更正了。值得注意的是，已經(jīng)更正的Bug 也可能又回來(lái)了，有的Bug 經(jīng)過(guò)修改之后可能又產(chǎn)生了新的Bug。所以，回歸測試可保證已更正的Bug不再重現，不產(chǎn)生新的Bug。
在正式發(fā)布產(chǎn)品之前往往要先發(fā)布一些測試版，讓用戶(hù)能夠反饋出相關(guān)信息，或者找到存在的Bug，以便在正式版中得到解決。
特別是在有客戶(hù)參加的情況下，對系統進(jìn)行測試可能會(huì )出現一些我們沒(méi)有考慮的情況，還可以解決一些客戶(hù)實(shí)際關(guān)心的問(wèn)題。
不同的測試技術(shù)區分
2.3 覆蓋測試技術(shù)
說(shuō)明:測試覆蓋率可以看出測試的完成度，在測試分析報告中可以作為量化指標的依據，測試覆蓋率越高效果越好。
覆蓋測試可以是程序代碼的執行路徑覆蓋，亦可以是功能實(shí)現的步驟覆蓋（可以理解成流程圖的路徑覆蓋）。
該技術(shù)可以用在任何測試階段，包括單元測試、集成測試、系統測試。
使用該技術(shù)時(shí)可以使用以上的任何測試方法和測試技術(shù)。
2.4 白盒測試和黑盒測試技術(shù)
白盒測試技術(shù) (White Box Testing)：該技術(shù)主要的特征是測試對象進(jìn)入了代碼內部，根據開(kāi)發(fā)人員對代碼和對程序的熟悉程度，對有需要的部分進(jìn)行測試。在軟件編碼階段，開(kāi)發(fā)人員根據自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開(kāi)發(fā)人員為主，使用Xunit系列工具進(jìn)行測試，可以包括很多方面如功能性能等。
黑盒測試 (Black Box Testing)：測試的主體部分，黑盒測試的內容主要有以下幾個(gè)方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結合兼容，性能測試等方面進(jìn)行，包括的不同測試類(lèi)型請參考以上內容。
2.5 手工測試和自動(dòng)化測試
手工測試 （Manual Testing）：即依靠人力來(lái)查找Bug。方法可以參考上邊的測試，也可以根據對實(shí)現技術(shù)及經(jīng)驗等進(jìn)行不同的測試。
自動(dòng)測試 （Automation Testing）：使用有針對工具實(shí)行?？梢宰鞒鲎詣?dòng)化測試的計劃，對可以進(jìn)行自動(dòng)化測試的部分編寫(xiě)或者錄制相應的腳本，可以加入功能，容錯，表單提交等，可以參考MI,Rational或者其他類(lèi)測試工具說(shuō)明。
根據權威的軟件測試經(jīng)驗，手工測試還是主要的測試方法，自動(dòng)測試不夠靈活，在這里不再詳述。微軟的測試過(guò)程80％還是手工完成。
自動(dòng)測試永遠也代替不了手工測試，但是手工測試的工作量很大是不爭的事實(shí)。
2.6 根據RUP標準按階段區分測試
單元測試：在上邊有詳細的敘述，還有針對單元測試和集成測試的論述，請參考。
集成測試：分為功能集成測試和系統集成測試，相互有調用的功能集成，在系統環(huán)境下功能相互調用的影響等，使用方法可以任意選用上面的內容。注重功能方面。
系統測試：在功能實(shí)現的基礎上，可以加入兼容性，易用性，性能等等。
驗收測試：可以包括Alpha和Beta測試，在這里就不再詳述。
3. 存在風(fēng)險及解決方法
說(shuō)明：測試不能找出所有的問(wèn)題，只是盡量在開(kāi)發(fā)階段解決大多數的問(wèn)題而已。
測試風(fēng)險如下：
軟硬件的測試環(huán)境提供上也對測試結果有很大的影響；
測試團隊的水平，經(jīng)驗，合作效果等；
整個(gè)開(kāi)發(fā)流程對測試的重視程度，測試的進(jìn)入時(shí)間等；
由于測試環(huán)境操作系統，網(wǎng)絡(luò )環(huán)境，帶寬等情況可能產(chǎn)生的測試結果可能不同這是就需要經(jīng)驗以及對測試環(huán)境的保護等方面下一些功夫。
4. 軟件缺陷的原則
軟件缺陷區別于軟件bug,它是在測試過(guò)程中出現的對系統有影響的，但是在設計中沒(méi)有的或者對修改后的bug測試和開(kāi)發(fā)人員有不同意見(jiàn)等。
Ø 軟件未達到產(chǎn)品說(shuō)明書(shū)標明的功能；
Ø 軟件出現了產(chǎn)品說(shuō)明書(shū)指明不會(huì )出現的錯誤；
Ø 軟件功能超出產(chǎn)品說(shuō)明書(shū)指明范圍；
Ø 軟件未達到產(chǎn)品說(shuō)明書(shū)雖未指出但應達到的目標；
Ø 軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶(hù)認為不好。
5. 文檔測試
產(chǎn)品說(shuō)明書(shū)屬性檢查清單
Ø 完整：是否有遺漏和丟失？完全嗎？單獨使用是否包含全部?jì)热荩?/span>
Ø 準確：既定解決方案正確嗎？目標明確嗎？有沒(méi)有錯誤？
Ø 精確：不含糊，清晰。描述是否一清二楚？還是自說(shuō)自話(huà)？容易看懂和理解嗎？
Ø 一致：產(chǎn)品功能描述是否自相矛盾？與其他功能有沒(méi)有沖突
Ø 貼切：描述功能的陳述是否必要有沒(méi)有多余信息功能是否滿(mǎn)足的客戶(hù)要求
Ø 合理：在特定的預算和進(jìn)度下，以現有人力，物力和資源能否實(shí)現
Ø 代碼無(wú)關(guān)：是否堅持定義產(chǎn)品，而不是定義其所信賴(lài)的軟件設計，架構和代碼
Ø 可測試性：特性能否測試測試員建立驗證操作的測試程序是否提供足夠的信息
產(chǎn)品說(shuō)明書(shū)用語(yǔ)檢查清單
說(shuō)明：對問(wèn)題的描述通常表現為粉飾沒(méi)有仔細考慮的功能----可歸結于前文所述的屬性。從產(chǎn)品說(shuō)明書(shū)上找出這樣的用語(yǔ)，仔細審視它們在文中是怎樣使用的。產(chǎn)品說(shuō)明書(shū)可能會(huì )為其掩飾和開(kāi)脫,也可能含糊其詞----無(wú)論是哪一種情況都可視為軟件缺陷。
Ø 總是，每一種，所有，沒(méi)有，從不。如果看到此類(lèi)絕對或肯定的，切實(shí)認定的敘述，軟件測試員就可以著(zhù)手設計針?shù)h相對的案例。
Ø 當然，因此，明顯，顯然，必然。這些話(huà)意圖誘使接受假定情況，不要中了圈套。
Ø 某些，有時(shí)，常常，通常，慣常，經(jīng)常，大多，幾乎。這些話(huà)太過(guò)模糊，"有時(shí)"發(fā)生作用的功能無(wú)法測試。
Ø 等等，諸如此類(lèi)，依此類(lèi)推。以這樣的詞結束的功能清單無(wú)法測試，功能清單要絕對或者解釋明確，以免讓人迷惑，不知如何推論。
Ø 良好，迅速，廉價(jià)，高效，小，穩定。這些是不確定的說(shuō)法，不可測試。如果在產(chǎn)品說(shuō)明書(shū)中出現，就必須進(jìn)一步指明含義。
Ø 已處理，已拒絕，已忽略，已消除。這些廉潔可能會(huì )隱藏大量需要說(shuō)明的功能。
Ø 如果...那么...(沒(méi)有否則)。找出有"如果...那么..."而缺少配套的"否則"結構的陳述，想一想"如果"沒(méi)有發(fā)生會(huì )怎樣。
聯(lián)系客服
