測試部門軟件測試規範

1. 概述

本規範是對項目軟件測試的一份指導性文件,對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準以及測試流程進行總體規範,以有效保證軟件產品的質量。

項目軟件測試是對軟件設計的一種控制手段,是對軟件產品質量的一種檢查和審覈手段,項目測試人員應按本規範要求對軟件進行檢查、測試。

2. 測試目標

(1)測試是爲了發現程序中的錯誤而執行程序的過程;

(2)好的測試用例是極可能發現迄今爲止尚未發現的錯誤的用例;

(3)成功的測試是發現了至今爲止尚未發現的錯誤的測試。

3. 軟件測試流程

無規矩不成方圓,做好項目就是做正確的事情,而正確地處理事情才能更好地提高效率。測試部門在接到一個新的項目後,需要按照以下五個流程逐步開展測試工作,該流程在實際的工作中,可根據實際情況進行補充和完善。

3.1. 測試參考文檔

在測試人員開展工作之後,需要藉助產品人員和開發人員提供的文檔,形式的文檔可以給測試工作帶來依據。具體參考文檔包括:產品需求說明書、產品設計原型、數據庫設計方案、開發部門代碼規範說明、開發人員(前端和後臺)任務分配表等。

3.2. 測試工作流程圖

測試工作的基本流程圖如下圖所示:

測試流程.png

4. 軟件測試方法

根據項目需要,目前主要進行的有功能測試和性能測試。現階段以功能測試爲主,而功能測試目前使用最多的測試方法有等價類劃分法、邊界值分析法和錯誤推測法。這三種都屬於最常用、最典型、也是最重要的黑盒測試方法。 其他的方法還會涉及到因果圖法、判定表法、正交分析法、場景法等。

4.1. 等價類劃分方法 

將所有可能的輸入數據劃分成若干個子集,在每個子集中,如果任意一個輸入數據對於揭露程序中潛在錯誤都具有同等效果,那麼這樣的子集就構成了一個等價類。後續只要從每個等價類中任意選取一個值進行測試,就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。

4.2. 邊界值分析方法

選取輸入、輸出的邊界值進行測試。因爲通常大量的軟件錯誤是發生在輸入或輸出範圍的邊界上,所以需要對邊界值進行重點測試,通常選取正好等於、剛剛大於或剛剛小於邊界的值作爲測試數據。從方法論上可以看出來,邊界值分析是對等價類劃分的補充,所以這兩種測試方法經常結合起來使用。   

4.3. 錯誤推測法

在很大程度上是憑經驗進行的,是憑人們對過去所作的測試工作結果的分析,對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。

示例:針對“用戶登錄”功能,基於等價類劃分和邊界值分析方法,我們設計的測試用例包括:

1. 輸入已註冊的用戶名和正確的密碼,驗證是否登錄成功;

2. 輸入已註冊的用戶名和不正確的密碼,驗證是否登錄失敗,並且提示信息正確;

3. 輸入未註冊的用戶名和任意密碼,驗證是否登錄失敗,並且提示信息正確;

4. 用戶名和密碼兩者都爲空,驗證是否登錄失敗,並且提示信息正確;

5. 用戶名和密碼兩者之一爲空,驗證是否登錄失敗,並且提示信息正確;

6. 如果登錄功能啓用了驗證碼功能,在用戶名和密碼正確的前提下,輸入正確的驗證碼,驗證是否登 錄成功;

7. 如果登錄功能啓用了驗證碼功能,在用戶名和密碼正確的前提下,輸入錯誤的驗證碼,驗證是否登 錄失敗,並且提示信息正確。

如果再加上錯誤推測法(因人而異),會再增加以下的測試用例:

1. 用戶名和密碼是否大小寫敏感;

2. 頁面上的密碼框是否加密顯示;

3. 後臺系統創建的用戶第一次登錄成功時,是否提示修改密碼;

4. 忘記用戶名和忘記密碼的功能是否可用;

5. 前端頁面是否根據設計要求限制用戶名和密碼長度;

6. 如果登錄功能需要驗證碼,點擊驗證碼圖片是否可以更換驗證碼,更換後的驗證碼是否可用;

7. 刷新頁面是否會刷新驗證碼;

8. 如果驗證碼具有時效性,需要分別驗證時效內和時效外驗證碼的有效性;

9. 用戶登錄成功但是會話超時後,繼續操作是否會重定向到用戶登錄界面;

10. 不同級別的用戶,比如管理員用戶和普通用戶,登錄系統後的權限是否正確;

11. 頁面默認焦點是否定位在用戶名的輸入框中;

12. 快捷鍵 Tab 和 Enter 等,是否可以正常使用。

5. 非功能性測試

一個質量過硬的軟件系統,除了顯式功能性需求以外,其他的非功能性需求即隱式功能性需求也是極其關鍵的。顯式功能性需求的含義從字面上就可以很好地理解,指的是軟件本身需要實現的具體功能。比如“正常用戶使用正確的用戶名和密碼可以成功登錄”、“非註冊用戶無法登錄”等,這都是屬於典型的顯式功能性需求描述。從軟件測試的維度來看,非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的測試用例設計中,我們完全沒有考慮對非功能性需求的測試,但這些往往是決定軟件質量的關鍵因素。

示例:我們來繼續完善“用戶登錄”的測試用例。

在安全性方面補充的測試用例包括:

1. 用戶密碼後臺存儲是否加密;

2. 用戶密碼在網絡傳輸過程中是否加密;

3. 密碼是否具有有效期,密碼有效期到期後,是否提示需要修改密碼;

4. 不登錄的情況下,在瀏覽器中直接輸入登錄後的URL地址,驗證是否會重新定向到用戶登錄界面;

