術(shù)語、名詞定義
1.?黑盒測試

　　黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測試者把被測程序看成一個黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試是基于用戶角度進行的測試。
2.?白盒測試

　　軟件測試的主要方法之一，也稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內(nèi)部結(jié)構(gòu)、算法等信息，這是從程序設(shè)計者的角度對程序進行的測試。它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。
3.?灰盒測試

　　可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試，灰盒就是界于黑白之間, 對軟件內(nèi)部有所了解, 但不見得到了如指掌的程度, 卻可以結(jié)合這些了解做些比黑盒多點的測試。
4.?文檔測試

　　文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試內(nèi)容也有所變化。在需求分析以及原型架構(gòu)階段，文檔測試主要目標(biāo)是： Sitemap、動作分解列表、數(shù)據(jù)庫ER圖、UML用例圖、流程圖、需求文檔等文檔。

　　文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內(nèi)容前后矛盾。完整性是指文檔不可以漏掉關(guān)鍵性內(nèi)容?？衫斫庑允侵冈谖臋n中描述的語言要簡明易懂，不能讓別的開發(fā)人員拿到文檔時看不懂文檔的內(nèi)容。
5.?命名規(guī)范測試

　　命名規(guī)范測試用于測試項目中的文件命名、代碼以及版本號等書寫是否符合規(guī)范。文件命名規(guī)范以及版本號命名規(guī)范可以參看第四部分里軟件命名規(guī)范的詳細(xì)信息；各種語言的命名規(guī)范可以參考語言自身的規(guī)范，如NoahWeb的可以參考 http://docs.noahweb.net附錄中的《NoahWeb各類資源命名規(guī)范》。
6.?需求完整性測試

　　需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認(rèn)需求是否明確。另外，需求完整性測試也承擔(dān)著一部分澄清需求的任務(wù)。
7.?鏈接完整性測試

　　在原型架構(gòu)階段，鏈接完整性的測試是非常有必要的。該項測試任務(wù)主要是檢查假頁面中各種鏈接是否完整，是否指向目標(biāo)位置，屬于檢查性的測試。
8.?頁面完整性測試

　　頁面完整性測試主要存在于集成測試階段以及其后續(xù)其它階段中，測試頁面是否完整，頁面質(zhì)量是否達標(biāo)，屬于檢查性測試。
9.?UI合理性測試

　　UI合理性測試也就是人機交互界面的合理性，UI合理性測試的內(nèi)容很多，具體測試內(nèi)容如下：
o?提示、菜單、幫助的格式是否一致；
o?提示、菜單、幫助中的術(shù)語是否一致；
o?各個控件之間的對齊方式是否一致；
o?輸入界面和輸出界面在外觀、布局、交互方式上是否一致；
o?功能類似的相關(guān)界面在外觀、布局、交互方式上是否一致；
o?同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小 是否與界面的大小比例協(xié)調(diào)；
o?多個連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致；
o?系統(tǒng)是否拒絕客戶的錯誤輸入并做出提示；
o?系統(tǒng)是否在用戶完成操作時給出操作成功的提示；
o?用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；
o?各個控件的間隔是否一致，垂直和水平方向上是否對齊；
o?是否允許動作的可逆性，返回原有操做；
10.?數(shù)據(jù)和數(shù)據(jù)庫完整性測試

　　因為在開發(fā)階段開發(fā)人員隨時都有可能根據(jù)需要來修改數(shù)據(jù)庫，所以對數(shù)據(jù)和數(shù)據(jù)庫完整性測試在軟件項目的任何階段也是非常必要的。該項測試內(nèi)容主要是以數(shù)據(jù)庫表為單位，檢查數(shù)據(jù)庫表以及表中各字段命名是否符合命名規(guī)范，表中字段是否完整，數(shù)據(jù)庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數(shù)據(jù)庫表中的關(guān)系、索引、主鍵、約束是否正確。
11.?功能測試

　　功能測試在軟件項目的任何階段中都是重要的。實現(xiàn)功能，滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項出現(xiàn)。該項測試任務(wù)主要為了測試已實現(xiàn)的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態(tài)下，該測試均會被使用。

　　功能測試中測試人員往往會忽略掉一些細(xì)節(jié)問題，比如：一個功能的實現(xiàn)必須要經(jīng)過6步操作才能完成，而且需要加入20條信息才能看得出測試結(jié)果，有的測試人員為了節(jié)省時間雖然做完了6步操作，但是沒有加入足量的信息，,使得測試不全面,正是因為這樣而導(dǎo)致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進行的測試功能每一步都執(zhí)行一遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以避免遺漏掉BUG沒有測試出來。
12.?壓力測試

　　壓力測試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會變得不可接受。這通過改變應(yīng)用程序的輸入以對應(yīng)用程序施加越來越大的負(fù)載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負(fù)載測試，但是負(fù)載測試通常描述一種特定類型的壓力測試——增加用戶數(shù)量以對應(yīng)用程序進行壓力測試。

　　對應(yīng)用程序進行壓力測試最簡單的方法是手工改變輸入（客戶機數(shù)量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內(nèi)改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。
13.?安全性測試

　　安全性測試主要是測試系統(tǒng)在沒有授權(quán)的內(nèi)部或者外部用戶對系統(tǒng)進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數(shù)據(jù)和頁面的安全。測試人員可以學(xué)習(xí)一些黑客技術(shù)，來對系統(tǒng)進行攻擊。 另外，對操作權(quán)限的測試也包含在安全性測試中。具體測試內(nèi)容如下：
o?執(zhí)行添加、刪除、修改等動作中是否做過登錄檢測。
o?退出系統(tǒng)之后的操作是否可以完成。
o?所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲，特殊字符為：！?#￥%……—*（）~——-+=[]{}、|；：‘”？/《》<>，。
o?在帶有參數(shù)的回顯數(shù)據(jù)的動作中更改參數(shù)，把參數(shù)改為特殊字符并加入操作語句看是否出錯。
o?測試表單中有沒有做標(biāo)簽檢測，標(biāo)簽檢測是否完整。
o?在插入表單中加入特殊的HTML代碼，例如：表單中的字本是否移動？。
14.?頁面腳本測試

　　頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進行測試。其主要內(nèi)容包括：相關(guān)頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。
15.?提示文本測試

　　提示文本測試從嚴(yán)格意義上來講應(yīng)該屬于UI合理性測試的一部分，該項測試主要針對各個頁面中使用到的大量提示文檔進行測試，主要包括：表達不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。
16.?瀏覽器測試

　　由于B/S結(jié)構(gòu)項目是基于瀏覽器運行的，所以需要對瀏覽器進行必要的測試。該測試任務(wù)主要是軟件對各種瀏覽器（IE5.5、IE6.0、 FireFox瀏覽器 ）的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。
17.?安裝測試

　　在軟件項目的后期階段，會對做好的軟件進行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進行安裝功能方面的測試。該測試的主要任務(wù)是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。
18.?自定義測試

　　在常規(guī)測試時可能表中的測試項不能滿足測試要求，如果有特殊測試項請測試人員自己定義修改測試的類型。