--用例由哪些元素組成?
標題,優先順序,預置條件、編號、預期結果,操作步驟
--用例設計方法
涉及引數校驗;頁面字段;輸入資料。等價類(類:代表值),邊界值(是等價類的補充),正交表,錯誤推斷,判定表,場景法(業務流程圖,模組流程圖,覆蓋流程,使用者角度的流程),因果圖,如何發散思維
--設計好的測試用例,吃透需求分析,知道使用者想要什麼樣的產品。
思路清晰,盡可能發散,按照類別來分類,從整體到區域性。用例規範,
--用例需要評審,專案組測試工程師(內審),(外審)開發:產品師開發做的,最有評審資格。
測試目的的唯一性
測試目的明確性
測試目的簡潔性
搭建測試環境事項
根據環境搭建文件: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 呼叫記錄按呼叫時間順...