中文字幕二区_国产精品免费在线观看_黄色网站观看_人人草人人澡_日本真实娇小xxxx

術(shù)語、名詞定義

1. 黑盒測試
   
   　　黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測試者把被測程序看成一個黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測試是在程序接口處進(jìn)行測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試是基于用戶角度進(jìn)行的測試。
   
   
2. 白盒測試
   
   　　軟件測試的主要方法之一，也稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的內(nèi)部結(jié)構(gòu)、算法等信息，這是從程序設(shè)計者的角度對程序進(jìn)行的測試。它的優(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)容。可理解性是指在文檔中描述的語言要簡明易懂，不能讓別的開發(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ì)量是否達(dá)標(biāo)，屬于檢查性測試。
   
   
9. UI合理性測試
   
   　　UI合理性測試也就是人機(jī)交互界面的合理性，UI合理性測試的內(nèi)容很多，具體測試內(nèi)容如下：
   
   
   • 提示、菜單、幫助的格式是否一致；
   • 提示、菜單、幫助中的術(shù)語是否一致；
   • 各個控件之間的對齊方式是否一致；
   • 輸入界面和輸出界面在外觀、布局、交互方式上是否一致；
   • 功能類似的相關(guān)界面在外觀、布局、交互方式上是否一致；
   • 同一層次的文字在同一種提示場合（一般情況、特殊字體、警告等）在文字大小、字體、顏色、對齊方式方面是否一致，字體大小 是否與界面的大小比例協(xié)調(diào)；
   • 多個連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致；
   • 系統(tǒng)是否拒絕客戶的錯誤輸入并做出提示；
   • 系統(tǒng)是否在用戶完成操作時給出操作成功的提示；
   • 用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；
   • 各個控件的間隔是否一致，垂直和水平方向上是否對齊；
   • 是否允許動作的可逆性，返回原有操做；
     
     
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沒有被測試出來。所以說在功能測試中要按部就班的把所有要進(jìn)行的測試功能每一步都執(zhí)行一遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以避免遺漏掉BUG沒有測試出來。
    
    
12. 壓力測試
    
    　　壓力測試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會變得不可接受。這通過改變應(yīng)用程序的輸入以對應(yīng)用程序施加越來越大的負(fù)載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負(fù)載測試，但是負(fù)載測試通常描述一種特定類型的壓力測試——增加用戶數(shù)量以對應(yīng)用程序進(jìn)行壓力測試。
    
    　　對應(yīng)用程序進(jìn)行壓力測試最簡單的方法是手工改變輸入（客戶機(jī)數(shù)量、需求大小、請求的頻率、請求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需要在大的范圍內(nèi)改變輸入，那么你可以借助一個自動化的壓力測試工具來完成此測試。
    
    
13. 安全性測試
    
    　　安全性測試主要是測試系統(tǒng)在沒有授權(quán)的內(nèi)部或者外部用戶對系統(tǒng)進(jìn)行攻擊或者惡意破壞時如何進(jìn)行處理，是否仍能保證數(shù)據(jù)和頁面的安全。測試人員可以學(xué)習(xí)一些黑客技術(shù)，來對系統(tǒng)進(jìn)行攻擊。 另外，對操作權(quán)限的測試也包含在安全性測試中。具體測試內(nèi)容如下：
    
    
    • 執(zhí)行添加、刪除、修改等動作中是否做過登錄檢測。
    • 退出系統(tǒng)之后的操作是否可以完成。
    • 所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲，特殊字符為：！?#￥%……—*（）~——-+=[]{}、|；：‘”？/《》<>，。
    • 在帶有參數(shù)的回顯數(shù)據(jù)的動作中更改參數(shù)，把參數(shù)改為特殊字符并加入操作語句看是否出錯。
    • 測試表單中有沒有做標(biāo)簽檢測，標(biāo)簽檢測是否完整。
    • 在插入表單中加入特殊的HTML代碼，例如：<marquee>表單中的字本是否移動？</marquee>。
      
      
14. 頁面腳本測試
    
    　　頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進(jìn)行測試。其主要內(nèi)容包括：相關(guān)頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。
    
    
15. 提示文本測試
    
    　　提示文本測試從嚴(yán)格意義上來講應(yīng)該屬于UI合理性測試的一部分，該項測試主要針對各個頁面中使用到的大量提示文檔進(jìn)行測試，主要包括：表達(dá)不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。
    
    
