術語、名詞定義

1. 黑盒測試
   
   　　黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內部邏輯結構。測試者把被測程序看成一個黑盒,不用關心程序的內部結構。黑盒測試是在程序接口處進行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數據產生正確的輸出信息，并且保持外部信息(如數據庫或文件)的完整性。黑盒測試是基于用戶角度進行的測試。
   
   
2. 白盒測試
   
   　　軟件測試的主要方法之一，也稱結構測試、邏輯驅動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內部結構、算法等信息，這是從程序設計者的角度對程序進行的測試。它的優點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。
   
   
3. 灰盒測試
   
   　　可以理解為靜態的白盒測試或動態的黑盒測試，灰盒就是界于黑白之間, 對軟件內部有所了解, 但不見得到了如指掌的程度, 卻可以結合這些了解做些比黑盒多點的測試。
   
   
4. 文檔測試
   
   　　文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試內容也有所變化。在需求分析以及原型架構階段，文檔測試主要目標是： Sitemap、動作分解列表、數據庫ER圖、UML用例圖、流程圖、需求文檔等文檔。
   
   　　文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔內容前后矛盾。完整性是指文檔不可以漏掉關鍵性內容?？衫斫庑允侵冈谖臋n中描述的語言要簡明易懂，不能讓別的開發人員拿到文檔時看不懂文檔的內容。
   
   
5. 命名規范測試
   
   　　命名規范測試用于測試項目中的文件命名、代碼以及版本號等書寫是否符合規范。文件命名規范以及版本號命名規范可以參看第四部分里軟件命名規范的詳細信息；各種語言的命名規范可以參考語言自身的規范。
   
   
6. 需求完整性測試
   
   　　需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認需求是否明確。另外，需求完整性測試也承擔著一部分澄清需求的任務。
   
   
7. 鏈接完整性測試
   
   　　在原型架構階段，鏈接完整性的測試是非常有必要的。該項測試任務主要是檢查假頁面中各種鏈接是否完整，是否指向目標位置，屬于檢查性的測試。
   
   
8. 頁面完整性測試
   
   　　頁面完整性測試主要存在于集成測試階段以及其后續其它階段中，測試頁面是否完整，頁面質量是否達標，屬于檢查性測試。
   
   
9. UI合理性測試
   
   　　UI合理性測試也就是人機交互界面的合理性，UI合理性測試的內容很多，具體測試內容如下：
   
   
   • 提示、菜單、幫助的格式是否一致；
   • 提示、菜單、幫助中的術語是否一致；
   • 各個控件之間的對齊方式是否一致；
   • 輸入界面和輸出界面在外觀、布局、交互方式上是否一致；
   • 功能類似的相關界面在外觀、布局、交互方式上是否一致；
   • 同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小 是否與界面的大小比例協調；
   • 多個連續界面依次出現的情況下，界面的外觀、操作方式是否一致；
   • 系統是否拒絕客戶的錯誤輸入并做出提示；
   • 系統是否在用戶完成操作時給出操作成功的提示；
   • 用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；
   • 各個控件的間隔是否一致，垂直和水平方向上是否對齊；
   • 是否允許動作的可逆性，返回原有操做；
     
     
10. 數據和數據庫完整性測試
    
    　　因為在開發階段開發人員隨時都有可能根據需要來修改數據庫，所以對數據和數據庫完整性測試在軟件項目的任何階段也是非常必要的。該項測試內容主要是以數據庫表為單位，檢查數據庫表以及表中各字段命名是否符合命名規范，表中字段是否完整，數據庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數據庫表中的關系、索引、主鍵、約束是否正確。
    
    
11. 功能測試
    
    　　功能測試在軟件項目的任何階段中都是重要的。實現功能，滿足客戶需求是軟件本身最大的使命。功能測試在任何階段下基本上都作為測試工作的第一項出現。該項測試任務主要為了測試已實現的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態下，該測試均會被使用。
    
    　　功能測試中測試人員往往會忽略掉一些細節問題，比如：一個功能的實現必須要經過6步操作才能完成，而且需要加入20條信息才能看得出測試結果，有的測試人員為了節省時間雖然做完了6步操作，但是沒有加入足量的信息，,使得測試不全面,正是因為這樣而導致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進行的測試功能每一步都執行一遍，應該添加的數據都添加完整，以避免遺漏掉BUG沒有測試出來。
    
    
12. 壓力測試
    
    　　壓力測試是為了發現在什么條件下您的應用程序的性能會變得不可接受。這通過改變應用程序的輸入以對應用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現的。這種操作也稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試——增加用戶數量以對應用程序進行壓力測試。
    
    　　對應用程序進行壓力測試最簡單的方法是手工改變輸入（客戶機數量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。
    
    
