軟體測試需求分析:
1:什麼是軟體需求
測試需求主要解決"測什麼"的問題,一般 來自需求規格說明書中原始需求
測試需求應全部覆蓋已定義的業務流程,以及功能和非功能方面的需求
2:軟體需求的必要性
簡而言之:只有明確了測試需求,才知道怎麼去測試?什麼時候開始測試,要多少人測試,在什麼環境上測試?
3:如何進行軟體測試需求
測試需求分析的主要目的:依據需求文件提取測試點,根據測試點來編寫測試用例
測試點分析:(正面,反面)
—通過分析需求描述中的輸入,輸出,處理,限制,約束等,給出對應的驗證內容:(功能測試)
—通過分析各個功能模組之間的業務順序,和各個功能模組之間傳遞的資訊和資料,對存在功能互動的功能項,給出對應的驗證內容;(功能互動測試)
—考慮到需求的完整性,要充分覆蓋軟體需求的各種特徵,包含**需求的驗證,比如介面的驗證,註冊賬號的唯一性驗證(介面,易用性,相容性,安全性,效能壓力)
什麼叫軟體測試用例
定義:測試用例(testcase)是為專案需求而編制的一組測試輸入,執行條件以及預期結果,以便測試某個程式是否滿足客戶需求
可以總結為:每個測試點的資料設計和步驟設計
測試用例的設計方法：
軟體測試的核心編寫測試用例
基本原則：
準確性：明確測試的目標
經濟性：避免一些重複的或者是負責的步驟，資源占用
可復用性：盡可能的在類似的情況下重複使用
可追蹤性：必須追溯到需求
恰當性：對測試環境測試人員的要求恰當
完整性：考慮到各種情況
不依賴性：要求測試用例與測試人員無關
黑盒測試方法：
**1、等價類劃分法：**等價類劃分法是一種典型的、重要的黑盒方法，是指某個輸入域的子集合，在該子集合中所有的輸入資料對於揭露軟體中的錯誤都是等效的。
等價類劃分為有效等價和無效等價
**2、邊界值劃分法：**是對等價類劃分法的乙個補充，邊界值一般都是從等價類的邊緣值去尋找，邊界值分析的基本思想：正好等於，剛剛大於，剛剛小於邊界的值作為測試資料。0.01、200.01
注意：0是乙個特殊值，我們在考慮邊界值的時候同時也要考慮這個特殊值。負數
邊界值的作用：人們從長期的測試工作經驗得知，大量的錯誤是發生在輸入或者輸出範圍的邊界上，而不是在輸入範圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤！
**3.場景法：**通過場景描述的業務流程（業務邏輯），也包括**實現邏輯，設計用例來遍歷場景（路徑），驗證軟體系統功能的正確性
注意：場景法的重點是測試流程，因此每個流程乙個用例驗證即可，流程測試沒有問題並不能說明系統功能沒有問題了，還需要針對單步的功能進行測試，只有單個功能點和流程測試，才算是充分的測試。
**4.錯誤推測法:**在測試程式時，人們可以根據經驗或直覺推測程式中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。
**5.因果圖法:**分析程式規範的描述中哪些是原因,哪些是結果,原因常常是輸入條件或是輸入條件的等價類,結果是輸出條件
測試用例方法的選擇
使用各種測試方法的綜合策略:
首先進行等價類劃分,主要輸輸入條件的劃分,這是提高測試效率最有效的方法;
在任何情況下都必須使用邊界值分析法,這種方法設計出的測試用例發現程式錯誤的能力最強切記不要窮舉測試;
用錯誤推測法追加測試用例,這需要測試工程師的經驗總結;
對照程式邏輯,檢查已設計出的測試用例的邏輯覆蓋程度,如果沒有大袋覆蓋標準,應當再補充足夠的測試用例(場景法)
測試用例的八大要素:測試用例評審的流程:
1.評審材料準備好(主要是測試用例,評審檢查清單)
2.提前(2天)發布評審通知(oa通知,郵件,或者討論組發布資訊).同樣將評審材料傳送給評審成員,以節約溝通成本
主要的參與評審人員:專案經理,測試負責人,測試人員,產品經理,開發人員;
3.召開會議評審:針對評審用例檢查清單,評審過程中收集相關人員的反饋資訊(即問題記錄清單),並在此基礎上進行測試用例更新.直到評審通過
4.評審結束後,測試負責人處測試用例評審報告給到相關人員,評審結果經專案經理同意確認
bug等級:
可以劃分為三四五級別
（1）致命錯誤
1、常規操作引起的系統奔潰、宕機、死迴圈
2、造成資料洩露的安全性問題，比如惡意攻擊造成的賬戶私密資訊洩露
3、涉及金錢計算
4、阻斷性測試，所有測試工作進行不下去
（2）嚴重錯誤
1、重要功能不能實現
2、錯誤的波及面廣，影響到其它重要功能正常實現；功能互動
3、非常規操作導致的程式奔潰,宕機,死迴圈
4、外觀(介面)難以接受的缺陷
5、密碼明文顯示(介面+資料庫)
（3）一般錯誤
不影響產品的執行,不會成為故障起因,但對產品外觀和下道工序影響較大的缺陷
1、次要功能不能正常實現
2、操作介面錯誤(包括資料視窗內列名定義,含義不一致)
3、查詢錯誤,資料錯誤顯示
4、簡單的輸入限制未放在前端進行控制(格式限制)長度
5、刪除操作未給出提示
（4）細微錯誤
程式在一些顯示上不美觀,不符合使用者習慣,或者是一些文字的錯誤
1、介面不規範
2、輔助說明描述不清楚
3、提示視窗文字未採用行業術語
4、介面存在文字錯誤
改進建議:可以提高產品質量的建議,包括新需求和對需求的改進
bug的生命週期:
新建–指派(開發,測試老大,開發經理)–待修復–已解決–待驗–關閉
如果待驗的bug在驗證時沒有解決好,我們需要重新開啟(啟用)–指派–待修復–已解決–待驗,迴圈這個過程
中間其他狀態:拒絕,延期等
如何提交bug:
1、常規操作引起的系統奔潰、宕機、死迴圈
2、造成資料洩露的安全性問題，比如惡意攻擊造成的賬戶私密資訊洩露
3、涉及金錢計算
4、阻斷性測試，所有測試工作進行不下去
（2）嚴重錯誤
1、重要功能不能實現
2、錯誤的波及面廣，影響到其它重要功能正常實現；功能互動
3、非常規操作導致的程式奔潰,宕機,死迴圈
4、外觀(介面)難以接受的缺陷
5、密碼明文顯示(介面+資料庫)
（3）一般錯誤
不影響產品的執行,不會成為故障起因,但對產品外觀和下道工序影響較大的缺陷
1、次要功能不能正常實現
2、操作介面錯誤(包括資料視窗內列名定義,含義不一致)
3、查詢錯誤,資料錯誤顯示
4、簡單的輸入限制未放在前端進行控制(格式限制)長度
5、刪除操作未給出提示
（4）細微錯誤
程式在一些顯示上不美觀,不符合使用者習慣,或者是一些文字的錯誤
1、介面不規範
2、輔助說明描述不清楚
3、提示視窗文字未採用行業術語
4、介面存在文字錯誤
改進建議:可以提高產品質量的建議,包括新需求和對需求的改進
bug的生命週期:
新建–指派(開發,測試老大,開發經理)–待修復–已解決–待驗–關閉
如果待驗的bug在驗證時沒有解決好,我們需要重新開啟(啟用)–指派–待修復–已解決–待驗,迴圈這個過程
中間其他狀態:拒絕,延期等
如何提交bug:重現步驟:詳細寫下發現bug的測試過程.能指導開發重現這個bug,附上測試資料
實際結果:出現bug的結果,貼上bug截圖,日誌截圖
預期結果:寫清楚預期結果
bug型別和嚴重程度:便於後續測試結果分析,bug的統計
bug型別和嚴重程度:便於後續測試結果分析,bug的統計
軟體測試基礎 軟體測試概要
1.歷史上由軟體bug引發的重大事故 因此，軟體質量是非常重要的，而軟體測試作為軟體質量保證重要的組成部分，在軟體研發中有著重要的地位，是不可或缺的一環。2.什麼是測試？ieee定義 iso iec ieee 29119 使用人工或自動的手段來執行或測量軟體系統的過程，以檢驗軟體系統是否滿足規定的要...
軟體測試理論基礎總結 三
應當把 盡早和不斷的測試 作為開發者的座右銘 程式設計師應該避免檢查自己的程式，測試工作應該由獨立的專業的軟體測試機構來完成 設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況下要製造極端狀態和意外狀態，比如網路異常中斷 電源斷電等情況 一定要注意測試中的錯誤集中發生現象，這...
軟體測試基礎
功能測試 主要是黑盒測試，也稱行為測試 只考慮各個功能，不考慮整個軟體的內部結構及 一般從軟體產品的介面 架構出發 按照需求編寫出來的測試用例，輸入資料在預期結果和實際結果之間進行評測，進而提出使產品更加符合使用者使用的要求。包括邊界值測試 找到邊界，然後在其邊界及其邊界附近選點 健壯性測試 最壞情...