16. 瀏覽器測試
    
    　　由于B/S結(jié)構(gòu)項目是基于瀏覽器運行的，所以需要對瀏覽器進(jìn)行必要的測試。該測試任務(wù)主要是軟件對各種瀏覽器（IE5.5、IE6.0、 FireFox瀏覽器 ）的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。
    
    
17. 安裝測試
    
    　　在軟件項目的后期階段，會對做好的軟件進(jìn)行打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進(jìn)行安裝功能方面的測試。該測試的主要任務(wù)是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。
    
    
18. 自定義測試
    
    　　在常規(guī)測試時可能表中的測試項不能滿足測試要求，如果有特殊測試項請測試人員自己定義修改測試的類型。

返回導(dǎo)航

軟件命名規(guī)范

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

   

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

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

   　　如果是同一版本同一階段的文件修改過兩次以上，則在階段標(biāo)識后面加以數(shù)字標(biāo)識，每次修改數(shù)字加1，項目外包平臺測試報告1.1.1.051021_beta_b1.xls
   
   　　當(dāng)有多人同時提交同一份文件時，可以在階段標(biāo)識的后面加入人名或縮寫來區(qū)別，例如：項目外包平臺測試報告1.1.1.051021_beta_b_LiuQi.xls。當(dāng)此文件再次提交時也可以在人名或人名縮寫的后面加入序號來區(qū)別，例如：項目外包平臺測試報告1.1.1.051021_beta_b_LiuQi2.xls
   
   
4. 版本號的階段標(biāo)識
   
   軟件的每個版本中包括11個階段，詳細(xì)階段描述如下：
   
   

   階段名稱	階段標(biāo)識
   需求控制	a
   設(shè)計階段	b
   編碼階段	c
   單元測試	d
   單元測試修改	e
   集成測試	f
   集成測試修改	g
   系統(tǒng)測試	h
   系統(tǒng)測試修改	i
   驗收測試	j
   驗收測試修改	k

   
   

測試任務(wù)描述

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

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

返回導(dǎo)航

測試工作流程圖

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

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

測試提交文檔

測試文檔使用方法

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

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

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

測試文檔下載

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

返回導(dǎo)航

測試方法和方式

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

測試方法	測試覆蓋率	執(zhí)行人員	描述
黑盒測試	100%	測試人員	功能測試或數(shù)據(jù)驅(qū)動測試
灰盒測試	10~20%	測試或開發(fā)人員	靜態(tài)的白盒測試或動態(tài)的黑盒測試
白盒測試	5%	開發(fā)人員	結(jié)構(gòu)測試或邏輯驅(qū)動測試

　　說明：黑盒測試是依據(jù)用戶能看到的規(guī)格說明，即針對命令、信息、報表等用戶界面及體現(xiàn)他們的輸入數(shù)據(jù)與輸出數(shù)據(jù)之間的對應(yīng)關(guān)系，特別是針對功能進(jìn)行測試。主要由客戶或系統(tǒng)使用者完成執(zhí)行黑盒測試。

黑盒測試覆蓋范圍:

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

返回導(dǎo)航

通過測試的標(biāo)準(zhǔn)

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

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

備選通過辦法：

　　根據(jù)實際情況由項目經(jīng)理和測試負(fù)責(zé)人以及用戶等共同討論確定本階段是否結(jié)束。

返回導(dǎo)航

實施建議

對于系統(tǒng)的一些實施建議：

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

  
  返回導(dǎo)航

附錄一：缺陷分類

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

返回導(dǎo)航

附錄二：缺陷嚴(yán)重程度

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

返回導(dǎo)航

附錄三：優(yōu)先級

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

返回導(dǎo)航

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

項目經(jīng)理審批意見：           　　　　　　　　　　　　　　　　　　　　項目經(jīng)理簽字： 　　　　　　　　　　　　　　　　　　　　　　　　日期：

返回導(dǎo)航

后記：

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

 

動感體驗:

　　您是否愿意更多的了解NoahWeb？是否愿意全面深入的體會和了解NoahWeb？是否愿意參與到“真實”的開發(fā)團(tuán)隊中使用NoahWeb進(jìn)行實際的項目開發(fā)，在“實戰(zhàn)”中，與其他同仁組成的開發(fā)團(tuán)隊一起感受NoahWeb的魅力，點擊這里回答幾個簡單的問題，讓我們了解你的想法，讓我們帶給你更多精彩。