13. 安全性測試
    
    　　安全性測試主要是測試系統在沒有授權的內部或者外部用戶對系統進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數據和頁面的安全。測試人員可以學習一些黑客技術，來對系統進行攻擊。 另外，對操作權限的測試也包含在安全性測試中。具體測試內容如下：
    
    
    • 執行添加、刪除、修改等動作中是否做過登錄檢測。
    • 退出系統之后的操作是否可以完成。
    • 所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲，特殊字符為：！?#￥%……—*（）~——-+=[]{}、|；：‘”？/《》<>，。
    • 在帶有參數的回顯數據的動作中更改參數，把參數改為特殊字符并加入操作語句看是否出錯。
    • 測試表單中有沒有做標簽檢測，標簽檢測是否完整。
    • 在插入表單中加入特殊的HTML代碼，例如：<marquee>表單中的字本是否移動？</marquee>。
      
      
14. 頁面腳本測試
    
    　　頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進行測試。其主要內容包括：相關頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。
    
    
15. 提示文本測試
    
    　　提示文本測試從嚴格意義上來講應該屬于UI合理性測試的一部分，該項測試主要針對各個頁面中使用到的大量提示文檔進行測試，主要包括：表達不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。
    
    
16. 瀏覽器測試
    
    　　由于B/S結構項目是基于瀏覽器運行的，所以需要對瀏覽器進行必要的測試。該測試任務主要是軟件對各種瀏覽器（IE5.5、IE6.0、 FireFox瀏覽器 ）的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。
    
    
17. 安裝測試
    
    　　在軟件項目的后期階段，會對做好的軟件進行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進行安裝功能方面的測試。該測試的主要任務是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。
    
    
18. 自定義測試
    
    　　在常規測試時可能表中的測試項不能滿足測試要求，如果有特殊測試項請測試人員自己定義修改測試的類型。

軟件命名規范

1. 軟件版本階段說明
   
   
   • Base版: 此版本表示該軟件僅僅是一個假頁面鏈接，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實現，只是做為整體網站的一個基礎架構。
     
   • Alpha版: 此版本表示該軟件在此階段主要是以實現軟件功能為主，通常只在軟件開發者內部交流，一般而言，該版本軟件的Bug較多，需要繼續修改。
     
   • Beta版: 該版本相對于α版已有了很大的改進，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過多次測試來進一步消除，此版本主要的修改對像是軟件的UI。
     
   • RC版: 該版本已經相當成熟了，基本上不存在導致錯誤的BUG，與即將發行的正式版相差無幾。
     
   • Release版: 該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱為標準版。一般情況下，Release不會以單詞形式出現在軟件封面上，取而代之的是符號(Ｒ)。
   
   
2. 版本命名規范
   
   　　軟件版本號由四部分組成，第一個1為主版本號，第二個1為子版本號，第三個1為階段版本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有5種，分別為：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。
   
   
   

   

   
   
   版本號定修改規則：
   
   
   • 主版本號(1)：當功能模塊有較大的變動，比如增加多個模塊或者整體架構發生變化。此版本號由項目決定是否修改。
     
   • 子版本號(1)：當功能有一定的增加或變化，比如增加了對權限控制、增加自定義視圖等功能。此版本號由項目決定是否修改。
     
   • 階段版本號(1)：一般是 Bug 修復或是一些小的變動，要經常發布修訂版，時間間隔不限，修復一個嚴重的bug即可發布一個修訂版。此版本號由項目經理決定是否修改。
     
   • 日期版本號(051021):用于記錄修改項目的當前日期，每天對項目的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
     
   • 希臘字母版本號(beta):此版本號用于標注當前版本的軟件處于哪個開發階段，當軟件進入到另一個階段時需要修改此版本號。此版本號由項目決定是否修改。

   
   
3. 文件命名規范
   
   　　文件名稱由四部分組成：第一部分為項目名稱，第二部分為文件的描述，第三部分為當前軟件的版本號，第四部分為文件階段標識加文件后綴，例如：項目外包平臺測試報告1.1.1.051021_beta_b.xls，此文件為項目外包平臺的測試報告文檔，版本號為：1.1.1.051021_beta。
   
   
   
   
   
   
   

   　　如果是同一版本同一階段的文件修改過兩次以上，則在階段標識后面加以數字標識，每次修改數字加1，項目外包平臺測試報告1.1.1.051021_beta_b1.xls
   
   　　當有多人同時提交同一份文件時，可以在階段標識的后面加入人名或縮寫來區別，例如：項目外包平臺測試報告1.1.1.051021_beta_b_LiuQi.xls。當此文件再次提交時也可以在人名或人名縮寫的后面加入序號來區別，例如：項目外包平臺測試報告1.1.1.051021_beta_b_LiuQi2.xls
   
   
