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