1. 概述

本規(guī)范是對項目軟件測試的一份指導性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準以及測試流程進行總體規(guī)范，以有效保證軟件產(chǎn)品的質(zhì)量。

項目軟件測試是對軟件設計的一種控制手段，是對軟件產(chǎn)品質(zhì)量的一種檢查和審核手段，項目測試人員應按本規(guī)范要求對軟件進行檢查、測試。

2. 測試目標

（1）測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；

（2）好的測試用例是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的用例；

（3）成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。

3. 軟件測試流程

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

創(chuàng)新互聯(lián)建站服務項目包括邢臺網(wǎng)站建設、邢臺網(wǎng)站制作、邢臺網(wǎng)頁制作以及邢臺網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，邢臺網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到邢臺省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

3.1. 測試參考文檔

在測試人員開展工作之后，需要借助產(chǎn)品人員和開發(fā)人員提供的文檔，形式的文檔可以給測試工作帶來依據(jù)。具體參考文檔包括：產(chǎn)品需求說明書、產(chǎn)品設計原型、數(shù)據(jù)庫設計方案、開發(fā)部門代碼規(guī)范說明、開發(fā)人員（前端和后臺）任務分配表等。

3.2. 測試工作流程圖

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

4. 軟件測試方法

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

4.1. 等價類劃分方法　

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

4.2. 邊界值分析方法

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

4.3. 錯誤推測法

在很大程度上是憑經(jīng)驗進行的，是憑人們對過去所作的測試工作結果的分析，對所揭示的缺陷的規(guī)律性作直覺的推測來發(fā)現(xiàn)缺陷的。

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

1.輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功；

2.輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，并且提示信息正確；

3.輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，并且提示信息正確；

4.用戶名和密碼兩者都為空，驗證是否登錄失敗，并且提示信息正確；

5.用戶名和密碼兩者之一為空，驗證是否登錄失敗，并且提示信息正確；

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

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

如果再加上錯誤推測法（因人而異），會再增加以下的測試用例：

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

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

3.后臺系統(tǒng)創(chuàng)建的用戶第一次登錄成功時，是否提示修改密碼；

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

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

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

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

8.如果驗證碼具有時效性，需要分別驗證時效內(nèi)和時效外驗證碼的有效性；

9.用戶登錄成功但是會話超時后，繼續(xù)操作是否會重定向到用戶登錄界面；

10.不同級別的用戶，比如管理員用戶和普通用戶，登錄系統(tǒng)后的權限是否正確；

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

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

5. 非功能性測試

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

示例：我們來繼續(xù)完善“用戶登錄”的測試用例。

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

1.用戶密碼后臺存儲是否加密；

2.用戶密碼在網(wǎng)絡傳輸過程中是否加密；

3.密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；

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

5.密碼輸入框是否不支持復制和粘貼；

6.密碼輸入框內(nèi)輸入的密碼是否都可以在頁面源碼模式下被查看；

7.用戶名和密碼的輸入框中分別輸入典型的“SQL 注入***”字符串，驗證系統(tǒng)的返回頁面；

8.用戶名和密碼的輸入框中分別輸入典型的“XSS 跨站腳本***”字符串，驗證系統(tǒng)行為是否被篡 改；

9.連續(xù)多次登錄失敗情況下，系統(tǒng)是否會阻止后續(xù)的嘗試以應對暴力破解；

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

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

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

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

2.單用戶登錄時，后臺請求數(shù)量是否過多；

3.高并發(fā)場景下用戶登錄的響應時間是否小于 5 秒；

4.高并發(fā)場景下服務端的監(jiān)控指標是否符合預期；

5.高集合點并發(fā)場景下，是否存在資源死鎖和不合理的資源等待；

6.長時間大量用戶連續(xù)登錄和登出，服務器端是否存在內(nèi)存泄漏。

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

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

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

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

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

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

6. 缺陷分類

根據(jù)缺陷的定義，將缺陷分為如下4類:

 6.1文檔缺陷

指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定，被評審的對象包括最終出產(chǎn)出物和中間過程產(chǎn)出物。比如產(chǎn)品需求文檔、原型設計文檔、測試計劃、測試用例等。

6.2代碼缺陷

指對代碼進行同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷。

6.3測試缺陷

指由測試活動發(fā)現(xiàn)的測試對象的缺陷，被測對象一般是指可運行的代碼、系統(tǒng)，不包括靜態(tài)測試發(fā)現(xiàn)的問題。

6.4過程缺陷

又叫做不符合項問題，是指通過過程審計、過程分析、管理評審、質(zhì)量評估、質(zhì)量審核等活動發(fā)現(xiàn)的關于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試人員、項目經(jīng)理等。

 

7 Bug的嚴重性定義

根據(jù)所提交bug的嚴重性，本規(guī)范定義以下五個級別。

A類：嚴重錯誤，包括以下各種錯誤：

（1）由于程序所引起的死機，非法退出。

（2）死循環(huán)

（3）數(shù)據(jù)庫發(fā)生死鎖

（4）因錯誤操作導致的程序中斷

（5）功能錯誤

（6）與數(shù)據(jù)庫連接錯誤

（7）數(shù)據(jù)通訊錯誤

B類：較嚴重錯誤，包括以下各種錯誤：

（1）程序錯誤

（2）程序接口錯誤

（3）數(shù)據(jù)庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件

C類：一般性錯誤，包括以下各種錯誤：

（1）操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）

（2）打印內(nèi)容、格式錯誤

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

（4）刪除操作未給出提示

（5）數(shù)據(jù)庫表中有過多的空字段

D類：較小錯誤，包括以下各種錯誤：

（1）界面不規(guī)范

（2）輔助說明描述不清楚

（3）輸入輸出不規(guī)范

（4）長操作未給用戶提示

（5）提示窗口文字未采用行業(yè)術語

（6）可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志

E類：測試建議

8. Bug的優(yōu)先級定義

根據(jù)所提交bug的優(yōu)先級，本規(guī)范定義以下五個級別。

1. Highest：表示問題必須馬上解決，否則系統(tǒng)根本無法達到預定的需求。

2. High：表示問題的修復很緊要，很急迫，關系到系統(tǒng)的主要功能模塊能否正常。

3. Medium：表示有時間就要馬上解決，否則系統(tǒng)偏離需求較大或預定功能不能正常實現(xiàn)。

4. Low：表示計劃解決，表示問題不影響需求的實現(xiàn)，但是影響其他使用方面，比如頁面調(diào)用出錯，調(diào)用了錯誤的等。

5. Lowest：即問題在系統(tǒng)發(fā)布以前必須確認解決或確認可以不予解決。

9、測試標準

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

（1）單元功能同設計需求一致；

（2）規(guī)定的路徑覆蓋率及覆蓋類達到要求，且執(zhí)行正確；

（3）所規(guī)定的黑盒測試手段被使用，且執(zhí)行正確；

（4）對殘留錯誤有合法解釋或被認可暫留；

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

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

A類錯誤	B類錯誤	C類錯誤	D類錯誤	E類建議
無	無	<1%	<5%	暫不作要求

以上比例為錯誤占總測試模塊的比例。

軟件產(chǎn)品未經(jīng)測試合格，不允許上線發(fā)布。

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

文章名稱：測試部門軟件測試規(guī)范
本文URL：http://chinadenli.net/article42/gioihc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設、微信公眾號、關鍵詞優(yōu)化、面包屑導航、外貿(mào)建站、標簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)