4. 版本號的階段標識
   
   軟件的每個版本中包括11個階段，詳細階段描述如下：
   
   
   clearcase/" target="_blank" >cccccc>

   階段名稱	階段標識
   需求控制	a
   設計階段	b
   編碼階段	c
   單元測試	d
   單元測試修改	e
   集成測試	f
   集成測試修改	g
   系統測試	h
   系統測試修改	i
   驗收測試	j
   驗收測試修改	k

   
   

測試任務描述

　　在軟件的開發過程中每個版本都會經歷四次測試任務，分別為：單元測試、集成測試、系統測試、驗收測試，在這四次測試任務中，每次測試都有不同的測試方向和重點。

1. 單元測試
   
   　　單元測試是軟件開發過程中要進行的最基本的測試，屬于白盒測試范圍，一般情況下是在開發人員完成了某個單獨模塊的編碼之后做的測試。它的目的是檢查軟件編碼的正確性以及一些規范性測試，站在開發人員的角度上來查找軟件所存在的BUG并記錄下產生BUG的原因，以便開發人員進行修改。這樣可以在很大程度上減少集成以后而出現的BUG。
   
   　　一旦編碼完成，開發人員總是會迫切希望進行軟件的集成工作，這樣他們就能夠看到實際的系統開始啟動工作了。 這在外表上看來是一項明顯的進步，而象單元測試會推遲對整個系統進行合并這種真正有意思的工作啟動的時間。
   
   　　這種開發步驟中，真實意義上的進步被軟件合并后的外表上的進步取代了。系統能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug?，F實的開發中，沒有單元測試的軟件常常會導致這樣的結果，軟件甚至無法運行。更進一步的結果是大量的時間將被花費在本應該在單元測試里就完成的簡單Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會延長軟件集成為一個系統的時間， 而且當這個系統投入使用時也無法確保它能夠可靠運行。
   
   　　單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試應該是可重復的，無論是在軟件修改，或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟件系統的生命周期中進行，也就是說每個版本的開發都需要經過單元測試，這樣可以在以后的開發階段減少很多不必要的麻煩。
   
   　　單元測試的重點測試內容包括：源代碼測試、命名規范測試、需求完整性測試、頁面完整性測試、提示文本測試、頁面腳本測試等。
   
   
2. 集成測試
   
   　　集成測試也屬于白盒測試范圍，是在單元測試的基礎上將軟件的多個模塊或者系統前后臺合并之后進行的測試，也可以算是對單元測試修改進行的復審測試。在集成測試中可以彌補單元測試中沒有測試到的BUG，也可以檢查出單元測試沒法測試的功能，比如前后臺的集成之后的關聯功能，對于這些有關聯性功能的測試，單元測試中是無能為力的，必須依靠集成測試來保證功能的完整性和正確性。和系統測試相比較集成測試從程序結構出發，目的性、針對性更強，發現問題的效率高，較容易測試特殊的處理流程中存在的BUG。
   
   　　集成測試的重點測試內容包括：鏈接完整性測試、頁面完整性測試、數據和數據庫完整性測試、功能測試、壓力測試、安全性測試、頁面腳本測試、提示文本測試等。
   
   
3. 系統測試
   
   　　系統測試屬于黑盒測試范圍，是在系統集成測試修改完BUG之后進行的測試。從軟件工程和測試的分類來看：集成測試在系統測試之前就必須要進行完畢，只有集成測試完成了，才能保證相應的系統測試進行。也就是說，集成測試是系統測試的基礎。
   
   　　系統測試是針對整個產品的全面測試，既包含各模塊的驗證性測試和功能合理性測試，又包括對整個產品的可靠性、健壯性、安全性、UI合理性及各種性能參數的測試。
   
   　　系統測試的重點測試內容包括：鏈接完整性測試、UI合理性測試、命名規范測試、功能測試、壓力測試、頁面完整性測試、安裝測試、提示文本測試、游覽器測試等。
   
   
