--用例由哪些元素組成？
標題，優先順序，預置條件、編號、預期結果，操作步驟
--用例設計方法
涉及引數校驗；頁面字段；輸入資料。等價類（類：代表值），邊界值（是等價類的補充），正交表，錯誤推斷，判定表，場景法（業務流程圖，模組流程圖，覆蓋流程，使用者角度的流程），因果圖，如何發散思維
--設計好的測試用例，吃透需求分析，知道使用者想要什麼樣的產品。
思路清晰，盡可能發散，按照類別來分類，從整體到區域性。用例規範，
--用例需要評審，專案組測試工程師（內審），（外審）開發：產品師開發做的，最有評審資格。
測試目的的唯一性
測試目的明確性
測試目的簡潔性
搭建測試環境事項
根據環境搭建文件：db，伺服器，**包（mt.war）。svn工具進行資源共享
--開發和測試的環境分開
注意前提條件和特殊說明
測試用例要全部執行
不要忽視任何偶然現象（閃退）
加強測試過程記錄
提交缺陷時與開發的關係處理
及時更新測試用例
缺陷產生原因
需求，設計，編碼，其他
追蹤**
（二八定理）
抗藥性-》交叉測試
--並非所有的缺陷都要修復
1.修復的風險太大
2.沒有足夠的時間
3.下一版本修復
--所有未修復的bug都出於「掛起」狀態
缺陷包含要素
bugid
bug標題
附件-》抓包/日照/
復現步驟
路徑指派給/抄送給 開發
狀態--new --open --fixed --rejected
--reopen --closed --deferred --assigned open --hangs
new->open->fixed->closed
fixed->reopen->fixed
注意：不同的bug管理工具，bug狀態定義不同。
如禪道：啟用、已解決、
--嚴重程度
致命：軟體無法執行，或者軟體的主要功能喪失，或者很大可能性會造成嚴重不良後果。（不會發現致命bug）
嚴重：軟體的次要功能喪失，或者主要功能在一些特定情況下會出錯，比如金額計算等。（業務/流程/功能缺失：10%-15%）
一般：軟體在某些情況下會出錯，但是造成的後果影響不大。
輕微：在某些情況下會出錯，但是造成的後果影響很小（提示資訊/使用者體驗/建議）
--優先順序
注釋測試報告包含哪些內容？
3.1.1資料統計
3.1.2遺留bug情況
3.1.3測試風險
3.1.4測試物件評估
3.1.5測試結論
問題--測試過程中有哪些輸入/輸出件?(參考資料/交付件)
參考資料：
《使用者需求說明書》《概要設計說明書》《詳細設計說明書》《使用者手冊》等
交付件：
《測試計畫》《測試用例》《bug清單》《測試報告》
--測試的啟動條件/什麼時候可以開始測試？
1.測試用例已寫完並評審
2.測試環境已經準備好
--測試什麼時候可以結束/版本達到公司上線的標準是什麼？
1.測試用例已執行完成，100%的覆蓋到需求
2.所有bug基本已得到解決，除非遺留幾個比較輕微不影響使用者使用的bug
3.經過幾輪測試後，版本質量已穩定，達到公司上線標準
4.測試計畫包含哪些內容？
評審給你提過哪些問題：有些場景沒有覆蓋到，煙的條和煙的包
5.用例評審，將流程細化分解為功能點，通過用例一一覆蓋
6.具體情況具體分析，用例背景，專案階段
測試用例設計經驗
專注乙個點的測試
發散思維
把握關鍵點
日期三條用例：昨天，今天，未來
日期過渡太長。普通情況不測試
時間有限，抓住重點
附件：兩條用例，限制條件測試用例
冒煙：借還款
下拉框：第一條，最後一條，中間一條
金融一一測試
測試用例（四）測試用例編寫
一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來，但它不是從乙個等價類中任選乙個例子作為代表，而是...
手機測試用例 STK測試用例
id 功能描述 操作步驟 預期結果 test time p fcomment tester test time p fcomment tester stk服務 sim卡適應性測試 1 選取支援stk功能的sim卡，插入手機中 手機應支援stk功能，會將stk選單自動加入主選單列表中 2 進入stk功...
手機測試用例 通話測試用例
id 功能描述 操作步驟 預期結果 test time p fcomment tester test time p fcomment tester 通話功能 快速檢視已撥 1 待機介面下按一下呼叫鍵可進入已撥 記錄 2 每次呼叫記錄都應正確無誤 號碼 時間 序號 通話時長等 3 呼叫記錄按呼叫時間順...