B/S軟件開發測試規範_試行1.1.0604 (收錄於網絡,供學習用,如果侵犯了你們版權請與本人聯繫)

B/S軟件開發測試規範_試行1.1.0604


編者按:

  軟件測試是軟件項目開發過程中不可忽視的重要組成部分,是保證項目實施進度與實施質量的重要手段。

  完全依靠開發人員或測試人員自身的素質決定着軟件效果的時代已經不復存在。但是,由於B/S行業團隊與機構分散,不同的行業團隊中對於B/S開發中測試方式、測試方法、測試內容、測試結果的描述等又各有差異,因此在團隊內部人員或是團隊與團隊之間協作時,測試完全處於無序狀態,爲了避免以上問題,解決各種歧義、杜絕測試人員由於自身素質導致的測試質量問題,我們需要一套完整的B/S測試規範。

  B/S軟件測試規範的作用是使B/S測試過程更加標準化,以便於B/S軟件開發過程的管理,同時也使開發的過程更加規範化。B/S軟件測試規範可使測試報告嚴謹、可讀性強且責任清楚,語言約定相一致,並且儘可能的直觀。通過統一的標準使得團隊可以按照相同的習慣去工作,目前該規範從我們的項目經驗中整理,並在對規範1.0.06規範實施半年後整理爲1.1.0604_試行版本,在該期《領航人》中同各位分享。在此也希望得到更多行業團隊對於該規範的使用,並且也非常希望能有更多的行業團隊或是機構能共同參與一起發展後續版本的制訂。如有更多的興趣可發送郵件至[email protected]與我們聯繫。

  在本期月刊中,我們將詳細介紹“B/S軟件開發測試規範_試行1.1.0604”,希望對各位在軟件測試的理解和學習方面能有所幫助。

 

段落導航:

   爲了方便大家的閱讀,我們將本期內容進行了合理的分類,您可以使用下面的鏈接瀏覽您感興趣的主題。  

 

適用對象和範圍


  主要適用對象爲軟件管理人員、軟件開發人員、軟件測試人員以及軟件維護人員。

 

返回導航


什麼是軟件測試

  爲了保證軟件的質量和可靠性,應力求在分析、設計等各個開發階段結束前,對軟件進行嚴格技術評審。但由於人們能力的侷限性,審查不能發現所有的錯誤。而且在編碼階段還會引進大量的錯誤。這些錯誤和缺陷如果遺留到軟件交付投入運行之時,終將會暴露出來。但到那時,不僅改正這些錯誤的代價更高,而且往往造成很惡劣的後果。

  軟件測試就是在軟件投入運行前,對軟件需求分析、設計規格說明和編碼的最終複審,是軟件質量保證的關鍵步驟。如果給軟件測試下定義,可以這樣講:軟件測試是爲了發現錯誤而執行程序的過程。或者說,軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計的一批測試用例(即輸入一些數據而得到其預期的結果),並利用這些測試用例去運行程序,以發現程序錯誤的過程。

  軟件測試在軟件生存期中橫跨兩個階段:通常在編寫出每一個模塊之後就對它做必要的測試(稱爲單元測試)。編碼與單元測試屬於軟件生存期中的同一個階段。在結束這個階段之後,對軟件系統還要進行各種終合測試,這是軟件生存期的另一個階段,即測試階段,通常由專門的測試人員承擔這項工作。

  大量統計資料表明,軟件測試的工作量往往佔軟件開發總工作量的40%以上,在極端情況,測試那種關係人的生命安全的軟件所花費的成本,可能相當於軟件工程其他開發步驟總成本的三倍到五倍。因此,必須高度重視軟件測試工作,絕不要以爲寫出程序之後軟件開發工作就接近完成了,實際上,大約還有同樣多的開發工作量需要完成。僅就測試而言,它的目標是發現軟件中的錯誤,但是,發現錯誤並不是我們的最終目的。軟件工程的根本目標是開發出高質量的完全符合用戶需要的軟件。

返回導航


軟件測試的目的

  基於不同的立場,存在着兩種完全不同的測試目的。從用戶的角度出發,普遍希望通過軟件測試暴露出軟件中陷藏的錯誤和缺陷,以考慮是否可以接受該產品。而從軟件開發者的角度出發,則希望測試成爲表明軟件產品中不存在錯誤的過程,驗證該軟件已正確地實現了用戶的要求,確立用戶對軟件質量的信心。

  因爲在程序中往往存在着許多預料不到的問題,可能會被疏漏,許多隱藏的錯誤只有在特定的環境下才可能暴露出來。如果不把着眼點放在儘可能查找錯誤這樣一個基礎上,這些隱藏的錯誤和缺陷就查不出來,會遺留到運行階段中去。如果站在用戶的角度替他們設想,就應當把測試活動的目標對準揭露程序中存在的錯誤。在選取測試用例時,考慮那些易於發現程序錯誤的數據。