4. 驗收測試
   
   　　驗收測試屬于黑盒測試范圍，是對系統測試修改后的復審，這方面和集成測試有些類似，首先確認系統測試中的BUG已經按要求修改完成，然后檢測一下功能是否符合用戶的需求、文檔是否完整、有沒有前面測試中遺漏沒有測試出來的BUG。要說明的一點是，此處的驗收測試并非客戶驗收測試，這里沒有客戶參與測試，只有測試人員參與測試。驗收測試是開發結束或進入下一版本的標志性測試。
   
   　　驗收測試的重點測試內容包括：鏈接完整性測試、UI合理性測試、功能測試、壓力測試、頁面完整性測試、提示文本測試、瀏覽器測試、安裝測試。

測試工作流程圖

　　軟件在開發過程中共有五個版本，分別是Base版、Alpha版、Beta版、RC版、Release版，每個版本的開發中都需要經過上述四次測試，但是每個版本中各階段的測試重點是不一樣的，詳細的測試流程和重點請看下面各版本流程圖：

1. Base版各個測試階段流程圖
   
   
   
   
   
   
   
   [查看大圖]
   
   
   
   
2. Alpha版各個測試階段流程圖
   
   
   
   
   
   
   
   [查看大圖]
   
   
   
   
3. Beta版各個測試階段流程圖
   
   
   
   
   
   
   
   [查看大圖]
   
   
   
   
4. RC版各個測試階段流程圖
   
   
   
   
   
   
   
   [查看大圖]
   
   
   
5. Release版各個測試階段流程圖
   
   
   
   
   
   
   
   [查看大圖]

測試提交文檔

測試文檔使用方法

　　在測試的過程中測試人員會用到三張表，第一張表是“測試任務表”，這張表中記錄的是軟件在每個版本的每個階段中需要做的具體測試任務，如果測試中不確定需要做哪些測試，在這張表中可以查詢各個階段中所要進行的測試項。

　　還有兩張表是需要在相應測試階段來添寫的測試文檔，分別是“白盒缺陷測試報告”和“黑盒測試缺陷報告”兩張表。單元測試和集成測試屬于白盒測試范圍，需要添寫白盒缺陷測試報告；系統測試和驗收測試屬于黑盒測試范圍，需要添寫黑盒測試缺陷報告。

　　測試人員測試完成之后，需要把所添寫的缺陷測試報告按時提交給項目經理，由項目經理來安排具體人員進行修改和審核。

測試文檔下載

• 測試任務表
  
• 白盒缺陷測試報告
  
• 黑盒缺陷測試報告
  
  
  注：
  
  　　在每次的測試中測試人員需要按表中的要求進行添寫測試報告，然后由項目經理來分配給開發人員處理，開發人員修改完BUG之后再交由項目經理來分配給測試人進行修改后的復審，檢查前面測試出來的BUG是否已經修改完成，在此要特別說明的一點是：為了讓測試報告更方便查看，如果在復審過程中查出還有BUG沒有修改完或是根本沒有修改，則在復審描述中說明原因，然后把此處標注成新的BUG索引項指到新的BUG編號上，詳細情況請看下面截圖：
  
  
  

 

測試方法和方式

　　測試方式主要以手工測試為主，在條件允許的情況下使用自動化測試工具進行測試。

測試方法	測試覆蓋率	執行人員	描述
黑盒測試	100%	測試人員	功能測試或數據驅動測試
灰盒測試	10~20%	測試或開發人員	靜態的白盒測試或動態的黑盒測試
白盒測試	5%	開發人員	結構測試或邏輯驅動測試

　　說明：黑盒測試是依據用戶能看到的規格說明，即針對命令、信息、報表等用戶界面及體現他們的輸入數據與輸出數據之間的對應關系，特別是針對功能進行測試。主要由客戶或系統使用者完成執行黑盒測試。

黑盒測試覆蓋范圍:

• 測試用例覆蓋：測試的每一個用例都被測試過。
  
• 輸入覆蓋：測試過程中所輸入的數據或資料必須一再的試驗，如在程序安裝過程中輸入用戶名時，測試者必須反復輸入不同長度的中文、英文或數字等來做測試。
  
• 輸出覆蓋：測試過程中程序所產生的行為、反映及數據必須都一再的試驗，如不同情況的對話窗口的內容、運算結果數據等都必須反復地測試審核。
  

通過測試的標準

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

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

備選通過辦法：

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

 

實施建議

對于系統的一些實施建議：

• 對系統測試人員進行必要的培訓，提高他們的測試效率。
• 項目經理和測試小組根據項目的資源、時間等限制因素，設法合理地減少測試的工作量，例如減少“冗余或無效”的測試。

  
   

附錄一：缺陷分類