5. 密碼輸入框是否不支持複製和粘貼;

6. 密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看;

7. 用戶名和密碼的輸入框中分別輸入典型的“SQL 注入***”字符串,驗證系統的返回頁面;

8. 用戶名和密碼的輸入框中分別輸入典型的“XSS 跨站腳本***”字符串,驗證系統行爲是否被篡 改;

9. 連續多次登錄失敗情況下,系統是否會阻止後續的嘗試以應對暴力破解;

10. 同一用戶在同一終端的多種瀏覽器上登錄,驗證登錄功能的互斥性是否符合設計預期;

11. 同一用戶先後在多臺終端的瀏覽器上登錄,驗證登錄是否具有互斥性。

站在性能壓力測試的角度測試用例包括:

1. 單用戶登錄的響應時間是否小於 3 秒;

2. 單用戶登錄時,後臺請求數量是否過多;

3. 高併發場景下用戶登錄的響應時間是否小於 5 秒;

4. 高併發場景下服務端的監控指標是否符合預期;

5. 高集合點併發場景下,是否存在資源死鎖和不合理的資源等待;

6. 長時間大量用戶連續登錄和登出,服務器端是否存在內存泄漏。

站在兼容性測試角度測試用例補充包括:

1. 不同瀏覽器下,驗證登錄頁面的顯示以及功能正確性;

2. 相同瀏覽器的不同版本下,驗證登錄頁面的顯示以及功能正確性;

3. 不同移動設備終端的不同瀏覽器下,驗證登錄頁面的顯示以及功能正確性;

4. 不同分辨率的界面下,驗證登錄頁面的顯示以及功能正確性。

對於高質量的軟件測試,用例設計不僅需要考慮明確的顯式功能性需求,還要涉及兼容性、安全性和性能等一系列的非功能性需求,這些非功能性需求對軟件系統的質量有着舉足輕重的作用。但軟件測試的用例設計是不可窮盡的,工程實踐中難免受制於時間成本和經濟成本,所以測試部門需要兼顧缺陷風險和研發成本之間的平衡。

6. 缺陷分類

根據缺陷的定義,將缺陷分爲如下4類:

 6.1文檔缺陷

指對文檔的靜態檢查過程中發現的缺陷。檢查活動包括同行評審、產品審計等。評審的缺陷要根據被評審對象的類型來確定,被評審的對象包括最終出產出物和中間過程產出物。比如產品需求文檔、原型設計文檔、測試計劃、測試用例等。

6.2代碼缺陷

指對代碼進行同行評審、審計或代碼走查過程中發現的缺陷。

6.3測試缺陷

指由測試活動發現的測試對象的缺陷,被測對象一般是指可運行的代碼、系統,不包括靜態測試發現的問題。

6.4過程缺陷

又叫做不符合項問題,是指通過過程審計、過程分析、管理評審、質量評估、質量審覈等活動發現的關於過程的缺陷和問題。過程缺陷的發現者一般是測試人員、項目經理等。

 

7 Bug的嚴重性定義

根據所提交bug的嚴重性,本規範定義以下五個級別。

A類:嚴重錯誤,包括以下各種錯誤:

(1)由於程序所引起的死機,非法退出。

(2)死循環

(3)數據庫發生死鎖

(4)因錯誤操作導致的程序中斷

(5)功能錯誤

(6)與數據庫連接錯誤

(7)數據通訊錯誤

B類:較嚴重錯誤,包括以下各種錯誤:

(1)程序錯誤

(2)程序接口錯誤

(3)數據庫的表、業務規則、缺省值未加完整性等約束條件

C類:一般性錯誤,包括以下各種錯誤:

(1)操作界面錯誤(包括數據窗口內列名定義、含義是否一致)

(2)打印內容、格式錯誤

(3)簡單的輸入限制未放在前臺進行控制

(4)刪除操作未給出提示

(5)數據庫表中有過多的空字段

D類:較小錯誤,包括以下各種錯誤:

(1)界面不規範

(2)輔助說明描述不清楚

(3)輸入輸出不規範

(4)長操作未給用戶提示

(5)提示窗口文字未採用行業術語

(6)可輸入區域和只讀區域沒有明顯的區分標誌

E類:測試建議

8. Bug的優先級定義

根據所提交bug的優先級,本規範定義以下五個級別。

1. Highest :表示問題必須馬上解決,否則系統根本無法達到預定的需求。

2. High:表示問題的修復很緊要,很急迫,關係到系統的主要功能模塊能否正常。

3. Medium:表示有時間就要馬上解決,否則系統偏離需求較大或預定功能不能正常實現。

4. Low:表示計劃解決,表示問題不影響需求的實現,但是影響其他使用方面,比如頁面調用出錯,調用了錯誤的等。

5. Lowest:即問題在系統發佈以前必須確認解決或確認可以不予解決。

9、測試標準

功能測試的通過準則一般有:

(1)單元功能同設計需求一致;

(2)規定的路徑覆蓋率及覆蓋類達到要求,且執行正確;

(3)所規定的黑盒測試手段被使用,且執行正確;

(4)對殘留錯誤有合法解釋或被認可暫留;

(5)雖然路徑覆蓋率不能達到,但其他各測試的錯誤查出率趨產0或穩定(時間的長短視情況而定)。

各類軟件測試合格須符合以下標準。

A類錯誤

B類錯誤

C類錯誤

D類錯誤

E類建議

<1%

<5%

暫不作要求

以上比例爲錯誤佔總測試模塊的比例。

軟件產品未經測試合格,不允許上線發佈。


更多精彩都在洋哥視頻課程學習地址http://edu.51cto.com/lecturer/5811414.html


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