下面這些規則也可以看作是測試的目的或定義:

  1. 測試是爲了發現程序中的錯誤而執行程序的過程;
  2. 好的測試方案是極可能發現迄今爲止尚未發現的錯誤的測試方案;
  3. 成功的測試是發現了至今爲止尚未發現的錯誤的測試。

  從上述規則可以看出,測試的正確定義是“爲了發現程序中的錯誤而執行程序的過程”。這和某些人通常想象的“測試是爲了表明程序是正確的”,“成功的測試是沒有發現錯誤的測試”等等是完全相反的。正確認識測試的目標是十分重要的,測試目標決定了測試方案的設計。如果爲了表明程序是正確的而進行測試,就會設計一些不易暴露錯誤的測試方案;相反,如果測試是爲了發現程序中的錯誤,就會力求設計出最能暴露錯誤的測試方案。

  由於測試的目標是暴露程序中的錯誤,從心理學角度看,由程序的編寫者自己進行測試是不恰當的。因此,在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外,應該認識到測試決不能證明程序是正確的。即使經過了最嚴格的測試之後,仍然可能還有沒被發現的錯誤潛藏在程序中。測試只能查找出程序中的錯誤,不能證明程序中沒有錯誤。

 


術語、名詞定義

  1. 黑盒測試

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

  2. 白盒測試

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

  3. 灰盒測試

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

  4. 文檔測試

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

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

  5. 命名規範測試

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

  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不會以單詞形式出現在軟件封面上,取而代之的是符號(R)。

版本命名規範

  軟件版本號由四部分組成,第一個1爲主版本號,第二個1爲子版本號,第三個1爲階段版本號,第四部分爲日期版本號加希臘字母版本號,希臘字母版本號共有5種,分別爲:base、alpha、beta、RC、release。例如:1.1.1.051021_beta。 



版本號定修改規則:

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

文件命名規範

  文件名稱由四部分組成:第一部分爲項目名稱,第二部分爲文件的描述,第三部分爲當前軟件的版本號,第四部分爲文件階段標識加文件後綴,例如:項目外包平臺測試報告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

版本號的階段標識

軟件的每個版本中包括11個階段,詳細階段描述如下: 

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


測試任務描述

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

  1. 單元測試

      單元測試是軟件開發過程中要進行的最基本的測試,屬於白盒測試範圍,一般情況下是在開發人員完成了某個單獨模塊的編碼之後做的測試。它的目的是檢查軟件編碼的正確性以及一些規範性測試,站在開發人員的角度上來查找軟件所存在的BUG並記錄下產生BUG的原因,以便開發人員進行修改。這樣可以在很大程度上減少集成以後而出現的BUG。

      一旦編碼完成,開發人員總是會迫切希望進行軟件的集成工作,這樣他們就能夠看到實際的系統開始啓動工作了。 這在外表上看來是一項明顯的進步,而象單元測試會推遲對整個系統進行合併這種真正有意思的工作啓動的時間。

      這種開發步驟中,真實意義上的進步被軟件合併後的外表上的進步取代了。系統能夠正常工作的可能性是很小的,更多的情況是充滿了各式各樣的Bug。現實的開發中,沒有單元測試的軟件常常會導致這樣的結果,軟件甚至無法運行。更進一步的結果是大量的時間將被花費在本應該在單元測試裏就完成的簡單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,而不是用過份的約束和絕對的限制來束縛測試人員的測試過程。標準是人定的,它並不是神聖不可侵犯的。所以,測試的規範是簡潔、完整和便於管理性的。而且這個規範需要在我們的實際工作當中繼續修改直到完善。

 


動感體驗:

  您是否願意更多的瞭解NoahWeb?是否願意全面深入的體會和了解NoahWeb?是否願意參與到“真實”的開發團隊中使用NoahWeb進行實際的項目開發,在“實戰”中,與其他同仁組成的開發團隊一起感受NoahWeb的魅力,點擊這裏回答幾個簡單的問題,讓我們瞭解你的想法,讓我們帶給你更多精彩。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章