軟件測試規范如寫詩一樣有多重要?《論測試人員的自我修養》

      網友投稿 715 2025-04-01

      流程和規范,是控制軟件質量不可或缺的一種手段。在現在復雜的軟件產品開發流程中,任何一個環節如果沒有做好,其引發的質量風險就像地雷一樣,隨時可能被下游團隊引爆。


      下面是血淋淋的例子:

      搜狗某產品在進行通知欄消息下發時,沒有嚴格遵守“先測試環境,后線上環境”的驗證流程,直接將通知信息發布在線上環境,致使下發的通知存在異常無法打開落地頁的問題,最終導致市場推廣計劃告吹。

      搜狗某產品,開發沒有提交測試驗證,私自打包上線,致使上線的數據存在異常,導致用戶大面積出現崩潰問題,崩潰率成倍飆升。

      好了,現在開始正題。

      Bug管理規范

      bug提交規范

      Bug的報告要求描述內容清晰、簡介、易懂,讓用根據簡要描述就可以大致了解問題所在:

      在提交BUG時,提交人可根據提交BUG的緊急程度,選擇對應的“優先級”,同時建議開發人員在處理BUG的時候能夠根據優先級進行處理,優先級別較高的可以最先進行處理。

      在BUG詳細描述中,可在從BUG產生的前提條件、操作的步驟、實際結果、預期結果等方面進行描述:

      1. 前提條件: 有些BUG的產生是需要在一定條件下才會出現,例如瀏覽器、分辨率、Office版本等,所以就要求在描述時描述清楚前提條件;

      2. BUG的操作步驟: 詳細的、有次序的、每一步的操作步驟,包括輸入的數據,盡可能的重新操作的步驟;

      3. 實際結果: 指的我按照以上的操作步驟,最后得出的結果是什么, 例如我點擊“增加”按鈕后出現白頁,這就是實際結果;

      4. 預期結果: 指的我按照以上的操作步驟,我想要得到的結果是什么,例如我點擊“增加”按鈕想要得到的預期結果是提示我“增加成功”提示;

      5. 圖文描述: 在必要的情況下可上傳截圖并注釋文字,這樣更便于確認錯誤的表現形式和錯誤位置等。

      一般情況下,開發人員在提交BUG時,“分派人”可指定對應的處理人員,如果無法確定“分派人”,可分派給項目的負責人,然后由項目負責人進行二次分派給對應的開發人員進行處理。在分派時可以添加一些對應的批注信息。

      bug級別定義

      具體的優先級別有以下幾種

      致命問題(一級bug)

      致命問題: 不能完全滿足系統正常的功能操作要求,系統停止運行,系統的重要部件無法運行,系統崩潰或掛起等導致系統不能繼續運行。

      常規操作下因程序問題導致系統崩潰,迫使整個系統無法使用(其中非程序問題有:系統配置、數據結構變動、session超時、網絡中斷、人為變更數據庫中的數據、系統缺少相應文件或目錄等)。

      常規操作下因程序問題導致程序重啟、死機或非法退出。

      常規操作下系統出現死循環。

      數據丟失或異常。

      模塊間數據傳遞及取值錯誤(如:輸入A,預期結果應該是B,但實際結果不是B等)。

      流程輸出錯誤(包括業務流程和事件流程。如:輸入流程A,但實際流程處理中未能按A流程處理數據;點擊某按鈕,應跳轉增加頁面,結果跳轉成修改頁面等)。

      按照需求文檔,功能未在程序中體現出來,即系統無此功能(據項目經理及相關負責人確認此功能必須具備的);功能不符合用戶需求,功能實現不正確(由項目經理及相關負責人確認此功能必須具備的)。

      嚴重問題(二級bug)

      嚴重問題: 嚴重地影響系統要求或基本功能的實現,且沒有更正辦法(重新安裝或重新啟動該軟件不屬于更正辦法)。使系統不穩定、或破壞數據、或產生錯誤結果,或部分功能無法執行,而且是常規操作中經常發生或非常規操作中不可避免(不能用其他操作修復問題)的主要問題,系統無法滿足主要的業務要求,性能、功能或可用性嚴重降低。

      數據計算錯誤。

      因程序問題迫使正在操作的流程無法繼續且無其他操作可以修復問題的(其中非程序問題有:系統配置、數據結構變動、Session超時、網絡中斷、人為變更數據庫中的數據、系統缺少相應文件或目錄等)。

      常規操作下功能異常,如:結果與實際查詢條件不一致、頁面按鈕點擊沒反應等。

      功能項的某些項目(可為所有控件)使用無效(對系統非致命的)。

      因程序問題迫使正在操作的流程無法繼續且有其他操作可以修復問題的(其中非程序問題有:系統配置、數據結構變動、Session超時、網絡中斷、人為變更數據庫中的數據、系統缺少相應文件或目錄等)。

      多余功能,且該功能影響了程序的正常使用(需項目經理及相關負責人確認),如客戶名稱錄入項需要錄入漢字和英文,但程序限制了只能輸入漢字等。

      常規操作下,程序打印、導出的內容錯誤。

      在程序安裝配置無誤的情況下相關功能js報錯,且該功能影響業務流的正常進行。

      在1024*768分辨率下,頁面嚴重變形,使數據無法瀏覽。

      在Session超時,無友情頁面提示

      中級問題(三級bug)

      系統可以滿足業務要求,系統性能或響應時間變慢、產生錯誤的中間結果但不影響最終結果等影響有限的問題,另外,還包括系統健壯性方面的測試。

      對于一些重要數據的操作、重要環節的變動且相關的操作和變動不可挽回時,系統應給出相應的操作確認提示,防止誤操作,如數據刪除、審批等。

      常規操作下頁面跳轉至錯誤友情提示頁面,且操作其他模塊,程序可正常運行(其中非程序問題有:系統配置、數據結構變動、Session超時、網絡中斷、人為變更數據庫中的數據、系統缺少相應文件或目錄)。

      功能實現不完整,如刪除時沒有考慮數據關聯。

      因錯誤操作且因程序問題導致系統崩潰,迫使整個系統無法使用(其中非程序問題有:系統配置、數據結構變動、Session超時、網絡中斷、人為變更數據庫中的數據、系統缺少相應文件或目錄等)。

      數據添加、修改、查看界面中控件沒有一一對應或對應控件長度、格式、驗證性提示信息內容等不一致,但又不影響程序功能的進一步的操作(最終以需求規格說明書中內容規定為準)。

      響應時間較慢。(不可超過1分鐘)

      功能性建議。

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

      簡單的輸入限制未放在前臺進行控制。

      雖然正確性不受影響,但系統性能和響應時間受到影響。

      常規操作下,程序顯示、打印、導出的內容格式錯誤,如頁面變形、金額類數據未加貨幣符號等。

      在程序安裝配置無誤的情況下相關功能js報錯,且該功能不影響業務流的正常進行。

      頁面驗證提示信息位置或內容錯誤,如空值驗證對應位置或內容錯誤、提示對話框內容錯誤等(最終以需求規格說明書中內容規定為準)。

      在1024*768分辨率下,頁面變形,但不影響數據的瀏覽。

      輸入超長數據或特殊字符導致程序報黃頁或跳轉到友情提示頁面等影響程序進一步的操作(需跳轉友情頁面)。

      在Session超時(需友情頁面)、網絡中斷時,出現瀏覽器卡死、報黃頁等異常情況,且沒有對應的錯誤捕獲機制并給出友情提示。

      滾動條無效,但不影響數據的顯示與瀏覽。

      界面不規范,頁面表現形式、樣式與其他類似功能模塊不一致,且差異明顯的。

      必填項與非必填項應加以區別。

      輕微問題

      頁面表現建議。

      功能操作建議。

      非程序代碼導致黃頁(如:手動刪除、修改、增加數據庫中的數據;缺少相應的系統配置;項目缺少目錄或文件、因不明操作導致數據庫中數據不符合正常邏輯關系)。

      輔助說明字體大小、顏色明顯與頁面整體表現形式不協調或者文字描述不清楚。

      長時間操作未給用戶提示(不可超過1分鐘),但程序一直在正常運行的,沒有出現卡死等情況,如給出旋轉的loading圖標或程序后臺操作進度條或顯示進度百分比等。

      提示窗口文字未采用行業術語。

      可輸入區域和只讀區域沒有明顯的區分標志,如只讀區域置灰顯示等。

      鍵盤支持不好,如在可輸入多行的字段中不支持回車換行,輸入查詢條件后不支持回車觸發查詢。

      界面不能及時刷新,如需要重新執行查詢或加載頁面等(最終以需求規格說明書中內容為準)。

      不用說謝謝,請叫我紅領巾

      以上就是產品的測試規范,囊括了從需求到測試計劃、測試準備、測試執行、結果分析、上線準備、跟蹤測試到項目總結的整個流程,規范了產品測試流程。

      以上文檔是我從事測試行業多年以來,一些是自己親身實踐、一些是自己平時在各位牛人的博客、網頁、論壇中看到的覺得很有用的資料所以保存了下來,積累編制成測試規范文檔,希望能給大家在測試上帶來一些幫助。

      《軟件測試規范文檔》PDF電子書

      最后給大家分享一份最新開源的《軟件測試規范文檔》,里面的測試規范示例堪稱全網最全!并且基本通用。篇幅原因,下面以展示部分目錄及內容,完整PDF點擊我的學習、摸魚群免費下載

      產品測試規范綱要

      目 錄

      第一章 產品測試規范

      1.1 產品測試流程

      軟件測試規范如寫詩一樣有多重要?《論測試人員的自我修養》

      1.1.1 測試流程圖

      1.1.2 測試流程說明

      1.2 需求梳理

      1.2.1 需求梳理

      1.3 測試計劃

      1.3.1 測試工具選取

      1.3.2 測試人員分配

      1.3.3 測試業務場景選取

      1.3.4 測試環境梳理

      1.3.5 測試數據梳理

      1.4 測試準備

      1.4.1 代碼管理

      1.4.2 測試環境搭建

      1.4.3 測試數據腳本編寫

      1.5 測試用例編寫(功能測試框架)

      1.5.1 界面友好性測試

      1.5.2 功能測試

      1.5.3 業務流程測試(主要功能測試)

      1.5.4 鏈接測試

      1.5.5 容錯測試

      1.5.6 穩定性測試

      1.5.7 常規性能測試

      1.5.8 易用性測試

      1.5.9 兼容性測試

      1.6 測試執行

      1.6.1 接口自動化測試

      1.6.2 探索式測試

      1.6.3 傳統測試用例測試

      1.6.4 Bug跟蹤

      1.7 測試結果分析

      1.7.1 結果收集

      1.7.2 結果分析

      1.7.3 測試分析報告

      1.8 上線準備

      1.8.1 版本發布

      1.8.2 數據準備

      1.9 上線測試跟蹤

      1.9.1 跟蹤測試

      1.10 BUG預防體系

      1.10.1 web常見產品問題及預防

      1.10.2 app常見產品問題及預防(1)

      1.10.2 app常見產品問題及預防(2)

      1.11 BUG管理規范

      1.11.1 bug提交規范

      1.11.2 bug級別定義

      Java Python web前端 自動化測試

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:excel自動求積的教程(excel自動求積怎么弄)
      下一篇:Python大規模機器學習》 —2.4.5使用SGD
      相關文章
      亚洲AV无码码潮喷在线观看| 亚洲AV成人片无码网站| 亚洲乱妇熟女爽到高潮的片| 亚洲一区在线视频| 精品亚洲成a人片在线观看少妇| 亚洲五月午夜免费在线视频| 亚洲精品456播放| 全亚洲最新黄色特级网站 | 亚洲日本人成中文字幕| 亚洲av永久无码精品天堂久久| 精品亚洲成a人片在线观看| 91亚洲导航深夜福利| 久久亚洲AV无码精品色午夜麻豆| 亚洲成a人片77777老司机| 久久精品国产亚洲AV麻豆~| 久久噜噜噜久久亚洲va久| 亚洲AV日韩AV永久无码免下载| 亚洲Av无码精品色午夜| 在线观看国产一区亚洲bd| 亚洲av激情无码专区在线播放| 国产V亚洲V天堂无码| 亚洲成色999久久网站| 亚洲黄色在线视频| 亚洲人成在线播放| 亚洲高清视频在线| 久久亚洲中文无码咪咪爱| 国产成人亚洲综合在线| 亚洲人成网站18禁止一区 | 亚洲女同成人AⅤ人片在线观看| 亚洲一级Av无码毛片久久精品| 亚洲亚洲人成综合网络| 亚洲AV无码一区二区二三区入口| 亚洲精品线在线观看| 亚洲国产成人手机在线电影bd| 亚洲成人激情小说| 日韩亚洲综合精品国产| 亚洲色成人网站WWW永久| 亚洲人成电影福利在线播放| 亚洲最新黄色网址| 亚洲中文无码亚洲人成影院| 高清在线亚洲精品国产二区|