-
LoadUI用于WebService性能測試。
查看全部 -
軟件測試應該覆蓋到研發的方方面面
核心要素:質量,其他四個要素都是為質量所服務
人員:人是決定性因素,決定了技術,流程,以及資源的配置使用
技術:軟件測試技術 方法,使用的工具 技術是手段
流程:測試計劃 測試用例 測試的執行和報告 每個階段進入進出的標準 流程是對測試的一個規范的要求
資源:測試環境當中所需要的網絡環境 測試數據 測試周期 測試時間?
測試覆蓋率能夠有效的保證軟件質量,提升測試效率能更好的完成軟件測試
經過軟件測試能夠發現軟件當中存在的一些故障,并不能保證軟件就沒有故障
越多缺陷的模塊質量就越不好越需要重點關注
測試用例和測試方法需要不定期的評審和修改,來測試系統的不同部分,從而發現更多的缺陷
80%的時間或資源用在20%重點模塊,來達到測試效率和資源配置的最佳比例
針對測試不同的背景,測試活動的定義也是不同的
查看全部 -
軟件測試應該覆蓋到研發的方方面面
核心要素:質量,其他四個要素都是為質量所服務
人員:人是決定性因素,決定了技術,流程,以及資源的配置使用
技術:軟件測試技術 方法,使用的工具 技術是手段
流程:測試計劃 測試用例 測試的執行和報告 每個階段進入進出的標準 流程是對測試的一個規范的要求
資源:測試環境當中所需要的網絡環境 測試數據 測試周期 測試時間?
測試覆蓋率能夠有效的保證軟件質量,提升測試效率能更好的完成軟件測試
經過軟件測試能夠發現軟件當中存在的一些故障,并不能保證軟件就沒有故障
越多缺陷的模塊質量就越不好越需要重點關注
測試用例和測試方法需要不定期的評審和修改,來測試系統的不同部分,從而發現更多的缺陷
80%的時間或資源用在20%重點模塊,來達到測試效率和資源配置的最佳比例
針對測試不同的背景,測試活動的定義也是不同的
查看全部 -
軟件測試應該覆蓋到研發的方方面面
核心要素:質量,其他四個要素都是為質量所服務
人員:人是決定性因素,決定了技術,流程,以及資源的配置使用
技術:軟件測試技術 方法,使用的工具 技術是手段
流程:測試計劃 測試用例 測試的執行和報告 每個階段進入進出的標準 流程是對測試的一個規范的要求
資源:測試環境當中所需要的網絡環境 測試數據 測試周期 測試時間?
測試覆蓋率能夠有效的保證軟件質量,提升測試效率能更好的完成軟件測試
經過軟件測試能夠發現軟件當中存在的一些故障,并不能保證軟件就沒有故障
越多缺陷的模塊質量就越不好越需要重點關注
測試用例和測試方法需要不定期的評審和修改,來測試系統的不同部分,從而發現更多的缺陷
80%的時間或資源用在20%重點模塊,來達到測試效率和資源配置的最佳比例
針對測試不同的背景,測試活動的定義也是不同的
查看全部 -
軟件測試應該覆蓋到研發的方方面面
核心要素:質量,其他四個要素都是為質量所服務
人員:人是決定性因素,決定了技術,流程,以及資源的配置使用
技術:軟件測試技術 方法,使用的工具 技術是手段
流程:測試計劃 測試用例 測試的執行和報告 每個階段進入進出的標準 流程是對測試的一個規范的要求
資源:測試環境當中所需要的網絡環境 測試數據 測試周期 測試時間?
測試覆蓋率能夠有效的保證軟件質量,提升測試效率能更好的完成軟件測試
經過軟件測試能夠發現軟件當中存在的一些故障,并不能保證軟件就沒有故障
越多缺陷的模塊質量就越不好越需要重點關注
測試用例和測試方法需要不定期的評審和修改,來測試系統的不同部分,從而發現更多的缺陷
80%的時間或資源用在20%重點模塊,來達到測試效率和資源配置的最佳比例
針對測試不同的背景,測試活動的定義也是不同的
查看全部 -
軟件測試應該覆蓋到研發的方方面面
核心要素:質量,其他四個要素都是為質量所服務
人員:人是決定性因素,決定了技術,流程,以及資源的配置使用
技術:軟件測試技術 方法,使用的工具 技術是手段
流程:測試計劃 測試用例 測試的執行和報告 每個階段進入進出的標準 流程是對測試的一個規范的要求
資源:測試環境當中所需要的網絡環境 測試數據 測試周期 測試時間?
測試覆蓋率能夠有效的保證軟件質量,提升測試效率能更好的完成軟件測試
經過軟件測試能夠發現軟件當中存在的一些故障,并不能保證軟件就沒有故障
越多缺陷的模塊質量就越不好越需要重點關注
測試用例和測試方法需要不定期的評審和修改,來測試系統的不同部分,從而發現更多的缺陷
80%的時間或資源用在20%重點模塊,來達到測試效率和資源配置的最佳比例
針對測試不同的背景,測試活動的定義也是不同的
查看全部 -
軟件測試的分類:
一.按測試階段來分來:
單元測試:
對軟件中的最小可測試單元進行檢查和驗證。
單元測試的原則:
1)盡可能保證各個測試用例是相互獨立的。
2)一般由代碼的開發人員來實施,用以校驗所開發的代碼功能符合自己的設計要求。
集成測試:
集成測試的主要實施方案:
1)Big Bang
2)自頂向下
3)自頂向上
系統測試:
1)關注系統本身的使用
2)關注系統與其他相關系統間的連通
3)關注系統在不同使用壓力下的表現
4)關注系統在真實使用環境下的表現
驗收測試:
1)用戶驗收測試
2)運行驗收測試
3)合同和規范驗收測試
4)alpha測試
5)Beta測試
查看全部 -
軟件測試的分類:
一.按測試階段來分來:
單元測試:
對軟件中的最小可測試單元進行檢查和驗證。
單元測試的原則:
1)盡可能保證各個測試用例是相互獨立的。
2)一般由代碼的開發人員來實施,用以校驗所開發的代碼功能符合自己的設計要求。
集成測試:
集成測試的主要實施方案:
1)Big Bang
2)自頂向下
3)自頂向上
系統測試:
1)關注系統本身的使用
2)關注系統與其他相關系統間的連通
3)關注系統在不同使用壓力下的表現
4)關注系統在真實使用環境下的表現
驗收測試:
1)用戶驗收測試
2)運行驗收測試
3)合同和規范驗收測試
4)alpha測試
5)Beta測試
查看全部 -
軟件測試的分類:
一.按測試階段來分來:
單元測試:
對軟件中的最小可測試單元進行檢查和驗證。
單元測試的原則:
1)盡可能保證各個測試用例是相互獨立的。
2)一般由代碼的開發人員來實施,用以校驗所開發的代碼功能符合自己的設計要求。
集成測試:
集成測試的主要實施方案:
1)Big Bang
2)自頂向下
3)自頂向上
系統測試:
1)關注系統本身的使用
2)關注系統與其他相關系統間的連通
3)關注系統在不同使用壓力下的表現
4)關注系統在真實使用環境下的表現
驗收測試:
1)用戶驗收測試
2)運行驗收測試
3)合同和規范驗收測試
4)alpha測試
5)Beta測試
查看全部 -
黑盒測試? ?只測試功能 一般是界面、功能
優點1、操作簡單,不關注內部功能實現
2、貼近用戶使用角度
缺點1、測試覆蓋率低,一般只能覆蓋40%
2、黑盒的自動化測試,復用率較低,維護成本高(軟件迭代更新快)
黑盒測試主要測試內容
1、軟件 對需求 功能的實現
2、在接口上,輸入輸出? 是否達到預期
3、是否有數據結構錯誤/訪問錯誤
4、性能是否滿足要求
查看全部 -
軟件測試分類
黑盒? 白盒
靜態 動態
手工 自動
查看全部 -
軟件測試的定義:通過手動/自動的手段來運行/測量軟件系統的過程,檢驗軟件系統是否滿足規定的要求,并發現與預期結果之間的差異
軟件測試的對象:軟件需求、概要設計、詳細設計、運行環境、可運行程序、軟件源代碼
軟件測試的要素:質量、人員、資源、流程、技術
軟件測試的目標:提高測試覆蓋率、提高測試效率
軟件測試原則:1、測試可顯示缺陷的存在,但不能證明系統不存在缺陷
2、窮盡測試是不可能的,應設定及時終止的條件(bug數量控制)
3、測試應該盡早進行(測試應該盡早介入)
4、缺陷具備群集特性(bug集中在少數模塊當中)缺陷往往是由少數模塊引起的,重點關注發現bug多的模塊
5、測試的殺蟲劑悖論(測試用例更新)
6、測試的二八原則(與2類似)80%的時間用在20%的模塊測試中
7、測試活動依賴于測試背景(不同的測試場景不同)
查看全部 -
軟件測試所遵循的原則
1.測試顯示缺陷的存在,但不能證明系統不存在缺陷
2.窮盡測試是不可能的,應設定及時終止的條件
3.測試應該盡早進行
4.缺陷具備群集特性
5.測試的殺蟲劑悖論
6.測試的二八原則
查看全部 -
1972年 第一次舉行主題會議
查看全部 -
1)軟件本身的兼容性:主要是軟件的向后兼容,如軟件升級,以前版本的功能也能使用
2)不同平臺下的兼容性:如在Linux系統下的ubuntu、openSUSE等,進行平臺的兼容性測試
3)對不同的設備的兼容性:如32位、64位、如小型機、PC等
4)軟件的互操作性:如和一些主流應用的兼容,也就是說和大眾軟件互通,比如和微信、微博、QQ能適用,有時是很多網站的登錄。。。。
查看全部 -
敏捷測試:遵循敏捷宣言的測試實踐
敏捷宣言:個體與交互重于過程與工具;可用的軟件重于完備的文檔;客戶協作重于合同談判;響應變化重于遵循計劃
強調從客戶角度進行測試
重點關注迭代測試新功能,不強調測試階段
盡早測試,不間斷測試,具備條件即測試
強調持續反饋
預防缺陷重于發現缺陷
基于腳本的測試(ST/SBT)
探索式測試(ET):完全拋開測試腳本的測試。是一種測試風格、測試思維,而不是測試技術
ST:系統性強,容易管理、控制;設計在先,執行在后;主要驗證自己的思路;可預見性
ET:自由靈活;與ST互補;設計與執行并行;不斷與系統交互,帶著問題測試;學習的過程
探索式測試優點:更能激發測試人員的創造性和工作樂趣;增加發現新的或較深入缺陷的可能性;在較短時間內找到最多BUG以及對被測系統做出快速評估;有利于更加有效地實施自動化;更加適用于敏捷項目;減少了在簡單、繁復用例上的編寫時間
缺點:在測試管理上有局限性,較難協調和控制;對BUG的重復利用和重現(設計與執行并行)、對測試人員的測試技能和業務知識深度依賴較大;只能在被測系統完全可用前提下更有作用;生產率難定義;本身較難進行自動化
基于風險的測試(RBT):基于對軟件失效的風險評估,并以此指導測試技術、設計、執行、結果評價的軟件測試類型
風險:質量風險(軟件質量問題)、管理分析(人員、第三方問題)
風險級別 = 風險可能性*風險嚴重程度
基于模型的測試:對需求功能點建模
查看全部 -
按測試模型分類
瀑布模型、敏捷測試、基于腳本的測試、基于風險的測試、探索式測試
瀑布模型:
優點:強調需求、設計的作用;前一階段完成后,只需關注后續階段;為項目提供了按階段劃分的檢查點,里程碑清晰;文檔規范
缺點:難以適應需求的頻繁變化;項目周期的后期才能看到成果;強制的里程碑、完成時間點;文檔工作量大
V模型:
W模型:
X模型:
H模型:
查看全部 -
按測試手段分類:
黑盒測試、白盒測試(對象可見度)
靜態測試、動態測試(狀態)
手工測試、自動化測試(執行方式)
黑盒測試:只測試單元功能,測試輸入輸出,不考慮內部結構,用戶需求出發,事件驅動,關注功能
黑盒測試優點:容易實施;更貼近用戶視角
缺點:測試覆蓋率較低,一般只能覆蓋代碼量不到40%;針對黑盒的自動化測試復用率較低(黑盒關注功能),維護成本較高
主要關注:是否有不正確、遺漏的功能;能夠正確輸入輸出;是否有數據結構或外部信息訪問錯誤;性能是否滿足要求(黑盒測試主要用于系統測試)
主要設計方法:等價類劃分法、因果圖法、邊界值分析法、正交試驗分析法、流程分析法、錯誤推測法、狀態遷移圖法
白盒測試:又稱結構化測試,強調邏輯結構(主要邏輯單位:語句、條件、條件組合、分支、路徑)
白盒測試優點:迫使測試人員思考軟件實現,理解原理;可檢測代碼中每條分支和路徑;揭示隱藏在代碼中的錯誤;對代碼測試比較徹底
缺點:昂貴,工作量大;無法檢測代碼中遺漏的路徑和數據敏感性錯誤;不能直接驗證需求正確性
主要測試方法:代碼檢測法(代碼審查、走查)、靜態結構分析法、靜態質量度量法(構造質量度量模型)、邏輯覆蓋法(語句覆蓋、條件覆蓋、條件組合覆蓋。。。)、基本路徑測試法(程序控制流圖)
灰盒測試:介于黑盒測試、白盒測試之間,既關注輸入輸出,也關注內部結構
靜態測試:不執行被測程序,通過評審軟件文檔或代碼度量程序靜態復雜度,檢查軟件是否符合編程標準,發現程序不足,減少錯誤出現(互審、走查、會議)
動態測試:運行被測程序,檢查運行結果與預期結果差異,分析運行效率、正確性、健壯性
手工測試:由測試人員從用戶視角驗證軟件是否滿足設計要求,適用針對深度的測試和強調主觀判斷的測試(眾包測試、探索化測試)
自動化測試:使用單獨測試工具軟件控制測試的自動化執行以及對于其預期和結果進行自動檢查(單元測試、接口測試、性能測試)
手工測試與自動化測試優缺點:
手工測試:
優點:易發現缺陷,容易實施、創造性、靈活性
缺點:覆蓋量化難、重復測試效率低、不一致性、可靠性低、人力資源依賴
自動化測試:
優點:高效率、速度快、高復用性、覆蓋率容易度量、準確、可靠、不知疲勞
缺點:機械、發現缺陷率低、一次性投入較大
查看全部 -
軟件測試,就是找茬^_^
查看全部 -
手工測試 自動化測試
查看全部 -
本地化測試要點
部署測試要點
無障礙測試
查看全部 -
瀏覽器兼容性測試
前2個是模擬
后面是從代碼層面測試
查看全部 -
集成測試:各個單元模塊的接口 系統測試:軟件在系統中運行的情況查看全部
-
junit 單元測試 java代碼查看全部
舉報