狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

術語、名詞定義

1.      黑盒測試

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

2.      白盒測試

　　軟件測試的主要方法之一，也稱結構測試、邏輯驅動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內部結構、算法等信息，這是從程序設計者的角度對程序進行的測試。它的優點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。

3.      灰盒測試

　　可以理解為靜態的白盒測試或動態的黑盒測試，灰盒就是界于黑白之間, 對軟件內部有所了解, 但不見得到了如指掌的程度, 卻可以結合這些了解做些比黑盒多點的測試。

4.      文檔測試

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

　　文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內容前后矛盾。完整性是指文檔不可以漏掉關鍵性內容。可理解性是指在文檔中描述的語言要簡明易懂，不能讓別的開發人員拿到文檔時看不懂文檔的內容。

5.      命名規范測試

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

6.      需求完整性測試

　　需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認需求是否明確。另外，需求完整性測試也承擔著一部分澄清需求的任務。

7.      鏈接完整性測試

　　在原型架構階段，鏈接完整性的測試是非常有必要的。該項測試任務主要是檢查假頁面中各種鏈接是否完整，是否指向目標位置，屬于檢查性的測試。

8.      頁面完整性測試

　　頁面完整性測試主要存在于集成測試階段以及其后續其它階段中，測試頁面是否完整，頁面質量是否達標，屬于檢查性測試。

9.      UI合理性測試

　　UI合理性測試也就是人機交互界面的合理性，UI合理性測試的內容很多，具體測試內容如下：

o      提示、菜單、幫助的格式是否一致；

o      提示、菜單、幫助中的術語是否一致；

o      各個控件之間的對齊方式是否一致；

o      輸入界面和輸出界面在外觀、布局、交互方式上是否一致；

o      功能類似的相關界面在外觀、布局、交互方式上是否一致；

o      同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小是否與界面的大小比例協調；

o      多個連續界面依次出現的情況下，界面的外觀、操作方式是否一致；

o      系統是否拒絕客戶的錯誤輸入并做出提示；

o      系統是否在用戶完成操作時給出操作成功的提示；

o      用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；

o      各個控件的間隔是否一致，垂直和水平方向上是否對齊；

o      是否允許動作的可逆性，返回原有操做；

10.   數據和數據庫完整性測試

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

11.   功能測試

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

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

12.   壓力測試

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

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

13.   安全性測試

　　安全性測試主要是測試系統在沒有授權的內部或者外部用戶對系統進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數據和頁面的安全。測試人員可以學習一些黑客技術，來對系統進行攻擊。另外，對操作權限的測試也包含在安全性測試中。具體測試內容如下：

o      執行添加、刪除、修改等動作中是否做過登錄檢測。

o      退出系統之后的操作是否可以完成。

o      所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲，特殊字符為：！?#￥%……—*（）~——-+=[]{}、|；：‘”？/《》<>，。

o      在帶有參數的回顯數據的動作中更改參數，把參數改為特殊字符并加入操作語句看是否出錯。

o      測試表單中有沒有做標簽檢測，標簽檢測是否完整。

o      在插入表單中加入特殊的HTML代碼，例如：<marquee>表單中的字本是否移動？</marquee>。

14.   頁面腳本測試

　　頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進行測試。其主要內容包括：相關頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。

15.   提示文本測試

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

16.   瀏覽器測試

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

17.   安裝測試

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

通過測試的標準

　　一般有“基于測試用例”和“基于缺陷密度”兩種評比準則，在這里我們采用前者。
準則如下：

　　1. 功能性測試用例通過率達到100％；
　　2. 非功能性測試用例通過率達到95％；

備選通過辦法：

　　根據實際情況由項目經理和測試負責人以及用戶等共同討論確定本階段是否結束。