一、測試用例
1. 編寫好的測試用例的要素？
(1) 規范編寫每一條測試用例（大家都能看得懂）
(2) 測試點覆蓋盡可能的全面
2. 如何保證測試用例的覆蓋全面性？
(1) 需求100%全面覆蓋
(2) 測試人員熟練綜合使用測試用例設計方法，設計盡可能多的測試點
(3) 開展用例評審，查漏補缺
3. 如何展開用例評審？
(1) 參與人員：需求人員、開發人員（不負責看覆蓋全面，而是用例是否合理）、測試經理、高級測試工程師
(2) 開展用例評審會議的流程
a) 會議前，提前確定會議時間和地點，郵件的形式將被評用例文檔發送給所有參會人員；
b) 會議中，如期開展會議，會議中，由被評者講解自己的測試用例，其他參會人員提出自己的意見，做好記錄
c) 會議后，根據意見修改測試用例，提交終稿
4. 一條測試用例包括那些要素？（8要素）
(1) 用例編號：用於唯一標識每一條測試用例
a) 項目代號-模塊名-序列號
b) bbjz-login-001
c) bbjz-zhichu-001
(2) 測試模塊
a) 一級模塊 一級模塊-二級模塊
b) 登錄 支出-增加支出
(3) 用例標題
a) 標題盡量簡潔，只寫關鍵測試點
b) 標題盡量不重復，每一條用例覆蓋不同的測試點，每個標題寫明具體的測試點
(4) 重要級別（優先級）
a) 用於決定用例的執行順序
b) 用例的優先級根據模塊的重要程度進行划分，可分成高、中、低
(5) 預置條件，第一個步驟完成的
(6) 操作步驟
(7) 測試輸入
(8) 預期結果
二、缺陷報告
1. 缺陷的管理工具
(1) 禪道
(2) Bugfree
(3) Bugzilla
(4) Jira
(5) QC
2. 禪道的搭建（網站的搭建）
在服務器端完成操作：
(1) 安裝web服務，如apache，用於監聽http請求
(2) 安裝數據庫，如mysql，用於存儲數據
(3) 安裝語言解釋器，如php組件，用於解釋語言
(4) 將網站的源代碼文件夾復制到htdocs下
(5) 打開瀏覽器，輸入：http://localhost/zentaopms/www
用戶端訪問：http://服務器IP地址 /zentaopms/www
方案一：安裝一款集成工具XAMPP，集成了Apache、mysql和php組件
XAMPP=Apache+mysql+php組件
方案二：分別下載Apache、mysql和php組件，單獨進行安裝
3. 缺陷報告的要素（以禪道為例）
(1) 缺陷編號
(2) 所屬產品
(3) 所屬模塊
(4) 所屬版本
(5) 當前指派
(a) 情況一：測試人員--測試經理--開發人員--測試人員
(b) 情況二：測試人員--開發人員--測試人員
(c) 情況三：測試人員--開發經理--開發人員--測試人員
(d) 情況四：測試人員--測試經理--開發經理--開發人員--測試人員
(6) Bug類型
(7) 測試環境
(a) 操作系統+瀏覽器（用戶端的環境）
(8) 嚴重程度：禪道中缺陷的嚴重程度划分如下
(a) p1：致命，導致系統閃退、無響應、崩潰、失效、造成用戶經濟損失等問題
(b) p2：嚴重，核心業務模塊功能出現問題，或者bug影響其他模塊的功能
(c) p3：一般，業務模塊功能出現問題
(d) p4：較小，輕微的bug，如界面問題，錯別字等
(9) 優先級
決定bug的處理順序
(a) P1：緊急處理
(b) P2：優先處理
(c) P3：正常排隊
(d) P4：推遲處理
缺陷嚴重程度越高，優先級一般越高（並非一定越高）
(10) 缺陷的標題
模板：在xx操作時，關鍵測試點，實際結果
例1：在增加賬戶轉賬時，轉出賬戶為空，增加成功
例2：在增加賬戶轉賬時，轉賬金額為負數，增加成功
例3：在登錄時，輸入正確的用戶名后加空格，登錄失敗
例4：在添加系統用戶時，輸入重復用戶名，增加成功
(11) 缺陷的詳細描述
(a) 預置條件
(b) 復現步驟
(c) 預期結果
(d) 實際結果
【預置條件】
1、登錄成功（測試帳號：笨笨媽，999）
【復現步驟】
1、登陸后的首頁中，點擊左側欄中的【賬戶轉賬】鏈接
2、點擊【增加】
3、轉出賬戶為空
4、其他輸入項合法：
（1）轉賬時間：2020-7-29
（2）轉入賬戶：信用卡
（3）轉賬金額：1000
（4）其他項默認
5、點擊【保存】按鈕
6、彈出的提示框中，點擊【確定】按鈕
【實際結果】
保存成功
【預期結果】
保存失敗，並給出友好提示
(12) 缺陷的狀態
(13) 創建人和創建時間
(14) 解決人和解決時間
(15) 解決方案
(16) Bug截圖附件
補充：一個正常缺陷的處理流程（缺陷的生命周期）
(1) 測試人員提交缺陷，分配給測試經理，狀態為激活（未確認）
(2) 測試經理審核缺陷，分配給開發人員，狀態為激活（已確認）
(3) 開發人員解決缺陷，分配給測試人員，狀態為已解決
(4) 測試人員驗證缺陷，若缺陷若缺陷修復正確，關閉缺陷，若缺陷修復不正確，則重新激活，再次分配給開發人員。
補充：禪道中缺陷的狀態？
(1) 激活
(2) 已解決
(3) 關閉
補充：禪道中，缺陷的解決方案
(1) 設計如此
(2) 重復bug
(3) 外部原因
(4) 已解決
(5) 無法重現
(6) 延期處理
(7) 不予解決
補充面試題：工作中，遇到無法復現的缺陷，你該如何處理？
（1）工作中養成遇到缺陷立刻截圖的習慣，遇到無法復現的缺陷時，我會嘗試在不同的瀏覽器、不同的操作系統、使用不同的數據，分析代碼和日志文件，盡量復現該bug
（2）復現bug消耗時長2小時后，若依然未復現，則暫停復現bug工作，先完成當日的分內工作
（3）利用中午休息時間，下班時間盡力再次復現缺陷，若未復現，則告知測試經理和開發人員協助解決。
補充面試題：延遲處理的缺陷如何處理？
（1）測試人員確認該缺陷是否可以延遲處理（與測試經理商討），若同意延遲處理，則與開發人員確認延遲時間，並在備忘錄中記錄，延遲時間到達后，在禪道中將缺陷重新激活，分給開發人員進行處理；若不同意延遲處理，則直接在禪道中將缺陷重新激活，分給開發人員進行處理。
補充面試題：當一個Bug在測試環境可以重現，但是在開發環境不能重現時，可能的原因有？
（1）測試環境中被測版本滯后
（2）測試人員與開發人員使用了不同的瀏覽器
（3）測試人員與開發人員使用了不同的操作系統
（4）測試人員與開發人員使用了不同的配置
（5）測試人員與開發人員是用了不同的數據
補充面試題：工作中，你提交的缺陷，開發不認可，你該如何處理？
（1）自己在不同的環境下，使用不同的數據多次復現缺陷，多分析缺陷產生的原因及不修復可能造成的影響
（2）找到開發人員進行溝通，盡力意見達成一致（注意溝通時間和技巧）
（3）若開發人員依然不認可，則找到測試經理協助解決
補充面試題：一條高質量的缺陷需要考慮的要素：
（1）缺陷的標題能概括缺陷的核心內容
（2）缺陷的描述及步驟完整
（3）明確指明缺陷嚴重等級和優先級等級
補充面試題：軟件通過測試，可以發布的標准是：
（1）完成了測試計划中規定的各個環節
（2）各階段的輸出均達到項目要求，如測試計划，方案，用例，缺陷報告，總結等
（3）測試對需求的覆蓋率達到100%
（4）驗收測試通過
開發人員可以提交缺陷嗎？ 不可以
開發人員可以關閉缺陷嗎？ 不可以
測試人員可以關閉未處理的缺陷 嗎？ 不可以
測試人員可以引用別人的缺陷嗎？可以