一、禪道的介紹
（1）定義禪道是一個項目管理工具，也是一個bug管理工具，還是一個用例管理工具。
（2）作用：為了解決眾多企業在管理中出現混亂，無序的現象，開發出來
（3）來源：禪道屬易軟天川公司
（4 ）禪道是集于產品管理，項目管理，測試管理于一身，同時包含事務管理，組織管理8眾多功能，是中小企業管理的首先工具
（5）架構：bs架構
（6）項目管理工具：
禪道、jira/confluence(雞爪)，tapd（騰訊開發，敏捷開發）
（7）常用的用例管理工具：
禪道、testlink、test manage、飛蛾、test? rail
（8）常見的bug管理工具：
bugfree、bugzilla、禪道
（9）為什么我們要學習禪道？
因為禪道集于用例管理工具，缺陷管理工具，項目工具一身
（10）禪道的特點？
a、開源、免費
b、安裝簡單
c、功能齊全
==========================================================
二、禪道的安裝
1、下載安裝包
?2、點解解壓 ，安裝包的路徑不要中文，或路徑太長
?3、點擊安裝包
?4、
?5、
?6、點擊訪問禪道
?7、點擊開源版
?8、輸入賬號，密碼
?9、搭建好禪道
?==============================
三、禪道的使用
?1、登錄頁面
?2、禪道人員工作分布和安排
?3、創建用戶
（1）創建單個用戶
?
?（2）批量創建用戶
?（3）產品中：新增需求添加產品
求
?（4）維護模塊
?（5）產品中的計劃
（6）編輯需求
?（7）添加項目
?
（8）項目中添加團隊
?（9）測試：? 測試用例，bug
?（10）新建用例
?（11）導出用例
1\
?
2\導出數據
3\導出模板和數據
?（12）導入用例
?5、導入所有的用例
?（6）用例的執行
?（7）編輯用例
（1）
?（8）bug的提交
（一）、 bug包含的內容：
1、所屬產品
2、所屬項目
3、所屬模塊
4、影響版本
5、當前指派
6、bug類型
7、bug標題
8、bug嚴重級別
9、bug優先級
10、重現步驟
11、相關聯需求
（二）bug類型：
（1）代碼錯誤
（2）界面優化
（3）配置相關
（4）安裝部署
（5）安全相關
（6）性能問題
（7）標準規范
（8）測試腳本
（9）其他
（三）操作系統
?（四）瀏覽器類型
?（五）bug的編輯和提交內容
?（6）關聯用例提bug
?（7）測試中的bug直接題bug
?（8）批量添加bug
?（9）bug 報表
?（10）導出bug，生成bug清單
?（11）導出bug的數據
?（12）bug嚴重級別
bug等級：
1級bug?（致命bug）
2級bug（嚴重bug）
3級bug?（一般bug）
4級bug（建議性bug）
1級bug?（致命bug）
必須優先修改，在測試中較少出現，一旦出現應立即中止當前版本測試；
致命bug：
（1）常規操作引起的崩潰，死機，死循環，內存泄露，無法啟動，異常退出，嚴重花屏
（2）數據泄露，數據安全性問題，?如惡意攻擊造成賬戶密碼信息泄露
（3）涉及金錢，如支付類的軟件，金錢的計算
（4）導致無法測試的錯誤：如服務器報500
（5）功能實際與需求嚴重不符
2級bug?（嚴重bug）不影響其他功能測試的情況下可以進行版本測試
（1）重要功能不能實現如：微信不能聊天，或發朋友圈
（2）錯誤的波及面廣，影響其他重要功能實現（如系統刷新，數據不更新）
（3）非常規操作告知:崩潰，死機，死循環，比如：一個賬號，多區域，多設備登錄等
（4）外觀難以接受的缺陷（如：頁面失真，完全變形）
（5）密碼銘文顯示（需要脫敏）
（6）輕微的數據計算錯誤
3級bug?（一般bug）
測試工作中存在最多的，解決率關系版本的優化程度
（1）次要功能不能實現：如表情包，添加文字
（2）操作頁面錯誤
（3）查詢錯誤，數據顯示錯誤
（4）兼容性問題
4級bug（建議性bug）
測試初期較多，優先程度低，在測試后期出現較少，
（1）界面不規范?（如：風格，一半中文，一半英文）
（2）輔助說明描述不清
（3）日常描述實用專業術語不規范
（4）界面存在錯誤文字
（5）用戶體驗感不好
============================
優先級
bug的處理的時間
1級? ?表示立即處理
2級? 表示緊急處理??
3級? 表示正常處理
4級 表示有時間處理
=======================
重現步驟
步驟
操作的流程
結果
實際測試結果
期望
預期結果
=======================
關聯需求
工作中提交bug，一定要記得關聯需求
=======================
bug生命周期：
一、bug 解決的基本流程
1、基本流程
新建bug（測試）=====指派給開發（前后端開發，測試指派）=======解決bug（開發）======待驗證，（開發轉給測試)=======驗證bug（測試）====? 驗證通過==關閉bug（測試）
2、異常流程（驗證不通過情況）
新建bug（測試）=====指派給開發（前后端開發，測試指派）=======解決bug（開發）======待驗證，（開發轉給測試)=======驗證bug（測試）====驗證不通過===指派給開發（前后端開發，測試指派）=======解決bug（開發）======待驗證，直到驗證通過===關閉bug（測試）
3、異常流程（關閉bug后，激活bug）
新建bug（測試）=====指派給開發（前后端開發，測試指派）=======解決bug（開發）======待驗證，（開發轉給測試)=======驗證bug（測試）====? 驗證通過==關閉bug（測試）=======激活bug======指派開發======解決bug（開發）======待驗證，（開發轉給測試)=======驗證bug（測試）====? 驗證通過==關閉bug（測試）
在工作中已經提了bug，需要和對應的開發通知下，自己要跟進
============================================
面試題：
bug的解決方案：
（1）設計如此
（2）重復bug
（3）外包原因
（4）已解決（比較多）
（5）無法重現
（6）延期處理
（7)不予解決
?===========================
激活bug
?
?
?==================================
工作中你認為是bug？ 開發認為不是bug，你是如何處理
總結：三個方向：
（1）自我原因，檢查自己的測試過程或疏忽的問題，如：頁面404，服務未啟動，自己配置錯了等。
（2）開發原因：
a.你把報錯的圖片截取出來
b.把測試步驟記錄下來，重現bug步驟
c. 查看后臺的日志，把日志錯誤查找出來
d、在和開發進行溝通，說明原因；如果電話溝通不了，現場溝通，操作bug說明報錯。
e.如果開發還是不認，需要找開發經理，協調測試，請求其他開發輔助解決；
（3）既不是開發原因，也不是測試原因，是產品原因
與開發溝通，開發是按需求開發，測試是按需求測試，測試的時候發現測試不了，少了某個步驟或環節，測試不了，找到開發，開發不認。找產品確定功能點，是不是產品遺漏了，如果是產品少了需求，就要從產品通過郵件發送整個項目組，補上需求，給開發加上工期，測試在測試。
==========================================
工作中出現了偶現的bug如何處理？（剛剛有，現在沒有了）
偶現bug就是無法重現的bug：
解決方案‘：
1、先記錄重現步驟，和報錯的現象
2、在與開發交流，描述bug的現象，確認bug的嚴重程度；
3、盡量去重現或查看源代碼，查看邏輯是否有問題，讓開發修改
4、根據bug的嚴重程度，找測試經理確認：影響小，不影響版本，先記錄下，寫明原因，下一個版本解決或后期關注；如果影響大，找測試經理和開發經理協調修改
===================================
bug的狀態：
1、new?（新的）
2、assigned(已指派)
3、open（打開）
4、fixd（修復）
5、pending?reset（待再測）
6、close（已關閉）
7、reopen（再次打開）
8、pending?reject(拒絕)
9、rejected（被拒絕）
===================================
bug的狀態：
1、new?（新的）
2、assigned(已指派)
3、open（打開）
4、fixd（修復）
5、pending?reset（待再測）
6、close（已關閉）
7、reopen（再次打開）
8、pending?reject(拒絕)
9、rejected（被拒絕）
多頁簽的實現（Tab）)