類 別	描 述
需求缺陷	1） 需求有誤 2） 需求邏輯錯誤 3） 需求不完備 4） 需求文檔描述問題 5） 需求更改
設計缺陷	功能的使用對用戶帶來不便及不符合行業標準的： 1） 設計不合理 2） 設計文檔描述問題 3） 設計變更帶來的問題
功能和性能缺陷	功能沒有達到需求的要求，或功能存在嚴重缺陷，系統在運行過程中存在性能瓶頸，或對系統性能有影響的功能： 1） 功能或性能有誤 2） 性能不完全 3） 功能不完全 4） 適應范圍有問題 5） 用戶信息和診斷信息有誤 6） 異常情況處理有誤 7） 其他功能錯誤
界面缺陷	系統上圖片、文字、按鈕等出現明顯錯誤
數據錯誤	訪問數據庫時出錯，得出的數據錯誤： 1） 數據定義數據結構錯誤 2） 數據存取及數據操作錯誤 3） 其它數據問題
結構缺陷	1） 控制流和控制順序錯 2） 處理錯
實現與編碼缺陷	1） 編碼錯誤 2） 違背編碼風格或標準 3） 文檔有誤 4） 其它實現的問題
系統結構缺陷	1） 操作系統引用或使用錯誤 2） 軟件結構錯誤 3） 恢復錯誤 4） 執行錯誤 5） 診斷錯誤 6） 分割覆蓋錯誤 7） 引用環境錯誤
測試設計與測試執行錯誤	1） 測試設計錯誤 2） 測試執行錯誤 3） 測試文檔有誤 4） 測試用例不充分 5） 其他測試錯誤
計算錯誤	數學結算錯誤
不同硬件設備所產生的錯誤	所產生的問題與硬件設備直接有關
其他錯誤	測試者檢查出來的且不包括在以上所有類型中的錯誤

附錄二：缺陷嚴重程度

類 別	描 述
1-致命	1）可能有災難性的后果，如造成系統崩潰，造成事故等 2） 程序無法運行
2-嚴重	產生錯誤的結果，導致系統不穩定的問題，運行時好時壞： 1）造成數據庫不穩定的錯誤 3）列在說明中的需求未在最終系統中實現 4）業務流程不正確
3-一般	不正確的，但不會影響系統穩定性的： 1） 過程調用或其它腳本錯誤 2） 系統刷新錯誤 3） 產生錯誤結果，如計算結果錯誤等 4） 功能的實現有問題。如在系統實現的界面上，一些可接受輸入的控件點擊后無作用，對數據庫的操作不能正確實現 5） 編碼時數據類型、長度定義錯誤的 6） 對用戶的使用有操作順序上的限制 7） 雖然正確性不受影響，但系統性能和響應時間受到影響
4-輕微	不正確的，但有使系統使用起來不太方便的錯誤： 1）系統的提示語不明確，不簡明 2）滾動條無效 3）可編輯區和不可編輯區不明顯 4）光標跳轉設置不好，鼠標（光標）定位錯誤 5）上下翻頁，首尾頁定位錯誤 6）界面不一致，或界面不正確 7）日期或時間初始值錯誤（起止日期、時間沒有限定） 8）按鈕或標簽上有拼寫錯誤的單詞、不正確的大小寫
5-建議	1） 容易給用戶誤解和岐議的提示 2） 界面需要改進的 3） 對有疑慮的文檔，提出修改建議

附錄三：優先級

類 別	描 述
1-立即修改完成（最高）	影響測試進度的BUG， 重大的功能缺陷BUG，需要及時處理的
2-下一個階段結束前必須修改完成	功能沒有達到需求的的BUG，設計上存在輕微缺陷的
3-產品推出前必須修改完成	系統上圖片、文字、按鈕、翻頁上有的BUG或建議
4-時間允許再進行修改	有缺陷，但不影響系統功能，只是系統使用起來不太方便
5-下個版本再修改（最低）	在此版本中不做修改，進入下一版本時再做修改
6-無法修改，不做處理	因為所要求的內容不合理，所以不做處理

附錄四：測試計劃審批意見

項目經理審批意見：           　　　　　　　　　　　　　　　　　　　　項目經理簽字： 　　　　　　　　　　　　　　　　　　　　　　　　日期：

后記：

　　軟件測試規范的目的是使測試報告易于閱讀和理解、易于PM對Bug的分配管理、易于開發人員處理測試中出現的Bug，而不是用過份的約束和絕對的限制來束縛測試人員的測試過程。標準是人定的，它并不是神圣不可侵犯的。所以，測試的規范是簡潔、完整和便于管理性的。而且這個規范需要在我們的實際工作當中繼續修改直到完善。