软件测试 - 功能测试（缺陷管理+禅道使用）
生活随笔
收集整理的這篇文章主要介紹了
软件测试 - 功能测试（缺陷管理+禅道使用）
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
一、缺陷管理
1.缺陷概述
1.1?缺陷的定義 *
- 產品實現不滿足用戶需求
- 測試執行時，實際結果和預期結果不一致
什么是Bug ？
- 狹義概念：是指軟件程序的漏洞或缺陷
- 廣義概念：除此之外還包括測試工程師或用戶所發現和提出的軟件可改進的細節（增強性，建議性）、或與需求文檔存在差異的功能實現等
- 軟件的bug指的是軟件中（包括程序和文檔）不符合用戶需求的問題。
1.2 缺陷的判定標準 *
- ?未達到需求說明書指明的功能
- ?出現了需求說明書指明不應該出現的錯誤
- ?實現了需求說明書之外的功能 ?
- ?未達到需求說明書雖未明確提及但是應該實現的目標（如：性能要求等）? ??
- 用戶角度發現的各種問題與錯誤
- 缺陷產生的原因
- 需求文檔存在錯誤
- 需求變更
- 設計存在錯誤
- 代碼錯誤
- 缺陷產生的根本原因
- 需求變更
- 溝通不暢、信息不同步
- 軟件復雜
- 進度壓力
- 標題：? ? ? ?描述缺陷的基本信息，如（輸入密碼長度為5時，注冊成功）
- 前置條件：描述缺陷出現依賴的相關基礎條件，如（未注冊手機號）
- 復現步驟：測試用例里面的執行步驟
- 實際結果：執行被測試軟件過程中，系統給出的結果
- 預期結果：參照需求說明書，在測試用例中設計的預期結果
- 附件：? ? ? ?方便開發定位bug的關鍵信息，包含圖片、日志log等
- ID編號：? ?唯一
- 模塊：? ? ? ?根據產品進行具體的劃分，如登錄、注冊
- 缺陷狀態：表明缺陷處理進度
- 嚴重程度：從技術維度來衡量，bug的破壞力
- 優先級：? ?從業務的角度，決定bug修改的先后順序
- 缺陷類別：用于分類整理缺陷
- new：新建
- open：打開
- fix：已修復
- close：關閉
- reopen：重新打開
- reject：已拒絕
- postpone：延期
- 5-致命的
- 4-非常高
- 3-高
- 2-中
- 1-低
- 5-緊急的
- 4-非常高
- 3-高
- 2-中
- 1-低
優先級和嚴重程度的區別：
- + Priority is Business? ??【優先級是從公司運營角度 (人力配置，資金投入等方面考慮)】
- + Severity is Technical??【嚴重級別是從技術角度】
- - 優先級還要考慮團隊的工作進度，阻塞工作的缺陷，要優先解決
- - 考慮解決缺陷的能力，難度，風險
- + 最終優先級
- + 確定權：產品經理、項目經理等
- + 建議權：測試
- 功能錯誤
- UI界面錯誤
- 兼容性
- 易用性
- 改進建議
- 其他
2.缺陷管理
2.1 缺陷信息 *- 核心要素
- 標題：? ? ? ?描述缺陷的基本信息，如（輸入密碼長度為5時，注冊成功。）
- 前置條件：描述缺陷出現依賴的相關基礎條件，如（未注冊手機號）
- 復現步驟：測試用例里面的執行步驟
- 實際結果：執行被測試軟件過程中，系統給出的結果
- 預期結果：參照需求說明書，在測試用例中設計的預期結果
- 附件：? ? ? ?方便開發定位bug的關鍵信息，包含圖片、日志log等
- 基本要素
- ID編號：? ?唯一
- 模塊：? ? ? ?根據產品進行具體的劃分，如登錄、注冊
- 缺陷狀態：表明缺陷處理進度
- 嚴重程度：從技術維度來衡量，bug的破壞力
- 優先級：? ?從業務的角度，決定bug修改的先后順序
- 缺陷類別：用于分類整理缺陷
- 體現測試的一個專業性
- 多站在開發的角度去思考問題（換位思考）
- 可復現
- 唯一性
- 一個問題只提交一個bug記錄
- 標題：應保持簡短、準確，提供缺陷的本質信息
- 復現步驟：應包含如何使別人能夠很容易的復現該缺陷的完整步驟
- 實際結果：是執行復現步驟后軟件的現象和產生的行為
- 預期結果：通常需要列出期望的結果是什么
- 附件：對缺陷描述的補充說明
- 場景1：確認BUG解決
- 測試【new】==》開發【open】==》開發【fix】==》測試【close】
- 場景2：驗證未通過，缺陷仍存在
- 測試【new】==》開發【open】==》開發【fix】==》測試【reopen】
- 場景3：開發延期處理
- 測試【new】==》開發【open】==》開發【postpone】
- 場景4：拒絕處理
- 測試【new】==》開發【open】==》開發【reject】
- 嚴重程度
- 提交人
- 缺陷類型
- ......
Bug的生命周期：發現 --> 新建 --> 指派 --> 確認 --> 修復 --> 驗證 --> 關閉
二、禪道使用
1.禪道簡介
- 禪道是由青島易軟天創公司開發的一款項目管理軟件。
- 特點是將軟件研發中的產品管理，項目管理，質量管理三個核心流程融合在一套工具里面，是
- 一款軟件生命周期管理工具。
- 輕量級實現，部署簡單
- 開源，免費
基本流程如下：
- 1. 產品經理創建產品
- 2. 產品經理創建需求
- 3. 項目經理創建項目
- 4. 項目經理確定項目要做的需求
- 5. 項目經理分解任務，指派到人
- 6. 開發人員實現需求
- 7. 測試人員測試，提交bug
2.禪道安裝
網盤鏈接：https://pan.baidu.com/s/176ZGvOCyG51QmwyE3N40qg?
提取碼：4yjg
- 雙擊解壓ZenTaoPMS.9.8.3.win64.exe，壓縮到某一個分區的根目錄，比如F:(必須是根目錄)
- 解壓完成后會在f盤根目錄自動生成一個?xampp?的文件夾
(2).進入xampp文件夾，點擊?start.exe，打開禪道集成運行環境
- 如果電腦沒有安裝過VC運行環境時，會提示安裝VC++環境
- Windows一鍵安裝包的運行，需要安裝VC++環境，點擊yes即可安裝。
注意：電腦中的vc++環境版本過低過高都會造成安裝失敗
注意：需要取消勾選 啟用Apache用戶訪問驗證
- 安裝好后，點擊啟動禪道，會自動啟動Apache和MySQL的服務，
- 如果服務啟動失敗，可能是端口被占用，解決方案：
- 點擊服務-配置端口，勾選自動更改端口，也可以手動改端口
(3).修改數據庫密碼
- 首次打開，會提示數據庫密碼太弱，建議修改密碼。
- 會默認顯示一個密碼，你也可以自己設置一個密碼，點OK后數據庫密碼會自動修改。
- 也可以通過禪道控制面板中【密碼】-【數據庫密碼】查看或者修改密碼
(4).訪問禪道
- 訪問地址：http://ip地址:端口號/文件名
- 點擊【訪問禪道】，系統會自動會使用默認瀏覽器打開禪道訪問頁面
- 也可以自己打開瀏覽器輸入網址訪問??
(5).登錄禪道
- 超級管理員登錄禪道后，一鍵安裝包默認的賬號密碼是admin/123456。
? ?
- 系統會檢測密碼安全級別，提示修改弱口令密碼，按照提示修改即可。
? ?
3.禪道的使用
? ?禪道使用流程圖
- 在禪道項目管理軟件中，核心的角色有產品經理、項目經理、研發團隊和測試團隊四種角色。
- 修改之后，下次有新用戶登錄，就不再檢查密碼是否為弱口令密碼
?(2).修改密碼
? ? 安全驗證密碼為當前密碼（舊密碼）
2.組織設置?
(1).設置公司信息
(2).設置部門結構
添加部門：
添加子部門：
3.用戶設置
(1).單個添加用戶
?
?(2).批量添加用戶
3.2?產品經理使用禪道
產品經理登錄：1.添加產品
- 產品名稱和產品代號是必填項。其中產品代號可以理解為團隊內部約定俗稱的一個稱呼， 比如禪道的代號是zentao，可以是英文字母和數字的組合。
- 產品線：該產品屬于那一個產品線。比如禪道這個產品線，下面包含禪道專業版，禪道開源版，禪道企業版 。
- 產品負責人：負責整理需求，對需求進行解釋負責，制定發布計劃，驗收需求。
- 測試負責人：可以為某一個產品指定測試負責人，這樣當創建bug，而不知道由誰進行處理的時候，該產品的測試負責人會成為默認的負責人。
- 發布負責人：由這個角色負責創建發布。
- 產品類型：默認是正常的類型， 還可以選擇多分支（適用于客戶定制場景）和 多平臺（適用于跨平臺應用開發，比如iOS，安卓，pc端等）的產品。
- 訪問控制：可以設置產品的訪問權限，其中默認設置只要有產品視圖的訪問權限就可以訪問。 如果這個產品是私有產品，可以將其設置為私有項目，那么就只有項目團隊成員才可以訪問。 或者還可以設置白名單，指定某些分組里面的用戶可以訪問該產品。
2.添加產品模塊
3.創建產品計劃
4.創建產品需求
- 需求的標題和所屬模塊是必填項。
- 所屬計劃可以暫時保留為空。
- 需求審核那塊，選擇不需要審核，這樣新創建的需求狀態就是激活的。只有激活狀態的需求才能關聯到項目中，進行開發。
- 需求可以設置抄送給字段，這樣需求的變化都可以通過email的形式抄送給相關人員。
- 可以設置關鍵詞，這樣可以比較方便的通過關鍵詞進行檢索。
5.需求評審
- 在創建需求的時候，有一個"不需要評審"的復選框，如果選中該復選框的話，需求的創建是【激活】中的； 但大部分情況下面，需求還是需要評審的；
- 即使產品完全由一個人負責，也可以將一些不成熟的想法存為草稿，后續再進行處理。新增需求的評審流程 如下：
- 如果創建需求時，未勾選不需要評審，那么創建的需求為【草稿】狀態 ?
- 評審是一個線下的活動（開會），只在禪道中更新評審結果；
- 評審結果有以下3種
- 確認通過
- 有待明確
- 拒絕
- 如果選擇“確認通過”， 則需求的狀態改為“激活”，然后就可以關聯到項目中進行開發了；
- 如果選擇“有待明確”，會保持需求的草稿狀態，并將需求指派回需求的創建者頭上，由其繼續進行完善；
- 如果選擇了“拒絕”，則需要給出相應的拒絕原因，拒絕原因可以有：
- 由誰評審：是記錄的參與評審的人員名單，可以輸入用戶名來自動篩選。 一般來講需求評審可以是一個線下的評審會議，在禪道里面記錄下參與需求評審的人員即可。 然后指定一個參與了評審的用戶在線上修改需求的狀態即可，如產品經理。
3.3?項目經理使用禪道
項目經理登錄：
1.添加項目?
- 注意事項
- 項目代號是一種隱喻，也就是團隊內部可以互相了解和知曉；
- 團隊名稱，可以自己定義，比如叫做“禪道開發團隊”等等；
- 在添加項目的時候，可以選擇關聯與之相關的產品，以便后續進行需求的關聯；
- 項目可以控制它的訪問權限，分為默認、私有和自定義白名單三種。
?2.設置團隊
3.關聯需求
4.分解任務
單個分解：
- 需要將所有的任務都分解出來。這里面包括設計，開發，測試，美工，甚至包括購買機器，部署測試環境等等；
- 任務分解的粒度越小越好，比如幾個小時就可以完成；
- 如果一個任務需要多個人負責，繼續考慮將其拆分 事務型的任務可以批量指派，如要讓團隊的每一個人都寫個項目總結，可以選擇類型是事務，然后批量指派給所有人員；
- 任務的分配最好自由領取，調動大家積極性；
- 任務的分解最好由團隊共同完成，不要由項目經理一人包辦；
?批量分解：
3.4 開發使用禪道
開發人員登錄：
基本操作：指派、開始、工時、完成、關閉、編輯
1.領取任務
- 領取任務后，任務的狀態為“進行中”
2.創建版本
3.提交測試
- 負責人為本次測試的負責人。
- 可以指定這次測試預計起止的時間。
- 任務描述里面，可以注明此次測試需要注意的地方。
3.5 測試使用禪道?
1.BUG跟蹤 *
- 測試提交缺陷
- 開發解決缺陷
- 測試回歸驗證
- 確認修復，關閉缺陷
- 并未修復，激活缺陷，重新指派給開發解決
- 關閉后的缺陷再次出現，測試激活該缺陷
(1).測試人員提BUG
測試人員登錄：
(2).開發人員解決BUG
開發人員登錄：
(3).測試人員回歸測試
2.編寫用例?
在禪道工具中不常用該功能，因為很麻煩~
單個添加：
批量添加：
(1).導出模板
- 注意：編碼格式選擇 GBK（支持中文）
(2). 按照模板格式，編寫用例
(3).導入數據?
總結
以上是生活随笔為你收集整理的软件测试 - 功能测试（缺陷管理+禅道使用）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用mockjs生成随机手机号码
- 下一篇： Python学习：演练分组函数和聚合函数